User Group Structuring

[nilism]

I am new to Joomla and I am considering building a Conda/HOA/Strata type site. I figured on of the better places to start on a project like this would be to build the usergroup structures first.

So I have a basic understanding of Access Level Control, Permissions, and User Groups. As well as inheritance. I am finding that knowing the vocabulary and being able to implement something intelligent are not exactly related.

I think I am having a hard time understanding how I should handle user "roles" and user groups.

Joomla comes built in with roles (Manager, Admin, Super Admin) which all do things and require additions permissions. Also I have the user groups, which in my case would be stuff like Contractor, Realestate Agent, Renter, Owner, Board member. These all require different ALCs but on their own they do not actually do things. A board member who is also a manager would be able to do things and have certain ALC.

So I guess I am wondering a few things:
-Should I strip any of the "stock" user groups away, such a publisher?
-How useful is inheritance? For instance, should all my logged in users be children of Registered? If so why doesn't Joomla follow this advice with manager/admin user groups?
-Should I try to combine roles and users? For instance, should Board Manager be a child of Board Member? I think all manager types, Property and Board Members will have the same permissions but not all will have the same ALC.
-Do users who inherit need to be in their parent groups? Eg. A Board Member must be an Owner who must be Registered, does that user need to be in all three groups or just the last child?

I've attached where I am at right now:

[Webdongle]

How useful is inheritance

imho 'inheritance' is the most important factor.

Ok, where to start ?

Ignore the default user groups and dont alter them ... create your own.

Set the Permissions in Article >> Options >>Permissions ... Leave the Global config Permissions Inherited.

• For the Users with no Edit Permissions for ' Contractor, Realestate Agent, Renter, Owner' etc. ... set User Groups (with registered as parent) everything inherited
• Create a User Group (with 'Contractor' as Parent) called 'Contractor writer' add 'Create and 'Edit Own' Permissions
• Create another user Group (with 'Contractor writer' as Parent) 'Contractor editor' and add 'Edit', 'Delete' and 'Edit State ' Permissions
  'Contractor editor' will inherit the the Permissions of 'Contractor writer' and have the extra ones you give it.

Do the same for Realestate Agent, Renter, Owner, . It doesn't matter if you call the 2nd and 3rd levels 'writer' and 'editor' ... call them what you want but keep it consistent. You can have as many levels as Permissions or only two levels depending on what you want each user group to do.

Now the complicated part

1. If you want Board members to have full permissions for all user groups then create a User Group (with Registered as Parent) called 'Board members' and give it all permissions.
2. If you want Board members to have their own section with different edit Permissions ... create a User Group (with Registered as Parent) called 'Board members' . everything inherited
   • Create a User Group (with 'Board members'' as Parent) called 'Board members' writer' add 'Create and 'Edit Own' Permissions (like the other user groups
3. If don't you want Board members to have their own section but want them to have various Permissions for other sections ... then DON'T create a user Group for them.

Next create view/access levels for Contractor Realestate Agent, Renter, Owner (and if A or B create one for Board members as well). When you create each view/access level ... assign the corresponding User Groups. Don't put Board members in Realestate Agent, Renter, Owner.

When a User is created put them in the correct User Group ... e.g. Put Contractors in 'Contractor' or 'Contractor writer' or 'Contractor editor' (Only one of the User Groups for Contractors). You may put Contractors in any of the 'Realestate Agent', 'Renter', 'Owner' User Groups if you want them to see that section but not in the Children of those User Groups.

When a Board member's User account is created
If A then put them in the 'Board members' User Group only (because the Contractors User Group already has the Permissions those Groups have).
If B then put them in one of 'Board members' or 'Board members writer' or 'Board members' (Only one of the User Groups for Board members). ... you can put them in in any of Contractor Realestate Agent, Renter, Owner (or their child Groups) User Groups but only one in each section.

Before creating the User Groups etc. ... work it out with pen and paper first. Creating the User Groups with their different Permissions is a little like a 'Logic Puzzle' where you draw a grid. When you create the User levels remember 'Inheritance' is important because it gives structure to the logic.

[nilism]

Firstly, Thank you for taking the time to write such a lengthy post.

Set the Permissions in Article >> Options >>Permissions ... Leave the Global config Permissions Inherited.
...
If you want Board members to have full permissions for all user groups then create a User Group (with Registered as Parent) called 'Board members' and give it all permissions.

At first I was a little confused by why you would want to set Article Permissions individually for every article but essentially you are not. I'm assuming you meant set my Board Member Writer/Editor Permissions Globally, and everything else Article specific as these would essentially be special cases.

So I have developed the Permissions as I described. All Permissions set at the Article level except my site wide Writer/Editor (Board Member Writer/Editor). This raised a side question. If a User has Permission to Write/Edit something that they should not, because you set Global Permissions, but they do not have ACL for that Article is this a potential security risk?

Now the complicated part...

I want some Board Members, Writer/Editor, to have Global access to all Articles. So I set them up in the same structure as the other User Groups, Registered as Parent, but I set these Permissions Globally. This was done only for the Board Member Writer/Editor User Groups as they are the only Users I want to ever have Global Access.

Next create view/access levels for Contractor Realestate Agent, Renter, Owner (and if A or B create one for Board members as well). When you create each view/access level ... assign the corresponding User Groups. Don't put Board members in Realestate Agent, Renter, Owner.

So I was a little confused on this point. I want me Board Members to have access to pretty much all the content. Certainly I want them to have access to Contractor/Real Estate Agent content... So how is this achieved if Board Members ACL is set to Board Members only? I know if I set the ACL at the article level as Registered then my Contractors and Board Members would have access but then Owners and Real Estate Agents would also, which I don't want.

Also, can ACL at the Article level be set for multiple ACL groups?



When a User is created put them in the correct User Group ... e.g. Put Contractors in 'Contractor' or 'Contractor writer' or 'Contractor editor' (Only one of the User Groups for Contractors). You may put Contractors in any of the 'Realestate Agent', 'Renter', 'Owner' User Groups if you want them to see that section but not in the Children of those User Groups.

When a Board member's User account is created
If A then put them in the 'Board members' User Group only (because the Contractors User Group already has the Permissions those Groups have).
If B then put them in one of 'Board members' or 'Board members writer' or 'Board members' (Only one of the User Groups for Board members). ... you can put them in in any of Contractor Realestate Agent, Renter, Owner (or their child Groups) User Groups but only one in each section.

Maybe this answers my previous question as I work through this, on the site and in this post. Yes, there is a bit of linear thought and growth as I follow through here. Anyway... If the ACLs are set as you described and I want Board Member Writer/Editor to be able to see (as requirement to editing I assume) Articles with the Contractor ACL then by also putting them in the Contractor Editor User Group they would gain the ability to "see" Contractor content and Edit it, although they already had the ability to Edit it, strictly speaking. This does seem a bit clunky, however it makes it clear on who has what access at all times through the nomenclature.

[Webdongle]

I want me Board Members to have access to pretty much all the content. Certainly I want them to have access to Contractor/Real Estate Agent content..

B. If you want Board members to have their own section with different edit Permissions ... create a User Group (with Registered as Parent) called 'Board members' . everything inherited



In view/access levels 'Contractor, Realestate Agent, Renter, Owner,' select the 'Board Member Group'. Board members will then be able to see Articles/menu items/modules etc that are set at view/access for any of them.

If you have also created a User Group (with 'Board members'' as Parent) called 'Board members' writer' with 'Create and 'Edit Own' Permissions (like the other user groups) ... select those as well. Then all Board members whatever Board Member group they are in can see everything ... and edit according to their group Permissions.

The secret is to work it out first then you can create user Groups and view access levels in that order. It means that you don't have to edit view/access levels evertime you create a new user group

[nilism]

Well I was definitely struggling with the organisational hierarchy first. I was basing my thought process off of organizational structures rather then a permission inheritance structure.

So I am pretty good with that now and things are making more sense.

The next thing is starting to think how Joomla is going to deal with these premissions and ACLs with respect to plugins like a document manager, web forum or some such thing where premissions matter a lot.

Hopefully these sorts of plugins will extend Joomla rather then try to recreate their own ACL/Permission system.

I'll post where I end up later today after lunch and monitor shopping. (o:' Thanks again for your valuable help.

[Webdongle]

With 3rd party modules you set their view/access levels. Default user Group is 'Public' (all user groups see 'Public' view/access). If set to a view/access then users in user groups (selected in that view/access level) can see it.

With 3rd party components their admin Options work the same as Joomla's component options. 3rd party components like download components and forums ... have their own permissions set on user groups. That way in a forum screen users can post only or post and edit others depending on what permissions box was selected for their group in the component.(much like selecting a user group in view/access levels). But don't worry you will understand it when you see it.