Forums / Developer / Seeking suggestions on an unusual permissions / node access problem

Seeking suggestions on an unusual permissions / node access problem

Next topic

Author	Message
Brendan Pike	Monday 01 March 2004 12:36:36 am I would like some advice on how to achieve the following in a correct method that still adheres to the core roles and security system of eZ publish 3.x. I need to create a potentially user heavy site with up to 1000 users over time. It's a 3 level structure, CEOs, Managers, Workers. CEOs should be able to see into their employees' nodes in any company they are over. Managers should be only able to see into their own node and all their workers' subnodes (but not other manager nodes on the same level, nor those managers' worker nodes) Workers should only see their own node. Please see the jpg on the following link for a better description. http://www.r2r.net.au/levels.gif I'd welcome suggestions on how to achieve this please. www.dbinformatics.com.au We are always interested in hearing from experienced eZ PHP programmers and eZ template designers interested in contract work.
Tore Skobba	Monday 01 March 2004 4:06:32 am How many companies are there? If there is a relative small number and fixed you could make sections? Otherwise you could look at the access rules for subtree, i.e. CEO has read access on all content in subtree "Company", while manager has read access on all content in subtree "Manager".
Brendan Pike	Monday 01 March 2004 8:02:20 pm Thanks for been the first to jump in with some advice Tore. We would anticipate it growing to around 200 companies, so I guess that would rule out using sections. When you say access rules are you referring to workflow? www.dbinformatics.com.au We are always interested in hearing from experienced eZ PHP programmers and eZ template designers interested in contract work.
Bård Farstad	Tuesday 02 March 2004 2:18:58 am Brendan, this is a tricky one. I have one suggestion, which may work. First you need to define three classes ( CEO, Manager, Worker ). I'm not sure if this fits with your content though. Further I would set up permissions for roles like this: CEO: can read ANY "CEO", "Manager" and "Worker" Manager can read ANY "Worker" and "Manager" objects which is created by himself ( managers needs to have ownership to their nodes ). Worker: Can read "Worker" objects where they have ownership. Ok, this will only work if you have one of these trees. So you would need to add a section limitation to all of these roles as well. I know this is not a good solution since it can create something like 200*3 roles. In 3.4 we have a mechanism to reuse a role and make the limitation on a subtree for the whole role. That way you could get off with only creating three roles and assign the roles to the users ( or user groups ) with a limitation. This should work for your case, but the feature is only available in 3.4 which is only available for testing at this time. I hope this helps you in deciding on the role setup for your site. --bård Documentation: http://ez.no/doc
Bruce Morrison	Tuesday 02 March 2004 6:41:22 pm Hi Brendan I agree with Bård, it sure is a tricky one. I've been giving this a bit of thought as I have a similar problem with complex permissions in an extranet system I am trying to build. As Bard has pointed out I'm not sure that it would be practicable to use the (current) permissions/roles system to achieve what you want. I think the only way to do this with the current version of eZ Publish is to use a combination of permissions and template logic to achieve what is required Deep breath....Here goes..... Create 3 content types, CEO, Manager, Worker under the Class Groups -> Users folder. Copy the default user class and rename appropriately and add any extra attributes required. You will also have a Company content type. Create 3 User groups: CEOs, Managers, Workers Create 3 Roles: one you each of the new user types - CEO , Manager, Worker. You then have the "generic" rules for each role Role: CEO content read class (Company, CEO, Manager, Worker), any section Role: Manager content read class (Company, Manager, Worker), any section Role: Worker content read class (Company, Worker), any section Assign these roles to the corresponding user groups. Add a company, create a section for this company, and assign the section to the newly created company Add a CEO to the company. You will also need to add the CEO to the CEOs user groups. Now I'm not sure if this will work (and it is pretty important that it does). Will the role that is assigned to the CEOs user group be applied to the CEO user as the node in the user group will not be the main node? You can make this an easier process by customising the edit template for the CEO content class (also do this for worker and manager content classes) to automatically place the node in the correct user group (See the edit_placement.tpl for an example of this). The new CEO user will be assigned the section ID of the parent company. Add Managers under the CEO and Workers under the Managers, making sure that they also get placed in their correct user group (these objects also get the same section ID as the company). So now you need to have custom templates for each of the user content types All - only display if the current user is of the same section as the current node (limits to a per company CEO - nothing extra - only one CEO per company (thank god) Manager - only display if current user is a CEO or has the same node ID as the current user Worker - only display if current user is a Manager or has the same node ID as the current user. It doesn't appear that you can fetch content and limit it to a specific section so you will have to do this "manually" when looping through the results. By enforcing this limitation in the template logic you will save you having to create a 3 roles per Company. Also I'm assuming that Workers, Managers and CEOs will not be creating their own objects so they will not "own" their own object. So by having the template logic take care of having to assign self ownership to the worker objects. Disclaimer: This "solution" has not been attempted and may not work. At the moment it is purely entirely a figment of my imagination. I'd be interested in any feedback as to potential issues, logic problems etc. Cheers Bruce My Blog: http://www.stuffandcontent.com/ Follow me on twitter: http://twitter.com/brucemorrison Consolidated eZ Publish Feed : http://friendfeed.com/rooms/ez-publish
Brendan Pike	Tuesday 02 March 2004 8:41:23 pm Thanks for the detailed response Bruce it was very thought provoking. I suspect that although your suggestion is most likely workable it is still not ideal. If I have understood it correctly I think this method we would be fighting to maintain solid data security from too many angles. It only partially uses the central permissions system (I think) and then uses templates to filter out the rest. I couldn't feel 100% confident with that on this job as the type of data is too sensitive. I'll most likely advise the client to break the project into a couple of phases and relook at that requirement after 3.4 is stable even though it will incur extra cost. Thank you again for taking the time, and helping. www.dbinformatics.com.au We are always interested in hearing from experienced eZ PHP programmers and eZ template designers interested in contract work.
Vaskin Kissoyan	Wednesday 16 June 2004 2:11:06 pm I've thought about this quite a bit too as we are trying to write an extranet also, and I believe you have to extend the code that deals with user sessions to store each company's root and programatically control the access to the company area and switch that out for each user/group. Then the CEO. Manager, etc would be able to play appropriate roles. I see this as a design flaw as ezpublish can handle intranet security anr roles fine, its when you add an extra layer there is no way to manage it. The only thing close would be to create new siteaccess entries and templates to control this, but again this would have to be done for each "comapany" .. all 200 in your case... Otherwise you are basiclaly going to end up doing a 3 roles for each company. There needs to be some way to tie a role to a specific set of subtrees (programatically changing based on current suer/group)...
Brendan Pike	Thursday 17 June 2004 3:27:14 am I agree Vaskin, we also could see that we would need 3 roles per company which was a little insane so in the end we decided to scrap the 3 levels of permissons and only go with one level for a little while. Sadly it means we wil need to rebuild the site dramatically at some point which will no doubt be a terrible experience. As it is now we auto create a new role + section for each new user. In 3.4 they have introduced a tree limiting capability but I have not looked at it closely enough to yet discover if it can achieve what we need. Thanks for you comments though. www.dbinformatics.com.au We are always interested in hearing from experienced eZ PHP programmers and eZ template designers interested in contract work.