Interface Changes

NAME

Bricolage Multi-Site Feature Functional Specification

VITALS

Version: $Revision: 1.8 $
Date: $Date: 2003/12/12 20:31:02 $
Status: Accepted
Target Version: 1.8

INTRODUCTION

This document describes the functional requirements for adding multi-site functionality to Bricolage. These should be regarded as abstract functionality goals, independent of any particular implementation. For the implementation details, please consult MultiSite::TechnicalSpec.

THE CURRENT DESIGN

Although Bricolage has been designed from the ground up to have the flexibility to manage multiple sites from a single Bricolage installation, support for managing multiple sites was never explicitly designed into the application. Thus, actually managing multiple sites requires using a number of workarounds. For example, due to the requirement that stories have unique URIs, no two sites can have the same URI for their own stories. Furthermore, nothing distinguishes what site a story belongs to; the Source attribute can help, but if any one site uses multiple sources for its content, the advantage of this approach is greatly reduced. And finally (and perhaps most importantly), users who can log into Bricolage can access all stories in the system, regardless of what site they belong to. This issue can be mitigated by setting up workflow, element, and category permissions, but this approach requires a good deal of work and careful planning.

In one multi-site installation, for example, categories have been set up for each site, like so:

  /site_one
  /site_two
  /site_three

A story belonging to a particular site must be placed in a sub-category of the appropriate site category. But once a story is published, the ``site_one'' part of the URI is meaningless, and ``/site_one'' isn't actually used as part of a URL on the site anywhere. So special care needs to be taken to strip out that part of the URI for all links to assets in the site, or to set up proper mod_rewrite rules to strip them out of requests to each site's production servers.

A further weakness of this approach is that it creates a double meaning for categories: 1) to specify a site; and 2) to categorize content. The result is that we must be careful to always use the appropriate meaning for a category in the appropriate context.

So although managing multiple sites is doable with the current design, it's not intuitive, and requires rather hackish workarounds to do it effectively. The most obvious solution to this problem is to set up multiple installations of Bricolage, one for each site. But there are obvious disadvantages to this approach, too, including:

This document thus proposes to address all of these issues by adding true multi-site functionality to Bricolage.

PROPOSED CHANGES

To add multi-site functionality to Bricolage, we propose that a new first-class business object, ``Site'', be added. The purpose of adding a true first-class site object is two-fold: first, to allow other objects to be associated with a given site; and second, to provide a site context in which users can log in and access the system.

A number of objects in the system will be explicitly associated with one or more sites. These include:

Categories: Because each category will be associated with a single site, different sites can have the same or different categories without worrying about URI conflicts. System-wide, this means that there can be multiple categories with the same category path, provided that each is in a different site.
Output Channels: Output channels are strongly related to format and appearance. Different sites will have different looks and feels, even if they publish the same content. Thus output channels will also each be associated with a single site. Of course this also means that there can be multiple output channels with the same name provided that each is in a different site. Output Channel inclusion will continue to work, however, and Output Channels may include output channels in different sites.
Destinations: Since destinations are associated with output channels, and since different sites will generally have different distribution destinations, it follows that they, too, will each be individually associated with a site, even if it's only indirectly through output channel associations (a detail left as an implementation problem).
Templates: Since templates are strongly associated with output channels, it follows that they too, will each be associated with a given site.
Elements: Elements may vary across sites, but in order to allow the sharing of content across sites, elements must be sharable between sites. This means that top-level (story type and media type) elements shall be associated with one or more sites. Sites that share top-level elements will be able to publish each other's content based on those top-level elements; sites that don't share elements will not be able to share stories and media. Subelements will be associated with no sites, and all elements will have to be uniquely named across sites in order to keep template development relatively simple.
Workflows: We assume that workflows will vary from site to site, so it makes sense that they'll be associated with particular sites. This will simplify setting up Bricolage to manage multiple sites in one installation without having to mess around with permissions so much. However, workflows will be able to manage assets from other sites, provided that the user has EDIT permission to such assets.
Users: Users may be associated with one or more sites, with a permission value assigned to each association. Thus, a user can have READ access to the assets of one site, and EDIT access to the assets of another. When a user logs in, she will select a ``site context'' and will have access to the workflows of the site with which she has permission. But she will also have access to the assets in other sites to which she has at least READ permission and which are not currently in another workflow. Existing permissions will also continue to apply, so access can continue to be limited within a particular site context.; Users can change site context by selecting a different site from a select list in My Workspace. That select list will also feature a special option for ``No Context'', in which case the workflows for all sites to which the user has permission will be displayed.
Business Assets: Stories and media assets (hereafter just referred to as ``stories'') will each be associated with a single site. The site can be selected from the list of sites associated with the top-level element on which the story is based and to which the current user has EDIT access. The site cannot be changed once the story is created, as the category and output channel associations depend on it.; One of the principal goals of this project is to allow users in one site to publish the content of another site without being able to alter the other site's content. To allow this functionality, users creating a new story will have the option of either creating a new story from scratch as in the current model, or to create an ``alias story,'' wherein the user selects a story from another site to which she has at least READ permission and the new story becomes an alias for the other. Output channel and category associations will then be editable for the context of the alias story, while the aliased story will retain its settings and not be editable from the alias story's profile.; A story may be aliased only once in each site, and may not alias stories in its own site. Nor will alias stories themselves be aliasable.

Interface Changes

Naturally, these changes will require a fair number of changes to the interface. This section documents the changes that will need to be made.

Site Profile: The addition of a major new object of course requires the addition of a new administrative interface. The Site Manager and Site Profile will work like all other managers and profiles. In addition to managing the standard properties of site objects (name, description domain name, etc.), site administrators will also be able to associate users and permissions with sites. The users available will be only those to which the administrator has EDIT permission.
Category Profile: The category profile administrative interface will simply have a new widget for associating a site with the category. The list of sites available in that select list will consist of only those sites to which the administrator editing the profile has EDIT access to its assets (not to the site itself). The default value will be the current site context. Categories will of course only be able to select parent categories from within the same site.
Output Channel Profile: As with the category profile, the output channel profile will have a new select list of the sites to which the user has EDIT access to its assets (not to the site itself), so that the output channel can be associated with a single site. Again, the default value will be the current site context. Output channels can include output channels from other sites. This will make it easy to share templates across sites.
Template Profile: The ``New Template'' screen in the template profile will be updated such that the template developer must select a site, and then, once the site has been selected, she can select the element, category and output channel. The site selection applies to all templates, including utility templates.
Element Profile: The element profile will be changed for top-level elements in that it will gain an interface for site association similar to the interface for output channel association.
Destination Profile: The destination profile will get a new first screen in which the user must select a site from the Site select list (containing all sites for which the user has READ access to the sites themselves). Then the main destination screen will contain the usual output channel association screen, but of course only for those output channels that are in the site that was selected on the first screen.
Workflow Profile: The workflow profile will have a select list of sites to which the user has READ access, and of course one is required. The default will be the current site context. Note that desks can still be shared between workflows in different sites. This makes it easier to share assets across sites as part of the workflow process.
User Profile: The User profile's permissions screen will have a new section added to it listing sites. The sites in the list will be only those to which the administrator has EDIT permission. For each site, the user can be granted a permission, READ, EDIT, or DENY. This will grant the permission to the user for the assets in that site.
Story & Media Profiles: The story and media profiles will undergo the greatest changes. (Assume that when I refer to ``stories'' in the remainder of this section I mean both stories and media.) New stories will default to the context of the workflow in which they're created. The ``Information'' section of the story profile will have a new section identifying the story's site. Everything else about the profile of a normal story will remain the same.; However, the ``New Story'' screen will be changed to allow users to make the new story an ``alias story'' instead of a normal story. An alias story will not be based on an element or anything else, but will instead be an alias for a story in another site. The user creating the new alias story will then be prompted to search for a story to alias, and the story she selects will become the ``aliased story''. Bricolage will then create the alias story and put it on the user's workspace. Next it will search the aliased story for related stories and media. If it finds any, it will list all to which the user has at least READ access, along with checkboxes for each (checked by default) indicating whether new alias assets should be created for each of those, too. All that are selected will also be created and put on the user's workspace.; In the main story profile, an alias story will be displayed very much as a READ-only story profile is currently displayed. The difference is that the ``Output Channels'' and ``Categories'' sections of the alias story's profile will be editable so that they can be tweaked for its site context. This is because the same output channels and categories will not exist in both the alias story's site and the aliased story's site, so they will have to be set for the alias story's site. All other metadata and content data on the story will not be editable; the original story must be edited, instead.; The publishing of an aliased story will cause all of its aliases to be published, as well. However, whenever an alias story is published, only it will be published; the aliased story will not be republished and none of its other aliases will be, either.
My Workspace: When a user logs in, she'll be logged in to a particular ``site context''. This means that the workflows she'll see will be those associated with that site, and that when she's presented with a list of sites to choose from for associating an object, the current site context will be the default selection. My Workspace will feature a new select list of all the sites to which the user has READ, EDIT, or CREATE access. By selecting a site from this list, the user can change her site context, thus gaining access to the workflows in that context. A special ``NONE'' option, allowed by the setting of a new bricolage.conf configuration directive, will allow the user to see all of the workflows to which she has READ, EDIT, or CREATE access. The last site selected will stick across logins for the user.; My Workspace will still display all of the assets the current user has checked out, regardless of what sites the assets are in.
Workflows: Assets can be checked out of a desk the user has access to, or can be searched for in the library and checked into a workflow, as usual. Although workflows are associated with sites and assets are associated with sites, assets from any site to which the user has EDIT or CREATE access can be checked into any workflow the user has access to. The idea here is that the workflows are designed to manage the workflow for a particular site, but that site may be publishing stories from other sites.
Find Assets: The ``Find Templates'', ``Find Stories'', and ``Find Media'' interfaces will allow users to search for and find assets in all of the sites to which they have READ, EDIT, or CREATE access. The ``Advanced Search'' interface will be augmented to limit a search to a particular site. Each of the assets listed in the search results will have a new field listing the sites with which they're associated. Furthermore, stories and media assets that can be aliased by the user will have a new checkbox enabling the user to create new aliases from selected stories. Such alias stories will be created and put in the user's workspace or, if only one alias is being created, the user will be put right into the new alias story's profile.

AUTHOR

David Wheeler <david@kineticode.com>