FisheryPackage

Combination of features from fisheye and treasury galleries

Created by: Lester Caine, Last modification: 19 Jul 2008 (11:16 UTC)
__NOTICE: THIS DOCUMENTATION IS UNDER DEVELOPMENT AND SHOULD NOT BE RELIED ON.
This documentation will need to be 'de-politicized' once all the problem areas have been formalized, but currently it is partly a sounding board for suggestions.
(Thanks to kinderlehrer for the box (:biggrin:) )
.__

Having found problems with treasury working on multisites, some of the difficulties of ring fencing content have come to the front again. treasury has a problem with it's gallery display which is reliant on LibertyStructures. This does not allow for filtering of content, and so all galleries from all sites are displayed rather than the reduced set that relate to a single site, and more important those galleries that a user has permission to access via protector or a similar security service. fisheye still has some problems but it does at least only display a sub set of galleries when required.
Obviously these problems need fixing, but since other facilities are also required, a short term solution has been to combine some of the features of both rolled into a new package - fishery.

Outline of requirements

fisheye has already been extended to provide a list view in addition to the three grid views, and so one of the requirements had already been covered, but further options to the layout would be useful. These are probably just variations on the two bases of list or grid, and even list is just a single column grid.

Top level index

One of the niggles with fisheye is it's based on a single user default for the top level. This is ACTUALLY correct even for multisites, but the option to change views would be useful, such as 'all' and 'group'. One of the problems with even that simple statement is deciding what to use as a group, since multisites has it's own means of filtering content, as does protector and other filters are possible because of the core design of bitweaver.
People will be aware that I prefer a 'flat' identification system, so that having a reference ID one can go on to identify what type of content is involved, and I have come back to user_id and group_id as another area that needs a little tidy up - from MY point of view. And even multisite comes into that equation. From a management point of view, every group needs an administrator, and so for every group I create a group_admin user, and each group lines up with a multisite entrypoint. Although there can and would be more than one group in a site - however registered and editor groups will still be used to determine capability. These are a little at odds with 'grouping' content and should perhaps be viewed as ROLES instead?
index page will default to group which is actually the group_admin user but will have options for 'all'-showing all visible galleries and 'user'-to show all galleries the user has created, but in multisite these would be sub-galleries of each group the user is a member of
How users can access data from other groups/multisites still needs to be sorted. It may be that the multisite filter is enabled if a user is required to log onto a different site to see their content in that site.
Ideally the top level index will simply be another gallery view rather than having it's own code, since the gallery can be displayed as a list now.

Gallery View

This follows on from the last statement, but it may be that we have different filters displayed if the 'default' gallery is displayed as against a selected gallery. This may come out in the wash anyway, since an important filter in the gallery view is one for content type. This would be populated with a list of just the content types available in the directory, but in line with the 'flat' view, mime based content will provide additional types for the mime types available. An obvious tidy up of this will be to provide an 'image' selection as well as ( or perhaps instead of ) 'image/jpg' etc. It would also be nice to have the same grouping perhaps for 'drawing' and 'document' so that 'drawing/dxf' or 'document/odt' and the like but that is just a matter of correctly identifying or extending mime types.
Currently implemented is the ability to select the style of display for a gallery, along with the additional layout features as required, and this can be extended to provide additional features.

Content View

At the base level this should already be implemented in LibertyContent, with additional facilities provided by LibertyMime, so there should be no need to discuss it here - except ...
The gallery navigation bar is an optional facility that can be added to content, and it is intended that this will be displayed if provided in the url. So a default content url will take the format /?content_id=627&gallery_path=/3/4 although the actual path should not need to be specified. &gallery_path=0 would cause it to be calculated from the content_id.
In much the same way that gallery layout can be selected on a gallery by gallery basis, content can either be displayed using the default mime layout, or additional 'plugin' type layouts. This layout control will also apply to content entries displayed IN the gallery.

Gallery Content Management

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, 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. multisites provides one way of achieving this, wjames5 has produced groups as an alternative, and 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?
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?

Related Items

Online Help » Packages

  •    •    •    •    •    •    •    •    •    •    •    •    •    •    •    •    •    •    •    •    •    •    •    •    •    •    •    •    •    •    •    •    •    •    •    •    •    •    •    •    •    •    •    •    •    •    •    •    •    •    •    •    •    •    •    •    •    •    •    •    •    •    •