#207 Unique reference for each screen/form/report.

v1.4
closed
nobody
5
2014-09-21
2011-11-20
No

For easier to refer to different parts of LedgerSMB it would be wise to have a unique reference for each screen / form / report.
We my call it something like <application part id>.

We can make it small, almost invisible, in the lower right corner. (perhaps only visible via javascript text url in screens)

Reason 1 : Improve bug reporting, feature request and support request. (Be sure that we all talk about the same thing..)
Reason 2 : Direct linking of choices - simpler to use.

Extra addon to this:
Search for <application part id> and show the click path. (click able with links, to the part you need to start in the application, to reach the screen / form / report.)

Search <application part id>
Return: (application click path..)
System -> Chart of Accounts -> List Accounts (Select one account nr from list) -> Edit account

In the example above. All levels to "List Accounts (Select one account nr from list)" could be hyper linked, so you could go direct to the choice.
Screens like "Edit account" could be linked to in to ways.
1) show a search page before you show "Edit account" to select the right account.
2) show "Edit account" with the first account in the list.

Addon to this:
Make it possible to link tho the <application part id> in your browser and in a personal bookmark list for each user. This list could be a part of a LedgerSMB dashboard / personal menu"

Discussion

  • Chris Travers

    Chris Travers - 2012-02-06

    Long-run this is a requirement. Short-run it may not be possible due to what we've inherited from SL.

     
  • Erik Huelsmann

    Erik Huelsmann - 2013-12-08
    • summary: Enhanc. req: Unique reference for each screen/form/report. --> Unique reference for each screen/form/report.
     
  • Erik Huelsmann

    Erik Huelsmann - 2013-12-28
    • status: open --> pending
    • Group: v1.3.0 --> v1.4
     
  • Chris Travers

    Chris Travers - 2014-09-21

    This is already the case of reports. I think we should go and close this, accepting it as a requirement in future work.

    Basically new code in 1.4 largely uses this approach. With luck new code in 1.5 will use it for a lot more.

     
  • Chris Travers

    Chris Travers - 2014-09-21
    • status: pending --> closed
     

Log in to post a comment.

Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:





No, thanks