These are more patches on aulawiki.1.6.2 posted by xavi
2.2, the way it worked before.
workspace (not only users), and see all child's groups, starting from
the topmost a user can admin, when adding perms to single workspace
resources.
This was be done by adding some new functions to workspaceslib.php:
- get_includable_child_workspaces_groups : will get all groups in WS and child workspaces, starting from the uppermost on which one has admin objectperm down, purged by veryfing a list of includable groups to avoid loop inclusion.
- user_can_admin_workspace_or_upper(), an alias of
get_topmost_workspace_Iadmin(): will get up in the workspace path and
return an upmost parent workspace one can admin, thus gives him admin
capability on the ws and children, or false.
And in lib/workspaces/userslib.php, function group_can_include_group() will check if the group we are trying to include can be included.
with these functions a RolePerm with tiki_p_admin_workspace has
view of all child workspaces and their groups down from the
topmost one he can admin, no matter in which of these he is actually
(current workspace), and be able to add groups and assign perms to
groups within all these ones (only) without need of of having
tiki_p_admin_workspaces also on any child ws.
To the intermediate objectperm tiki_p_create_workspace_resour has been given as a gift the possibility to add single users, not groups, to the workspace predefined groups. On the other hand he can grant objectperms to his resources choosing among any group that belongs to his 'workspace-level'(brothers workspaces) + his parent's (dad, see what I am doing!)
This behaviour is easily changeable in the code, as the ability to do things is stated at the top, where (object)permissions on the workspace are tested once and translated into variables used throughout the code.
In practice:
=====
from the RolePerms template for that type of Workspace) is de-facto a
local Workspace administrator. He can do everything (create new sub workspaces, add groups, change perms) except define new
workspace types and roles, and he sees only groups starting from the
topmost workspace he can admin to the bottom.
RolePerms template for that type of Workspace), can manage objectperms
of his ws resources (excluded the ws object itself) choosing among
a tree of groups that starts at his parent's level (dad, see what I am doing), includes 'brother workspaces' (on the same level, child of the same parent), down to bottom. He is a resource manager. For adding users/groups to the ws, he can only add single users by typing the name, no groups. But if his ws has an admin group, he could add himself there. So tipically workspaces either have a ws_admin role OR a ws_resource manager role. On the other hand, a top, empty (no resources) workspace, with only an ws_admin role, would grant administration to all childs.
For a user that has the approriate objectperms from the roles template
to the workspace (tiki_p_admin_workspace or, with less possibilities,
tiki_p_create_ws_resour, for the workspace object), everything can be
done starting from the resources module that has extra links to create child ws, add users/groups, and assign perms to resources.
The resouces module will show/hide Buttons and icons next to each
resource accordingly to what can be done by the actual type of user.
Most of the modifications happened in :
- tiki-workspaces_objectpermissions.ptp + templates
- modules/mod-workspaces_users_groups.php + templates
- lib/workspaceslib.php (new functions only)
- lib/users.php (new functions only)
With respect to the connection workspaces-categories, nothing should be changed. All categories related code is still there and used as before.
New permission scheme 1.7.0:
1.6.2 ------------------------------------------------------------------------ perm allows as allows as name group perm objectperm ------------------------------------------------------------------------ view_ws - -view the ws create_resour - -create resour onws admin_ws do all on any ws -add group/user to ws 1.7.x ----------------------------------------------------------------------- perm allows as allows as name group perm objectperm ------------------------------------------------------------------------ view_ws - -view the ws create_resour - (1) -create resour on ws (de facto admin resour) -change perms on ws resources (excluded the ws itself) choosing from the father ws groups and childs (father+brothers-to-bottom) (3) -add single users(not groups) to ws predefined groups admin_ws -do all on any ws(2) -create child workspaces for any ws from the topmost ws he has admin rights -change perms on ws object itself & resources & child-ws objects and resources choosing from the topmost ws groups he has admin rights -add any groups to any ws choosing from the topmost ws groups he has admin rights -create child workspaces to any ws from the topmost ws he has admin rights notes: (1) this slot is free! Can't we use it to allow the creation of an 'organic workspace' of some predefined type with himself as tiki_p_create_resour objectperm on it? (2) as he can add the 'admins' group, and add users to it, he is defacto a tiki_p_admin. maybe he should only be able to add 'workspaces groups'? This would make him different from a tiki_p_admin_groups and tiki_p_admin. see comments and examples of different possiblties in mod-workspaces_users_groups.php (3) see comments and examples of different possiblties in tiki-workspaces_objectpermissions.php --------------------------------------------------------------------- TODO: there's quite a lot I think, especially in the interface, making it nicer and more intuitive. -Add confirmation steps for various deletion actions -Deletion of workspace does not delete its objects (should it?) -test it really hard -understand first, and maybe integrate, the working of 'Private Zones' and 'user Workspace types' (isuserWS and userws filed in table).
LATEST NOTE:
Version 1.7.x has been committed to svn trunk.
You can now download the up-to-date version (not in mods format though) from:
https://tikiwiki.svn.sourceforge.net/svnroot/tikiwiki/mods/trunk/features/aulawiki/
The mod in the repository does not provide a working example of these new features, it has the usual Teacher/Student Roles. One has to define roles with 'tiki_p_admin_workspace' and 'tiki_p_create_workspace_resour' to see this in action
To help developers solve the bug, we kindly request that you demonstrate your bug on a show2.tiki.org instance. To start, simply select a version and click on "Create show2.tiki.org instance". Once the instance is ready (in a minute or two), as indicated in the status window below, you can then access that instance, login (the initial admin username/password is "admin") and configure the Tiki to demonstrate your bug. Priority will be given to bugs that have been demonstrated on show2.tiki.org.
To help developers solve the bug, we kindly request that you demonstrate your bug on a show.tikiwiki.org instance. To start, simply select a version and click on "Create show.tikiwiki.org instance". Once the instance is ready (in a minute or two), as indicated in the status window below, you can then access that instance, login (the initial admin username/password is "admin") and configure the Tiki to demonstrate your bug. Priority will be given to bugs that have been demonstrated on show.tikiwiki.org.