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)
hi Matt!
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 guardian.rb and /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?
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.
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 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 is_admin or is_staff?
The “sudo” would just need to add a “staff_mode” toggle, and is_staff and is_admin functions could check the state of that toggle AND the user.admin or user.staff flag. (Of course, activating the toggle would need a special check which just looked at the user.admin or user.staff value.)
Here, a user is reporting a workflow problem with the interface. It’s really troublesome for me to try to replicate this, because my always-on admin access means that I’m not constrained by the permissions that workflow depends on anyway.
Another example case. Here, a user is noting that they are getting an unhelpful error message while trying to post to a category which it turns out they don’t have permissions to post to. Since I do have those permissions as site admin, I can’t reproduce directly.
What’s your current workaround for the lack of this feature, @mattdm?
In the past, I’ve used a separate account with a + address to log in and see the world through non-admin eyes (bonus: since I rarely had to do that, I’d also get the activity summary periodically for that user to keep an eye on what that looks like).
I have a test account that I log into in situations where I need to try something out, and I log into that using a private browser window. That is always possible, but I think there’s a lot of cases where I’d just notice things if my access were “regular” by default.
It also doesn’t prevent me from accidentally violating constraints I set up on purpose (like the tag rules, or posting in categories which are supposed to be read-only).
The other alternative — making my main account be a regular account and having a separate admin one — would solve that, but in practice be a hassle, and also I’d miss notifications for flags and for private messages.
Instead of this, have you considered using the test account in a browser you don’t regularly use? Then it can just stay logged in. For example I have the following:
Chrome: Admin(my main use)
Edge: Test User
Firefox: Used to Impersonate specific users when necessary
That works as long as there is no browser dependent issues to solve out. For me and in my world that is such fast fix than using PM as a draft container — yes, it works, kind of, but it is not nice and stylish solution for an user.
Draft question was easy: there is technical limits and can’t be done other way. Is there something similar with that question? Because if not I don’t understand why this is still open topic. I understand totally if there isn’t enough time and manpower to code it, but even then it would be nice to hear it.
My solution is opening profile of my test user and fast login that way. But because I can’t reverse back to my admin account I have to logout. That is not bigger issue, but unnecessary trip — well, DiscourseHub is somekind issue because it can’t natively use SSOs like Google, Microsoft etc.
