Loading...
 

A More Complete Workspaces 1.7.x Example

Following this previous post The 'Simple' workspace example I try to explain how t osetup a more complete example of Workspace implementation using the features of Workspaces 1.7.x

  • First of all you'd install the aulawiki-1.7.1 mod.
  • Then, as in the 'Simple' example, I suggest you to erase everything that is shipped, workspace-related:
    Workspace types (COURSE, GROUP, FOLDER etc)
    Workspace Roles (TEacher, Student)
    Groups related to these: RolePerms-Teacher, RolePerms-Student, Owner


The process of configuring and creating your first workspaces has 3 steps, to be done in sequence:

  1. Define Roles
  2. Define Workspaces types, and assign Roles, Resources and Desktop for them
  3. Create a Workspace

Workspace Roles

There will be 3 Roles, equivalent to the 3 workspace permission available:

  • An AreaAdmin
    Can Create New Sub Workspaces, Manage Workspaces Groups
  • A SpaceManager
    Can create new resources inside his workspace, assign permissions to them, optionally add single users/member to his workspaces Groups
  • A Member
    Can use the workspace, editing pages, posting to blogs, forums, or whatever the objectpermissions of the workspace resources will allow his Role to do.


Already at this point we click on the blue personnel icon next to the Role, and assign permission to this Role.
What we are really doing here is not assigning permission to any group of users, but defining a Template of permissions that will be converted into Objectpermissions for every future object that will be created.
THIS IS VERY IMPORTANT:
So, if we say that the Member Role will have tiki_p_edit, it means that, when a new page will be added to the workspace, this page will be created with objectpermission tiki_p_edit already assigned to all the groups of type Member. We don't have to add any users or goups to these RolePerms-xxx groups, as they are just a template.

The trigger that enables a Member, or and SpaceManager or an AreaAdmin, to act as such inside the workspace, are the tiki_p_admin_workspace, tiki_p_create_workspace_rdesour, tiki_p_view_Workspace permissions.

So, here as an example, the perms assigned to the various RolePerms-xxx objectpermission templates:


Name: RolePerms-AreaAdmin
Desc: Template of Objectpermissions that each object will grant to Groups of type AdminArea, in the Workspace Types that have this Role defined)
Permissions:

tiki_p_admin_calendar
tiki_p_admin_cms
tiki_p_admin_comments
tiki_p_admin_directory
tiki_p_admin_directory_cats
tiki_p_admin_directory_sites
tiki_p_admin_drawings
tiki_p_admin_faqs
tiki_p_admin_file_galleries
tiki_p_admin_forum
tiki_p_admin_freetags
tiki_p_admin_galleries
tiki_p_admin_newsletters
tiki_p_admin_wiki
tiki_p_admin_workspace
tiki_p_approve_submission
tiki_p_assign_perm_image_gallery
tiki_p_autoapprove_submission
tiki_p_autosubmit_link
tiki_p_batch_upload_images
tiki_p_blog_admin
tiki_p_create_galleries
tiki_p_create_workspace_resour
tiki_p_edit_article
tiki_p_edit_html_pages
tiki_p_edit_sheet
tiki_p_edit_submission
tiki_p_freetags_tag
tiki_p_list_users
tiki_p_post_comments
tiki_p_post_shoutbox
tiki_p_remove_article
tiki_p_remove_submission
tiki_p_sendme_articles
tiki_p_submit_article
tiki_p_submit_link
tiki_p_subscribe_groups
tiki_p_unassign_freetags
tiki_p_upload_images
tiki_p_use_HTML
tiki_p_validate_links
tiki_p_view_sheet_history



Name: RolePerms-SpaceManager
Desc: Template of Objectpermissions that each object will grant to Groups of type SpaceManager, in the Workspace Types that have this Role defined)
Permissions:
tiki_p_add_events
tiki_p_admin_file_galleries
tiki_p_admin_galleries
tiki_p_admin_wiki
tiki_p_autoapprove_submission
tiki_p_autosubmit_link
tiki_p_batch_upload_image_dir
tiki_p_blog_post
tiki_p_change_events
tiki_p_create_workspace_resour
tiki_p_edit_sheet
tiki_p_forum_attach
tiki_p_forum_autoapp
tiki_p_forum_edit_own_posts
tiki_p_forum_post
tiki_p_forum_post_topic
tiki_p_freetags_tag
tiki_p_post_comments
tiki_p_post_shoutbox
tiki_p_sendme_articles
tiki_p_submit_article
tiki_p_submit_link
tiki_p_suggest_faq
tiki_p_upload_images
tiki_p_view_sheet_history



Name: RolePerms-Member
Desc: Template of Objectpermissions that each object will grant to Groups of type Member, in the Workspace Types that have this Role defined)
Permissions:
tiki_p_add_events
tiki_p_attach_trackers
tiki_p_autoapprove_submission
tiki_p_autosubmit_link
tiki_p_batch_upload_files
tiki_p_batch_upload_images
tiki_p_blog_post
tiki_p_change_events
tiki_p_comment_tracker_items
tiki_p_create_tracker_items
tiki_p_edit
tiki_p_edit_gallery_file
tiki_p_edit_sheet
tiki_p_forum_attach
tiki_p_freetags_tag
tiki_p_list_trackers
tiki_p_list_users
tiki_p_modify_tracker_items
tiki_p_post_comments
tiki_p_post_shoutbox
tiki_p_rollback
tiki_p_sendme_articles
tiki_p_submit_article
tiki_p_submit_link
tiki_p_suggest_faq
tiki_p_upload_files
tiki_p_upload_images
tiki_p_view_sheet_history
tiki_p_watch_trackers
tiki_p_wiki_attach_files
tiki_p_wiki_view_history


Note
-Registered and Anonymous groups will have tiki_p_view_workspace, and it will be inherithed by anyone else.
-Of course, below the Member role you can define a Lurker role with even less permission, eg: only post comments tyo threads etc
-These examples are permissions for workspaces with objects like Wiki, Imagegals, Filegals, Calendar, Trackers. If you plan to create other types of objects, more perms need to be added
-Many of these permissions do not take count that permission inheritance exist also inside object perms, and are duplicated from the various role templates for good sake. Once the common method $tikilib->get_perm_object($objectId, $objectType, $info='', $global=true) is used in the code, many of the permissions can be avoided because will be inherited. As of now inheritance inside objectperms is granted only from Anonymous and Registered.


Workspace Types.


Now, after defining the Workspace Roles, we will define the Workspace Types. For each type we have to define which Roles (defined in the previous step) it will have, and what Resuorces it will have, what it's Desktop modules will be.
Anything here can be changed in the future, so don't worry too much to define the exact number of objects, or adding Groups to Groups. This is only a template, everything can be changed at any time on a per-object or per-workspace basis! But of course, if you're going to create a new workspace per minute, it is better to correct the Workspace Resources or the Workspace Roles so things come out right at creation time.
The most common problem is a ws member telling you he cannot post to the forum or modify a workspace page. If you are only a ws admin for this workspace, you can correct the objectperms of those objects, but if you are admin you should also backport this correction to the relative RolePerms template, so the next time an object of that type is created, it will come out with the right perms


Our workspace Structure will be as follows:

  • A Workspaces Area root workspace
  • Any number of Projects workspaces under it
  • Each Project workspace can have any number of Member Space workspaces under it.


So there are going to be 3 main workspace types:

  • The Workspace Area type root workspace (Code WSAREA)
    this will be the root workspace.
    We have to add to it the AreaAdmin Role,
    We may add to it the Member Role (see next paragraph)
    we may mark it hidden (see next paragraph)
    This Workspace is just an utility so that we can define an admin for it who will be capable of managing all Projects and Members workspaces under it, without the need of being part of the admin group
    We might want to add resources here.
    Because this is a root workspace, resources here can be made common, by the AreaAdmin, to all Projects workspaces under it. To do this, we will add the Anonymous, Registered and Member groups, so that later we can add all subprojects members groups to the Member groups of this workspace. They will be part of this workspace too, and be able to modify these common resources. In this case you may not want to mark it 'hidden'.
    This workspace Type will have no objects, We will add objects to it when we need.
    we will define a Desktop for this workspace (Desktop icon on right of Workspace Type definition), with a single Zone and the ''workspace_resources module in it. That has all the tools to manage and access the workspace


  • The Project type workspace, which we plan to use under the Workspace Area (Code PROJECT)
    This will have Area Admin and Member Roles, the Anonymous and Registered Groups
    This workspace will have,eg the following Resources:
    -a Wiki Page
    -a Calendar
    -a Tracker
    -a Forum
    -an Image Gallery
    -a File Gallery
    we will define a Desktop for it (Desktop icon on right of Workspace Type definition), with a single Zone and the ''workspace_resources module in it. That has all the tools to manage and access the workspace
    We can always add more objects when we need.
    The AreaAdmin will be able to add more objects, and assign permission to all the Workspace Objects of this workspace and any subworkspace.
    He will be able to create subworkspaces of type PROJECT, MEMBERSPACE etc, and manage the Groups/Users that will belong to these workspaces roles

  • The Member Space type workspace, which we may later create under each Project Workspace (Code MEMBERSPACE)
    This will have SpaceManager and Member Roles, the Anonymous and Registered Groups
    This workspace will have,eg the following Resources:
    -a Wiki Page
    -an Image Gallery
    -a Blog
    we will define a Desktop for it (Desktop icon on right of Workspace Type definition), with a single Zone and the ''workspace_resources module in it. That has all the tools to manage and access the workspace
    The SpaceManager will be able to add more objects, and assign permission to all the Workspace Objects he manages


Note
-The previous structure is just a model, one can add a Project type under a Project type, or an Area Type under a Project Type.
-The AreaAdmin role (objectperm tiki_p_admin_workspaces granted on the workspace) does not allow the definition of new workspace types nor roles. But those are just creation templates. He can modify a workspace that he admins as he wants, by changing objectperms and adding other roles. In any case there are only two perms that matter for the workspace environment: tiki_p_admin_workspace and tiki_p_create_workspace_resour and he has both.

Create the Workspace (Menu Admin Workspaces)


Now we will create the root Workspace Area, of type WSAREA. Lets call this workspace PROJECTSAREA
At his point , in this Workspace desktop, we will see the workspace>_resources module, where we can add Users/Groups to this workspace PROJECTAREA-AreaAdmin Group the groups or users we want to be in charge of administering this workspaces and all subworkspaces.
After this, we can logout, and login as one of the prevoius users/groups, and manage the creation of sub-workspaces without being admin.

Under the PROJECTSAREA workspace, we will create a first Project Workspace, of type PROJECT, lets call ir DOCPROJECT.
Same as before, we can add Users/Groups to its DOCPROJECT-AreaAdmin and DOCPROJECT-Members groups

Once a member of this DOCPROJECT wants to have his own space, we (as AreaAdmin) will create a MEMBERSPACE type of workspace under this DOCPROJECT workspace, and give it a name.
Being a space of type MEMBERSPACE it will have only SpaceManager and Member roles (+ Anonymous and Registered). We will our User/Group to the SpaceManager Roles of this workspace, and from this moment he will be able to add more users (but no groups) to this ws roles, create new resources, and assign perms to them. He will not be able to create sub-workspaces though.

  • Notes

The capability, for a SpaceManager (tiki_p_create_workspace_resour) to add users to his Workspace's groups has to be enabled, by setting the
_TIKI_P_CREATE_WORKSPACE_RESOUR_CAN_ADD_USERS_",true

constant in lib/workspaces/userlib.php

By default the tiki_p_create_workspace_resour objectpermission on a workspace grants only creation of new resources and assigning perms to them. If you enable adding users to the Ws groups, be aware that the workspace type should not have an AreaAdmin (tiki_p_admin_workspace) role, otherwise a SpaceManager can escalate to AreaAdmin.

The most demanding jobs are defining complete RolePerms-xxx templates and the Workspace Types. But, mostly, you have to define them only once, and then you can use them for other implementations of workspaces at your site: some of these same Workspace Roles (AreaAdmin, SpaceManager) and Types (WorkspaceArea, MemberSpace), exactly as they were defined here, allow you to create another different, parallel Workspace Area type of root workspace that you can name SOCIALNET that will hold any number of Member Space type workspaces under it. The Member_Space workspace type doesn't need many object resources at start, because its SpaceAdmin can add new ones as he needs, so the basic WikiPage, Imagegal and Blog will do also for a SOCIALNET Workspace Area, parallel to the PROJECTASAREA we defined before. That would be a new, 2 level top workspace: A Workspace_Area root under top with many Member_Space workspaces under it, using the roles and types already defined for the Projects Area.

Further evolutions

  • Once defined a Workspace, you can add its 'Member' type group (eg DOCPROJECT-Members) to the Groups one can choose at registration time (Admin->Groups), so people can join the Workspace when registering.
  • By the same process, if you add an AdminArea groups as choosable on register, one can create his workspace + subworkspaces, but for a Social Network a ws of type 'MemberSpace' is better.
  • A resource can belong only to one workspace. This is better for deletion, etc. But an AdminArea or a SpaceManager can add objectpermissions to it choosing from a wide selection of Workspace Groups (read the next paragraph), and make it readable/writable/administrable by whoever he wants. Other workspaces need to have a link for it somehow, because this shared object will not show up in their workspace, nevertheless it will grant the same permissions as if it was.
  • The default view on groups a role can assign objectperm to (he can choose to assign objectperm to these groups), is the following:
    • Admin (tiki_p_admin or tiki_p_admin_workspaces group perm): Any group, excluded non-includable (group inclusion looping)
    • AreaAdmin (tiki_p_admin_workspace objectperm in RolePerms template):he can choose among all groups belonging from topmost-ws-he-admins to bottom
    • SpaceManager (tiki_p_create_workspace_resour objectperm in RolePerms template): he can only choose among his ws groups (default), but in tiki-workspaces_objectpermissions.php there are other, commented examples to have that:
      • he can only choose among those from-this-ws-level-to-bottom (this+brothers-to-bottom: father excluded) This is the most suitable for a Socialnet.
      • he can only choose among those from-this-ws-level-to-bottom (this-to-bottom, this included)
      • he can only choose among those from-father-level-to-bottom ( father-to-bottom, father+brothers included).


Must reads


Contributors to this page: drsassafras , pingus2 and pingus .
Page last modified on Friday 20 September, 2019 15:46:06 GMT-0000 by drsassafras.

Keywords

The following is a list of keywords that should serve as hubs for navigation within the Tiki development and should correspond to documentation keywords.

Each feature in Tiki has a wiki page which regroups all the bugs, requests for enhancements, etc. It is somewhat a form of wiki-based project management. You can also express your interest in a feature by adding it to your profile. You can also try out the Dynamic filter.

Accessibility (WAI & 508)
Accounting
Administration
Ajax
Articles & Submissions
Backlinks
Banner
Batch
BigBlueButton audio/video/chat/screensharing
Blog
Bookmark
Browser Compatibility
Calendar
Category
Chat
Comment
Communication Center
Consistency
Contacts Address book
Contact us
Content template
Contribution
Cookie
Copyright
Credits
Custom Home (and Group Home Page)
Database MySQL - MyISAM
Database MySQL - InnoDB
Date and Time
Debugger Console
Diagram
Directory (of hyperlinks)
Documentation link from Tiki to doc.tiki.org (Help System)
Docs
DogFood
Draw -superseded by Diagram
Dynamic Content
Preferences
Dynamic Variable
External Authentication
FAQ
Featured links
Feeds (RSS)
File Gallery
Forum
Friendship Network (Community)
Gantt
Group
Groupmail
Help
History
Hotword
HTML Page
i18n (Multilingual, l10n, Babelfish)
Image Gallery
Import-Export
Install
Integrator
Interoperability
Inter-User Messages
InterTiki
jQuery
Kaltura video management
Karma
Live Support
Logs (system & action)
Lost edit protection
Mail-in
Map
Menu
Meta Tag
Missing features
Visual Mapping
Mobile
Mods
Modules
MultiTiki
MyTiki
Newsletter
Notepad
OS independence (Non-Linux, Windows/IIS, Mac, BSD)
Organic Groups (Self-managed Teams)
Packages
Payment
PDF
Performance Speed / Load / Compression / Cache
Permission
Poll
Profiles
Quiz
Rating
Realname
Report
Revision Approval
Scheduler
Score
Search engine optimization (SEO)
Search
Security
Semantic links
Share
Shopping Cart
Shoutbox
Site Identity
Slideshow
Smarty Template
Social Networking
Spam protection (Anti-bot CATPCHA)
Spellcheck
Spreadsheet
Staging and Approval
Stats
Survey
Syntax Highlighter (Codemirror)
Tablesorter
Tags
Task
Tell a Friend
Terms and Conditions
Theme
TikiTests
Timesheet
Token Access
Toolbar (Quicktags)
Tours
Trackers
TRIM
User Administration
User Files
User Menu
Watch
Webmail and Groupmail
WebServices
Wiki History, page rename, etc
Wiki plugins extends basic syntax
Wiki syntax text area, parser, etc
Wiki structure (book and table of content)
Workspace and perspectives
WYSIWTSN
WYSIWYCA
WYSIWYG
XMLRPC
XMPP




Useful Tools