Culmination of Permissions Ruminations

godboko71

  • Fence accomplished!
  • Hello
  • Posts: 361
Re: Culmination of Permissions Ruminations
« Reply #15, on June 4th, 2013, 06:14 AM »
One of these days I will have time to expand on my posts. Maybe less storms this week and less guests oh and less other distractions.
Thank you,
Boko

live627

  • Should five per cent appear too small / Be thankful I don't take it all / 'Cause I'm the taxman, yeah I'm the taxman
  • Posts: 1,670
A confident man keeps quiet.whereas a frightened man keeps talking, hiding his fear.

emanuele

  • Posts: 125
Re: Culmination of Permissions Ruminations
« Reply #17, on June 5th, 2013, 04:00 PM »
Interesting discussion! :D
Quote
tl:dr; do we actually *need* or *want* post count permissions? It seems like it has served to confuse people more than it has helped them.
As you underlined an important thing would be to have groups able to inherit permissions (or whatever) when post count increases (i.e. 0+, 50+, 100+ as you described).
This is probably the most useful thing about post-based groups.
Not sure how else use them since I always prefer to set my permissions in stone. :P
Quote
tl:dr; The idea of primary/secondary groups is obsolete, I want to move them to a separate table, and I have funky ideas about changing post count groups including their permissions if we still want them.
Move groups to a separate table is something I was considering me too, though I've never been in the mood of actually do it (mainly because I find a pita write the upgrade scripts... :angel: )
Quote
Also tl:dr; I would explicitly add *everyone* to 'Regular Members' if they are logged in. This seems more logical to me that the current situation which is a by-product of the primary/secondary group antics.
That (having "regular member" lost when changing the primary group) is one of the things that confuses people more than anything else I think (at least it is frequently confusing for me :P).
Quote
tl:dr; We could reformulate admin powers to be less overarching and more granular. This has consequences for management too.
That's one of the few things that is not in a public board at ElkArte (mainly because the proposal was submitted as a security/privacy issue), the current "SMF-like" admin has a lot more power than usually needed for the classic "co-admin".
What I had in mind can be sort of summarised in two admin "roles": one that has access to the server (and so it can do *anything*, in fact the current SMF-like admin), and another one that doesn't have access to the server and so he can still do many "admin" things, but not any that requires some server interaction (mods, themes, server settings, etc.).
I don't necessarily mean there should be two groups, but that some permissions should be redistributed and separated from the admin_forum.

Arantor

  • As powerful as possible, as complex as necessary.
  • Posts: 14,278
Re: Culmination of Permissions Ruminations
« Reply #18, on June 5th, 2013, 09:55 PM »
Quote
As you underlined an important thing would be to have groups able to inherit permissions (or whatever) when post count increases (i.e. 0+, 50+, 100+ as you described).
This is probably the most useful thing about post-based groups.
Not sure how else use them since I always prefer to set my permissions in stone. :P
I have in the past suggested just attaching min/max post counts to permissions and essentially leave post counts/groups as not having actual permissions.
Quote
Move groups to a separate table is something I was considering me too, though I've never been in the mood of actually do it (mainly because I find a pita write the upgrade scripts... :angel: )
In our case there is still one place where we need primary groups, and that's to figure out what colour to assign to people, bah.
Quote
That (having "regular member" lost when changing the primary group) is one of the things that confuses people more than anything else I think (at least it is frequently confusing for me :P).
It is confusing. It's one of the many exciting and confusing things about SMF.
Quote
What I had in mind can be sort of summarised in two admin "roles": one that has access to the server (and so it can do *anything*, in fact the current SMF-like admin), and another one that doesn't have access to the server and so he can still do many "admin" things, but not any that requires some server interaction (mods, themes, server settings, etc.).
Well, plugins already explicitly require FTP in Wedge - it simply isn't possible to upload a plugin unless you have FTP or direct physical server access - the old uploader has gone. Other stuff has not yet gone but likely will in due course.

And yes, some permissions should be split off.
When we unite against a common enemy that attacks our ethos, it nurtures group solidarity. Trolls are sensational, yes, but we keep everyone honest. | Game Memorial

Dragooon

  • I can code! Really!
  • polygon.com has to be one of the best sites I've seen recently.
  • Posts: 1,841
Re: Culmination of Permissions Ruminations
« Reply #19, on June 6th, 2013, 08:32 AM »
This is feeling like an awfully familiar discussion, and I feel like I've said this before, but what about plugins? Every big plugin on SMF has had their own permission systems defined. That's not good, right?

But all in all roles is definitely a better route to go, and perhaps drop post-count based groups but instead have something like event-based groups? Where one can define events at which different groups can be assigned to a member, and that way one can hook into post counts, karma, likes etc.
The way it's meant to be

Arantor

  • As powerful as possible, as complex as necessary.
  • Posts: 14,278
Re: Culmination of Permissions Ruminations
« Reply #20, on June 6th, 2013, 02:33 PM »
They did, for the simple reason that they all needed something SMF's couldn't provide. SMF, conceptually, offers 'everywhere' and 'in this board' permissions.

I've proposed in the past various ways to fix that, and solving it really isn't the big headache it sounds like. Right now we have the 'membergroup' and 'board' permissions. I see no reason why it needs to be a ball-ache to create other entire classes of permission.