Loading...
 

Wiki_in_Multiuser_Portals_gmuslera

For fixing ideas, lets think in a corporate/organizational portal, with information about the organization maintained by some internals people, but can have registered users with some priviledges (but not to change organization's own pages, of course). The tikiwiki.org site could be seen as an example. Lets think that wiki is the main way to publish information.

For the internal editors of the site, some coordination is needed. Something that assign tasks, generate conventions on editing style, page naming, and things like that, and wiki is a good way to do that. But, of course, coordination info is not part of the widely available site, that should not be visible for normal or anonymous users, maybe not even listed (this could be related to the concept of WYSIWYCA)

This can be done with Tiki, but, for a not very small amount of pages, managing the permissions of every newly created page, for coordination or content, could be a big task. For this, there are 2 solutions, having some inheritance in permissions (i.e. if I first create a page clicking in the "?" of a wikiword on an existing wiki page, then the permission of that page could be inherited by the new page) or categories (I'm not entirely sure if right now can be assigned permissions to a wiki category that will have every wiki page on it, but is a way).


Chealer9 comment : I think "permissions templates" are ideal to deal with this. It's quite possible that multiple categories would need the same permissions. I think it should be fairly easy to code a global permissions templates editor that would ask for setting each permission associated with the currently edited template's object type. Cool features would include starting from other permission templates as a base for creating new ones, using the global permissions to establish the default permission template and using an object with custom permissions to create a permissions template based on it.


But when non-editor users can have they own wiki home page, and could create new pages from there, could be a problem with page names. Think in an user creating a page called i.e. Introduction and later the main site wants to have an Introduction page.

Current permission systems enable or create pages in general (if you can create ))UserPagemyuseryou can create any other page) or not create pages at all. More permissions could be created for managing this kind of problems, i.e. a permission that enables the user to create just hisUserPage(( and no other.

Another alternative is to have a permission that tells if the user can "extend" the wiki pages namespace (i.e. lets assume he can create ))UserPagemyuser, and if it have that permission, and no the generic wiki page creation, can createUserPagemyuser_IntroductionandUserPagemyuser-Projects(( but no the page called Introduction, it could be checked having some sort of separator in the name of the page and verifying if the user can edit the page named as the first part, then he can extend that page namespace and create another with the same beginning and a random suffix.

A third approach in the same line as the previous example could be to some sort of prefixing "namespaces" with associated permissions, i.e. a "root" namespace, with empty prefix, that the users wich can create any wiki page belongs, or a project namespace, i.e. all pages named ))MyProject-IntroductionorMyProject-Screenshotswhere the users belonging to some group could add new pages, and maybe aUserPagecurrentuser(( namespace for enable some groups of users to edit and maintain the subtree of pages related to them.

Another thing that could be wanted, if Tiki is used as a CMS, is that the organizational could want to not show the wiki edited pages as wiki pages, if someone want to learn about an organization/company maybe looking at options like export, history or other wiki specific features could be confusing. '

something on this could already be done, modifying i.e. in tiki-index.php in the last lines where do an smarty->assign('show_page_bar'), putting $tiki_p_edit instead of "y" will show the editing controls only to editors


Tiki have a lot of places where publish information more than just Wiki, some could be integrated with Wiki pages thru plugins, or not, but the user could have a "homepage" that could or not be a just wiki page. Like the permission to enable the user to have a subsection of the wiki tree, more permissions could enable the user to have a user-related subsection of other information in the system, i.e. a permission to enable the user to have just his weblog (actual permission enables or not eh user to create any number of weblogs, the one i propose could be used to enable the user to create just one), the same with trackers, etc. Going that direction, even in some future maybe the user could have a "homepage", where with some layout, like a newspaper, are displayed there as a mosaic the content of the user own information, i.e. the latest N blog posts and headers of the latest, the wiki user page, part of his directory, etc (maybe it can be done just with the right wiki plugins anyway)


mstovenour comment: I also am struggling with this same concept of administrative zones within one wiki. One important addition would be the ability to display the permission set for a given page. Maybe an additional button to show the permission templates assigned. This button might only be visible for users with particular permissions like "edit". This would allow an editor to quickly verify who has viewing or editing rights for a given object.

I agree with Chealer9 that permission templates are the way to go. Having them inherited from the previous page when created would greatly simplify the administration of permissions.




Page last modified on Friday 16 April 2004 21:45:30 GMT-0000

Upcoming Events

1)  21 Mar 2024 18:00 GMT-0000
Tiki Roundtable Meeting
2)  25 Mar 2024 17:00 GMT-0000
29th anniversary WikiBirthday (With Ward Cunningham)
3)  18 Apr 2024 18:00 GMT-0000
Tiki Roundtable Meeting
4)  16 May 2024 18:00 GMT-0000
Tiki Roundtable Meeting
5)  20 Jun 2024 14:00 GMT-0000
Tiki Roundtable Meeting
6)  18 Jul 2024 14:00 GMT-0000
Tiki Roundtable Meeting
7)  15 Aug 2024 14:00 GMT-0000
Tiki Roundtable Meeting
8)  19 Sep 2024 14:00 GMT-0000
Tiki Roundtable Meeting
9) 
Tiki birthday
10)  17 Oct 2024 14:00 GMT-0000
Tiki Roundtable Meeting