Report of issues that have not been dismissed

If I am understanding you correctly -- that you want the dashboard views to not include dismissed results in the issue counts -- the views should already be behaving as you describe, provided people are using "Mark as checked and OK" to dismiss alerts they have reviewed. The mark OK button records the dismissal and decrements the number of issues found on that page in the results table.

The "Hide alert" button only ignores it for the active user, so it remains visible in the result counts.

The reason you are struggling with creating views is that individual result counts are not recorded at all -- the only thing recorded per page is a count of each type of issue that has not been marked as OK.

If that is confusing -- you can control the ability to "mark OK" and "mark hidden (ignore)" by role -- so you could just turn off "mark hidden" on a site and only have one button. It's...possible that would be a less confusing default configuration for the module...

Ah... I see. We had not planned on allowing editors to mark OK for all as we kinda assume they will just clear results that are still an issue. (As I like to say to my teams, "editors are gonna edit." 😆)

I can work with the current model by having our admins review items that editors have dismissed and mark them as okay when they have been reviewed.

Thank you for the explanation!

Editors gonna edit indeed.

I could add a routine to drop records of hiddens when something is marked OK. It makes sense to keep storing multiple hiddens against the same issue, but not a hidden and an OK...

Of course, if I stop storing that, someone marking OK and then reverting the OK would purge those hiddens for everyone, which could be handy or confusing...

......this is why I'm so afraid to touch this part of the logic 😆

......this is why I'm so afraid to touch this part of the logic 😆

Indeed! 😆

We rewrote much of the standard dashboard into an accessibility report that pulls in content based on an editor's group membership using views_custom_tables and some entity referencing from an entity ID relationship. Our end goal is to give editors a checklist of content to address—and maybe give them a cheery message when they've completed it all.

Now that we understand the logic a bit better, we've decided to have an administrator report that shows content marked and okay by editors that can be reviewed monthly or quarterly to address editor's over-reporting content as okay when it isn't. This particular team has a really strong editor mentorship approach built into their governance.

If you are interested, I could do a demo for you when I've finished up the approach.

I'd love to see it when it's ready; I'm all for making the default dashboard more useful, and for documenting ways to extend it.