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

[edu.t.o] Development


The 'Simple' workspace example

posts: 52
I write this because I went through a lot of tests before
understanding it, and I think it can be useful.
This also explain what I meant in previous posts with statements like
'has tiki_p_admin_workspaces objectpermission' etc.
Most of this is written by memory, there might per minor differences with a real test :-)

First of all one has to have clear the difference between
grouppermissions (groupperms) and object permissions (objectperms).
When an object, eg a wiki page, has 'individual object permission
tiki_p_edit' assigned to 'user1' or 'group1', 'user1' or 'group1' will be able to edit that
page, even if his group has not that privilege. And 'user2', although he
belongs to a group that has 'tiki_p_edit', will not be able to edit
that wiki page.
Objectperms on a single object have the priority and override and
annihilate any groupperm a group may have on that type of object.

Workspaces are an automated way of assigning objectperms to resources of
a workspace. A user of a workspace (eg.:'teacher') doesn't need any
group perm to act on the ws and its objects. More, he shouldn't have
any group perm at all, if he's had to act only on the ws resources. He should be able to
do everything solely through object permissions granted to him/his group
As admin you can always check individual objectperms eg of a page by listing wiki_pages and clicking on the key next to the one you want.

The Simple workspace example:

Step 1
I start with an almost fresh tw
I log in as admin.
There are only 3 groups defined: Admins, Anonymous and Registered.
Then I install workspaces mod: a hyper of new Groups will be there.
I delete them all not to get confused, until I see again the basic
three groups; Anonymous, Registered, Admins.
For good sake I also delete any existing workspace and workspace types and workspace
roles.
As admin I then add 'tiki_p_view' to Anonymous, (if he hasn't
already), then I add a 'user1' user, affiliated to no group, he's just a Registered

Step 2
Then I go on defining a new workspace Role: SimpleAdmin
Looking at groups now I can see 2 new groups:
- RolePerms-SimpleAdmin
- ROLEGRPSimpleAdmin

What are them?

- RolePerms-SimpleAdmin is a template of object permissions, which will be
applied to every object in the workspace that will be created

- ROLEGRPSimpleAdmin is a facility group, made in case I want to add common
groupperms to all SimpleAdmins. Perms added here will be groupperms, valid
all over tiki objects (except of course those that have individual
objectperms). I will not use this. My SimpleAdmin will not have group permissions,
no perms outside the workspace.

Instead, I add to the RolePerms-SimpleAdmin group these permissions
tiki_p_edit
tiki_p_view_workspace
tiki_p_admin_workspace
tiki_p_create_workspace_resour

Step 3
Now I define a workspace type, let's call it 'Simple'. This will be a
single level workspace, no children.
I define its resources: a wiki page and a blog
With tiki-workspaces_wstype_roles.php I define the only role that will be able
to act in this type of workspace:
SimpleAdmin

Looking at groups now, I see :
-Anonymous with 1 permission (tiki_p_view)
-Registered with 0 perms
-RolePerms-SimpleAdmin with 4 permissions,
-Admins with 1 permission (tiki_p_admin)
-ROLEGRPSimpleAdmin with 0 permissions
-No group includes RolePerms-SimpleAdmin nor ROLEGRPSimpleAdmin
-'user1' belongs to Registered, he totalize 1 perm: tiki_p_view

Step 4
I create a new Workspace of type 'Simple', code 'SIMPLE01'

Looking at groups now, I see some new groups:
-WSSIMPLE01-SimpleAdmin with 0 groupperms
It includes the empty ROLEGRPSimpleAdmin with 0 groupperms
-WSSIMPLE01 is another new utility group where to add common groupperms
to all members of a group. 0 groupperms. I will not use it either.

Then I use the Users/Groups ws module to add 'user1' to the group
WSSIMPLE01-SimpleAdmin

Now in admin users I see this:
- user1 is assigned to group WSSIMPLE01-SimpleAdmin

in admin groups the situation is this now:

-Anonymous with 1 permission,
-Registered with 0 perms
-RolePerms-SimpleAdmin with 4 permissions,
-Admins with 1 permission,
-ROLEGRPSimpleAdmin with 0 permissions
-WSSIMPLE01-SimpleAdmin now includes ROLEGRPSimpleAdmin, both totalizing 0 perms
-No group includes RolePerms-SimpleAdmin with its 4 perms
(so noone can edit a wiki page)
-'user1' is assigned to group WSSIMPLE01-SimpleAdmin And ROLEGRPSimpleAdmin, totalizing
1 perm, 'tiki_p_view'

Step 5

Logout and login as user1
I can edit the 'WSSIMPLE01 - Home Page'
I can add new users to the Ws group WSSIMPLE01-SimpleAdmin
I can create a new wiki page and edit it
I cannot view nor post to the 'WSSIMPLE01 Blog'

Still 'user1', nor the groups he belongs to, have any group permissionm
other than tiki_p_view.

Conclusion:
Workspaces and its permission were intended and designed to work
without the need to assign nor use groupperms.

Further work:
one can see an try the different possibilities obtained by adding/removing certain permissions to the RolePerms-xxx objectperms template, in particular workspace_related permissions 'tiki_p_admin_workspace' and 'tiki_p_create_workspace_resour'

It would be nice if someone could write a more complex example, maybe one involving Personal/Local Folders ws types and Owner Roles. I miss to understand how this works completely.

I wrote this because I think this is the kind of information a web administrator wants to know about workspaces. Maybe it can be a point of start for a bottom up documentation intended for tiki admins.
posts: 32
Pingus, thanks for your efforts documenting this. I will try to test in a clean installation of TW.

Let me now to comment something about permissions.

>...
> Objectperms on a single object have the priority and override and
> annihilate any groupperm a group may have on that type of object.
>
It's the tiki way. As far as I understand, in tiki the object perms are at the top of the hierarchy, somehow it's possible to violate the hierarchy you have established with the groups of users. Actually, object perms breaks this hierarchy. Is this desirable? Well, I don't know. Maybe in the new workspaces we want to develop, we should guarantee an order in the permissions inherit. Worspaces must continue being an automated way of assigning objectperms to resources within them. How could we articulate this with categories? This is the next issue.

Switch Language