on Tue 17 of Mar., 2009 12:37 CET, by pingus
posts: 25
> We will start with the lib of categories to creae this new organic
workspaces.
I am reflecting about categories (the issue eh?), and their enlargment
to manage workspaces and groups. I might be damn wrong on some of the
following statements, please point it out to me!
Categoris and objects
Categories are a pyramid, a 'tree' structure (as opposed to a 'net'
structure), at the base of which are objects.
A category can have n child categories, but every category has only one
parent.
At the base of this tree there are objects, which, differently than
categories, can belog to multiple categories. Categorized object can
belong to multiple categories, but categories can't. So at the lowest
level, the object base of the categories pyramid, and for one level
only, this becomes a 'net' structure'.
There is a difference in the terms 'is child of' (a category of a single
category) and 'belongs to' (an object to one-or-more categories).
Workspaces are categories and objects at the same time! And Workspaces
are a different type of objects, because they themself contain other
objects that cannot be contained in any other workspace.
And I think they are the only objects that can contain other objects.
Eg:
Image galleries are objects, but the single images in them are not. You
can categorize a image gallery, but not its images.
So if you consider a ws as a category, it can be child of only one
category. And as a category it stays the top af the category tree.
If you consider the workspace as an object , it could belong to
multiple categories, something which clashes with the previuos
statement. In fact it is a category at the top of the categ tree, and
an object of this same category.
Can you categorize categories? joke :)
Or, more realistic, or think of different category types.
Maybe this is the way to go... Maybe think of caterogries whose type
allows to be child of multiple parents, whose object are in reality
object containers like the categories themself, but with a different
logic and structure inside them.
Then,more, any object belonging to a ws (eg.: a resource) has only one
parent,the workspace it belongs to. For this reason I think categori
es have been used up to now: the easy grouping of its resources.
Also ws resources can't belong to multiple workspaces, , but as objects
they belong to the workspace's category and should be able to belong
to any other category, because we want to be able to freely categorize
these too (eg.: a wiki page balonks to its ws category but may aloso belong
to other categories).
For me Categories are useful to group objects of a workspace and basta,
that's all. I'd even find a different mechanism to do this, and bee free
to categorize as usual workspaces and their objects.
Another example are permission groups.
Groups are different from categories because it is not a pyramid, a
'tree' structure. It is a 'net' structure. A group can contain n groups
and be contained in n groups. There is not the 'one-parent-many-child'
relation here.
The RolePerm? stuff introduced de facto a new group type: object
permission template group. No user should be assigned to this group.
Maybe can be handy to include in it some other groups of this same type,
the object permission template group type, but...
So now we have
- '(tiki-wide) Permission Groups' type of groups, that can hold multiple other
Permission Groups' and/or users and be included in multiple groups.
This is 'net' structure.
- 'ObjectPermission Templates' type of groups, that will not contain any
user, but may (?) be used to contain multiple other
'ObjectPermission Groups templates'
This also is a 'net' type of structure
What I miss is a 'UsersGroups' type of groups, that can contain only
users. It's something that exists 'de facto', but it would be better if stated and clear somehow. That would be handy. This is also a 'net'
type of structure
All these 'net' structures don't fall in the 'tree' stucture of
categories.
Categories are more fit to handle the 'level' managing of
permission groups, because this is a 'tree' structure.
>
> > 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
Workspaces, Groups, Categories
workspaces.
I am reflecting about categories (the issue eh?), and their enlargment
to manage workspaces and groups. I might be damn wrong on some of the
following statements, please point it out to me!
- Categoris and objects
Categories are a pyramid, a 'tree' structure (as opposed to a 'net'structure), at the base of which are objects.
A category can have n child categories, but every category has only one
parent.
At the base of this tree there are objects, which, differently than
categories, can belog to multiple categories. Categorized object can
belong to multiple categories, but categories can't. So at the lowest
level, the object base of the categories pyramid, and for one level
only, this becomes a 'net' structure'.
There is a difference in the terms 'is child of' (a category of a single
category) and 'belongs to' (an object to one-or-more categories).
Workspaces are categories and objects at the same time! And Workspaces
are a different type of objects, because they themself contain other
objects that cannot be contained in any other workspace.
And I think they are the only objects that can contain other objects.
Eg:
Image galleries are objects, but the single images in them are not. You
can categorize a image gallery, but not its images.
So if you consider a ws as a category, it can be child of only one
category. And as a category it stays the top af the category tree.
If you consider the workspace as an object , it could belong to
multiple categories, something which clashes with the previuos
statement. In fact it is a category at the top of the categ tree, and
an object of this same category.
Can you categorize categories? joke :)
Or, more realistic, or think of different category types.
Maybe this is the way to go... Maybe think of caterogries whose type
allows to be child of multiple parents, whose object are in reality
object containers like the categories themself, but with a different
logic and structure inside them.
Then,more, any object belonging to a ws (eg.: a resource) has only one
parent,the workspace it belongs to. For this reason I think categori
es have been used up to now: the easy grouping of its resources.
Also ws resources can't belong to multiple workspaces, , but as objects
they belong to the workspace's category and should be able to belong
to any other category, because we want to be able to freely categorize
these too (eg.: a wiki page balonks to its ws category but may aloso belong
to other categories).
For me Categories are useful to group objects of a workspace and basta,
that's all. I'd even find a different mechanism to do this, and bee free
to categorize as usual workspaces and their objects.
- Another example are permission groups.
Groups are different from categories because it is not a pyramid, a'tree' structure. It is a 'net' structure. A group can contain n groups
and be contained in n groups. There is not the 'one-parent-many-child'
relation here.
The RolePerm? stuff introduced de facto a new group type: object
permission template group. No user should be assigned to this group.
Maybe can be handy to include in it some other groups of this same type,
the object permission template group type, but...
So now we have
- '(tiki-wide) Permission Groups' type of groups, that can hold multiple other
Permission Groups' and/or users and be included in multiple groups.
This is 'net' structure.
- 'ObjectPermission Templates' type of groups, that will not contain any
user, but may (?) be used to contain multiple other
'ObjectPermission Groups templates'
This also is a 'net' type of structure
What I miss is a 'UsersGroups' type of groups, that can contain only
users. It's something that exists 'de facto', but it would be better
if stated and clear somehow. That would be handy. This is also a 'net'
type of structure
All these 'net' structures don't fall in the 'tree' stucture of
categories.
Categories are more fit to handle the 'level' managing of
permission groups, because this is a 'tree' structure.
>
> > 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