Note: A new feature called Workspace UI makes the creation of Workspaces easier since Tiki10

One of the frequently requested information about workspaces is where the workspace checkbox can be found. You can use them without an easy User Interface, or take profit of the easy-to-use Workspaces User Iinterface ("Workspaces UI") that you can enable here:
Admin home (Control Panels) > Workspaces & Areas (tiki-admin.php?page=workspace) > Workspaces UI

All the components are in place and are ready to be used, with or without UI. However, some consideration must be placed on how to assemble them for your particular use case if you don't use the Workspaces UI.

For maximum control and for experienced powerusers/developers, you can create workpaces by hand (without an easy-to-use UI) following the indications below in this page

Hand-made workspaces

The cycle to complete workspaces is in multiple steps:

  1. Experiment by building hand-made workspaces
  2. Automate the creation process through Data Channels
  3. Distribute learning through Profiles
  4. Go to 1

The workspaces are composed of very simple components in Tiki. Primarily Categories, Groups and optionally Perspectives. By creating a category and several groups, one can create a workspace with specialized roles. Simply by placing the wiki pages or other objects in the category, the workspace's content will be made accessible based on the rules set for the workspace, provided that you ensure that there are no object permissions there which might overrule those workspace (category) permissions if you don't want to.

Perspectives will modify certain aspects of the Tiki instance to make the workspace more visual. Below is a summary of the steps involved. For a more detailed tutorials, see: Tutorial: Manually creating a Workspace.

  1. Create a category (write down the ID)
  2. Create several roles for the workspace, and one group for each role.
  3. Modify the permissions on the category so the newly created roles (groups) have privileged access
  4. Add users to those groups
  5. Create a new perspective
  6. Edit and add the Category Jail preference to the perspective and enter the category ID in it (you can search for "jail" and then drag and drop the result above to the Configurations area - needs JQuery UI feature enabled)
  7. Modify the permissions on the perspective so that the groups can view it
  8. Add the perspective module

Already, you have a basic workspace in place.

Play with it

Switch to the perspective using the module. Because of the category jail, if you go to list pages, you won't see any pages. They are automatically filtered out so you can focus on your project.

When you attempt to create a new wiki page, the category will automatically be selected. (This may require some permissions to assign categories to objects and add objects to a category)

Switching out of the perspective will make everything visible again.

Progressive improvements can be made to the workspace. By changing more preferences on the perspective, the experience can be adapted. Consider changing the site's title or the theme option to make it clear when you are in a perspective.

Create a dashboard

The category jail affects how you view the content inside Tiki. The listing inside modules will be altered. Go a step further and change the home page of the perspective to a dashboard so members can quickly see what is going on when they begin working on the project.

  1. Create a new wiki page (like My First Workspace Dashboard)
  2. Add a workspace-aware plugin to it, like the category plugin to display the elements of the workspace
  3. Change the wiki home page inside the perspective

You can also add the PluginMemberList to allow user management from the dashboard for the administrator of the workspace (permissions required) or simply to let members view who else is working with them.

As you create multiple workspaces manually, patterns will emerge. All those steps are tedious and some steps require higher privileges that most site administrators would like to grant to too many people. This is where automation comes into play.

Automation through Data Channels

If you need to create workspaces often for various projects, going through the manual steps every time may take a long time. Setting the permissions correctly on all objects for all groups will quickly become tedious. There are multiple error opportunities that could cost many hours.

Data channels allow to automate the process and convert workspace creation to a single step. However, some time must be invested to create the workspace template that will be used to initialize workspaces and serve as a starting point. The workspace can then be customized as needed using typical Tiki features.

Data channels use the same syntax as profiles for their definition. Extensive reference documentation can be found on the profiles' site. They are stored in wiki pages, so complete history is provided to allow more collaboration. However, when executed, data channels have extensive rights, so limiting access to trusted users is a must.

When starting out, it's better to test on a separate installation to avoid excessive amounts of test data from being generated.

Organizing the workspace template

Profile definitions can be cryptic. However, only the code blocks are evaluated and there can be multiple blocks in the page.

Use the space in-between to describe what they do and what the objectives are.

  1. Create a new category to contain your workspace template and make sure only trusted users have edit rights
  2. Create a WorkspaceTemplate page and put it in your new category
  3. Register the page as a data channel in the profiles administration page, under the Advanced tab. The line should look like this:
    • workspace_template, tiki://local, WorkspaceTemplate, Admins
    • The line indicates that a channel named workspace_template can be executed by members of the group Admins and uses the page WorkspaceTemplate as the definition locally.
  4. Create an interface to call the data channel using a wiki plugin. It can be on any page of your choosing. See Code Block #1. The plugin will display a form with a workspace name field. When called, the data channel will be provided with that name as an argument.
  5. Modify your WorkspaceTemplate page to contain the workspace definition. A basic definition containing the creation of a category and a perspective can be seen in Code Block #2. A second part containing group definitions can be seen in Code Block #3.

Code Block #1: Data channel interface
Copy to clipboard
{DATACHANNEL(channel=workspace_template)} workspace_name,Workspace Name {DATACHANNEL}

You can add additional fields by adding more rows in the plugin. The format is very simple: value name inside the data channel followed by the label to display on screen.

Code Block #2: Perspective and category
Copy to clipboard
{CODE(caption=>YAML)} objects: - type: category ref: workspace_root data: name: Workspace $profilerequest:workspace_name$Unknown$ - type: perspective ref: workspace_perspective data: name: Workspace $profilerequest:workspace_name$Unknown$ preferences: category_jail: $workspace_root {CODE}

The above may seem a little confusing at first, but the format is regular enough when you are used to it. First, one must notice that two objects are created. One of type category and the other of type perspective. The ref argument below the type indicates a name that will be used to reference to the object elsewhere in the template. The type indicates how the data block will be processed. The values that can be provided are specified as part of the developer documentation page. under Category Handler and Perspective Handler.

Both names contain a strange structure: $profilerequest:workspace_name$Unknown$. This will be replaced by the name provided in the data channel form. If Test is entered as the workspace name, both the category and the perspective will be named Workspace Test.

The perspective also contains the preferences that will be used. In this case, only the category_jail preference is set. The preference names are those used internally by Tiki. Some research may be required to find those. The value is set to $workspace_root, which is the name given to the category. It will be replaced by the ID of the freshly created category.

Test it out

Without the groups of the following section, you can run the data channel and generate perspectives and category. As an exercise, try the following:

  • Change the site title as part of the perspective
  • Change the theme
  • Place the workspace categories under a common category

Code Block #3: Creating groups
Copy to clipboard
{CODE(caption=>YAML)} mappings: Member: $profilerequest:workspace_name$Unknown$ Member Lead: $profilerequest:workspace_name$Unknown$ Lead groups: Member: autojoin: y objects: - type: category id: $workspace_root allow: - view - edit - view_category - add_object - modify_object_categories - type: perspective id: $workspace_perspective allow: [ perspective_view ] Lead: autojoin: y objects: - type: category id: $workspace_root allow: - rollback - remove_object - type: group id: Member allow: - group_view - group_view_members - group_add_member - group_remove_member {CODE}

The initial section defines mappings. Using a syntax explained earlier, the profile will create groups named Workspace Lead and Workspace Member. Lead and Member are used as shorthands for the remaining of the definition.

The groups section provides more information along with the privileges they grant. The autojoin flag indicates that the user triggering the data channel will automatically become a member of the group. Here, privileges are not granted globally. Instead, they are defined for the category and perspective.

  • Members can view and edit wiki pages in the category, add objects to it and modify the categories on objects. However, they will not be able to remove objects from the workspace.
  • Leaders can rollback changes and remove objects from the workspace
  • Leaders can view the member group and manage the users in it.

Test it out

With those groups, you create a minimal workspace with enough permissions to make it usable. Try to go further.

  • Let members view each other
  • Grant permissions on different object types
  • Create other groups for the workspace
  • Add a dashboard

A more complete template example can be found as part of the Project Management Profile.

Distributing knowledge

About Profiles

Profiles are Tiki's configuration distribution system. The configuration scripts are stored in a wiki, also running Tiki, referred to as the repository. The primary repository is profiles.tikiwiki.org, but any installation can be used by applying the Profile Repository Profile.

Profiles can be applied from the admin panels.

Not all contexts will require the same kind of workspaces. However, many of them are bound to have similarities. Once the workspace set-up has been running for a while, it is recommended to share the set-up with others. Ideally, communities will form around a given use-case. Like most configurations, the workspace set-up can be distributed using profiles.

A workspace profile is essentially a normal profile, but will require to copy the template verbatim and create the data channel. The repository will need to contain at least two pages: one for the profile definition and one containing the template. The template page can be an exact copy of the page currently used as a template. If the template uses external dependencies, those must also be provided by the profile.

Data channel registration - MyWorkspaces
Copy to clipboard
{CODE(caption=>YAML)} objects: - type: wiki_page ref: workspace_template data: name: workspace_template content: wikidirect:MyWorkspaces_template - type: datachannel data: name: workspace_template profile: $workspace_template groups: [ Admins ] {CODE}

In the above, a wiki page is first created. The page name will be workspace_template and the content will be taken from the page MyWorkspaces_template on the repository. Unlike wikicontent:, wikidirect: will not resolve references, which is required to load a profile template.

The datachannel is then registered and granted to the Admins group.

Additionally, you can add the perspective switching module automatically.

Module switcher - MyWorkspaces
Copy to clipboard
objects: - type: module ref: switcher data: name: perspective position: right order: 10 groups: [ Registered ]

Historic notes

Starting in Tiki4 and continued in Tiki5, massive improvements to existing features like Categories, Permissions, Groups, etc and the addition of some new concepts, like Perspectives and Organic Groups permit to generate workspaces. All these features are in the core.

This permits to make smaller spaces within a Tiki instance, where Preferences can be overridden and permissions can be different.

Workspaces will help with Social Networking, Project Management and Customer Relationship Management, which are use cases & profiles in addition to features.

For more details, please see: Workspace

This is different than a previous effort AulaWiki, which is available as a mods (additional code).

Simple explanation

See here: Simple_explanation_of_perspectives_categories_category_jail_etc.

and the following conversation

FAQ-alike IRC conversation (helpful to understand)

Following an excerpt of an IRC conversation between mikebeary and nkoth, that the both guys allowed to use for the documentation:

can someone please give me a general idea of how workspaces are different than perspectives? I'm having trouble finding a concise definition

a workspace is a use case - there is technically not really a workspace feature. Perspectives, combined with other features such as category jailroots are the features that enable create workspaces

so its a general term that just describes the work area a person is in based on what they've clicked on, who they are, etc.? As opposed to a separate page or something?

yes, workspaces is a rather general term describing a work area that could consist of a certain way it looks, certain permissions that exist in that state, and things presented, etc..

I want to create a wiki that begins with a site for all the colleges in a Missouri, from which you select your college, and then select your campus and then your club. Would each of the different colleges just have their own workspace and then each campus would have their own workspace, etc? as opposed to making a totally separate page? I'm guessing perspectives and jailroot features would bring them to their workspace based on them selecting their college or their campus?

possibly , but you have to consider what is your reason for dividing up the wiki into multiple workspaces to begin with.
Is it to prevent one person from seeing the other group's things?
Is it to present a different screen layout?
Is it to limit the amount of things a person is seeing while in a particular workspace so that he is not information overloaded but he can still switch between workspaces?

not to limit, but just so that each level can have their own calendar, their own forums, their own file galleries, etc.

Sounds like you need to create some categories some perspectives and then configure each of the different perspectives to have different jailroot
each perspective would have also its own different home page so that when you switch to it (the perpective), the user sees that home page


and while they are in that perspective they are exposed only to things in the category jail root of that perspective

really, it'd be the same .php file, but a different theme kind of thing?

basically tiki has a lot of preferences right?


for each perspective you can have a different "setup" of preferences


so the possibilities are really up to your imagination the UI is at tiki-edit_perspective.php
you search for a pref, drag it into the perspective and configure it (basically overriding the global value) for that specific perspective

So say for instance I go to Missouri's website. I'd be at the tiki-index.php. Then I'd select my local college. Are you saying at that point, I could be at my college's "site" but without ever leaving tiki-index.php? I'd just be changing everything based on jailroot and persepective settings?

the link to switch perspectives is tiki-switch_perspective.php?perspective=3 to switch to perspective 3
So that could very well be how you "goto" to the college's "site" which is perspective 3

And essentially what I’ve done by selecting my college's "site" is to select a different workspace

technically speaking, you switch to a different perspective which yeah I suppose it sounds synonymous with workspaces, but the point is that a perspective could be used for something as simple as say, having a different page header and not necessarily to the extent of creating workspaces which is what you are doing.

ok, that makes sense.

and what exactly is a jailroot

it is a pref (and so you can configure it globally or for any specific perspective)
Basically it is a list of category IDs . If you set it to e..g 2, 3, and 5, then users can only see/search for/are exposed to items that are in categories 2, 3, and 5

so kind of like bulk-processing for perspectives? So you don't have to change a whole lot of perspectives to achieve what you can with categories?

not exactly.
well, the point is that categories are just that, you put things in them and you can set permission for them by setting a category jailroot for a perspective, say the college's perspective
you are basically saying that "while a user is in the college's 'site' he is exposed only to things inside those categories specified in that jailroot
it could just be one category, or it could be many categories - it's up to you

if you could perhaps cut and paste this conversation into the wiki page where you expected this info to be in the first place on doc.tiki.org, it could be useful for now, until you have developed more fancy documentation liek that youtube video you talked about

Ok, I will definitely do that.


Alias names for this page
workspaces | WS | Category Jail | CategoryJail | Jail


Get Started

Admin Guide User Guide


Keywords serve as "hubs" for navigation within the Tiki documentation. They correspond to development keywords (bug reports and feature requests):

Accessibility (WAI and 508)
Articles and Submissions
BigBlueButton audio/video/chat/screensharing
Browser Compatibility
Link Cache
Clean URLs
Communication Center
Compression (gzip)
Contacts (Address Book)
Contact us
Content Templates
Custom Home and Group Home Page
Date and Time
Debugger Console
Directory of hyperlinks
Documentation link from Tiki to doc.tiki.org (Help System)
Dynamic Content
Dynamic Variable
External Authentication
Featured links
File Gallery
Friendship Network (Community)
Gmap Google maps
i18n (Multilingual, l10n)
Image Gallery
Inter-User Messages
Kaltura video management
Live Support
Logs (system & action)
Look and Feel
Map with Mapserver
Meta Elements
Mobile Tiki and Voice Tiki
Performance Speed / Load
Platform independence (Linux-Apache, Windows/IIS, Mac, BSD)
Profile Manager
Search engine optimization
Search and Replace
Semantic links
Shadow Layers
Shopping cart
Social Networks
Spam protection (Anti-bot CATPCHA)
Tell a Friend, alert + Social Bookmarking
Theme CSS & Smarty
Tiki Manager
User Administration including registration and banning
User Files
User Menu
Web Services
Wiki History, page rename, etc
Wiki Syntax
Wiki structure (book and table of content)

Tiki Newsletter

Delivered fresh to your email inbox!
Newsletter subscribe icon
Don't miss major announcements and other news!
Contribute to Tiki