Hide specific content from admin (a different take)

feature
1

Ok,
So we are using a discourse board for team collaboration within our professional representative organization.

We have elected executive positions and elected representatives as well.

I am a representative, however I setup and am the admin of our board. (I’m sure I won’t be forever, but at the moment I am.) It is login required to view anything, invite only to join. Totaling 20 users currently, but will scale up to about 30.

We created an executive group work space where the group and content should only be visible to those specific members within the group. Really, its content shouldn’t be to the admin, only the category. And please refrain from the “if you can’t trust the admin” thing… Basically for the purposes of the organization, I’m not “read into” those discussions regardless that I’m the only one admin-ing the board. Call that category “above my pay grade.”

Here’s what I want to do, and could use a little help if there’s some CSS that can solve this.

  1. Not hide category (I still need to admin it if sub cats are needed), but hide the content of the category. The category is only visible to “Executive” group members.

    • So is there a way to use CSS to say hide category content within that category (and on home screen preview) unless you belong to a group. Or better said, display that content to group “Executive” otherwise hide it.

  1. Hide the “Messages” tab on a user profile and hide the “impersonate user” button on the admin user page.

    • What I’d like to do is only leave it visible to the developer account which is a universal admin account that will rarely be used beside for board maintenance, and really only through the console rather than UI. Other than that account, those elements not be displayed.

Yes, I know how anyone with root can parse anything from the database. I know any admin can go edit/comment out the css and see what they want then change it back.
I wish there were a better “secure” way to do it baked into discourse but there isn’t. Ideally when messages are encrypted (should have a setting to default on/off) the PM reading wouldn’t be an issue minus impersonate.

But for the sake of this organization, this will absolutely suffice. Nobody would understand how to undo this as fellow admins. And I know the why give them admin vs mod, they could break things discussion, but they need to be granted admin as it’s not something that can be withheld within the organization from the leadership. And they need to see that barring me taking extra measures to truly try to go out of my way read stuff I’m not read into, that my access dosn’t exceed my authority.

Bottom line, I was hoping someone could help with the CSS to hide those elements.

  1. category contents from ALL except the specific group members
  2. the message/impersonate options from all admins except developer acct.

Reason for the lengthy write-up is that I know all the “why nots.” I just need some assistance with this as it is a workable solution for MY group, and I don’t have half a clue dealing with CSS.

If you all could make a separate set of permissions/differentiate a super admin credential (dev acct), and can be enabled/disabled on standard admin accounts, man that would be phenomenal for private organizations that use discourse.

None of these concerns would apply to my use of discourse for the public board I run, but for a private organization, there are some access control tweaks that would really make discourse second to none.

3

I do not think you need an admin if you want to hide things from the forum.
Remove the administrator permissions.

Why do not create new groups, edit permissions, add people, edit category permissions, and so on?

4

No matter whether you have category permissions set to only one group, admins can still see it.

all i want to do is hide the contents of the category from admins. it’s a layer of accountability. the elected officers are not up to setting up and running this board. I am. But they aren’t going to want me to see their private workspace.

I thought I explained all this earlier.

I need to know what elements to hide in order to hide “impersonate” “messages” and contents within one category from non group users so that admins don’t see that category’s contents unless they are part of the executive group.

5

You got to take advantage of category muting. Muted categories are suppressed from the home page. So you can have every admin get a customized home page by muting a bunch of categories.

5 Likes
6

Thats a start! thanks @sam

Any idea what element Id I can use to hide the impersonate (admin private user settings) and messages (in admin view public user profile page) buttons? I can find the element ids in a specific page, but that’s not tenable for me to have to update this to every user page within the CSS.

7

I highly recommend reaching out to #marketplace here, sound to me like only an hour or 2 of CSS work would get you where you need to go.

8

What does the CSS solve if you’re the admin these buttons are being hidden from, and know they’re not actually hidden? You’re going to achieve more by painting whiteout on your screen.

If there’s stuff you shouldn’t see then I would suggest you read the RFC on encryption and input into that.

I usually only see this problem in unions and professional groups because elsewhere administrators are either trusted, or Rights Management is in place.

2 Likes
9

Good point. The other option would be to create a plugin that disables impersonation.

10

@Stephen

This is exactly the use case. Professional Union.

I’m not an (elected) executive officer.
I am an elected representative. One step below Exec. Officer. But I am our “tech guy” and this discourse instance is my idea and project to bring the organization more up to date rather than everything being done through email chains.

All I want to do is make it harder for me to access without being obvious in the logs (available to the other Execs.) that I’m snooping. It’s a peace of mind thing.

11

people would love this. there would be a lot of boards who could use this.

The group has agreed to use this for a trial period of 3 months. They won’t spend $ on dev work until its officially adopted. That would be my intent long term. But this is to take away the “easy” ways to snoop without leaving logs. Yes impersonate leaves logs, but reading messages through the user’s profile tab/messages button does not. I simply want it to be “obvious” that I am intentionally looking where I shouldn’t so they can trust the system.

Obviously it’s totally possibly to parse the DB through the root. But if I was doing that, they’d have bigger issues with me or any future admin.

12

Are you planning to give them admin rights so that they can see the log?

1 Like
13

That’s my point really, none of this is security, it’s security theatre at best giving the false impression of security where none exists.

It would be better to tackle attitudes to that, than create a facade of security - because if there is an incident where data gets out none of the above is going to protect you from being implicated.

14

yes. or at least mod. as mods can see logs too

but ideally this board should have another functioning co-admin and it should be one of those three. I truly intend this to be “decentralized” so it can transcend any one user who has a had day and tries to kill the site.

Also like I said, I get the security theatre issue. It’s what I have to work with at the moment. Until I can get them to allocate resources to develop plugins to do this. As of right now, this is a 3 month teat deployment. If the group really gets into this board, and we keep it, I can get resources allocated to do this right.

15

If it’s data you can never be trusted to not look at then you can only encrypt. The data is always there to access otherwise.

1 Like