Admin section user list: Same icon for admins & moderators


(Michael Downey) #1

Currently the user list has the same shield icon for admins as for moderators. So as a result, you’ll see two of the same icon side-by-side when someone has both roles.

It’d be much more helpful if these icons were different, yes? :smile:


(Dave McClure) #2

I propose:

  • Use fa-key for admin icon
    fa-key: Font Awesome Icons
  • Only show moderator icon (shield) next to user avatars in the public UI
  • In admin UI, show both

(James Milligan) #3

Yep, I’m not a huge fan of having the same icons. To users it doesn’t make a huge difference whether someone is a moderator or admin, but for larger sites I can imagine there being a need for more distinction.

As for the actual icons, how about fa-cogs, fa-code, or fa-terminal for admin? I think fa-shield is good for moderators.


(Rikki Tooley) #4

What would be nice in the long run is extending the badge system to provide admin and mod permissions.

Would require two changes

  1. Badges may grant permissions; can’t have certain roles without having the badge (i.e. reverse the relationship we have now between Trust Levels and badges)
  2. Badges may grant icons as well as titles - both customisable.

IMO badges are already a core feature, they aren’t going away, so it’d be cool to use all the badge infrastructure wherever possible. Trust Levels atm are decided with an SQL query… we can already grant badges using an SQL query - why not combine the concepts?


(Jens Maier) #5

No, as long as Badges can be disabled, they should not replace the admin and moderator flags. Also, admin and mod privileges are dangerous and I believe that code that deals with these privileges should be as simple and straight forward as possible. Flags in the user model are this; badges are not.

If we’re discussing the long run, I’d like to see a fine grained ACL system where I can redefine the permissions associated with all the system groups in the admin backend, assign permissions to custom groups and limit such permissions to individual categories.

As for the icon, you don’t need to turn the current system upside down to achieve this. Instead, add an icon, title and weight field to groups; the highest weighted group a user is in confers its icon to the user. The rest can be done in the JS frontend and CSS.


(Rikki Tooley) #6

Well, they’re a core feature. I was under the impression they were disabled by default because the feature was not finished yet.

It could be a hybrid system if it is that worrying, staff remain simple flags, badges for the rest. Personally I think the less logic in the code, the fewer bugs and corner cases we get.

See, I despise ACLs. phpBB for example has one of the most flexible permission systems, but it’s also the worst - it’s hard to understand and keep track of who has what permissions when you have three or four layers that can all override each other (up to infinite layers if you have a ton of subcategories). I knew how it worked - but if I ever wanted to delegate a task to one of my fellow staff members that involved editing permissions (like a forum game) it always took longer to explain how to do it than to actually do it. It is just too complex unless you work with it all the time.

There must be a better way… I think badges are a possible way to make the concept of permissions easier to visualise and intuit? Would need to work out some details of course, but the fact that badges are already undeniably more visible and tangible than “group” is a plus to me.

Anyway this is maybe a bit off topic here…


(Jens Maier) #7

PhpBB’s ACLs are hard to understand because the permission editor UI is a mess and because the permission templates add immense and wholly unnecessary bloat. That’s not what I want from Discourse, and that’s not what I meant with fine-grained.


(Jeff Atwood) #8

Yes, that was the primary motivation for the change. Also general simplification.

I suggest overriding the CSS locally as needed.


(Michael Downey) #9

We’re talking about the admin page here, not user-viewable stuff.

If it doesn’t matter then get rid of the separate roles. Oh, wait…it DOES matter.


(Sam Saffron) #10

I totally agree with this change, nobody really needs to know the difference between admin and moderator.

There is one slight amendment though I would like to see, I think admins should be allowed to “hide” admin status if they see fit. (this is particularly useful for us on sites we host)


(Zane Beckman) #11

One thought I had was just to make the Moderator shield a horizontal mirror image of the Admin shield. I’m not sure if this is easy to do with FontAwesome or not.

Additionally, I don’t see any reason why both shields should be displayed for a user. If you’re admin, you have all the permissions of a moderator and then some. It seems redundant to show both.


(Dave McClure) #12

As I learned here, the admin role is not all inclusive of the moderator role.

So, since admin and moderator status can be treated independently, what about doing this?

To clarify:

  • user is moderator only
    • shield badge shown in public UI and admin UI
  • user is admin only
    • no badge shown in public UI, key badge shown in admin UI
  • user is admin and moderator
    • shield badge shown in public UI, shield and key shown in admin UI

(Jeff Atwood) #13

Yes but that is super rare – in fact that is the only instance that I know of where a moderator has something happen that does not also happen to admins.


(Sam Saffron) #14

This would be a breaking change, however I do kind of support it. Wonder how @codinghorror feels about it.

The downside is that its another edge of the system we would need to explain to everyone. A button “make shield visible” is way easier to explain cause I would not need to answer the same question 79103 times.


(Jeff Atwood) #15

I don’t like it. On most small sites, there is no practical difference between admin and moderator. Adding a bunch of extra rules and states here for display is needless complexity.


#16

I disagree. That seems like a useful thing for the community to recognize.


(cpradio) #17

Hide per account/user, right? As you wouldn’t want to hide “all admins”. You are simply wanting to hide the fact that the Discourse team are admins (so you don’t get PMs related to the community being hosted).


(Sam Saffron) #18

I think @codinghorror’s idea here is fine.

Have all admins unconditionally hidden, moderators visible. If you are an admin and need to show the glyph grant yourself moderator.

Its also way more correct conceptually.


(cpradio) #19

I somehow missed that post (or didn’t comprehend it when I read it – maybe it was before caffeine).

I think that would work out just fine. :smile:


(Binoj David) #20

(post withdrawn by author, will be automatically deleted in 24 hours unless flagged)