Configuring users for multiple sites/permissions/workflow

(Hourihanj) #1
We are in the process of working out how best to configure our back-end/easy-edit users within Matrix, for an installation with multiple sites and 1000+ users.
 
We would like to: 
  • Use LDAP to create shadow asset users in Matrix (with permissions)
  • Control user access to sites (using permissions)
  • Establish workflow for specific pages within each site (with email notifications)
  • Easily maintain editor and approver permissions (through inheritance)
These are the options we are exploring, but would appreciate any expertise in the best way to do this.
 

1. Create nested User groups - This will create a lot of user groups and duplicated workflows

 

 - Approvers (user group)
    - Site 1 Approvers (user group)
       - Site 1 approver Joe (user)
       - Site 1 approver Jane (user)
    - Site 2 Approvers (user group)
       - Site 2 approver Tom (user)
       - Site 2 approver Sally (user)  
 - Editors (user group)
    - Site 1 Editors (user group)
       - Site 1 editor Jack (user)
       - Site 1 editor Sarah (user)
    - Site 2 Approvers (user group)
       - Site 2 editor Dave (user)
       - Site 2 editor Kate (user)
 

2. Use Roles alongside User Groups - Does this still have an impact on the performance of Matrix?

 
3. Use some clever linked-user structure - Is there an approach for this?
 
 
Thanks in advance
James
 
(Bart Banda) #2

I would recommend option 1, using user groups and applying permissions to those. Roles do have a performance hit in Matrix. 

(Hourihanj) #3

Thanks for your advice Bart.

 

Just to pick your brains a little further, we noticed when testing this that we had to create duplicate workflow schema (same steps but different user groups) to avoid blanket workflow notifications going to the wrong people (i.e. approval email just goes to "Site 1 Approvers" rather than the entire Approvers group)

 

Is there a way of simplifying this in Matrix?

 

All the best

James

(Bart Banda) #4

You could use streams as well, but that's essentially the same thing except that it's kept within the 1 schema. You would also need to give the editors admin rights to the asset to be able to select which stream. Other than that, you are probably best of with a schema per site. 

(Tim Davison) #5

We have a similar setup to your option 1 using with shadow assets and roles, and we have to use roles to map users and/or user groups to steps in a workflow.  But this allows us to use a global workflow for all sites on the instance.  You just make the workflow condition a role rather than a user group, and then for each asset you assign the user and/or user group to the role for that asset, rather than a blanket one for the site.  When the asset goes into workflow, it uses whoever is assigned to that role for that specific asset.  This mean workflow emails are targeted to specific people/groups and allows us to assign permissions separately to conditions steps in workflow.

 

One of the issues we have had recently with another instance is they went the path of multiple workflow schemas and have now found themselves in a situation where they need to update all of their workflow emails (department has been renamed, restructured, etc) but that means updating 500+ custom emails in workflow (there's multiple per workflow step).  If you don't need/want to customise workflow emails, then this is irrelevant.

 

A note about inheritance: Roles and permissions can be automatically cascaded in Matrix - just set them correctly on the top-level pages and make them auto-cascade.  For some roles we have a trigger to set the role (e.g. the person who creates the asset is assigned to the asset 'Owner').  But be careful, automatic cascades are *not* the same as inheritance.  This is a subtle distinction that has caught us out several times.  Roles/permissions/schemas/workflow can all be cascaded at the point of creation and/or linking under an asset, but once assigned it's assigned - there's no way to say to Matrix "I'll have whatever the parent's having", so if you move assets around a lot they can end up with multiple, not just what the current parent asset has.  Perhaps this would make a good feature request???

 

Not sure how much roles actually affects performance, and at which points (e.g. I kinda don't mind a little extra time on authoring, but I don't want my page presentation to slow down).  Perhaps Squiz engineer has some actual info on performance hit?

(Hourihanj) #6

Hi Tim

 

Thanks very much for your post. Its great to hear from someone using roles in Matrix, as they seem to offer a lot of flexibility within workflow/permissions.

In regards to the performance hit, how many sites/users do you roughly have and do you get many complaints about the speed of the system from them?

 

Could someone from Squiz provide some detail on the performance hit please?

 

Thanks

James

(Tim Davison) #7

We have 5 sites and roughly 300 authors.  We often have complaints about system responsiveness (who doesn't??) but we've always had roles so I can't say whether roles are specifically the issue since I've nothing to compare them to.  In my work on non-live sites (e.g. testing and staging, where I don't define any roles) I personally don't notice any difference whatsoever - but it may be different if you turned off the roles system completely.