| @@ -30,5 +30,6 @@ |
| !!Access to galleries/content
|
| Having made the above distinction, access control is much simplified. What content is visible is controlled at a higher level, such as the multisites filter, but HOW content is presented is controlled by 'role' of the user in that area It is this that messes things up since it is not controlled on a user by group basis!
|
| Permission management then becomes a 'group' function, so that particular combinations of 'roles' can be assigned to that group. We still need to be able to add 'roles' such as 'moderator', but a user needs a 'role' in a 'group'. I am tempted to say that they should only have ONE role which could be 'custom' but rather than setting anonymous,registered and editor, an editor role would have all the other relevant permissions set - or have it's own inherit of registered which then inherits anonymous. In any case, the individual content custom permissions still work based on the 'role' of the user at that time?
|
| +++green:The main problem here is 'access control'. Content needs to be grouped at several levels, so that a group site can have content that is visible to anonymous users, extra content that can be viewed once registered users log on, and further content restricted to higher level users. This could be achieved by using separate groups of anonymous, registered, and editor for each site, but that causes management problems.++ |
| !!To do list
|
| NOW that I have a plan I can progress things. The view/edit problem for users ij a group was the one that was confusing me, but having established this outline, I can build fishery to follow the rules. HOWEVER I do think that some of the above thoughts should be incorporated into the core engine. In particular I think the role/group distinction would help with the groups package? |
|
|