Project 9: roles for a restricted editor #

Real sites never give every editor the administrator account. In this project you give a group of club editors the right to work on their own part of the site, and nothing else, and you prove it. The steps follow Roles, policies and unactivated users.

Contents #

1. At a glance
2. Goal
3. Before you start
4. Tasks
5. Hand in
6. Rubric
7. Stretch goals

At a glance #

Goal #

A user group "Club editors" with one test user, a role that lets the group create and edit content only inside the "Student club" subtree, an assignment, and proof from the test user's side of what works and what is refused.

Before you start #

Read Roles, policies and unactivated users, sections "In short" and 1 to 5. Know:

• A role is a set of policies; it does nothing until it is assigned to users or groups.
• A user has every policy of every role assigned to them or to one of their groups.
• Every change in the role editor is made in a draft; nothing changes until you press Save.
• Prefer assigning roles to groups.

Tasks #

1. Write an access plan first: what may a club editor do (sign in to the administration, read content, create and edit in the club subtree, upload images for it), and what not (setup, users, other parts of the tree).
2. Create the group and the user. In Users, create a group "Club editors" and a user in it with an address at example.invalid and a password of at least 10 characters.
3. Read existing roles. Open Users > Roles and policies. Look at Editor (if your site package has it) and Anonymous; read their policies as sentences (section 2).
4. Build the role. New role, name "Club editors". Add policies with the wizard (module, function, limitations), for example content/read, content/create and content/edit with a Subtree limitation, and the policy that lets the user sign in to the administration's siteaccess. Press Save (section 3). Avoid any policy over every module, which gives full access, and any policy over the role module, which lets users give themselves any access (In short).
5. Assign it to the group, or with Assign with limitation to the subtree (section 5).
6. Test as the editor in a private window: sign in, create an article in the club folder, edit another, then try to create something outside the subtree and to open Setup. Note each result and message.
7. Fix and test again until the plan and the results match. Each fix is a change to the role, never giving the test user the Administrator role.
8. Read the role page with its figures and its policies as sentences, and compare it with your plan.

Hand in #

• The access plan, and the final role as the role page shows it (policies as sentences).
• Screenshots from the editor's side: a successful edit inside the subtree, and a refused action outside it.
• A short report: which policy you added last and why, and what "least privilege" means for this group.

Rubric #

Score the four common criteria of Grading your own work, and these checks (8):

1. The plan was written before the role.
2. The role is assigned to a group, not to the individual user only.
3. No policy over every module and none over the role module.
4. Create and edit are limited to the club subtree.
5. The test user can work inside the subtree, shown with a screenshot.
6. The test user is refused outside it, shown with the message.
7. The test user's address is at example.invalid.
8. The report explains the difference between a role and its assignment.

Stretch goals #

• Limit the role further by Class (Article and Image only) and test again.
• Add a translator who may edit only one language (Content languages, section 7).
• Give the editors the editor siteaccess instead of admin: it is the administration for content only, without setup, design and developer tools (Installing Exponential 6.0).
• Turn on two-step sign-in for the test user (How do I turn on two-step sign-in?).

Related pages #

• Study projects: overview
• Roles, policies and unactivated users
• Sharing one study site with a class
• Free documentation: this page is free to copy, translate and improve under the GNU FDL 1.3.