http://edutiki.ourproject.org/tiki-forum_rss.php?forumId=1 Fri, 08 May 2026 04:45:13 +0100 Tiki CMS/Groupware via FeedCreator 1.7.2.1 http://edutiki.ourproject.org/img/tiki/tikilogo.png http://edutiki.ourproject.org/tiki-index.php en-us http://edutiki.ourproject.org/tiki-view_forum_thread.php?forumId=1&comments_parentId=310 Mon, 11 May 2009 14:11:13 +0100 http://edutiki.ourproject.org/tiki-view_forum_thread.php?forumId=1&comments_parentId=306 Thu, 07 May 2009 16:51:31 +0100 http://edutiki.ourproject.org/tiki-view_forum_thread.php?forumId=1&comments_parentId=302 Wed, 18 Mar 2009 12:00:45 +0100 http://edutiki.ourproject.org/tiki-view_forum_thread.php?forumId=1&comments_parentId=300 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]]> Tue, 17 Mar 2009 11:37:40 +0100 http://edutiki.ourproject.org/tiki-view_forum_thread.php?forumId=1&comments_parentId=294 Tue, 10 Mar 2009 08:47:35 +0100 http://edutiki.ourproject.org/tiki-view_forum_thread.php?forumId=1&comments_parentId=287 Thu, 05 Mar 2009 09:07:34 +0100 http://edutiki.ourproject.org/tiki-view_forum_thread.php?forumId=1&comments_parentId=284 Tue, 03 Mar 2009 09:24:09 +0100 http://edutiki.ourproject.org/tiki-view_forum_thread.php?forumId=1&comments_parentId=272 Fri, 27 Feb 2009 20:46:27 +0100 http://edutiki.ourproject.org/tiki-view_forum_thread.php?forumId=1&comments_parentId=263 Wed, 25 Feb 2009 08:52:56 +0100 http://edutiki.ourproject.org/tiki-view_forum_thread.php?forumId=1&comments_parentId=259 Sat, 21 Feb 2009 11:24:05 +0100