Is there a way to target the Impersonate and anonymize user buttons on the admin/user page?
I want to hide those specific buttons. Rather I can only seem to identify .btn-danger, .admin-wizards-custom-fields .btn.destroy
Which hides the delete, merge, silence and suspend buttons as well.
Also, I can’t seem to hide the messages tab on the user card with the ability to restore/display the element for “self”
What problem are you trying to solve? Are you saying that you don’t trust your administrators not to impersonate or anonymize users? And that they won’t know how to use safe-mode to bypass your hiding these buttons? If so, you have a problem that can’t be solved with CSS.
I had done this before a while back, just can’t remember the specific css I wrote for it.
The use case for this forum is a work group, but not a typical one. It’s a union and this is specifically for elected reps. Some of the reps are in leadership some are not. Either way, those in leadership need functional administrator capabilities but not in the way a community forum admin has access.
There is ZERO need for moderation, there is absolutely no good reason to read someone’s PMs (as we are trying to get away from email as a primary means of discussion but chat clients like slack aren’t as useful as a forum style board), and there is no need to ever impersonate a user. Additionally anonymizing is absolutely unnecessary.
Also none of the admins (leadership roles in the group) have any IT background. The way I had implemented this before was to create a theme component that hid all the stuff that makes discourse useful for a community forum and not a business work group. Then I created a data explorer query to show if/when that theme component was disabled. This way if it was ever done, anyone could call the person intruding on privacy/protected categories to task.
This is a small work group, we don’t have access to an IT department to maintain it. CSS hides it, and yea I know anyone can go parse out the info they want from the CLI, but at that point we’d have much bigger problems.
Well, the template may have changed, as neither of us can see how to target just that button. (This does seem like an unlikely change, though).
From what I can tell, I’d probably try to figure out how to add whatever admin stuff normal users need rather than pretending admins can’t do everything.
I think it may have as those buttons didn’t have a dynamic ember before.
I know what I’m trying to do configuration wise is a little weird, but it’s well thought through with a full understanding of the mechanics of it. I just really want to make use of discourse instead of other communications options for our group because I believe it is the best for what we can use it for all around. There are just few things baked in that make it a challenge as there’s no way to toggle the capabilities off on the whole (and enable them only if needed with logged actions).
right, but that hides delete user and merge buttons too. I was hoping to keep those.
I’m trying to target the button itself. I did it with the messages tab on the user page this way to hide from all users (admin) and re-display it for self
.pull-right is a utility class that’s used in a lot of places, so this would likely have negative impacts! Generally with CSS, if you’re trying to target one element… you want to consider how specific the selector sounds. If it sounds like something generic that could be used elsewhere (like .btn for another example) then it’s probably too broad. Something like .admin-user .pull-right might be specific enough.
Anyway, I’ve submitted a pull request to add some classes to those admin buttons. This should be available in Discourse updates at some point over the next couple of days.
Once that’s merged you’ll be able to do any mix of