| Moving items from a moderator group ( and there could be a number of such groups ) into the generally visable group could be carried out manually via the normal item edit, or an alternative means can be added via additional service functions. One option is to use the stars package ( should that be 'service' ) and once an item has received a certain level of stars, the group flag is automatically changed.
|
| !!Other developments
|
| One of the main problems with this approach is the fact that the current integral permissions system requires separate view, edit, admin permissions for every package. What would be nice would be to replace that complexity with a much simpler create/edit/admin function for each group, in much the same way as the unix security system works. This would remove the cumbersome management functions required to control the currently vast array of permissions. A simple start to this may be possible by introducing a generic set of basic permissions, but this does need to be addressed.
|
| +!!Operating Modes |
| +There are currently two modes of operation of the service, single group and multiple group. |
| +Personally I only see the need for content being assinged to a single group and this makes management of the content a lot easier. A user will be assigned to multiple groups and can therefore see a spread of data. |
| +The service has been extended to allow content to be assigned to multiple groups, but this is a mode that I can see will only cause problems in the future and complicates the validation logic in the SQL. While I can see the advantage of being able to assign content to more than one group, we are already seeing requests for 'modified' versions of content based on a user id, and that I see in a similar light. Just like translations, different content should have different copies, so while you may have content for 'X', a second copy for 'Y' should be a second copy so that modifications made to 'Y' that are not appropriate for 'X' are not visible by 'X'! |
| !!Todo
|
| -The current protector package SHOULD already be operational in HEAD via the servicesSql interface, and provides filtering on lists and serach results and restricts access to content where the group setting do not match. Not sure if comments are being correctly filtered at this time, but 'moderation' of comments would require that function.
|
| +++red:This still needs a review!++ |
| +The current protector package ))SHOULD(( already be operational in HEAD via the servicesSql interface, and provides filtering on lists and serach results and restricts access to content where the group setting do not match. Not sure if comments are being correctly filtered at this time, but 'moderation' of comments would require that function. |
| It would be nice if links from unsecure content to secure content were simply disabled, rather than going to a 'you do not have permision to view this page!'
|
| Some additional management of the protector selection when editing would be useful, a permission on a group to be able to the grouping of a content item.
|
| A display of the 'group' of a content item when the basic view is selected. This may need to be 'inteligent' so that, say, a moderated group item is flagged as 'unapproved', but a simple text field against each group may be all that is needed ( anon->Public, registered->Private, moderated->Unaproved for example ). |