The Workspaces Integration in Tiki
1. Project Highlights
[+]
1.1. What a Workspace is
Because an image is better than a thousand of words ...
Formal definition
A Workspace (ws) is a collection of tiki-items/objects (wikis, forums, blogs, etc.), user groups, with all the relations between them all and profiles/data-channels for automating things. Each group may have access to a set of items within the ws, and with specific permissions.
For example, Students Morning can view the forum and edit the wiki, but users in Students Evening can post in the forum and only view the wiki. There may exist special groups with special permissions within the ws like the teachers group, and for them there are tools using profiles and data channels for automating certain things like add tiki-items, perms, groups, and more.
1.2. The team
- Architects: Axold, MangaPower, Louis-Philippe, rlopez, pingus, jreyes, xavi, Sylvieg, Jonny and all of you with your comments.
- Coding warriors/wizards: Axold, MangaPowerX, you?.
- Testing team: Matthew, marclaporte,rlopez, Regis you?.
- Documentation team: Axold, MangaPowerX, rlopez, you?.
1.3. Key features
- Ability to categorize ws - You want to have a hierarchy to W1:Company-A . Under W1, W11:Administration, W12:HHRR, etc.
- Ability to share items between different ws.
- Important to avoid silos and duplication
- Ability to automate things with Profiles/Data Channels, so you don't need to reinvent the wheel if you don't want.
- Permissions within the workspace - Can be different than in another workspace
- Perspectives - modules layout is contextual to which workspace I am currently in. If I am in the Chemistry 101 workspaces, I will see those modules (last forum posts of Chemistry 101 class, last uploads in Chemistry 101 file gallery, etc). However, I am one click away from Physics 202.
- Like modules, menus can be workspace/perspective aware.
- Search restricted to workspaces - To be able to search within one workspace.
- Since_last_visit(_new) - restricted to the workspace you are at.
- Statistics - To be able to see the module "Since last visit" with content only from your workspace/s.
- Wishlist presented at TikiFest Madrid
- Preferences can be manageable per workspace dev:dynamic preferences
- Theme control - To be able to assign a theme to a workspace, like we can for categories.
- Layout per section: ability to set tiki to hide any side column or header /footer when using workspaces
- Ability to have different domain name per workspace (If someone uses a specific domain name, they are sent to workspace X)
- Will we need home page per workspace?
- Emergence & groups
- Organic Groups
- PluginInvite to invite people to one of my groups (one-click join the group/workspace)
- Can workspaces emerge and die on their own, or they need admin?
- Ability to join workspaces - A bit like groups in 2.x, some workspaces, you can join and leave (there could be the need for admin approval).
- Concept of group roles - Think of a teacher vs students, Team leader vs team members, etc. Group leader has permissions to add people to groups or remove them, assign perms within the workspace. (or perhaps this will be done like now with two groups)
- Group application. A person can attempt to join a group, but a workspace admin needs to approve.
- When you apply or join a group, there can be a form (Why did you want to join this group? tell us about yourself, etc.)
- Welcome email when applying/joining for a group (thanks for joining, a group admin will get back to you, etc.)
- Can workspace admins manage user accounts (change password, change email, user tracker) needed for a Customer Relationship Management vs just add or remove from group for a TikiForge.
- New permissions with respect to workspaces (see below)
1.4. Risks/limitations
- Name collisions need to be addressed or accepted as a limitation
- wiki page names
- group names
- logins
- trackers
- There is no permission inheritance in workspaces. Like in object perms, once you set some, it completely overrides global perms (no negative perms)
1.5. And its possible solutions
- Name collisions need to be addressed or accepted as a limitation
- wiki page names - For now, we are going to use the MediaWiki form (more or less), i.e ws_id<:>workspace<:>wikipage. Yes, we know that using the ws_id and the workspace name is redundant, but it can be useful for avoid certain queries to the database.
- group names - The same as above.
- logins - We still thinking about that.
- trackers - We still thinking about that.
1.6. WS and AulaWiki
We love Aulawiki, and a lot of things are going to come from it, but here we would like to remark which are the main differences:
- WS become a core feature, with their own API/lib.
- WS have been designed to be easy to understand, use and manage. Profiles&Data channels will be the key point.
- WS will solve the performance problems in Aulawiki.
- We are not reinventing the wheel. All what tiki has now can be used: categories, groups, perms, aulawiki and profiles.
1.7. Roadmap
2. Implementation details
[+]Creation and Identification of Workspaces
The idea is to store WS (Workspaces) in the categories table. The first problem is to separate the common categories and the WS categories. The idea is to create a WS container, that is a category which categID will be used define whether an object under it in the hierarchy is a WS or not. This container ID can be stored in in tiki_preferences, and it is created the first time you activate the WS feature. Let's see how it works.
When activating through admin panel the WS feature, tiki will pick up a categID for this container, e.g. 3. With the creation of the new field rootCategId, we can set whether a category is a WS or a common category. So, if a category have the value NULL in rootCategId, then it's a common one; by the other hand, if the value is equal to the WS container (e.g. WS Container ID = 3) then it means it's a WS.
Since we have this new field, we can create categories under WS and, obviously, sub-WS.
2.1. How to create a WS tree
Some users would like to have a WS hierarchy tree, in the same time establish "sub WS". For this issue we have been thinking in using the description field of the categories, but with the appearance of rootCategId we will be able to use parentID, just like common categories do and use the description field normally.
E.g: If there are three WS: W1,W11,W12 and the user want to set W11 and W12 under W1. If W1 ID is 5 then W11 and W12 should have in the parentID field the value 5.
So with one query we can ask to the database the workspaces which rootCategId is 3, and when we have all workspaces, we sent it into JSON or XML format and Javascript on the client side will create the WS tree with the info in the description field.
2.2. New permission for WS management
Since WS will become a new resource in Tiki it's necessary to add new permissions that enable to handle and manage WS. After some days analyzing what permissions are needed for WS we make a list of permissions that would be nice to have in Tiki:
- tiki_p_ws_listwsResources : The most basic and the second most important permission for WS. This will enable to a group to enter in a WS and list all it resources (Without it it's impossible to access in a WS).
- tiki_p_ws_addresources : Enable to create or add resources to a WS.
- tiki_p_ws_removeresources : Enable to remove resources from a WS.
- tiki_p_ws_adminresources : Enable to admin the resources in a WS (adding, creating, removing).
- tiki_p_ws_admingroups : Enable to add or remove groups in a WS (this will add/remove the tiki_p_ws_listwsresources for a group in a specific WS).
- tiki_p_ws_adminperms : Enable to create permissions templates for the resources stored in a WS (explanation of this in Permission Management in WS) and add/remove permissions for the resources stored in the WS.
- tiki_p_ws_addws : Enable to add (create) WS.
- tiki_p_ws_removews : Enable to delete WS.
- tiki_p_ws_admin : The most important and powerful permission, with this permission can access in all WS stored in Tiki and have all the permission described above.
2.3. Permission Management in WS
Workspaces are based on relations with groups and items. One of the things we thought was how we can get the maximum productivity with less clicks. The response are: profiles/data-channels. With them we can automate certain things:
- Creation of items (if exists a handler for it) like Wikis, blogs, forums and so on. So this can be nice for the teachers group for example, because they are allowed to create things in the workspace.
- Creation of new workspaces (as they are based on categories, it can be created with a data channel)
- You can set the permissions of a certain group respect to an item.
- You can grab profiles in the workspaces.profiles.com page (an example) and increase your collection of management scripts.
Example:
Suppose you are in the teachers group and you want to allow that the students morning group have access to edit the wiki which id is 6.
The yaml code could be:
permissions: Students-Evening: objects: - type: wiki id: 6 allow: [ edit ]
If you see the syntax is elegant, but for a teacher he doesn't need to know how to use the permissions handler. So for this, we are going to create an automatic interface that allows to create things like that dynamically. You only provide what you want to do, and the interface will translate it to a profile/data-channel module. That is what we called Profiler Tool and Workspaces will be the first app in Tiki that uses it.
2.4. Perspective by last name - the solution for name collisions?
Think on a tiki+WS installation, e.g. tiki in a company where we have n departments (D1,D2 ... Dn) and n WS (WS1,WS2, ... WSn). For each department we may have one group of users (GD1,GD2, ... GDn). Probably, each department want to have a wiki page called "Contact". How can we manage this wiki page name collision?
We can do this with last names and separating the GUI from the data tiki manages.
When GD1 create the wiki page "Contact", they actually create a wiki page which ID isWS1id::Contact
What do we have to do? A function that does read the tiki object name, and that shows to the users only the name (deletes the last name in the GUI level). Can this be done?
Problems?
| Problem | Possible solution | Status |
| What if two workspaces with the same name at different level? | We can use wsid Contact. But with more precision we can use wsid workspacename::Contact. | Added this way of solving the problem to the documentation. Thanks Marc. |
| What to do when an object is in more than one WS? | The same as with wiki pages belonging to several structures: a drop down box is shown in the top right corner of the page, to allow choosing inside which structure you want to see that page. The same, then, for an object in several ws. (to show it inside the appropiate ws desktop) |
Suggestions?
- Other wiki engines use Namespace:Name_of_wikipage for wiki farms, afaik. Why not adding the same character (: colon) as delimiter? - Added the :: as delimiter.
- whatever delimiter we choose, it has to be Rewrite rules friendly 😊. So i guess that "$" should be avoided, even if I'm not an expert on rewrite rules (Xavi)....
2.5. How should the GUI be?
One of the things we have in mind is the interface, by far the key aspects of the GUI must be:
- It must be very simple and human understandable
- If it possible, the use of Ajax for certain aspects would be nice
- It's better to have more tiki-workspaces pages that do one thing well, than have tiki-list-workspaces that do 20.000 things
So with this 3 things on mind, we have designated these pages (of course, we probably need to create more, so don't be afraid and if you have suggestions, please add them below):
2.5.1. Admin Section
2.5.1.1. Workspaces
This is the global configuration page of WS. Nothing related to single WS or whatever related to that. A list of things that the admin could see in this page are:
2.5.1.1.1. Activation
It will be ruled optionally also by dates (start date and end date), if needed. Else, the workspace will be a never ending ws.
2.5.1.1.2. Enable/disable templates option
I.e this is a special category ("ws type"?) - of workspaces in profiles.tw.org
With this option the user could benefit from the advantages of using profiles and the profiler tool for doing automated things in WS.
2.5.1.1.3. Workspace types
The type of worksapces that can be created. Each WS type will have it's own equivalent set of pages in profiles.tw.o to define the default values for that worksapce type:
- modules for the workspace desktop and how to display them by default,
- resources added to that ws at creation time
- whether ws childs need to be enabled/allowed,
- whether they should expire after a certain period of time by default or never ending,
- ...
See current implementation of ws types at the Mod AulaWiki
2.5.1.1.4. Workspaces Owner List
With this, the admin can add to a workspace an owner or owners. Remember that user is GOD.
2.5.1.1.5. Hibernate Workspaces
This is the same idea as closing the workspace, as it's done in Mod Aulawiki. If you activate this option all workspaces are disabled, but not deleted from the database.
2.5.1.1.6. More things coming
Add your suggestions here!
2.5.2. User Section
2.5.2.1. Workspaces Home
This page is the welcome page when you want to visit workspaces. If you are a newcomer the page will suggest you public workspaces to visit and join in, if possible, as well as the featured workspaces, last activity in public workspaces and more. If you have personal stuff like your own blog, wikipages, and more items, in ws home you can access it. The idea is to get a very similar facebook page that shows how tiki can act as a social network.
2.5.2.2. My Workspaces
This page will list all workspaces a user belongs to. And of course he/she can navigate deeper in a workspace and its child workspaces, if any.
2.5.2.3. Workspaces Desktop
The WS Desktop is the Home of a single Workspace. It could very well imitate, as a starting point, at least, the workspaces desktop GUI found in the workspaces at the Mod Aulawiki.
Example:
2.5.2.4. Workspace Administration
This page will appear if the user has one perm to manage a workspace so its interface will be different depending the perms the user has. This could be shown as a new tab at the WS dektop, provided that the user has the perms to admin that ws. Right now, Mod Aulawiki handles the tab edition through what it's called there as "ws zones". See the tab named as "Admin" at the previous screenshot as example (in aulawiki, the tabs are not wysiwyca, but in tiki 4.0 they should be.
The options here will be:
2.5.2.4.1. Create a new WS, eventually not related to the current WS, if the user has the perms to also do that.
2.5.2.4.2. Create a child WS of the current one you are at, with Profiler Tool
Creation of workspaces will be the key point of the interface for creating dynamic profiles.
2.5.2.4.3. Delete ws objects or the whole ws
2.5.2.4.4. Edit WS
2.5.2.4.5. WS preferences
2.5.2.4.6. Manage WS Groups and users
2.5.2.4.7. Assign WS modules to the workspaces desktop
2.5.2.4.8. Invite a user, or group of users, to join to your workspace
New WS Handler for profiles
Yes, we are developing a new WS Handler for profiles because we want to make your live easy 😉 (and keep in mind that his handler will be used by profiler tool). Take a look in ws handler page for obtain more info, and remember we are working on it, so the syntax could be wrong and bugs and ... you know!
3. Development
[+]3.1. Coding
| SVN Server | ExperimentalBranchesWorkspaces | |
| Status | Please, grab the code from the SVN server. All code is in a VERY alpha stage so we don't recommend you to use it in a production server. | |
3.2. GIT try out comes to Tiki!
After a few discussions in the Tikifest GSoC 2009 it was agreed that we would try out using git alongside svn on the experimental Workspaces branch. The idea is to demonstrate all the major features that git currently has, and how it can improve our lives as developers (hopefully solve svn merge pain 😊 ). This will allow us to identify what the issues might be. We will also examine how git works together with svn.
For now, I'm doing some related task to have ready the GIT repository asap (Aldo). Don't expect to work properly until we have test some things.
Git clone repository:
git://tikiwiki.git.sourceforge.net/gitroot/tikiwiki (read-only) ssh://putyoursourceforgenickname@tikiwiki.git.sourceforge.net/gitroot/tikiwiki (read/write)
3.3. Dogfood - Try it!
Historically, the Tiki community handles workspaces by installing many instances of Tiki and having features to share data, such as InterTiki or External Wiki. This works for large segments / subcommunities / projects like doc.tiki.org
However, we could take advantage or workspaces to create micro-communities around features & mods. It would be more like a *forge-type approach where each project has a set of wiki pages, a file gallery, a blog, etc.
3.3.1. Test WS Branch
Current version of the workspaces experimental branch is installed here. Please use it and give us feedback.
3.3.2. Test Aulawiki 1.7
Latest version of Aulawiki can be tested here. Please use it and give us feedback too. It's important to test the current version to do the best migration.
You can also see some working examples of aulawiki mod for production, using also the workspaces desktop, here:
- http://edu.tiki.org/tiki-workspaces_desktop.php?workspaceId=2&moduleId=35
- http://www.ub.edu/optics/tiki/ws7
- http://www.ub.edu/gclub/ws4
- http://moviments.net/cursos/ws100
4. Opinions, Suggestions, Ideas ...
[+]
- Profiles could eventually be used to populate these workspaces with features, settings, permissions and data
- Could workspaces happen by improving categories?
- Already handled by categories
- Theme control
- Missing / not good enough
- Better category permissions (all perms to be assignable, not like in 2.x)
- Menu & modules contextual to category of currently show item (wiki page, article, tracker, etc)
- Objects/resources belong to different categories. Can this be managed by categories?
- Desired
- Resources that belong to a workspace belong to a category. It doesn't mean they can't belong to different categories; the difference will be that the other categories can be mere common categories, but the workspace category will rule the access to these resources (who can view, edit, comment,....).
- Categories should have the same permissions as groups have, in order to get a better and customized management of categorized resources.
- Already handled by categories
5. GSOC 2009 Project
[+]5.1. Schedule
| Date | Activity | Milestone |
| Feb 15 / April 30 | Documenting/Reading | - |
| Feb 15 | Star reading materials / designing | |
| March 15 | Star writing proposal | |
| April 15 | Proposal written | |
| April 16 | Start preparing presentation for Tikifest (the community review the project) | |
| April 26 | Presentation at TikiFest in London | |
| April 30 | Final version of the proposal written | |
| May/June | Working on the main contribution | - |
| May 18 | Submit a very preliminary version (Design) | |
| May 18 / June 15 | Mid-Term Evaluation of Design | |
| 15 June | Start coding | |
| July | Testing/Releasing | - |
| July 15 | Testing stage finished | |
| Juy 31 | Last Version released | |
| August 1 / August 25 | Documenting - Minor testing - Final Release | - |
| August 1 - 17 | Improve documentation, scrub code | |
| August 17 - 24 | Final Submission | |
| Next TikiFest | Presentation to the Tiki Community | |
5.2. Documentation
[+]
5.2.1. Workspace Lib
5.2.1.1. Possible Models
Item is like a file, an image, a forum post/thread.
Container is like a file gallery, a forum, a wiki.
| Model | Description | |
| Item and container > category -> global | Current Model. There will be a "special" category, that acts as a workspaces parent. | |
| Item and container > category/workspace -> global | Categories are improved to be used as workspaces. Each workspace has its own category. You hang the items (blogs,wikis, ...) on each of them. Can we share items amongst categories? | |
| Item -> category -> workspace -> global | Each workspace has its own category tree. Differences from the previous one are: | |
| Item -> workspace -> category -> global | Category tree is shared amongst all workspaces. Isn't it like the first one? | |
| Item -> workspace/category -> domain.com -> global | We could also try to segment by domain. Tiki WikiFarm / Native multi-site / multi-domain handling | |
5.2.2. Workspace GUI
List of possible quantifiable results:
- GUI for the administration.
- GUI for workspaces management: workspaces creation, listing, search, erase and edit.
- Profiles for Workspaces Management - Workspaces_alpha
- Data Channels for Workspaces Resources Management, it will let the users to populate their workspaces with the resources a specific workspace will contain
Profiler Tool - See the presentation of TikiFest UK:
- A new form of creating things in Tiki:
- jQuery is Mandatory!
- You drop things in a flow (like automator does), and tiki will do the rest.
- Possible uses: manage workspaces, configure your tiki profile during the installation, whatever, ... You don't need to know YAML syntax! Only Drag and Drop!
- More info in the Profiler Tool page!
6. Materials
[+]6.1. Audioconference July 9
6.2. Workspaces presentations on Tikifest GSoC Edition
- Axold : See the file attached
6.3. Must readings:
- Workspaces profiles (why it's essential to use profiles for workspace creation)
- this wiki page of course.
- Documentation of the former workspaces, under the Mod Aulawiki, in a single pdf (En, Es, Ca). Or page by page here:
- Perspective
- Preferences
- Madrid Tikifest materials and videos
- Profiles
- The following video
- TikiFest UK Presentation
6.4. The big picture
[+]Whiteboard - 2009 Feb 16th, morning, TikiFest Madrid - CLICK TO SEE IT FULL SIZE
Whiteboard - 2009 April 16th - CLICK TO SEE IT FULL SIZE
Please note the order is wrong - it is special perms, then group perms then categories perms(sylvie)
6.5. More related links you would like to use for inspiration:
[+]- A More Complete Workspaces 1.7.x Example
- http://www.e-aula.com/dvideo/davver.html
- http://workspaces.xwiki.org/
- TWiki Webs
- http://en.wikipedia.org/wiki/Workspace#Online_applications
- http://www.socialtext.com/products/features/Socialtext-Workspace.php
- http://www.atlassian.com/software/confluence/features/workspaces.jsp
- http://groups.yahoo.com/
7. Wishlist
[+]Open
Pending
| Rating | Subject | Submitted by | Importance | Easy to solve? | Priority | Category | Volunteered to solve | Created | LastModif | Comments | |
|---|---|---|---|---|---|---|---|---|---|---|---|
| (0) | Tiki WikiFarm / Native multi-site / multi-domain handling | Marc Laporte | 7 | 35 |
| Louis-Philippe Huberdeau | 2007-12-02 | 2012-05-19 | 2 marclaporte-04 Aug 09 | ||
| (0) | 1-click access to be able to do certain actions (view a page, edit a page, edit user tracker, etc) | Marc Laporte | 6 | 30 |
| 2008-02-26 | 2010-02-28 | 1 marclaporte-15 Jan 10 | |||
| (0) | When creating a page, how to inherit permissions from source page? | Marc Laporte | 7 | 35 |
| 2008-11-08 | 2008-11-08 | 1 ChadDa3mon-14 Apr 09 | |||
| (1) | Template groups: Fix or make optional | Xavier de Pedro | 9 | 4 | 36 |
| Jonny Bradley | 2020-03-20 | 2020-05-14 | 1 jonnybradley-21 Mar 20 | |
| (0) | perspectives module doesn't show up anymore even if defined in the profile as in TikiFestBarcelona | Xavier de Pedro | 8 | 8 | 64 |
| 2009-09-05 | 2010-01-17 | 1 Chealer9-17 Jan 10 |
Closed
| Rating | Subject | Submitted by | Importance | Easy to solve? | Priority | Category | Volunteered to solve | Created | LastModif | Comments | |
|---|---|---|---|---|---|---|---|---|---|---|---|
| (0) | Modules: if a feature is turned off, it should be hidden or somehow filtered + other ideas | Marc Laporte | 9 high | 45 |
| 2007-08-12 | 2013-06-05 | 0 | |||
| (0) | Workspaces calendar: Missing argument 2 for date_format() in lib/tikilib.php on line 6307 | Xavier de Pedro | 4 | 20 |
| 2007-09-11 | 2009-06-06 | 0 | |||
| (0) | Feature Workspaces is half broken on 1.10: add resources: ko, ws calendar: ko, ... | Xavier de Pedro | 8 | 40 |
| 2008-05-05 | 2009-06-06 | 0 | |||
| (0) | Menu & modules contextual to category of currently show item (wiki page, article, tracker, etc) | Marc Laporte | 7 | 35 |
| 2008-05-26 | 2012-09-28 | 2 marclaporte-28 Sep 12 | |||
| (0) | Workspaces: add to main Tiki code base | Marc Laporte | 8 | 40 |
| Louis-Philippe Huberdeau | 2008-06-03 | 2013-06-05 | 0 | ||
| (0) | Error installing the workspace mod in v2.0 | starnix | 6 | 30 |
| 2008-09-27 | 2009-06-06 | 0 | |||
| (0) | broken install of aulawiki | volx | 5 | 25 |
| 2008-11-02 | 2009-01-13 | 0 | |||
| (0) | Allow a user role or group to automatically generate a personal page, an image gallery, a weblog a | dweade | 9 high | 45 |
| Louis-Philippe Huberdeau | 2008-11-06 | 2010-02-06 | 2 marclaporte-06 Feb 10 | ||
| (0) | Patch for aulawiki.1.6 to run on tikiwiki.2.2 | pingus | 25 |
| 2008-12-16 | 2009-01-13 | 0 | ||||
| (0) | another patch on aulawiki.1.6.2 for tikiwiki.2.2 + a new workspaces | pingus | 25 |
| 2009-02-09 | 2013-06-10 | 4 xavi-06 Jun 09 | ||||
| (0) | Workspace Resources | Oberlus | 8 | 1 difficult | 8 |
| 2009-06-17 | 2019-08-29 | 0 | ||
| (0) | Deploy watch category to tiki-browse_categories.php (and everywhere relevant) | Marc Laporte | 9 high | 8 | 72 |
| lindon | 2009-08-28 | 2010-01-22 | 1 marclaporte-22 Jan 10 | |
| (0) | perspectives module doesn't show up anymore even if defined in the profile as in TikiFestBarcelona | Xavier de Pedro | 8 | 40 |
| 2009-09-05 | 2009-09-05 | 0 | |||
| (0) | tiki-list_object_permissions.php needs refining (adding groups, links to category perms) | Marc Laporte | 9 high | 8 | 72 |
| Jonny Bradley | 2009-11-17 | 2010-01-18 | 0 | |
| (0) | Object permissions for menus: not functional | Marc Laporte | 3 | 15 |
| 2011-05-26 | 2011-09-12 | 0 | |||
| (0) | Switching perspectives should have URL of the home page of that perspective, instead of tiki-index.php | Marc Laporte | 3 | 8 | 24 |
| 2013-08-24 | 2013-10-19 | 0 | ||
| (0) | Areas administration: deleting categories don't remove them from Area | Marc Laporte | 4 | 3 | 12 |
| Jonny Bradley | 2013-10-28 | 2013-10-28 | 0 | |
| (0) | Selecting a new wiki homepage "Courses:_:Foo" got understood as "Courses" | Xavier de Pedro | 5 | 8 | 40 |
| molnarl | 2016-09-11 | 2016-11-07 | 9 jonnybradley-11 Nov 16 |
8. F.A.Q
[+]8.1.1. About Concepts
Question: I don't have clear the structure of a Workspace
===A workspace only is a wrapper=== of things created in Tiki before. This is, a workspace is a container that holds categories, groups, and perms. This is a clever solution, because we are not reinventing the wheel, so if anything beneath the workspace change (e.g adding more perms to categories), workspaces are still working.
Question: I don't have clear what roles exists in a Workspace, please, could you explain me more detailed this?
Workspaces __are not limited__ to only Educational Scenarios. So, why do you want to limit the context, pingus? The major roles exists in Workspaces are: *Admin - this can do anything *Users - this are inside in a workspace (and needs to be inside in a group) You don't need more! You should see the perms, and the picture above! Example: If you are a teacher, you will belong to the Teachers Groups, and this group with profiles and data-channels can manage things inside the workspace. So, in fact, if the group has the correct perms, they could manage the others groups, and wikis. So we don't need right now all you said about group administration by non-admins. Please go to [http://profiles.tiki.org|profiles page] and see what this things are ;)
9. Old stuff
[+]
9.1. What a Workspace is
- Easy content partitioning. Call it sites, namespace, whatever — a way that an admin can create a collection of content that is separate from other content, has a defined security boundary and url separation
- Workspaces (though Tiki does have a 3rd party workspace mods) and/or Management interface for Tiki to be used in a WikiFarm
- Workspaces will help with Social Networking, Project Management and Customer Relationship Management, which are use cases & profiles in addition to features. Will permit to do stuff like Ning.
9.2. What we have, and what we want
- Workspaces work as mods. They are implemented in aulawiki (mentioned above).
- We want Workspaces to be integrated in Tiki as a core feature.
- We have a bunch of features from Tiki 1.9.x, 2.x and 3.x soon that can be used to create these (new) workspaces. The main features we are planning to use are: categories, permissions, menus, modules, aulawiki ....
- So, if you already have these features, why do you want to develop something new? Well, this is not easily scalable to hundreds of groups, and it would be useful to create:
- A WORKSPACES LIB that brings together all the features tiki already has. The objective: an abstraction layer for managing the workspaces.
- A WORKSPACES GUI for administration and for users. What will we have behind the curtain? Profiles and Data Channels, both will be used to populate with resources all the workspaces. The objective? Easy administration panel (point and click) for the admin (and those who have the correct perms to create new Workspaces). Personalized menu for those who are inside in a Workspace. This is we called perspective.