Todo #5445
open
Improve banner for "background activity"
0%
Description
A number of router functions involve background activity which is ongoing for a while before completing. (Examples: package install/update, firmware update, waiting for reboot, waiting for rules to be reloaded, php crash detected)
Quite often the user gets shown a status banner for (some) of these but it's very "hit and miss" and shows in some circumstances but not others. So there isn't a consistent info banner displayed to the user, when these kinds of activities are going on in the background, displayed above the current page on every page, until they complete. But often there should be a one-line banner displayed saying "packages being reinstalled" or "package reinstall complete" following an update, so the user is aware this is still going on rather than having to wonder if it's complete yet.
So this is a request - can we have a consistent "notification system", a bit like the system log ticker perhaps, that doesn't take much screen real estate, but certain background activities can \2set" and "unset" text to go in it, so the user can see at least a note that "background activities in progress" and click to expand and view what activities of these kinds are ongoing or completed, and dismiss/clear them at will.
That way, for any present or future router functionality or package activity that may require some time to complete in the background, once started, the user can see an icon on the banner bar that indicates "something is being done in the background" and can click to view the current background activities and statuses, if they wish.
The current system isn't very informative or consistent (you often "lose" this info if you do something else while waiting and then its not always easy to be sure what is going on, or if it completed yet).
Hope I've explained this well enough!
Updated by Phillip Davis over 8 years ago
Some activities output their text progress to a text box in the UI (e.g. package installation). If the user navigates away from the relevant page then stuff goes wrong with the "background" process that is doing the work. It would be nice to avoid that - put the output of such things into a text file somewhere and display that output when the user comes back to the "package installation..." page so they can see what happened without having broken the background process.
And as Stilez has said above, provide a consistent status banner thing.
Updated by Stilez y over 8 years ago
The "notices" in the banner in 2.3 alpha is an improvement on 2.2.x, in this area, for what it's worth.
Updated by Stilez y over 8 years ago
(sorry, I hit "submit" early)
... To expand a bit following PD's comment, part of the issue is that it shouldn't only display "when the user comes back to the package installation page". Not only some background activities (reload rules etc) allow the user to navigate away and do other things at the same time, but also the user might log out then log back in, they may not remember, other colleagues may log in who may not be aware in the first place. So relying on them to revisit the same page in order to be aware something's happening, and allow for it, isn't really as good as consistent banner info visible whatever page one is on.
So if something major of these kinds (including but not limited to maintenance/updates/reinstall/etc) is going on, I think that either the UI shouldn't allow them to see anything but the banner while it's happening, or - if they can navigate elsewhere while it's happening - then it should remain apparent in the UI header that something is going on, not break the "background" process, and be viewable what is going on and where it's up to.
Perhaps an elegant "fix" would be something a bit reminiscent of the "dirty" flag system, where any activity can be added to a list of "activities running in background" along with a list of pages that won't be operable until it's completed. For example:
// ...reinstall of all packages gets kicked off...
/* note the new activity:
parameters: activity brief description, pages inoperable until completed, banner for these pages if accessed
return value: an ID so this can be cancelled and updated as we progress
*/
$notice_id = background_activity_start("Reinstall all packages", array("pkg_mgr.php", "pkg_mgr_installed.php"),"Packages are being reinstalled, you cannot change packages until this is complete");
// ... reinstall progresses...
/* update the info as required:
parameters: the notice ID, description of this stage, % of current stage complete, % overall completed
*/
background_activity_update($notice_id, "Package 3/10, installing Perl X.Y.Z", 30, 45);
// ...reinstall ends, successfully or otherwise...
/* final result and close this activity, which automatically re-enables any disabled pages
parameters: the notice ID, final message, and an error code or 0=success
*/
background_activity_end($notice_id, "All packages reinstalled", 0);
The effect is that there's a single system which anything using background processes can use consistently. Not sure the details but would "something like this" work?
Updated by Phillip Davis over 8 years ago
Not sure the details but would "something like this" work?
Yes, basically a combination of the existing components that:
a) Presents the message about "Packages are reinstalling in the background..." - expand that to use it in more places, give updated progress...
b) The file_notice() function that presents important messages that the GUI user needs to look at and clear - use it judiciously for telling when something important has finished.
c) Re-engineer "inline GUI" code that is doing real stuff so that it works away in the background and uses (a) and (b) as appropriate to communicate with the user.
Updated by Anonymous over 8 years ago
The progress system used in pkg_mgr_install.php will allow the user to navigate away from the page, then come back later and pick up the progress. I may encapsulate this system to make it easy to use on other pages, but I need to finish the system base firmware update first. It does store the progress in a server file and fetch it via ajax.
Updated by