Collaborative Space Plugin 5.6
The Collaborative Space plugin provides support to open, manage and work in Collaborative Spaces.
A Collaborative Space is a portal of services dedicated to a set of members.
This plugin's version requires JCMS 8.0 SP3.
In addition to functional services (calendar, wiki, document explorer, ...) special services are reserved to the administrators:
- members management: to add members, send invitations and validate subscriptions
- service management: to add and remove services
- usage analytics: to view usage and analytics of the collaborative space
- settings: to customize the behavior and the look of the collaborative space
A collaborative space has a dashboard which is composed of a set of services. It may also have a sidebar which is always present.
Services are portlet with ability Application or Dashboard.
A Dashboard service is placed in the dashboard or in the sidebar. An Application service has a dedicated tab and is displayed in full when it is selected (in the dashboard place).
A Collaborative Space :
- has an access policy (either public, private or secret)
- has a sign-up policy
- can have sub Collaborative Spaces
- can be categorized using a Typology
Collaborative Space plugin introduces Guest account, an account with restricted rights.
- Follow the Plugin Manager installation process
- Restart the site
- At first start, the plugin will initialize some Datas, like a default model
- Go to the admin area and click on the link Open a new Collaborative Space to create your first collaborative space
A Collaborative Space is created from a model. A model defines a set of services and default settings.
Once installed, the plugin provides one default model. Additionnal models can be easily added.
A model is a Collaborative Space which workspace is declared as model.
The models are also the repository for common services. An administrator chooses services to add from the models services and from local services.
Access and Sign-up policies
3 access policies are available:
Reading contents of a private or secret space is only available for members of this space.
Private spaces are visible by all members, whereas secret space aren't. A member who does not belong to a secret space, won't ever know this space exists.
Sign-up policy depends on access policy.
|Sign-up managed by an admin||x||x||x|
My Collaborative Spaces Portlet
The My Collaborative Spaces portlet does list all the Collaborative Spaces the member belongs to and all other public and private Collaborative Spaces. It also provides a form to open a new Collaborative Space, or request for a new Collaborative Space creation.
My Collaborative Spaces Portlet - My Spaces
The My Collaborative Spaces portlet also provides a sub spaces template. This template will display the sub Collaborative Spaces of the current Collaborative Space. It will only work when displayed in Front Office of a Collaborative Space.
My Collaborative Spaces Portlet - Sub Spaces
Collaborative Spaces can be categorized through a typology. This typology is defined with a dedicated branch of categories. If the typology is defined, the My Collaborative Spaces portlet provides a typology filter. The Collaborative Space (portal) of models must also be categorized with the typology categories. There should be at least one model attached to the root of typologies. To enable the typology, you must create a dedicated category and declare it in the property Root of collaborative space typology.
A new Collaborative Space can be created either from the My Collaborative Spaces portlet or from the Admin area with the link Open a new Collaborative Space. If the member has the rights to open Collaborative Spaces, it is immediatly available.
Otherwise the request must be validated in a workflow. Once the request has been validated, the space is open, the administrator(s) and the attendees can be notified by e-mail.
Note: The Collaborative Space - Creation ACL is provided to allow non-admin members to open Collaborative Spaces.
What are Guest Accounts ?
A Guest account is an account that belongs to Guests Group.
This account only have access to Collaborative Spaces he has been invited to.
Guest accounts are only relevant for private site. If site is public, the restrictions are disabled, and the account can navigate as a normal account. (Since versions 4.4 & 5.2)
This feature allows you to invite external persons of your organization, only in one or more Collaborative Space. This member can be a simple reader, or a worker with more rights.
The following restrictions apply on such a Member :
- he cannot belong to non CollaborativeSpace Workspace
- he cannot create Contact
- it must only be used in case of private site
- Confidentiality :
- he only can see Publications of his workspace(s)
- he only can see Members that share one or more of his space(s)
- he cannot see Contact members
- see also § Custom Policy Filter
How to enable this feature ?
- activate it through the plugin properties
- create a dedicated Group (eg. named "Guest accounts")
- fill the Guest Accounts Group property with the previous Group identifier
Required right to init a Guest
To init a Guest, one needs the 3 following rights:
- be leader of a CollaborativeSpace
- have Edit Member ACL
- have Guest management ACL
Those rights can be set on one Member, are split between a submitter, and a validator.
Thus, initializing a Guest can be done in one or two steps with validation.
You can allow collaborative space leaders to ask for Guest initialization, which requests will be validated by a another Member.
Required rights for a Guest creation:
|Creation||Space leader||Guest management||Member management|
Required rights for a Guest transformation:
|Transformation||Space leader||Guest management||Member management|
Same rights are required as for creation.
Roles and workflow
Guest initialization requires to set-up Forms.
Two Form types allow to init a Guest:
- Guest creation form (a new Member is created)
- Guest from an existing contact transformation (existing contact is updated to an account)
A validation workflow can be associated to those Form types.
The request storage workspace can be set-up in the plugin properties. By default, the default workspace will be used.
How to create Guest Accounts ?
There are several ways to create a Guest.
- put an existing member into the dedicated Guest Accounts Group
- (*) use the Form Guest Account - Creation request to create a new guest account from the CS members management area
- (*) use the Form Guest Account - Contact conversion Request to convert an existing Member with Contact usage, to a Guest. (You can access this form either on the contact Profile display, or in the contact's member CTX Menu)
(*) you will need to have the expected rights to perform those actions : see Who can create Guest Accounts ?
- Then, put the member in some Collaborative Space's Group to give him access to some space
Note: a Guest with no CS group won't be able to log in.
Workflow processing and storage workspace
You may declare a custom storage workspace for those Form requests. (See plugin properties)
If not set, the site's default workspace will be used.
In this storage space, you can manage the Guest Requests' workflow processing.
- set Enabled for Guest to be available immediatly
- set Disabled to disallow request submission
- set Guest Account - Opening Request Workflow to use manual validation (*)
(*) Allow separation of guest creation process in two steps validation :
- a Collaborative Space(s)' leader chooses the Guest's Collaborative Spaces' groups, and submits a request
- once the request is validated, the Guest is created / converted
Custom Policy Filter
Guest Account RightPolicyFilter : all Publication types are controlled by a custom RPF when the member is a Guest. A publication can only be seen if the Guest belongs to the publication's workspace.
You may want to customize how the RPF behave :
If you want a custom Publication Type not to be controlled by the RPF, you may declare a new plugin property with the following syntax :
Example : the NewsletterPlugin sets the NewsletterContent type not to be controlled, using property :
It means that a Guest will have the right to see a NewsletterContent, even if he does not belong to the NewsletterContent's workspace.
ACL & Rights delegation
The Collaborative Space plugin allows to delegate the functional CS administration to some members, using ACL.
Edit Members and Workspace's Members ACLs allow to manage the members in your Collaborative Space. You may also give them Edit Groups ACL, or Edit Workspace's Groups ACL to add them the right to manage CS's groups.
Collaborative Space - Services ACL allow members to manage the CS's services.
To access Collaborative Space analytics, you need to have Usage analytics ACL (global, or Workspace ACL).
Collaborative Space - Settings ACL allow members to manage the CS's settings.
How to setup your CS model ?
If you need to delegate those administration areas, it might be helpful to update your CS model. To do so, follow :
- as an admin, create a new Workspace ACL, named "CS - manage services", with right"Collaborative Space - Services"
- create a Group named "Manage CS Services" or "$NAME$ - Manage CS Services", link it in your CS model, and give it the created ACL. ($NAME$ will be replaced by the new workspace name)
- when you create a new CS from your model, an additional Group "Your CS Name - Manage CS Services" should have been created
- repeat those steps if you need to delegate others rights
Version 4.1 provides a new access policy : secret. (See CSP-120)
It is mandatory to migrate the old access policy (publicAccess) to the new one (accessPolicy).
Migration rules are :
publicAccess : true -> accessPolicy : public publicAccess : false -> accessPolicy : secret
A Perl script, convertCSPublicAccessToAccessPolicy.pl, is available. How to use :
$ ./convertCSPublicAccessToAccessPolicy.pl store.xml > newStore.xml