From: Giancarlo P. <gia...@ya...> - 2009-06-29 10:33:59
|
Lester Caine wrote: > Giancarlo Pinerolo wrote: >> because workspaces are going to introduce a new challenging (and very >> delicate) feature to tiki: >> group administration by non-admins > > This is an area I'm currently having fun with on bitweaver, and it stems > from the same base problem. 'groups' of permissions have been wrong from > day one? And the added level of custom permissions per content item just > adds to the confusion! Well, in the end it is quite powerful and can work well, needs some rawhiding to conceal the complications. Permission per-item (objectperm), is written in the item, not in the group. So these are quite separate things. > p_admin has to go in the dustbin, or rather is only > appropriate to a superuser account, and so anything that isAdmin needs > to be reassessed and replaced with a canAdmin appropriate to the correct > restricted view of content. Then tiki has, now, three different ways of viewing things: -global by object types (can_admin_wiki, can_admin_blogs etc) -on a per item (item_can_be_administered_by) -on a per item-container (workspaces/categories themselves and also each of their items can_be_whatever) The problem is category/workspace groups, which with a foresight should be seen as items themselves, contained in categories/workspaces, and be manageable with a set of to-be-written permission schemes. At the moment, when you want to add a group to another group, you see a list of groupnames (dozens of it if you implement Personal workspaces) of which you have no idea what they are and what they contain: permission groups, People groups, PermTemplate groups, a mix of perm/people groups etc. > > workspaces looks very much like 'groups' which was a package created in > bitweaver some time ago, but THAT is not the correct solution to the > problem either since it uses custom permissions to try and get around > the core faults. Personally I'm looking to switch off custom > permissions, restructure things so that you have roles such as > superuser, admin(site), manager, supervisor, user, anon which can be > restricted to a multisite workspace and/or a role type workspace and can Workspaces in tiki are a role type workspace. Groups there are/shouldbe containers for people only, with 0 permissions, because the permissions for them are written in the objects/items. Included the workspace/object itself, which allows different perms on managing its contained resources. > I've not worked with the original tikiwiki code for some years now, but > I hope that a 'fresh input' to the discussion will help. bitweaver does > not have a generic solution to the problem either, but I do have my own > branch which runs a customer support site which allows multisite access > private areas for each set of customer employees, while maintaining the > core content generally available. Each 'site' can maintain their own > user list, and other sites are unable to see private material, or > similarly material from a 'manager' role level on a site if they have a > lower role. I'm probably going to 'rename' groups to roles before my > next phase of development. And strip most of the by package permissions > to leave a simple view/edit/create/admin/delete set of functions, > although I can see the use of managing that on a by package basis. > Packages are groups of objects, like workspaces in tiki I suppose. Workspaces, if I get it right, is like by-package in your example. > I have to admit that my customers are not a typical 'web target', since > in many cases material added to each customer site SHOULD be grouped by > 'site'/'role' rather than 'user', since the users will come and go, > while the data MUST be maintained transparently over time >( hence delete > is an admin/superuser function ;) ) Yes, there was a discussion abou this few days ago, and I see a point for this now. I would ask you to try registering at http://workspaces.altervista.org (choose demo profile at registration, you'll be a non-admin there with different priviliges in different WS areas), and see what can be done. I'd appreciate your feedback Giancarlo |