Because an image is better than a thousand of words ...
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.
- 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?.
- 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)
- Name collisions need to be addressed or accepted as a limitation
- wiki page names
- group names
- There is no permission inheritance in workspaces. Like in object perms, once you set some, it completely overrides global perms (no negative perms)
- 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.
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.
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.
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.
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.
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.
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.
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 is
WS1id::Contact. The double colon is just a delimiter (feel free to chose another). With these last names in the objects, you solve the name collision between WS.
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?
|What if two workspaces with the same name at different level?||We can use wsid|
Contact. But with more precision we can use wsidworkspacename::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)|
- 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)....
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):
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:
It will be ruled optionally also by dates (start date and end date), if needed. Else, the workspace will be a never ending ws.
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.
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
With this, the admin can add to a workspace an owner or owners. Remember that user is GOD.
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.
Add your suggestions here!
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.
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.
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:
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:
126.96.36.199.1. Create a new WS, eventually not related to the current WS, if the user has the perms to also do that.
Creation of workspaces will be the key point of the interface for creating dynamic 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!
|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.|
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://firstname.lastname@example.org/gitroot/tikiwiki (read/write)
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.
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:
- 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?
- 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
|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 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|
Item is like a file, an image, a forum post/thread.
Container is like a file gallery, a forum, a wiki.
|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|
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!
- Axold : See the file attached
- 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:
- Madrid Tikifest materials and videos
- The following video
- TikiFest UK Presentation
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)
- A More Complete Workspaces 1.7.x Example
- TWiki Webs
|Rating||Subject||Submitted by||Importance||Easy to solve?||Priority||Category||Volunteered to solve||LastModif||Comments|
|(0)||When creating a page, how to inherit permissions from source page?||Marc Laporte||7||35||2008-11-08||1|
ChadDa3mon-14 Apr 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||2010-02-28||1|
marclaporte-15 Jan 10
|(0)||perspectives module doesn't show up anymore even if defined in the profile as in TikiFestBarcelona||Xavier de Pedro||8||8||64||2010-01-17||1|
Chealer9-17 Jan 10
|(1)||Template groups: Fix or make optional||Xavier de Pedro||9||4||36||Jonny Bradley||2020-05-14||1|
jonnybradley-21 Mar 20
|(0)||Tiki WikiFarm / Native multi-site / multi-domain handling||Marc Laporte||7||35||Louis-Philippe Huberdeau||2012-05-19||2|
marclaporte-04 Aug 09
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 ;)
- 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.
- 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.