[UX] Dismissible status report messages.

jenlampton commented 4 years ago

Description of the need

In some cases, there will be errors or warnings on the status report that administrators will choose to accept, and ignore. It would be nice to be able to mark these messages as dismissed, so that they do not 1) trigger the red-dot if they are errors, or 2) clutter the status report.

Proposed solution

I would like every error or warning on the status report to provide an X that administrators could use to dismiss the message.

When dismissed, the message would be moved to one of the following places (discuss!)

a collapsed fieldset at the bottom of the status report
it's usual position in the list of status report messages - but grayed out as though disabled

When dismissed, the X on that message would be replaced with another tool that would provide the ability to re-enable the message. (suggestions?)

Additional information

This feature was recommended by @quicksetch in #3824 and would also help progress other issues, like #3490 and #5106.

Other things we discussed being dismissible:

docwilmot commented 4 years ago

Curious, what would be the best way to record dismissals? Cookie or db entry? I imagine db as it should dismiss per site, not per browser.

jenlampton commented 4 years ago

Yeah, I was thinking of using state_set() and state_get() so it would track per site.

On Sat, Sep 12, 2020, 2:22 PM docwilmot notifications@github.com wrote:

Curious, what would be the best way to record dismissals? Cookie it db entry? I imagine db as it should dismiss per site, not per browser.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/backdrop/backdrop-issues/issues/4617#issuecomment-691551107, or unsubscribe https://github.com/notifications/unsubscribe-auth/AADBER6NAFLZW2Q65C5QVBLSFPRADANCNFSM4RJ57G3Q .

klonos commented 4 years ago

With re to the placement of various entries in the status report page are, we have to cases:

Those that have a "permanent" place in the status table: Their "normal" or expected behavior is either a green status row, or a gray info row. If something is wrong, these become either yellow warnings, or red errors, and they bubble up the table. I agree that when this kind of errors/warnings are dismissed, they should return to their usual place (alphabetical order), but they should retain the warning/error icon; the only difference in that "dismissed" or "acknowledged" state should be that their icon should be gray instead of yellow/red.
Those that are hidden unless something is wrong: These have no entry in the status table when they are green/OK; they are only shown if something is wrong, and they also bubble up at the top of the table. We could add a separate table for those when dismissed/acknowledged, but why not put them in alphabetical order in the existing table (with gray icons)?

When dismissed, the X on that message would be replaced with another tool that would provide the ability to re-enable the message. (suggestions?)

How about a "reset" or "undo" icon?: https://fontawesome.com/icons/undo

As for using an x "close" button, it is my understanding that the expectation from a UX point would be to make the message go away. Since we will only be reordering things to be less distractive, I think that this icon should be a UTF-8 tick (✔) instead.

klonos commented 4 years ago

Yeah, I was thinking of using state_set() and state_get() so it would track per site.

Is that saved in the database ? If so, then perhaps we should consider doing it in config instead; so that people can sync these settings across their environments (w/o having to also sync their db).

jenlampton commented 4 years ago

Yes, the point of using state is that this setting needs to be enviornment specific (because the contents of the status report is also enviornment specific). This setting should not be sycn'd.

We could maybe also do some kind of settings.php override if we find a use-case for it.

On Sat, Sep 12, 2020, 9:44 PM Gregory Netsas notifications@github.com wrote:

Yeah, I was thinking of using state_set() and state_get() so it would track per site.

Is that saved in the database ? If so, then perhaps we should consider doing it in config instead; so that people can sync these settings across their environments, w/o having to also sync their db.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/backdrop/backdrop-issues/issues/4617#issuecomment-691611690, or unsubscribe https://github.com/notifications/unsubscribe-auth/AADBER2UANXNQ6T6UD6HJKTSFRE2ZANCNFSM4RJ57G3Q .

quicksketch commented 4 years ago

I think this would be a useful thing where the status report may make suggestions that are impossible to implement or perhaps just unnecessary for certain environments.

A wish-list item from myself that may or may not be "too much": when dismissing any status report setting, administrators could optionally enter a message indicating why they disabled the message. Though if we start collecting more than a simple flag, recording the user account and the time at which the status was dismissed might also be useful.

indigoxela commented 2 years ago

Although some additional suggestions here haven't been implemented, I belief, this has been fixed in https://github.com/backdrop/backdrop-issues/issues/4571 (1.20.0).

quicksketch commented 2 years ago

This issue about the status report at /admin/reports/status, where users may want to dismiss the errors or warnings for their site. These are different than the messages from backdrop_set_message(), which is what https://github.com/backdrop/backdrop-issues/issues/4571 handled.

backdrop / backdrop-issues

[UX] Dismissible status report messages. #4617