Page tree
Skip to end of metadata
Go to start of metadata
Your Rating: Results: 1 Star2 Star3 Star4 Star5 Star 98 rates


GREYSummary of finding and ideas identified while looking at possible ways to implement MGNLDMS-137@jiraGREY


  • Create version of documents on public instance during activation
  • Provide means so serve different versions of same document via paragraphs


Versioning is inherently possible in any workspace and website or dms workspaces on public instance are not an exception. To enable versioning on public instance as part of the activation process it is necessary to open a hook for command chain (to allow arbitrary execution of any command). Commands in the chain have to be configurable and have to be differentiated per workspace (same as on the author during activation).

Additional work to be done if proceeding with the above:

  • Activation integration test suite is necessary to ensure current activation process is not adversely affected by the change.
  • Parallelization of activation (Activating multiple documents at once) has to be preserved.
  • While implementing the change in m-m-exchange-simple, XA activation needs to be re-tested as well to ensure no impact as well.


  • As a result of execution of versioning command, whole activation will be significantly slower (first guess is about 50% - from 2 secs per doc to 3 secs per doc)
  • Size of the public database will grow significantly faster then before.
  • Any future upgraded would have to be performed twice - once for author instance and once for public instance since each of them can have different versions. Upgrading only author and activating all content to fresh public instance would mean the versions on public would be lost during such upgrade.
  • With the above implemented, it is still possible to only activate current version of the document from author, and such document will be versioned on public instance no matter whether versioning on author is enabled or not.


  • It will not be possible to activate any arbitrary version of document into same version number of same document on public. Versioning schemas of each instance are independent.
  • When versioning content templates are not versioned as they are stored in file system only, hence displaying old version of content may be affected by template changes (e.g. fields existing previously, but removed in never version of template will not be visible when browsing previous versions of content). Same limitation already applies to all content versioned on author.

Open questions

  • how to write paragraphs that could deal with displaying arbitrary version of given document? Do we need to do anything extra to facilitate that?
  • do we need to do anything about security (like add extra permissions to versions)?
  • if this change is to be implemented in Magnolia itself rather then as extra module, it means quite big change and doesn't qualify as minor/bugfix release.
    • Do we really want this in core of Magnolia?


  1. I assume this makes most sense for intranet scenarios. Can't really see that being useful for a normal web site.

  2. Having the possibility to expose versions of Pages and Documents on Public instances can be important in knowledge management oriented projects as customer extranets (think of selling and supporting investment goods) or as said intranets.

    It should be easy for a the administrator to allow public versioning on specific branches and for the site designer to enable in the templates to offer the versions of an object if they exist.

    This feature was requested in the project at AMF where major documents come from Alfresco DMS with an official release versions, and updates should be still one document. The planned work around is that one DMS folder will the document with its node as versions. The visible version is stored as an attribute. For the authors a single node with it's versions would be more convenient.