I’ve seen restrictions on admins before in other software, it almost always comes in the form of administrator permissions (vB, MyBB, etc.).
They have 40 or so permissions which lock down exactly what an admin can and can’t do. The folks over at MyBB don’t think it’s enough and want to add even more permissions.
They even have an “account protection” system which prevents admins from modifying the account of the super admin, just in case an admin goes rogue.
They come up with all sorts of ways to restrict admins to create an illusion of safety for the site owner, but at the end of the day, if you can’t trust an admin, then they shouldn’t be an admin.
If you think admins reading PMs is a problematic feature which invites snooping around PMs out of curiosity, then the ability to disable this feature entirely might be preferable to another set of lock and keys.
Admins would still be able to poke around the database, if they think an investigation is in order. Perhaps, it could be a plugin, it would also be easier to implement.
Incorrect, we call them Personal Messages. If there is any place where the copy still says Private, we should change those as well. I can sweep the codebase tomorrow to check.
Discourse may call them personal messages but you are the first person to use the term on this thread by the look of it.
I’m not at all sure what value that semantic hair splitting has anyway when talking about UX. Calling them Personal rather than Private doesn’t make me feel any better about people reading them.
Accessing PM seems as good a place as any to give admins a quick reminder that they are using logged admin functions and what kind of logs Discourse keeps. This should probably have “don’t show me again” tick box or automatically expire after being tripped X times.
It sounds like you have admins who really shouldn’t be admins. This can happen for organizational reasons (VP or key investor wants to be an admin). Perhaps you can just edit the masthead in the about section to read “our team” rather than “our admins” then just list everyone you need to list prominently rather than your actual admins. Maybe all you really need to give them is a spot on the about page and a cool title.
An interesting question that I don’t know the answer to.
However, most Staff Actions are more or less non-routine. But If looking at any message they look at is logged - including messages Staff would routinely read (eg. Flag, Staff group messages) - the Staff Actions Log would quickly fill up and bump the more rare actions off of the list thereby making it less useful. If only looking at messages where they normally wouldn’t be a topic user is logged, then I agree, logging the action could be a good thing.
Right … I guess it turns on the actual definition of logging message reads “for other users/groups”. Hopefully it wouldn’t include stuff that the admin already has direct access or membership to.
@jomaxro@sam@techAPJ
Is there any way to get an option added to webhooks to secondary service or site mailing option that can be used to notify immediately selected users if this “logged action” happens, and if the logging setting is toggled off/on.
I’d like it for immediate accountability to other admins/staff.
This would be used in a business/elected representative group, so there’s no way to boot someone from staff role, but if it can be actively monitored it would prevent unnecessary temptation
