Scoop -- the swiss army chainsaw of content management
Front Page · Everything · News · Code · Help! · Wishlist · Project · Scoop Sites · Dev Notes · Latest CVS changes · Development Activities
Changing Group & User Management in Scoop New Code
By hulver , Section Project []
Posted on Fri Aug 15, 2003 at 12:00:00 PM PST
For a while now, I've been dissatisfied with the way Groups work in Scoop.

It's OK for simple applications. Once you start getting into slightly more complicated things though, it starts getting silly.

Take subscriptions as an example.

If somebody subscribes, they are moved to a different group. This group has got exactly the same permissions as the normal users group, except for a couple of extra permissions to use the spell checker and hotlist_flex box.

Now what happens if a subsribed user mod-bombs somebody? They're ratings are undone, and they're moved to an "un-rateable" group.

Except, whoops. They've just lost all their subscription perks.

So, you have to create another group, call it "subscribed un-rateable" and manually move them there.

Now, I've got an idea for a scoop site where there would be many editors. Each editor would be responsible for a specific section. They can post stories straight to that section. Now what do I do? I have to create a group for each section. If I have subscribed users then I have to create 2 groups for each section.

I've got an idea for a more flexible approach.

Each user can belong to more than 1 group. Many groups in fact.

This makes the section permissions easier. You want somebody to be able to post stories straight to your "LUG" section, but also to your "BSD" section?

Just add them to the LUG-Editors group, and the BSD-Editors group.

How do you deal with taking permissions away?

Well, there are two ways to do this. You could create groups for permissions that you might want to remove from people. However, when it gets down to that, you might as well be assigning permissions on an individual basis.

Or, you could create another state for permissions.

At the moment we've got "On" and "Off". With another state of "Always-Off" you could make sure that somebody never has the Comment-rate permission for example, even if another group says they can have it.

< AutoFormat as default input? | RFQ >

Menu
· create account
· faq
· search
· report bugs
· Scoop Administrators Guide
· Scoop Box Exchange

Login
Make a new account
Username:
Password:

Poll
What do you think?
· Good Idea 75%
· Bad Idea 0%
· Too complicated 25%
· Something else 0%

Votes: 4
Results | Other Polls

Related Links
· Scoop
· More on New Code
· Also by hulver

Story Views
  48 Scoop users have viewed this story.

Display: Sort:
Changing Group & User Management in Scoop | 12 comments (12 topical, 0 hidden)
Unix vs. VMS groups. (none / 0) (#1)
by haflinger on Fri Aug 15, 2003 at 06:36:19 PM PST

You're basically proposing VMS-type identifiers to be used for groups. Scoop's current grouping scheme is based on Unix groups.

Of course, I love VMS, so I'm all in favour. But be warned of the kettle of worms. Or perhaps cauldron.



Look to other existing solutions (none / 0) (#2)
by rusty on Fri Aug 15, 2003 at 08:51:48 PM PST

I always thought there should be a user-level axis to permissions in addition to groups, which would basically mirror unix file permissions. So you'd have group perms, for large-scale permission granting, and user-level perms, for fine-tuning one particular user.

For your examples, the ratings abuser could remain in the subscriber group, but lose the permission to rate comments at the user level. If you wanted your editiors to be able to edit some sections, you'd just add what sections they can edit to their user perms, and leave group at a general "editor powers" level. That kind of thing.

I think the reason we didn't do this to begin with was just that no one needed it. But there's no compelling reason it couldn't be done. You'd just need either a field in users to store the user-specific permissions, or a table that links a uid with some perms. Probably a field in users would be best, since you already have a record for everyone. You'd need a syntax that would allow you to specify the removal of a perm, as opposed to groups which just enable them, because the fallback if something wasn't mentioned at the user-level would be to use the group perm. And then after the group perms are loaded for a user, you'd load the user perms and modify the actual perm set accordingly. 90% of the coding would probably be the interface, because the backend code is dead simple.

This is not to say that multiple groups isn't an option too. Just that it might be a little bit tricky due to that perm conflict thing you mentioned. Though with individual perms as well as multiple groups you wouldn't have to worry about that. Individual perms always trump group perms, so setting a user to "can't rate" will overrule any group she belongs to.



Had something similar planned out (none / 0) (#3)
by panner on Fri Aug 15, 2003 at 09:36:42 PM PST

There was a plan all worked out for something like this where multiple groups could be assigned, and the perms could override each other through something like inheritance. However, I don't remember it exactly right now, so I need to map it back out. Unfortunately, I don't have time to do that right now. So, stay tuned for an alternate version.



--
Keith Smiley



This kind of dovetails well with an idea I had... (none / 0) (#4)
by CaveMan on Sat Aug 16, 2003 at 12:46:55 AM PST

...about 'auto-promotion' of accounts between groups. Similar to what happens now with subscriptions where subscribers are upgraded from a 'user' group to 'subscriber'.

Auto-promotion would allow for things like 'trusted-user' status to work without being a special case throughout the scoop code. When someone's mojo crossed the TU limit, the auto-promotion code would promote them to the TU group. Mojo falls below TU limit, they're demoted back to regular user status. This would also allow admins to give trusted users additional permissions, if they so wished.

Having multiple groups would simplify this. Rather than changing what group the user is in and dealing with all the possible 'state-change' possibilities, the trigger would only have to add or remove a permission group.

Next, I just have to come up with a generic way of setting up the trigger to mediate the promotions.

Mike
--
#import <sig>



Would Access Control Lists work? (none / 0) (#6)
by wedman on Tue Aug 26, 2003 at 01:26:20 AM PST

I've always thought that ACLs made more sense, in terms of flexibility. I've implemented them before (in PERL even!).



Whose only theme is Chanel (none / 0) (#7)
by Gabrielly on Fri Aug 05, 2016 at 02:33:33 AM PST

Chanel's handbag lookbooks are always fun; they usually contain 35 to 45 bags, ranging from casual looks like denim or canvas to eye-popping exotics and pieces that feature heavy beading longchamp outlet or embroidery, all of which give Chanel fans a very good idea of the full lines they'll find in stores. For Pre-Collection Fall 2016, Chanel has been even more generous: its just-launched lookbook features 64 brand new bags. In this replica handbags uk collection, there aren't any heavy pop cultural influences, as has been common in seasonal Chanel collections of the recent past. Instead, Karl Lagerfeld and his accessories team went back to basics, with rich ray ban outlet tweeds, quilted leather and embellished python. Every couple of years, it's nice to have a Chanel collection whose only theme is Chanel. Take a cheap monster beats look at the bags and their prices below; this collection is currently available in Chanel boutiques worldwide.



Leather Pants (none / 0) (#8)
by jasonmorgan on Tue Jul 10, 2018 at 02:59:33 AM PST

Having different gatherings would rearrange this. As opposed to changing what aggregate the client is in and managing all the conceivable 'state-change' potential outcomes, the trigger would just need to include or evacuate a consent gathering. Leather Pants



Thank you (none / 0) (#9)
by scdobre on Mon Feb 18, 2019 at 04:28:15 AM PST

I hope to see more projects from you gmail email login



simple (none / 0) (#10)
by scoby on Fri Apr 17, 2020 at 06:57:10 AM PST

forex trading made simple forex rating



great (none / 0) (#11)
by heenacruzl on Sat Jul 11, 2020 at 03:34:42 AM PST

The things you give are very convincing, I have read it many times and feel very logical. This is my own opinion, but many people may not be like that, but I hope you continue to develop to have more similar articles. game



prime factorization (none / 0) (#12)
by Jack Son on Sat Dec 05, 2020 at 08:00:16 AM PST

Just admiring your work and wondering how you managed this blog so well. It's so remarkable that I can't afford to not go through this valuable information whenever I surf the internet! prime factorization



Changing Group & User Management in Scoop | 12 comments (12 topical, 0 hidden)
Display: Sort:

Hosted by ScoopHost.com Powered by Scoop
All trademarks and copyrights on this page are owned by their respective companies. Comments are owned by the Poster. The Rest © 1999 The Management

create account | faq | search