Multiple User Communities - tsgrp/hpi GitHub Wiki

When a client would like to have multiple user communities using OCMS, there are a few ways to set this up. This page will overview these scenarios. Note that this page will use the term HPI to refer to the front end interface portion of OCMS.

Note that in the scenarios below that involve an Application ID, this functionality is only available in OCMS 3.0 and above. In 3.0 and above, the project folder can specify an appId in it's config-project.js file. See here for instructions on how to setup an HPI project folder with an alternate application ID.

Note that at least one HPI must have an application ID of default.

One HPI, One OpenContent

With this approach, utilize the configuration capabilities of HPI as well as repository security to separate users by group:

  • Dashboard - tie dashlets to one one or more user groups as appropriate
  • Repository Security - Configure repository security to ensure users in the proper groups can view/edit/delete the appropriate documents.
  • HPI Tracs - separate document types by trac as appropriate.
  • If necessary, utilize the HPI admin Trac Security config to show and hide tracs based on group membership

Pros

  • One environment to maintain
  • Users can work on documents across tracs if necessary
  • One centralized set of HPI configurations to maintain
  • One URL for end users to go to

Cons

  • May not be possible to separate user communities if repository groups are not clearly defined
  • Upgrading HPI affects all user communities (could be a pro in some cases)
  • Certain areas in HPI are not configurable by group. For example, it's not possible to show the Search or Dashboard header links based on group membership. Similarly, if you have Dashboard configured as the login landing page in Application Config, this applies to all users logging in to HPI, regardless of group membership.
  • System downtime cannot be segmented per user community

Multiple HPIs, each with their own OpenContent

Utilizing this approach, each HPI can be configured totally independently of the other. The OpenContent for each HPI can point to a separate repository or the same repository. If the OpenContent WARs are utilizing the same repository, you must separate out each HPI with a separate application ID with one being set to default.

Note that if you're running OC against Alfresco, in order to utilize this approach you'll have to install a separate Alfresco repository for each HPI implementation. This is due to OpenContent being an embedded subsystem within Alfresco.

Pros

  • User communities are completely separate (may be a pro for some)
  • HPIs can be configured independently
  • HPIs can be upgraded separately
  • System downtime can be segmented per user community on both the HPI and OpenContent side.

Cons

  • User communities are completely separate (may be a con for some)
  • Multiple environments to set up and maintain
  • Does not work well in the Alfresco world since each HPI needs a separate Alfresco install
  • Cannot share documents across HPI instances if each OC is tied to a separate repository

Multiple HPIs pointing to the same OpenContent

This approach is similar to above, except that each HPI instance is utilizing the same OpenContent.

Pros

  • This is the best option for Alfresco clients who want multiple HPIs but do not want to install a new Alfresco repository
  • HPIs can be configured independently
  • More than likely, if OpenContent is upgraded for one HPI instance, it still should work with an older version of HPI 2.x. There may be cases where an older HPI will not work against a newer OC, but testing would need to be done to be sure.

Cons

  • Active Wizard does not currently have the same concept as HPI with application ID. AW forms are shared across all of OpenContent. Currently, AW forms can only be filtered based on the type of an attached workflow document.
  • Users must proxy their inbox on the default HPI. This means that all users must have the ability to at least login to the default HPI and set user preferences. See this issue for more details and updates.
  • Depending on how HPIs are upgraded, we may end up maintaining an older version of HPI against a newer OC, which as time goes on will more likely run into breaking changes.
  • Downtime to maintain OpenContent affects all HPI instances.