Create Policies and Restrict Access in eZ Publish

Step by step, restrict educator access.************************************************

Create a content subfolder for testing. Restricting access can too easily leave portions of the site unviewable to WWW. You are forewarned.

Presumes a site content structure below the Home page in <school name>-<grade level> - <teacher name> format. In this case below "Home" is Halfway RIII folder containing Kindergarten folder, with a sub-folder for each Kindergarten teacher.

1. Section off part of the site, name it by school-grade-teacher

A. Admin->Setup->Sections->New Section, Navigation part:->Content structure.

Initially all that is possible is to give it a name, Halfway-K-Ann

B. IMPORTANT - After the section is named, use the + sign icon on the right-hand side to assign the section to a subtree within site content by browsing and clicking "Select" Select the "Ann" folder pictured above. SEE TROUBLESHOOTING BELOW, forgetting to make this section assignment can be a difficult to debug down the road.

Section creation is complete, this section is where Ann will have complete access. There is not yet an "Ann" user.

2. Switch completely out of the Setup tab, and into the User accounts tab. Admin->User Accounts->Roles and Policies in the left pane, click the link to create a role named for the school-grade-teacher, like HW-K-ann.

Then a button appears, click "New policy" to define the policies for the role.

Step one: select module -> Module:Every module: drop it down and select "Content"

Click the "Grant access to one function" button, drop the function: list down, select "Read"

Click the "Grant full access" button, click "OK" at the bottom of the page.

For the next policy, select "content" at step 1, Grant access to one function-Create.

This time click the "Grant limited access" button. The idea is to restrict content creation to just the section created above. Select the "Halfway-K-Ann" line in the Section: box before clicking the "OK" button.

Next policy, "content" at step 1, "Edit" in function list. restrict editing the same way create content was restricted, to just the "Halfway-K-Ann" section.

Next policy, "websitetoolbar" at step 1, "Grant access to all functions" button click.

Summing up progress to this point, a new section was created, so it could be used to create the Role as pictured below.

Next, create a new user, Ann, in the "Partners" group. Still in Admin->User Accounts, Click "Partners" in the upper left pane, and at the bottom of the window that is displayed is a "Create here" button, with "User" preselected in the options list. Click "Create here" and fill in the details for the new user. By creating this new user in the "Partners" section, all roles applied to "Partners" are preset upon the newly created user. The "Partners" can do everything we need the this user to do, except for the HW-K-Ann Role created above.

The next step is to mate user "Ann" to this role. This is not very intuitive in the GUI. Easy to see users and user groups, easy to forget the "Roles and Policies" link. Click that link to display the roles, including the newly created role. The + icon to the right of the role allows assignment of this role to any set of users or user groups. Assign the role to the new "Ann" user.

Then login as Ann, and browse to the new section. Anywhere in site content, except for the new section, the website toolbar is available, but restricted, only the sort icon is displayed, because that is Ann's only permission sitewide.

When "Ann" logs in and clicks that link, full content create and edit capabilities are awarded to her within the Ann section of site content.

Permissions structures can be a little confusing for first timers, and difficult to set up. But after they are set up, they are dead simple to admin. You may soon enough find this preferable to systems that make setup simple, but quickly turn into a confusing quagmire on the admin side.

Flexibility (the above is not the only way to achieve the desired end), and ease of admin were apparently high on the list of goals for developers tasked with implementing permissions within the system. From those two perspectives, the system is hard to beat. The tradeoff for flexibility, is making the system simple to understand for first time users. It just isn't simple, will never be simple, too many options, too many way to achieve the desired outcome.

Anonymous users are casual web viewers, that concept is easy to understand, as is the concept of admin and admin login. Creating a new "Member" and a new "Partner" user, logging in as that level of user, comparing what can be achieved with each of those login classes to the Roles assigned is informative and worthwhile to more fully grasp permissions concepts.

Troubleshooting

Most common problem is at the first step, when creating the named section, failing to assign the named section to a real section within the site. Viewing the section assignments, everything looks correct, but permissions do not work, the user does not get their special permissions. Go back and check, and likely will find the section was created with a name, probably the section name, yet the section was never assigned in site content. Too easy to make this mistake, and difficult to debug.