Security - negative rights (how?)

(why explained last)

We have Create and See rights etc. I would need an easy way to implement See for a group for the entire site, except a few areas, basically a negative right coming into effect at higher priority.

Just thinking out loud here, as testing all the possibilities I can think of would take some time. Kinda hoping someone would say, why don’t you do it this way…

I guess I could create a group that gets See rights only. I’m guessing Discourse might be smart enough that if someone has See rights and everyone Write rights that area would become See only for the group? This would be a kind of automatic negative right implementation (cheapest option), although not a logical one. The problem is, even if it worked, going through all areas adding a group for “nasty but needed” users would take some time.

Cannot remove a user from everyone, uhum.

Creating a new pseudo-everyone with everyone but misbehaving users would be massive work (maybe not with a script but still).

Like I said, thinking out loud trying to solve the problem… hoping I would get an ahaa moment really :smiley: .


The actual problem is one user writing his posts into whatever area he is currently reading (often the newest post of anything). Not a biggie except the posts are so incoherent they are bound to disturb other users. Problem is, he is absolutely needed in one area (100%, money area) but I’d be happy to close him out into seeing mode everywhere else.

Most of the forum consist of locked areas, thankfully, but people still get weekly mails or whatever when he spreads into one of the few common areas.

3 Likes

I think the closest that you could get to this with Discourse is to silence the user, which would let him read/see but not post:

https://meta.discourse.org/t/discourse-moderation-guide/63116#silence-the-user-26

It’s not granular enough to allow him to post in certain categories only.

But as the moderator guide mentions, an option is also to try and reach out to the user first, before resorting to the silence/ban features:

https://meta.discourse.org/t/discourse-moderation-guide/63116#the-difficult-user-22

1 Like

No, those permissions are always additive.

4 Likes

Yeah, unfortunately this doesn’t work as he owns half the forum and 95% of the time is needed for decisions :slight_smile: . Oh well, rare enough and cleaning isn’t much of a chore (skipping the questions where his posts went). A nice tech solution could always rely on “technical difficulties” as an answer :wink:

Just had a chat, apparently he starts spamming all over when he reaches some level of max 3 posts. But maybe I got him moved away to messages again until he forgets it next time…

Hmm, locking his trust level at 0 or something might be useful :smiley: .

1 Like

I’ve pretty much always said negative permissions (usually) is a result of bad design. I’m amazed I found a situation where they would actually come in handy.

It’s pretty much a bitmask after all, first apply all additive permissions, all negative ones last.

I could see this being useful for elderly people (not politically correct example), only allowe them in the how-to-use area and then whatever area their particular group is interested in.

Guess I have just been lucky making almost all areas walled off, so by default, people never get disturbed by things they aren’t interested in. People actually marking an area as “not watching” or muted is too difficult for 99% of users. Or setting daily/weekly digests to off, easier to move everything to spam and then complain they never got a notice about something :smiley: .

1 Like

Another example would be if you want specific people banned from for instance marketplace.

I’ve been working on a plugin that allows dynamic groups so you can do boolean algebra like

groupA = groupB AND NOT groupC

and groupA will automatically update if people join or leave groupB or groupC. My plan is to finish it in the next month or so.

4 Likes

This concept was also being discussed here before:

I’m still in favor of it :smiling_face:

1 Like

Cool, search usually finds similar things but finding the correct words here was a chore :slight_smile: . Basically a exclude rights group which always has final/top priority would be the easiest way (not multiple groups or anything too fancy).

Oh well, doesn’t sound like this will appear anytime soon if ever.

I have written two inherited + exclude permission systems in my life and while they felt quite difficult to write, once you get the logic and ordering correct they did work like a charm (and not a lot of code either). Not many people understood how either worked though . 4 levels of allowed inheritance and excluding probably requires Mensa level or something. Even when you have use cases for all levels.

1 Like

So the problem is that he can’t post where you want him to so he starts posting other places. [quote]
Number of posts in a row a user can make in a topic before being prevented from adding another reply. This limit does not apply to the topic owner, site staff, or category moderators.
[/quote]

So the solution is to see that he can post where you want him to. Is it max consecutive replies that’s causing the problem?

that he’s hitting because he won’t edit posts and instead just keeps replying to himself? Maybe just change the setting or teach him to edit?

1 Like

Well, the real problem, which kinda was implied vaguely, is that the forum doesn’t have an alco lock. Then again, he doesn’t really need to apply for a job ever so spelling it out doesn’t actually matter.

So more a question of, replies pop up after whatever he read last. Training is not too helpful after the 15th beer :smiley: . In this case, even restricted access outside 9-17 wouldn’t help. Quite enlightning texts actually, problem is, once you mention (any) god and the existance of or not you are bound to offend half the planet…

So even if this stops the conversation (as partially unsolveable :slight_smile: ), the tech parts you sometimes wish you had considering normal users are still valid.

2 Likes

That’s a hard problem.

Basically, a massive code level overhaul of permissions is needed to do anything in this space.