# Become admin

**URL:** https://meta.discourse.org/t/become-admin/340308
**Category:** Feature
**Created:** [December 4, 2024, 7:43am UTC](https://meta.discourse.org/t/become-admin/340308 "2024-12-04T07:43:08Z")
**Posts on this page:** 9
**Page:** 1

<div class="post-metadata">

### Author: ![hellekin](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/hellekin/32/51636_2.png) [@hellekin](https://meta.discourse.org/u/hellekin)
#### Post date: [December 4, 2024, 7:43am UTC](https://meta.discourse.org/t/become-admin/340308/1 "2024-12-04T07:43:08Z")

</div>

## Problem

1. Administrators may inadvertently access confidential parts of the forum
2. Such unwanted access are not being logged
3. Administrators may miss misconfiguration because of their superpowers hiding the normal experience to them

## Feature description

In the same vein as the [Impersonating a user](https://meta.discourse.org/t/impersonating-a-user/80862) feature. a user with admin privilege should be able to _become admin_ to perform administrative tasks only when that is necessary.

**Unlike the Impersonation feature** , this feature should not require logging out to recover the normal user privileges.

This feature would:

1. allow administrators to browse the site as a normal user, sharing the daily experience of other users;
2. prevent admins from inadvertently accessing private spaces of the forum;
3. safeguard unauthorized access to such private spaces with actual log of admin access.

The first point is useful because the admin experience is so much different from the user experience, and admins may not be able to realize user issues (e.g., related to wrong permissions set on categories or groups, etc.)

The second point may be critical in cases where a group requires confidentiality: clicking a link might bring the admin to trespass inadvertently and break confidentiality.

The third point would enable administrators to be accountable for unauthorized access to confidential parts of the forum, while they’re currently not at all.

## How could it work?

- Privilege escalation should only be available to actual admin accounts;
- “Admin” could be considered like an extra Trust Level (e.g., level 5 \[1\]);
- Returning to “normal” mode would simply switch back to previous TL;

Instead of giving a whole new “admin perspective”, Admin mode could add an extra layer of user interface:

- highlighting links that only work _because_ you’re admin
- highlighting categories you only have access to _because_ you’re admin
- highlighting group memberships that you can see _because_ you’re admin (e.g., if you’re a member of the group with limited access to group membership, the highlight would not apply)
- highlighting information that _only_ admins can see

* * *

1. A reference to Chris Marker’s film [Level 5](https://en.wikipedia.org/wiki/Level_Five_(film)) in which a computer programmer tries to complete her deceased husband’s video game about the battle of Okinawa to overcome grief.

---

<div class="post-metadata">

### Author: ![Moin](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/moin/32/554653_2.png) [@Moin](https://meta.discourse.org/u/Moin)
#### Post date: [December 4, 2024, 7:52am UTC](https://meta.discourse.org/t/become-admin/340308/2 "2024-12-04T07:52:48Z")

</div>

I think this is similar to

> [@"Regular mode" for admins and moderators (e.g. something like "sudo")](https://meta.discourse.org/t/regular-mode-for-admins-and-moderators-e-g-something-like-sudo/211617):
>
> 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.

---

<div class="post-metadata">

### Author: ![hellekin](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/hellekin/32/51636_2.png) [@hellekin](https://meta.discourse.org/u/hellekin)
#### Post date: [December 4, 2024, 8:32am UTC](https://meta.discourse.org/t/become-admin/340308/3 "2024-12-04T08:32:05Z")

</div>

I can see how it is similar, yet there are issues in the other discussion that relate to the issue here:

> [@"Regular mode" for admins and moderators (e.g. something like "sudo")](https://meta.discourse.org/t/regular-mode-for-admins-and-moderators-e-g-something-like-sudo/211617/9):
>
> 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.

Except that, when you’re admin, you have no way of seeing that a link to a confidential conversation your normally would not have access to is actually off-limits. This is only _one_ case (that occurred to us yesterday and prompted me to start this topic) where the non-separation of admin and participant can be problematic.

Moreover, I see that the Discourse team has a habit to be all admins, which makes a horizontal superpower, and does not help, as a culture, to differentiate between normal usage and privileged usage. Not all communities are horizontal, sometimes the tech people who have administrator privilege should not be trusted with everything on the forum, and that is not an edge case: it’s been built in computer systems since the beginning that `root` can see and do everything. Privilege certainly comes with responsibility, but sometimes benevolence is not enough especially when one cannot distinguish between okay and off-limits.

Although the “use another browser profile” solution to handle a normal and admin account, it is not very practical, especially as we all get used to have the tools at hand. Firing up a new browser each time an admin feature is needed can be very annoying (not everyone likes nor can afford to having idle resources taken on their machine). It also does not prevent the prying eyes privileged BOFH situation from happening.

> [@"Regular mode" for admins and moderators (e.g. something like "sudo")](https://meta.discourse.org/t/regular-mode-for-admins-and-moderators-e-g-something-like-sudo/211617/6):
>
> 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.

> [@"Regular mode" for admins and moderators (e.g. something like "sudo")](https://meta.discourse.org/t/regular-mode-for-admins-and-moderators-e-g-something-like-sudo/211617/10):
>
> 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.

> [@"Regular mode" for admins and moderators (e.g. something like "sudo")](https://meta.discourse.org/t/regular-mode-for-admins-and-moderators-e-g-something-like-sudo/211617/11):
>
> I understand the concern, but it isn’t a huge issue in practice

Times change. Here, we have an admin who accidentally accessed confidential information that affected the life of other people, and they were not supposed to. This is privacy breach. It’s a security issue.

> [@"Regular mode" for admins and moderators (e.g. something like "sudo")](https://meta.discourse.org/t/regular-mode-for-admins-and-moderators-e-g-something-like-sudo/211617/12):
>
> Even though that logic is mostly centralized in [`guardian.rb`](https://github.com/discourse/discourse/blob/main/lib/guardian.rb#L14) and [`/lib/guardian/*.rb`](https://github.com/discourse/discourse/tree/main/lib/guardian), 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.

I understand the potential complexity, but the core issue remains and should probably be solved one way or another. IMHO, it would be useful to revisit the question now that the code base has matured, and evaluate whether the proposed approach would be doable.

> [@"Regular mode" for admins and moderators (e.g. something like "sudo")](https://meta.discourse.org/t/regular-mode-for-admins-and-moderators-e-g-something-like-sudo/211617/18):
>
> 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.

> [@"Regular mode" for admins and moderators (e.g. something like "sudo")](https://meta.discourse.org/t/regular-mode-for-admins-and-moderators-e-g-something-like-sudo/211617/19):
>
> It reminds me of something that occurred a few days ago. I’m in the process of migrating a forum.

Yes! Having warning and guards about this kind of (trespassing) issues would be useful.

* * *

On existing plugins:

- [GitHub - discourse/discourse-anonymous-moderators · GitHub](https://github.com/discourse/discourse-anonymous-moderators) might be useful, but a recent change handling email ([Enabling e-mail normalization by default](https://meta.discourse.org/t/enabling-e-mail-normalization-by-default/338641)) may change that – relying on no default settings may prove problematic.
- [GitHub - discourse/discourse-staff-alias: Allow staff users to post under an alias · GitHub](https://github.com/discourse/discourse-staff-alias) is only limited to _posting_.

I’d rather have a really clean separation between participant and admin using the classical and well-known _sudo_ metaphor, for all the reasons stated above.

---

<div class="post-metadata">

### Author: ![Ed\_S](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/ed_s/32/134015_2.png) [@Ed\_S](https://meta.discourse.org/u/Ed_S)
#### Post date: [December 4, 2024, 12:11pm UTC](https://meta.discourse.org/t/become-admin/340308/4 "2024-12-04T12:11:50Z")

</div>

I agree that the sudo mechanism - in windows the User Account Control dialogue - is a good way for an account to have the potential to act as an admin, but without always having the ability.

On one of my forums, the approach I use is to have an admin login, but usually to use Impersonate User to login as a normal account always all the time. When I need to act as admin, I logout and login again. This does mean two accounts.

One advantage of two accounts is that when I post or comment with my normal account, I do not appear as a powerful important person. (Sometimes, commenting as an admin will be taken as a pronouncement or a police action. It depends on the culture and expectation of the reader.)

---

<div class="post-metadata">

### Author: ![hellekin](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/hellekin/32/51636_2.png) [@hellekin](https://meta.discourse.org/u/hellekin)
#### Post date: [December 4, 2024, 8:11pm UTC](https://meta.discourse.org/t/become-admin/340308/5 "2024-12-04T20:11:51Z")

</div>

Since this feature, if it eventually comes to be implemented (do not forget to vote for it!), will take time before it happens, we are evaluating using two accounts. That means: converting existing accounts to normal accounts. Here is what it should entail (I will try to edit this post, or make it a wiki so we can keep an up-to-date documentation covering caveats)…

⚠ untested yet: this is all theoretical, from the top of my head.

## Converting an existing Discourse admin account into a normal user account

Since we do not want to lose history and “forum experience” from the original account, we need to proceed with care before removing admin privilege.

**Given** user _me_ with email _original-me@email.example_.

### First case: admin account in `DISCOURSE_DEVELOPER_EMAILS`

If the admin account’s email is part of `DISCOURSE_DEVELOPER_EMAILS`, it _cannot_ be demoted to a normal account.

1. Create a new account that will become admin, e.g., _me2_ with email _original-me+admin@email.example_.
2. From `me`, grant administration privilege to the new account `me2`.
3. Edit `app.yml` (or `web_only.yml` if you use the dual container setup) to replace `original-me@email.example` with `original-me+admin@email.example` and rebuild the container
4. From `me2`, demote the `me` original account

You now have a normal user account with all your experience (`me`) and a new admin-only account (`me2`): go to “Aftermath”.

### Second case: admin account promoted from normal user

This is simpler, since you _can_ demote this user without having to rebuild the container.

1. Create a new account that will become admin, e.g., _me2_ with email _original-me+admin@email.example_.
2. From `me`, grant administration privilege to the new account `me2`.
3. From `me2`, demote the `me` original account

You now have a normal user account with all your experience (`me`) and a new admin-only account (`me2`): go to “Aftermath”.

### Aftermath

Before, you had a single user account with admin privilege: you would receive notifications for system upgrades, review flags, and could access all areas, including those you’re _not_ supposed to see (e.g., private user messages if they are not encrypted) or categories restricted to groups you’re not a part of. All this is gone! Now you _must_ connect _regularly_ to your admin account to do anything you were used to do from your unique user/admin account (which is yet another reason why the proposed feature is useful). You need to build this discipline to open the two accounts at the same time if you want live admin notifications (e.g., using a private tab in Firefox, or equivalent for other web browsers).

#### Caveats

##### You _should not_ use your _admin_ account for _anything else_ than administration.

Do not browse discussions while you’re admin! This time is lost to your own trust level progression, and you never know when you might click a link that is off-limits for you as a person.

If you happen to read something while in your admin account that makes you react, either switch to your _normal user_ tab and browse to the original URL, or, if your normal user does not have access to that section: forget about it immediately (unless, of course, you _should_ react with your admin hat on).

##### You _should_ configure your admin account to look different

Change your avatar to ensure you _never_ confuse your admin account and your normal user account. Make your profile invisible. Change your background image or theme, your name to include “ADMIN” or something like “THIS ACCOUNT DOES NOT POST”, etc. Just make sure you do not _want_ to be tempted to post with your admin account, ever.

##### You _should_ configure your admin account to filter notifications

_TODO: detail this section_

You should setup your admin account to mute all notifications by email (unless you _want_ to receive such notifications, e.g., to avoid having to keep an admin tab open at all times) AND you are able to clearly distinguish which are destined for you as a person, or for your admin role.

You probably want to be notified on your desktop to catch flags and important messages.

#### What to do with _staff_ category and whispers?

Yes, you hit one more complicated issue with using two separate accounts for admin and normal user participation. Sometimes you _must_ interact on the forum as an admin. This is probably inevitable. Try not to become schizophrenic, and try to minimize your _staff_ interventions as much as you can. Please report your tactics for dealing with this arduous problem, and motivate the all-admin Discourse team to implement this feature. 😉

### Advantages of the Two-Account solution

1. Clean separation between participation and administration (sort of)
2. You cannot make mistakes from your normal account
3. All your admin actions are properly logged
4. As a user, you experience the forum as any other user, so you can easily catch permission issues
5. If you happen to post as `admin` but intended to post as yourself, you can change ownership to your other account (but this kinda defeats having two accounts).

---

<div class="post-metadata">

### Author: ![NateDhaliwal](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/natedhaliwal/32/313494_2.png) [@NateDhaliwal](https://meta.discourse.org/u/NateDhaliwal)
#### Post date: [December 4, 2024, 10:49pm UTC](https://meta.discourse.org/t/become-admin/340308/6 "2024-12-04T22:49:12Z")

</div>

So admins will be normal users or TL4s, but can turn on ‘admin mode’ to use the special admin features?  
If so, what’s stopping the admins to always leave it on?

---

<div class="post-metadata">

### Author: ![Ed\_S](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/ed_s/32/134015_2.png) [@Ed\_S](https://meta.discourse.org/u/Ed_S)
#### Post date: [December 5, 2024, 4:31pm UTC](https://meta.discourse.org/t/become-admin/340308/7 "2024-12-05T16:31:58Z")

</div>

> [@hellekin](#):
>
> You need to build this discipline to open the two accounts at the same time if you want live admin notifications

That’s an interesting note. Any way to close the gap - allow a group to control delivery of notifications, without the content? “There are flagged posts” “There is a message waiting” “Your installation is out of date”

---

<div class="post-metadata">

### Author: ![Ed\_S](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/ed_s/32/134015_2.png) [@Ed\_S](https://meta.discourse.org/u/Ed_S)
#### Post date: [December 5, 2024, 4:34pm UTC](https://meta.discourse.org/t/become-admin/340308/8 "2024-12-05T16:34:03Z")

</div>

> [@NateDhaliwal](#):
>
> what’s stopping the admins to always leave it on?

Here’s an idea: the admin role cannot post to a public category or thread, cannot like a post.

---

<div class="post-metadata">

### Author: ![Ar\_D](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/ar_d/32/231040_2.png) [@Ar\_D](https://meta.discourse.org/u/Ar_D)
#### Post date: [December 5, 2024, 6:14pm UTC](https://meta.discourse.org/t/become-admin/340308/9 "2024-12-05T18:14:24Z")

</div>

It also means the account could be ignored such as a normal user. Only getting necessary updates from the admin if we want to ignore them.  
Great one indeed 👍🏻
