I think you are making a fair point, but the problem is that the terms “moderator” and “admin” have a different (more technical) meaning in discourse. They simply refer to two levels of privileges: admins have all privileges and mods have limited privileges (only what they need to to their moderation job).
The discourse team will correct me if I’m wrong, but I can’t think of any easy way to achieve what you want by modifying the /about page.
However, what you could do is create new groups that correspond to your definition of admin and mod (or only mod) and direct people to that group’s membership list.
Actually, it doesn’t matter that admins have 100% of the power that mods have, they are separate groups. I can see as an admin by looking at the other admins — some are in the mod group and some aren’t.
So, there’s no need to change anything besides the display of the About page. Certainly there’s no need for new groups.
I totally agree. I am an admin on dozens of sites but am not a moderator on any (maybe one?).
Several times I have been contacted by a user about something that I could not help with or had the site owner express concern that I was listed on the about page.
Hiding people entirely would only sorta solve my concern (it would help avoid contacts to people who don’t want it, but they’d lose being honored as part of the staff). I want clarity about the admins who are mods so that it’s obvious that they are options when mods specifically are needed. I think I don’t want to hide the non-mod admins though. I’d still like them to be honored as being staff in our case.
I think the About page just could use a rethinking in how staff are presented overall. I could see several different ways to do it. One thought: flip the current approach, just maybe show all mod+admin folks under mod, but give them a special badge noting that they are admins. Another thought: Show it like a Venn diagram somehow so that everyone is in a big list but a section are highlighted mods and a section admins and show an overlapping section. I’m sure good UX folks could have other ideas.
The goal is just to have more clarity for the multiple purposes that we show who the staff are (knowing who to contact for things, honoring people for their work and positions…)
From the I-don’t-really-understand-serializers department. . .
# remove pfaffman from admins
puts "now Adding to serializer"
add_to_serializer(:about, :admins) do
object.admins.reject do |user|
puts "USER::: #{user}"
end
end
puts "end Adding to serializer"
I get no output between “now…” and “end…”.
I thought that # your criteria for removing users from the admins list would seem like I’d put something like user.username=='pfaffman' in there, but it doesn’t seem like anything is happening. Except that now no admins are displayed.
edit: This also removes moderators (I tried false too).
add_to_serializer(:about, :moderators) do
true
end
add_to_serializer is a function which takes three arguments.
Name of the serializer (:about)
Name of the variable you want to serialize (:admins)
A block. Think of this as a section of code that will be executed at some point in the future
So that is expected. The block you gave to add to serializer has not been executed yet. In fact, it will only be executed when the serializer is used. If you go and request about.json, you should then see "USER::: #{user}" appear in your console. And it will appear every single time you make the request.
Yes, that sounds like it should work. Remember it is case sensitive.