"Mark as read" button for reports about community HOT 6 CLOSED

A more drastic approach would be to implement this "mark as read" behavior without an explicit button, as soon as a particular list of reports is shown to a user (same as with unread/read private messages).

from community.

Not important enough considering the significant amount of work

from community.

I made a similar feature few months ago in another project (notifications for multiple users) where the read option was already present. The read action there is made by click, but the backend part may be implemented in similar way.

The feature involves adding a collection of helper objects linked to an entry report and containing a receiver's username/userGroup and isRead boolean. New entry report would be created initially with the helper object with ex. "trusted+" as receiver's userGroup and isRead=false, and the collection would be populated with every user reading entry reports list with isRead=true.

Preparing a list/count of reports to read would be more tricky - it's needed to search for objects with specific username or groups assigned to the user. Objects with matching username take precedence. If nothing can be found for the specific entry report and user, it's assumed the entry report is not for them to see.

The collection can be cleared from info who read the entry report when it's closed.

If it would be implemented this way, we can make use of "set a group as a receiver" feature and hide some of the reports from trusted users - they can do nothing about spammer notifications or artist ownership requests.

from community.

If it would be implemented this way, we can make use of "set a group as a receiver" feature and hide some of the reports from trusted users - they can do nothing about spammer notifications or artist ownership requests.

I want everyone to see the spammer notifications. Even if they can't disable, they can still keep an eye on the potential spammers.

Some filtering by user group could be done later, but that should be tracked in a new issue.

from community.

Main problem with this issue is that entry reports are global (not user-specific), and that's how they should be, because only one user can handle them. Meanwhile those read notifications would need to be per user. So that requires a new related entity ("linked object" as you said) to be created. Nowhere near impossible of course, but still a significant amount of work.

There is also the point of view that reports are intended to be short lived. Ideally only 1-2 days max. If the report cannot be resolved, then I usually recommend creating a comment and closing the report. Therefore such read acknowledgements would be short lived as well. Of course sometimes reports stay there a bit longer when they require a response from someone, but from what I've seen, most reports should be closed much faster than they currently are. I want to encourage fast resolution instead of keeping the reports there. That's why it's also better that the system keeps "nagging" you about the open reports.

from community.

This issue is stale because it has been open 60 days with no activity. Remove stale label or comment or this will be closed in 7 days.

from community.