Jump to content

Module: Dynamic Roles (for PW 2.4.6+)


ryan

Recommended Posts

Dynamic Roles are a powerful access control tool for ProcessWire. They pick up where traditional roles leave off, and allow you to assign permissions at runtime based on any factor present with the user. Once a user receives one or more dynamic roles (at runtime), those dynamic roles then specify what pages the user can view, edit, or add children to.
 
If traditional roles are a sledgehammer, Dynamic Roles are a scalpel, allowing nearly any finely tuned access control scenario. Traditional ProcessWire roles are limited to assignment of view/edit/add access on a per-template basis. Dynamic roles go outside those limitations and enable you to assign that access based on any factors present with a page (i.e. match any field values).
 
Dynamic Roles assign new access, but do not revoke existing access provided by traditional roles. As a result, Dynamic Roles can be used together with traditional roles, and the two work beautifully well together. Though Dynamic Roles can also replace all situations where you would use traditional roles for access control assignments. If using Dynamic Roles to assign page-view access, you would typically want to use traditional roles to revoke view access from at least the "guest" role at the template level. Then use Dynamic Roles to assign view access to those pages in a more granular manner.
 
This module directly affects the results of all page getting/finding operations by applying the access control directly to the database queries before pages are loaded. As a result, it is fast (regardless of scale), pagination friendly, and requires no further intervention by the developer other than configuring the dynamic roles as they see fit. Because it relies upon new features present only in ProcessWire 2.4.6+, it requires the current dev branch. 
  • Sponsored by Avoine
  • Concept by Antti Peisa
  • Code by Ryan Cramer

post-2-0-45292900-1404331427_thumb.png

PLEASE NOTE: This module is in pre-release state (like the PW dev branch it requires) and is not recommended for production use just yet. Though we do appreciate any testing and/or feedback that you are able to provide.

While not required, this module benefits from ProFields Multiplier. If you have ProFields Multiplier installed before installing this module, it will make this module more powerful by making all of your access control selectors have the ability to use OR-group conditions. Depending on your access control needs, this enables you to accomplish more with fewer Dynamic Roles.
 
 
 
How to install
  1. Make sure you are running ProcessWire 2.4.6 (dev branch) or newer. 
  2. Download from GitHub (we will add this module to the Modules directory later). 
  3. Place all files from this module in /site/modules/DynamicRoles/.
  4. In your admin, go to Modules > Check for new modules.
  5. Click "install" for the Dynamic Roles module (ProcessDynamicRoles).
  6. Click to Access > Dynamic Roles for the rest (see example and instructions below).

Example and instructions

Lets say you ran a Skyscrapers site and wanted a role enabling users with "portmanusa.com" in their email address to have edit access to skyscrapers designed by architect John Portman, with at least 40 floors, and built on-or-after 1970. Yes, this is an incredibly contrived example, but it is an example that also demonstrates the access control potential of this module.
 
1. In your admin, you would click to Access > Dynamic Roles.
 
2. Click "Add Dynamic Role". Enter a name for the dynamic role, like: "skyscraper-test-editor" and save.
 
3. Under "Who is in this dynamic role?" section, click "Add Field" and choose: Email => Contains Text => "portmanusa.com". This will match all users having "portmanusa.com" in their email address.
 
4. Under "permissions" check the boxes for: page-view and page-edit.
 
5. For this contrived example, we will assume the user already has view access to all skyscrapers, so we will leave the "What can they view?" section alone.
 
6. For the "What can they edit?" section:
  • Click "Add Field" and choose: template => Equals => Skyscraper.
  • Click "Add Field" and choose: architect => Equals => John Portman.
  • Click "Add Field" and choose: floors => Greater Than Or Equal => 40.
  • Click "Add Field" and choose: year => Greater Than Or Equal => 1970.
7. Click Save. Now users matching the conditions of your dynamic role will be able to edit the matching pages, but not any others (unless assigned by traditional roles).
 
 
  • Like 48
Link to comment
Share on other sites

Interesting.  When is the dev branch expected to be officially released?

 

There's a direct link to our dev branch on the download page. A lot of us use the dev branch for non-live stuff, sites in development, etc., and sometimes production sites when they are not mission critical, or if we need a feature that's only available on dev (and can keep an close eye on the site). The dev branch represents the next major version of ProcessWire, which would be 2.5 in this case. Once momentum drops on adding/fixing things and no major problems in the queue, we'll release it as 2.5. We haven't nailed down a date on that, but I think we're getting close. But if you want to start using it now, and don't mind watching for and reporting issues, use the dev branch. 

Link to comment
Share on other sites

I think this will become a default in future projects.

I think the one of the many super cool aspects here is that this beast sits on top of the current role system. So if you have all setup, but you want to add all those users with certain criteria (like email, age, some page relation etc) view or edit something that they currently cannot, then just add this in and all just works. Without this module, those scenarios would be pretty much impossible.

Hopefully many of you find this interesting. There are huge possibilities, so this is also pretty big one to test. I am sure there will be few edge cases, but Ryan has already thought many of those (like doing edits, that remove the editing rights, adding new pages and then saving it with values that are not available etc).

  • Like 3
Link to comment
Share on other sites

Yes, I understand :) And I think 90% doesn't need this kind of UA management, but those that do, will benefit this greatly.

So hoping for eager testers, but not on live site fellows.

  • Like 2
Link to comment
Share on other sites

This looks great. Thanks to all involved.

However, I can't work out the following.

I'd like to be able to create a role called newusers within Roles and then select all users who have that role via the use of Dynamic Roles. Then I can use the Dynamic Roles to select what that user group has access to as it's clearly more flexible. However, it seems when I choose custom (field=value) and input roles=newuser it doesn't work. The search tells me that members have been found (see attached pic), but when I click on the Show link, there are no results found. Also, it fails to save.

post-2170-0-62372000-1404413440_thumb.pn

Cheers!

Link to comment
Share on other sites

Ah, you are right. It can be found if you go to Access => Users and use InputfieldSelector there (in regular fields). That must be because roles is system field. 

Good find, I think this will be fixed soon (I would assume roles is pretty common selector there :)).

Link to comment
Share on other sites

I've pushed an update to this module that corrects the issue with roles missing from the user selection options. Also pushed a minor core update that should correct the issue with users not showing up in the preview modal. They weren't showing up because pages in the admin were excluded, and users are pages in the admin. 

  • Like 2
Link to comment
Share on other sites

I have come across another issue. Maybe I'm overlooking something.

I'm using the dev branch for the purpose of testing this module, so it's a fresh local install. Basically frontend pages are showing up when they shouldn't be. The steps I used are as follows.

1. Create a new role called newuser.

2. Create a new user called testuser and add this user to the newuser role.

3. Go to the basic-page template and remove view access for guest and newuser roles.

4. Log in as testuser and confirm that the pages using the basic-page template aren't visible via the frontend.

5. As admin, create a new dynamic role with the following: name - Equals - testuser (for who), and template - Equals - basic-page (for the view).

Now as expected, the pages using the basic-page template appear again. However, if I now go back into the Dynamic role settings and delete (template - Equals - basic-page) and then save, the pages using the basic-page template are still visible when logged in as testuser when they shouldn't be. The only way to correct this is to delete the whole Dynamic role, and then it works as expected again.

Link to comment
Share on other sites

  • 1 month later...
  • 2 weeks later...

I just tested this and I can confirm this happens like you describe.. though that could be intended (but can't say) in it that you just remove the "what" to view filter, but the dynamicrole is still there saying that user "testuser" can "view" pages...

But the fact that you delete and create a new dynamicrole with no "What to view" filter set, the basic-page pages aren't viewable anymore, unlike the other case. So definately something spooky going on here.

However you better open an issue on github on the module repository as it is more likely to be seen there by Ryan: https://github.com/ryancramerdesign/DynamicRoles/issues

and refer your post.

  • Like 1
Link to comment
Share on other sites

  • 2 weeks later...

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...