Loading...
 
[edu.t.o] Development

[edu.t.o] Development


Workspace perms and the 'Workspace Admin'

posts: 52
I've been reflecting on this and I try to analyse it, please point me
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
posts: 52
I tested back aulawiki-1.6.2 which should do the same aulawiki-1.5 did

needed actions and possible regrouping into existing/renamed perms
Copy to clipboard
admin single ws: objectperm (create-)admin_ws_resour create resour on ws change perms on ws resources (except ws object itself) add/remove users/groups among this ws type roles only admin_ws-downwards: objectpem admin_workspace create resour on ws-downwards change perms on ws object itself change perms on resources ws-downwards add/remove users/groups ws-downwards admin all ws: groupperm admin_workspace do all on any ws Table: 1.6.2 perm allows as allows as name groupperm objectperm ------------------------------------------------------------------------ view_ws - view the ws create_resour - create resour onws admin_ws do all on any ws add group/user to ws 1.6.3 proposed perm allows as allows as name groupperm objectperm ------------------------------------------------------------------------ view_ws - view the ws create_resour - create resour on ws (admin resour?) change perms on ws resour (except ws itself) add users/groups of this ws type roles admin_ws do all on any ws add user/group ws-down create resour ws-down change perms on ws-down change perms on ws object itself

.
posts: 32
Pingus, may you post the previous table here.
I think it's going to be easier to discuss about the new workspaces and to define a ToDo list there.

It's not very clear for me what you mean with it. I will think on it again.

Thanks wink
posts: 52
Yes Roberto, I read about Organic groups and it is very interesting.
I saw also that quite a few bricks have been laid already.
But I am too busy with work outside at the moment to follow this development, and I have the idea there's still quite a bit to be done and it will take some time.
Mine was an attempt to quickly get what I needed basing on 1.6.2.
The table is just way to reconsider the actual 3 permissions of workspaces, making
'tiki_p_create_workspace_resour'
become de facto something like
'tiki_p_admin_workspace_resour' for a single workspace,
and let
'tiki_p_admin_workspace'
be able to create/admin child workspaces (as objectperm, as group perm he would always be able to manage all workspaces)
It was also an occasion to verify if what I evinced through trial and tests was true :-)
I got acquainted with the code by now, and it's nice and clear and most needed functions are already there. And more are in the categories lib, very useful once there's a way to tie workspaces and their groups to categories. It is clear to me now that this was already in the original design.
With respect to 1.6.3, I see an immediate need to find the capability to control the addition of groups (only ws and children's group) for objectperm tiki_p_admin_ws, and allow only adding user to predefined ws groups (no adding new groups) for objectperm tiki_p_create_ws_resour

Xavi told me this can be done at the group level, maybe through user levels?

pingus
posts: 32
> 'tiki_p_admin_workspace_resour' for a single workspace,
I guess you mean for a single workspace resource, right?

> and let
> 'tiki_p_admin_workspace'
> be able to create/admin child workspaces (as objectperm, as group perm he would always be able to manage all workspaces)
This perm enables a hierarchy of workspaces.

I have seen in the last patch (1.6.4) that you added the functions to list all the hierarchy. That's great too.

> I got acquainted with the code by now, and it's nice and clear and most needed functions are already there. And more are in the categories lib, very useful once there's a way to tie workspaces and their groups to categories. It is clear to me now that this was already in the original design.

We will start with the lib of categories to creae this new organic workspaces.

> With respect to 1.6.3, I see an immediate need to find the capability to control the addition of groups (only ws and children's group) for objectperm tiki_p_admin_ws, and allow only adding user to predefined ws groups (no adding new groups) for objectperm tiki_p_create_ws_resour
>
> Xavi told me this can be done at the group level, maybe through user levels?
>
Sure. If you create user levels then you are able to administer permissions independently for each of them.
> pingus

posts: 32
>...
> 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

First things first. A good starting point for this new permissions hierarchy on workspaces should be not to add this new admin_child_workspace. Moreover, it has sense that you can manage all your child workspaces. We could think on a more sophisticated permissions hierarchy later.

>
> 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)
>

Sure, I agree again biggrin. This is an interesting point. Thinking on a student/employee that is the manager of a work group. He can't create the whole workspace but he can admin the resources. Less work for admin wink

> 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
>

I agree again.

Pingus. something we must consider is what mpvolt has suggested for perspectives:Organic groups.
Might it be the way users/admin manage workspaces?

I mean, what you are pointing is to go further with a permission systems that could be managed by organic workspaces, i.e. a workspace that can be born, grow and die without requiring the involvement of an administrator.

We are considering this in the new perspectives stuff.

Good work pingus. Let's continue. biggrin
posts: 52
Latest note to patches posted here:
http://dev.tikiwiki.org/tiki-view_tracker_item.php?itemId=2297&trackerId=5

  • Versions 1.6.2x are intended just to make aulawiki work on tikiwiki
2.2, the way it worked before.
  • Versions 1.6.3x is a transition step.
  • Versions 1.6.4x is a new development intended to give a RolePerm with
tiki_p_admin_workspace the capability to create new child workspaces. It
though limits him to adding only 'users' to the workspace, not groups.
For global tiki_p_admin_workspace nothing changes though.
  • Versions 1.6.5x will put back capability to add groups to the
workspace (not only users), and see all child's groups when adding perms to single workspace resources.
This will be done by adding some new functions to workspaceslib.php:

- get_child_workspaces_groups : will gel all groups in WS and child
workspaces. DONE
-get_topmost_workspace_IAdmin or get_my_topmost_workspace : will get up in the workspace path and get the topmost one on which I have
tiki_p_admin_workspace

with these functions a RolePerm with tiki_p_admin_workspace will have
complete 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 on any child ws
posts: 32
Nice work pingus!

We will upload to the experimental branch the version 1.6.4.

Thanks!

Switch Language