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

[edu.t.o] Development

Forum List Topic List

Forums » [edu.t.o] Development » Workspace perms and the 'Workspace Admin'
 
Thread actions
Print this page
  • Print all pages

    • Workspace perms and the 'Workspace Admin'

    Posted by pingus 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
    Reads: 21406
    Link
    Posted by 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
    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

    .
    Link
    Posted by Roberto López 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
    Link
    Posted by pingus 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
    Link
    Posted by Roberto López 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
    Link

    Posted by Roberto López 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
    Link
    Posted by pingus 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
    Link
    Posted by Roberto López posts: 32 ☆ ☆ ☆
    Nice work pingus!

    We will upload to the experimental branch the version 1.6.4.

    Thanks!
    Link

    Switch Language

    Show PHP error messages