Stephane Casset wrote:
>>>>> If think you need :
>>>>> o creating a workspace
>>>>> o adding users to the workspace
>>>>> o creating a group in a workspace
>>>>> o adding users to a group
>>>>> o creating a category
>>>>> o changing perms on objects/categories in the workspace
>> I meant *we need* also Adding groups to a group.
>>> Why ? You should be able to do almost evry thing in a workspace that you
>>> will do in main site, minus some operation, but creating groups and
>>> building a groups hierarchy should be doable no ? I agree that we may
>>> need to limit group recursion inside worspaces... but as an option
>>> because you could include groups that you know nothing about...
>> There is the problem in fact.
>> A non-admin adding groups to groups. A non-admin including existing
>> groups (and their unknown perms and further included groups too) into his
> Well I don't understand why you may want to import tiki groups inside a
> workspace. I mean you create a workspace for a group of people, and only
> these people can acces the workspace, and then they should be free to
> create groups among themselves, categories and documents (wiki pages,
> files, etc.) accessible only to the people of the workspace. You don't
> need extra groups from outside the workspace no ? Unless I misunderstand
> the concept... ;p
This is the base concept I started to work on in workspaces 1.7.
In fact workspaces do work well with 0 permission groups, because it's
all based on objectpermissions granted by the resources/containers.
-But then noone from outside the workspace must be able to add any
non-workspace group to a ws group, or maybe any group with more than 0
perms. Here comes the need for a people-only-groups blocking flag. And
the dont-include-included (1-level inclusion flag in the union table
proposed by Sylvie?)
Even so, as there are different level of category/workspace related
permissions among the workspace/category environment itself, one could
add another workspace's group to his that has more
workspace/category-related privileges than his
I am trying to solve this also, and I commited a patch yesterday, which
is present alredy at the workspaces.altervista.org demo site.
With this modification, now a non-admin sees his groups in three levels:
- level-0: The common workspace perms group that is at top of the ws
groups (level-0 : WSTEST)
-level-1: WSTEST is included ('contains' in tiki speech) in the
Workspace RoleGroups, (level-1: WSTEST-Admins,WSTEST-Members)
-level-2 other ws groups (eg WSTEST2-Admins) attached to level-1 groups
WSTEST-Admins can only:
- ADD GROUPS only to level-1, from a limited choice of groups
(his_+_all_other_wsgroups_downwards from the upmost he can admin), so
he can add othe ws groups only to WSTEST-Admins & WSTEST-Members.
- CREATE NEW/REMOVE GROUPS only under level-0 (WSTEST) (so not under
- ADD USERS to level-0 and level-1 only (so not to WSTEST2 groups)
> For me, and I've discuss with people here, and what they want, and what
> is laking in Tiki, is the hability for normal users to create a special
> container for a certain group of people, let say for organizing a
> workshop, for finalizing an article/experiment, and so on...
Workspaces now allow a non-admin to do this easily.
> Worspaces are just what we need but we should aim for something very
> basic, which will allow normal users to create a community of users what
> will share things. So you just create a container (workspace), affect
> this to one group and let them do what ever they want inside that group.
> The group could be created by the creator/owner of the workspace, so
> normal people should be able to create personal groups to, that would be
> visible only to the creator and members of the group...
Same, workspaces now can do this
> So workspace will work exactly as a normal tiki site but only for a
> limited mumber of users that are members of the workspace.
> We only need to find a simple way of saying this thing (group, category,
> data) is in a workspace... something like tiki_objects for example...
The fact that things are not simple is normal. How can these things be
simple? Simple must be the interface, what you see and how you
accomplish what you need. Behind, they are always complicate. raw-hide.