History of FisheryPackage

Differences from version 3 to 5



@@ -28,7 +28,8 @@

 !!Users and ROLES
 Firebird and I am sure other databases have the ability to assign roles to users, and these define functions that a user can apply to the elements of a database such as view, edit, modify and delete. I think part of the difficulty I have been having with the core permissions system is that we are mixing up different activities in the one area. I suspect that this is partially because *I* do not understand some of the internals still, but while being able to add hundreds of permissions to each content item is nice, management is a nightmare. Having now 'grouped' content together I need to be able to assign a role to a user - such as view, edit, modify or delete. THAT is the function that the internal 'group' should be providing, and a user needs to be assignable to that 'role-group' separately to the 'content-group'. I would STRONGLY suggest that at some point that distinction is made and then we can develop the right overlying concepts.
 !!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 NOT by the permissions attached to a content item. It is this that messes things up since it is not controlled on a user by user 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.
+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?
Page History
Date/CommentUserIPVersion
19 Jul 2008 (11:16 UTC)
Lester Caine81.138.11.1365
Current • Source
Lester Caine81.138.11.1364
View • Compare • Difference • Source
Lester Caine81.138.11.1363
View • Compare • Difference • Source
Lester Caine81.138.11.1362
View • Compare • Difference • Source
Lester Caine81.138.11.1361
View • Compare • Difference • Source