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
  34 Scoop users have viewed this story.

Display: Sort:
Changing Group & User Management in Scoop | 6 comments (6 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!).



Changing Group & User Management in Scoop | 6 comments (6 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