Recent Topics

1 Sep 05, 2005 18:08    

Here's how I think this should be implemented:

Right now we only have an EDITOR role who can create anything, edit anything and delete anything.

The extra granularity we need is this:
- being able to only create/edit one's own stuff without being able to touch what belongs to others.
- being able to only edit stuff that belongs to someone with a user LEVEL lower than yours.
- being able to only edit stuff that belongs to someone with the same user LEVEL as yours.
(I am talking abou the user LEVELs you see on the user list screen. Those are basically useless currently and waiting for the above implementation.).

(For the sake of simplicity I am deliberately leaving out the "delete" problem. Let's talk about it later, once the "edit" problem is clear :)

The 2 additional LEVEL based cases allow for collaborative editing having a hierarchy of competence.

Furthermore on the lower levels, you might want to allow people to only post drafts and then have someone with a higher level validate those drafts.

In the User Interface, this would translate to the following:
We keep the same "wide" checkbox table we already have, but we replace the 5 checkboxes in the columns for Published, Protected, Private, Draft & Deprecated.

We replace those checkboxes with select lists. In a full implementation those select lists would have all of the following choices:
- No
- Own
- < Own Level
- ≤ Own Level
- All

Of course the current implementation is equivalent to only having the following choices:
- No
- All (except for PRIVATE, see below)

NOTE: for the PRIVATE status, even in the full implemtation, we would only have:
- No
- Own
Because only yourself can see the private posts, so there it doesn't make sense to have editing rights on stuff you can't even see. (We might actually want to allow some super admin to see other people's private stuff but that's different from what we have now and would probably bug quite a few users. "If you don't want people to post private stuff on your blog don't allow them from the beginning").

In the Simple display UI, this would add the following new radio options:
o Not Member
o Member
o NEW: Writer (can post own stuff)
o NEW: Editor (can edit < own level)
o RENAMED: Moderator (can edit anything; this is the existing "editor" level)
o Admin
o Custom

It doesn't hurt if all new scenarios resolve into "custom" in the beginning, however we should try not to break the Javascript when adding selects.

check/uncheck all won't make sense any longer and can probably be removed, since you can select the admin radio in the "Debug" mode. Maybe we should make the debug mode a feature and call it "combined" or sth like that.

I think this can all be implemented very incrementally, one step at a time, without breaking anything, except maybe for the 'magic' javascript. Halton if you can't get the script to work, just let us know and Daniel or myself will look into it.

Okay this is a bit long but nothing too weird I think. Does it make sense?


PS: I've said it before, but someone should remove the 'non members' part from those screens and replace it with a text entry named "add member:"

2 Oct 04, 2005 20:04

I did a hack along these lines but did NOT include a user interface. I really like the idea of “> or >=” your current level (or group). To me it’s both a feature (when you want collaboration) and a flaw (when your bloggers are entirely independent authors), and therefore should be something the admin can define on a blog-by-blog basis.

3 Nov 28, 2005 14:55

Go ahaed.
I’m witing for this to happen…

4 Filthio Dec 31, 2005 18:35


See debate at

I’d be very keen to see some further implementation of the user levels - could be useful. But what about separating the editing of COMMENTS from POSTS? The current antispam restrictions are very user unfriendly for innocent visitors trying to comment. It would be nice to have a user status which over-rides antispam (for admins), as well as a default entry-level permission for unverified users.