Hello Brajesh;
I was thinking along those lines:

1.: maybe add a bespoke capability, like “moderate_bd_bmt_flags”. This way, an admin team can assing the capability to roles as they see fit (using User Role Editor or any some suchness);
you could, if you deem sensible, introduce a new bespoke role who has this very capability, too; or you could add to your documentation that roles that should be able to moderate BMT items, need to be assigned that capability.

2.: a) Rejected or cleared items should be removed from the “open” queue and logged according to action. The Admin/s, being god/s, should be able to see all actions logged + have the power to revoke actions logged. Like there’s regular police(wo)men + their chief/s.

3.: as with all hierarchies. On + by the same level, actions should not be countermandable; i.e. what a flag moderator has done should not be able to be undone by any _other_ flag moderator. It should, however, be undoable by the Admin/s.

As an additional idea down that lane, you might introduce some sort of “appeal” mechanism, consisting of 2 parts: a) the option to clear rejected and cleared items from log after x time units automatically + b) the option to allow the creator of a rejeted item to appeal the decision made (rejection) inside that timefram of x time units (which could then be included in the rejection notification). Appeals could be made moderatable only by admins.
This might help countering some of the inevitable bitchfighting bound to happen if users get to police each other (which can be held in check by setting the hide threshold higher than 1 or 2). But that’s really just an afterthought.

Let me know what you think.
Cheers – LX

• This reply was modified 6 years, 2 months ago by LX M.

Hello Brajesh
+ thank you for getting back to me re this.
Intuitively, I would have expected this to be like the other options, i.e. decideable per type of activity; I was thinking, that maybe an admin team might find themselves preferring different notifications for different occurrences – but I may be off with that subjective notion.

re hidden vs reported: I would think this to be dependent on the subjective urgency each of those might cause. I’d expect a community member to maybe find it important enough to receive a mail once something is hidden; and not only find out the next time they happen to log on and notice the bubble.
Again, strongly subjective; hence I would suggest to make it so that the individual admin crew can set this according to their individual circumstance/s and requirement/s;

makes sense?

Happy to hear there’s an update scheduled;
I have another suggestion to contribute, but will do so on a separate thread as this is a separate issue.
Cheers + thank you for the great work so far. (y)

LX