Users and roles
By Ed Mitchell 18th February 2010
That’s right folks, we’re using the word ‘user’. We love you dearly and know that you are humans with hearts and souls, but the word is so useful that we can’t avoid it. Just to prove it, here’s a photo of one (representing his local TT initiative at a Bristol street fayre):
- Dan from TT Montpelier with his ‘wish tree’
So now we’ve got that out the way, here’s our view on the different users and their related roles in our system. Dan will be a ‘primary point of contact’ and ‘Initiative Profile admin’ (not that he knows that yet)…
Anyone spots anything amiss, let us know and we’ll be very grateful – here’s a direct copy of the transition technologist work from our workspace:
Note: (You all know this, but I’m guessing many users of the site don’t…) Roles, like the permisions they wrap up, are cumulative. This means that users should be given the right combination of roles to do the job. For example, the Administrator role does NOT need to write newsletters or develop the site, so if an Administrator needs those facilities, they get given the ‘Newsletter Writer’ and ‘Developer’ roles as appropriate – rather than bloating and complicating the Administrator role. This is Jim Kirkpatrick’s work…
Normal User Roles (The General Public)
1) Anonymous Users (Unregistered)
Can:
- View content (not private stuff)
- Add comments to content types that allow it
- Download attachments
- Sign up to newsletter (anonymously, by email address only)
CANNOT:
- Get notifications (by group, content or author)
2) Pre-registered (Registered but not email validated)
This is LoginToboggan role to allow users to start using the site immediately rather than have to go to email verification first. These users can do what Anonymous users can, plus can:
- Create a User Profile
- Get notifications, follow users etc, join groups,
3 A) Registered Users (Email has been validated)
Can do what Pre-Registered users can, Additionally, they can:
- Create an Initiative or Project Profile
- Create News or Events for an Initiative Presence
- Create new Forum post
- Flag as ‘nonsense’
- Upload/attach files
3 B) Initiative/Project Profile Admin/Editor (Set as author/editor of an a given Profile)
NOTE: This role doesn’t really exist, these users get their permissions over their own Initiative or Project Profiles by being the ‘author’ – or by being one of the users referenced by the ‘Initiative Profile editable by’ field. Such users MUST be fully registered and can do everything a registered user can plus:
- Edit ‘their’ Initiative or Project Profile
- Add/change users able to edit the profile
4) Editorial & Focused Administrative Roles (The Content Team)
These have a little more responsibility and can do what Registered users can, plus what is listed below:
4 A) Forum Admin (Forum host/moderator/admin)
- Moderate all forum activity (create/delete/edit ANY forum post)
- Administrate Forums (create/edit/remove forum containers and fora)
4 B) Events Partner (Partner event adder)
- Add Imported Events
- Edit their events
4 C) Community Microsite Admin (Initiative Presence or Workspace admin)
- Manage membership of the initiative
- Edit the Initiative Presence
- Manage/edit/delete all group content in within the Initiative Presence
- TODO import new members with firstname, lastname, email, standard password (and username auto-completes)
- TODO Set up new group admins
4 D) Newsletter Editor
- Can write, complile, manage and send newsletter
- Can build/manage NodeQueues of posts to be used in the newsletter (this functionality is not fully implemented yet, but most the bits are ready)
4 E) Site Editor (network staff or movement)
- Can generally edit/create/delete most content
- Do general content administration
5) Administrative Roles (The Website Gods)
Can do what Registered users can, plus what is listed:
5 A) Site Admininstrator (BB, EM)
Can do everything a Site Editor can
- Plus can do everything administrator should be able to including managing users and their permissions (I think only Developers need this power but have left it in for now)
- Edit the ‘Status’ flag for Initiative Profiles
CANNOT
- do ‘development’ type tasks, or access dangerous features like using PHP within nodes
5 B) Developer
- Can do developer tasks, rare settings changes, use PHP in sensitive areas and nothing more
5 C) Transition Admin = User 1
This is the user 1 account, has access/permission to do everything. Only people updating the site’s modules need to know about or use this user account. Presently only John, Ed and I have this password…