I’m both an admin and a participant in the Fedora discourse sites. I’d like to be able to separate those roles. I know there’s the “staff color” for Official Posts, but I mean more from my side. Rather than admin wrenches and buttons everywhere whenever I’m logged in, I’d like a menu toggle which would activate Admin Mode on and off.
We also have
These plugins both let you disguise your identity as a staff member. i.e. you can make a post from a more ‘official’ looking account, which cannot be obviously linked back to you as an individual.
However, I don’t think that’s quite what you’re asking for? You want a way to make Discourse look/feel like it does for regular users, and then “enter sudo mode” to make all the extra admin-only functionality available?
I think it would probably be quite hard to implement… but it would be pretty awesome! Many years ago (before I joined the team), I made this component for my own self-hosted forum. It has the same kind of idea (make regular/admin privileges obvious), but it’s limited to one very specific case:
If there are other tightly-scoped cases that are often confusing on your site, it might be possible to make similar theme components to popup warnings before taking admin-only actions.
Yes, exactly. I guess it partly comes from years of being a sysadmin, and having the idea of “least necessary privilege” drilled into me by practical experience. (
rm -rf as root in the wrong place on a production system is a rite of passage!)
This is also of interest to me. My current workaround is to use both chrome and edge. In chrome I have my admin account, but in edge I am in the admin account and I impersonate a user account with an expired email. The impersonation is only because I don’t want to talk to IT.
In your sittuation you could create a second login, and have one browser for admin, one browser for user. Not perfect but for me it’s been good enough.
Here’s a good example of where this would be useful:
I don’t want to be able to accidentally violate intended tagging rules. (Are non-admin moderators also able to accidentally do this? I can’t easily test, even.)
I could create a separate admin account and demote my main one to a regular user, but I’m afraid I’d miss important flag notifications and messages.
This is something handled by the browser itself, see
That just looks like it lets me swap entire browser profile? That doesn’t seem like it helps, unless you make an entirely different Discourse user account for admin use.
Or am I missing something. Like, @codinghorror, your account is listed as an admin here, so I assume unless you’re doing something I totally misunderstood, you’re running in administrator mode right now. But you’re also acting as a site user. Don’t you run into things where (for example) you accidentally create posts that don’t follow the configured tag rules? (I’ve done that more than once by accident…)
Not really – part of being an admin is understanding the responsibility you have and the boundaries you must respect. If you can’t do that, you shouldn’t hold admin privileges.
But I also empathize with people who want to be ultra safe and I recommend they use two accounts and log in as a regular user when they need to be absolutely sure… and using the built in browser profile support, this is very easy to do.
Well, it’s kind of like the same thing as running as root on Linux system all the time. It’s not just respecting boundaries, but not accidentally walking over them when you don’t realize they’re there. Some things, like going into the settings aren’t going to happen by accident, but there seem to be a lot of little things where admin bypasses the configuration without any indication that there’s something being bypassed…
As I said above, having a second account isn’t really great, because I’d only see that accounts notifications infrequently.
I understand the concern, but it isn’t a huge issue in practice, at least not over the 10 years I’ve been working on this project.
(also bear in mind we auto-revoke staff access and require email revalidation for staff that are long absent, which patches most of this automatically IMO)
Just to add some color, the possiblity for an admin user to be acting as a regular user would add an extra dimension to absolutely all admin related authorization logic.
Even though that logic is mostly centralized in
/lib/guardian/*.rb, the complexity and bug potential for such a change would be very large, and the necessity of this feature would need need for far outweigh that, which it doesn’t, given the alternatives.
Would it be possible to consider more targeted “protection” for some of the more accidentally-possible things? Like a setting: “Staff must follow category tagging rules”? Honestly that one alone would solve most of the practical problem I am hitting.
Or… find it kind of weird that other things like post-length are still protected for even admins… maybe actually this particular thing is a matter of just making that the way it works rather than adding an option?
Adding post length would require the entire database to be changed. There’s a maximum number of characters we can store in the database per field.
This seems like a non sequitur to me but I might just be missing something. I mean:
- If I am an admin, and I try to post a post that is shorter than
min post length, I am given the normal error message and can’t proceed.
- If I am an admin, and I try to post with no tags in a category that requires one, it just lets me go ahead.
What’s being stored in the database here?
Oh sorry, I meant only post/title length – there’s a maximum size of post length content in the actual database field it is stored in. There’s a similar rule for post title, a maximum number of characters allocated for that particular field in the database.
So if an admin decided, “hey I want a 900,000 character post” or “hey, I want a post with a 500 character title” that’s not possible without changing the database.
It’s really a technicality but since you mentioned post length I was thinking about it.
Ah OK. Yeah, that’s really he opposite of the problem I’m concerned with
I assume that OP meant to work most of the time as a regular user. For me, I want to feel myself as a simple user too:
- less buttons
- no access to moder/admin actions
- use simple user cases
After upgrades or tune, I would like to interact with the forum as regular user see it to avoid misunderstands.
For my community admin mode is necessary only for upgrades or tests with plugins and UI. No need to be moderator all the time as well. Also I think that for some kind of people like me temporary switching to admin is better than having two accounts.
The OP wrote about
sudo. This is almost the same but invert. Usually I temporary switch to anonymous to check some cases. Anyway it would be great to have some light option to activate admin mode like ‘impersonate’ under special regular account.
It reminds me of something that occurred a few days ago. I’m in the process of migrating a forum.
I granted administrator privileges to the admin of the old forum.
He’s a Discourse user on two other forums, and also a moderator. So he knows a bit about Discourse interface and navigation.
From his admin account (I didn’t write any guideline to him, I let him discover stuff) he told me he was surprised to see he could access direct messages from other people; He clicked a bit randomly on a public profile page and saw a list of direct messages, which surprised him.
He told me he suddenly thought “Oh well, it seems I’m somewhere where I shouldn’t be” (to be understood as: he shouldn’t be here if he has no administrative/moderation purpose at this time).
He has no idea that he could access these messages from the interface, and not as easily as you access your own direct messages from your profile.
And it also happened to me a few weeks ago also, despite the fact that I’ve been an administrator of two Discourse forums since 2018…
In my opinion, on the “direct message” tab from a user’s public profile, as an admin, there should be an icon or any kind of warning that clicking it is a moderation or administration action, as you’ll see things meant to be “private” (in 99% of users’ minds anyway).
So… I’ve been thinking about this, and I’m less convinced that it’s a big change after all. Sure, there’s lots of scattered logic, but doesn’t it all come down to checking
The “sudo” would just need to add a “staff_mode” toggle, and
is_admin functions could check the state of that toggle
user.staff flag. (Of course, activating the toggle would need a special check which just looked at the