Workspace perms and the 'Workspace Admin'
out where I am wrong because some of these statements are just
assumptions that I couldn't test, eg. those based on what previous
versions did. I mark these with (?)
After actual verifying, I cut some parts of the original post
There are three workspace related perms:
tiki_p_view_workspace
tiki_p_create_workspace_resour
tiki_p_admin_workspace
All these have to be considered object permissions...
the ones that, once assigned to an object, override any group permissions a user has.
Because, except for admin-god, who anyway doesn't need
...
The workspace itself is an object, with its objectpermissions
Objectperms on a wiki page allow acting on it
Ojectperms on the ws object itself should allow acting on the workspace
But there are differences between what one can do if he has tiki_p_admin_workspace, tiki_p_create_ws_resour as group permission, rather than as objectpermission granted to him.
As group permission these allows managing all aspects of workspaces on every workspace.
The same perms, when granted as objectpermission, do/should do granting him same privileges, but on a single workspace and its childs.
these perms, as object perms, do:
-tiki_p_view_workspace this is self explanatory.
-tiki_p_create_workspace_resour
this allows to create eg. a new wiki page to the workspace
this page will have the permissions copied from the RolePerms of each
role in that workspace type (+ those from/for Anonymous and
Registered groups)
So if RolePerms-teacher has
tiki_p_view and tiki_p_edit, teacher can view and edit the page.
If RolePerms-student has only tiki_p_view, the page will grant student
perms to see it but not edit. Same for Anonimous if he has
tiki_p_view, as group though, 'cause he has no RolePerms.
As of aulawiki-1.6.2 it seems that only admin-god can singularily
change these perms (blue key right of resource in resources module)
-tiki_p_admin_workspace
in 1.6.2 this allows
.to add new users/groups to the workspace (?)
.one could also add parent's admin group to it if he knew the
group name (?)
in 1.6.3x it can allow
.add new users/groups to the workspace
.assign objectperms to all other workspace objects, only to the
workspace's predefined roles
.create sub workspaces with their roles and add parent's roles to
it (eg.: become workspace_admin of it)
The Workspace Admin
As you see, tiki_p_admin_workspaces is the key to subcontracting
workspace administration of a specific workspace.
In 1.6.2 it allowed him to add new users to the ws without disturbing
admin-god.
In 1.6.2 he could not admin a child workspace
(delete/create/assign-perms to new resources, add users/groups), unless
a user who had tiki_p_admin_ws on the child added his group to the ws
users/groups (?)
In 1.6.3 it can have more power. If we don't want to give this power
to anyone that has tiki_p_admin_workspace, we need one more perm
(create_child_workspace? admin_child_workspace?). My personal opinion
is not. I think he should be able to admin also all child workspaces: Workspace+Childs Admin
Maybe power to assign object perms for the each ws resource (except for
the workspace itself) can be granted to who has
tiki_p_create_workspace_resour and leave less problems to the Workspace
Admin? (eg student asks to make 'private' or 'public' a page he could just create)
If Workspace Admin = Workspace+Childs Admin, he should be able to grant objectperms to any resource in any of the child workspaces for all the groups in parent and child workspaces
pingus
Last wiki comments