| While I do have a dislike of content being located in multiple galleries, I do not see any problem with the concept, and in fact potentially there COULD be a gallery zero which would simply access all content_id entries - the 'list all content' - so that potentially 'raw' content would only be deletable at that level. (See later note ).
|
| What I do not like is the current fisheye way of selecting which gallery(ies) to use when editing an item. The separate tab for treasury is a bit tidier, but as has been indicated, that does not respect multisites/protector and the like. So the plan is to keep the tab as an option, and fix the display list, but also provide a 'located' function to allow a different gallery to be selected if required. This 'located' would be provided as an edit service, so that ANY content item can be located in a gallery. This is almost an alternative to protector, and highlights the problem of having multiple tables for some of these facilities. multisite_content, liberty_content_group_map and fishery_content_map are all doing similar jobs different ways, and the operation could be tidied into one central table - except when one adds multiple usage of content. But it is the MANAGING of that multiple usage across multiple sites or groups that focuses the various problems.
|
| !!Ring fencing content
|
| -The starting point is deciding HOW to model the management of content. And we all have different views on that, and different solutions. But there are a few basic rules that we can all agree. If we are using a single database that it has to be simply because at some point we need access to all content. If that is not he case, then use separate databases for each site.
|
| -
|
| -To be expanded - Basic premise is that ANY content item will be handled and can be added to a gallery, not just fishery attachments. |
| +The starting point is deciding HOW to model the management of content. And we all have different views on that, and different solutions. But there are a few basic rules that we can all agree. If we are using a single database that it has to be simply because at some point we need access to all content. If that is not he case, then use separate databases for each site, and all data is accessible within the site. |
| +The multiple site model comes about when you have a core of generic data and other content specific to particular groups of users. ((MultisitesPackage|multisites)) provides one way of achieving this, wjames5 has produced ((GroupsPackage|groups)) as an alternative, and ((ProtectorService|protector)) adds a simple means of hiding content from users who should not even know it is there. All target particular problems but none offers a total solution. |
| +My notes on ((Configuring multisites)) outline one way of building more secure access to some data, and fishery has come about because of the need to fill gaps in that model of working. However there are still a few holes to be ironed out. |
| +!!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 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? |