You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
When adding history, the History::add only picks up $_SERVER['REQUEST_URI'], which does not include any page arguments, such as filters. One example was listing tasks from task group, the group id was in the url as an argument, but the history was task/tasklist, so when you clicked on the history the task list is not the original view.
Proposal
Add a new optional parameter to History::add, where you can supply the arguments for the page. In the case of viewing tasks from task group, the tasklist would be able to determine the nature of the view, add an appropriate description to the history as well as the page args. The key is to be able, where required, differentiate between different views of the the same page, so you would need to make sure that views with args are appropriately identified (in the history label).
The opportunity
When adding history, the History::add only picks up $_SERVER['REQUEST_URI'], which does not include any page arguments, such as filters. One example was listing tasks from task group, the group id was in the url as an argument, but the history was task/tasklist, so when you clicked on the history the task list is not the original view.
Proposal
Add a new optional parameter to History::add, where you can supply the arguments for the page. In the case of viewing tasks from task group, the tasklist would be able to determine the nature of the view, add an appropriate description to the history as well as the page args. The key is to be able, where required, differentiate between different views of the the same page, so you would need to make sure that views with args are appropriately identified (in the history label).