[#MGNLDMS-137] Magnolia public instance does not contain versioned documents

Magnolia DMS Module

Magnolia public instance does not contain versioned documents

Created: 29/Sep/08 12:02 PM Updated: 17/Mar/09 07:39 PM

Component/s:

None

Affects Version/s:

None

Fix Version/s:

None

Time Tracking:

Not Specified

Visible to:	Giancarlo Berner, Naresh gangapur and sampath
Labels:
Date of First Response:	30/Sep/08 12:50 PM

Description

« Hide

versions documents in source DMS activated does not carry the versioned information to the destination instance ; we have functionality in the Author environment of the destintation instance which requires the documents to be versioned

All

Comments

Work Log

Change History

Sort Order:

[ Permlink | « Hide ]

Jan Haderka added a comment - 30/Sep/08 12:50 PM

Sunish,
all the content is always versioned only in author environment as this is where all the content editing happens. Public instance receives only copy of currently actual version of the content at the time of publishing, but it never carries any version information. You can think of public instance as a snapshot of the state of Author instance for given content at time of activation.

Could you try to describe in more details what kind of feature are you looking for and why would it make sense for you to version documents at public instance as well?

[ Permlink | « Hide ]

Sunish Abraham added a comment - 30/Sep/08 04:17 PM

Hi Jan,

We are using Magnolia Data and DMS modules to feed content to Java/Spring web application...accessing the content/data in Magnolia using JNDI module.

Here is the scenario...

1) EMEA administrator creates an abstract/ event in Staging Author. The documents associated are version 1.0
2) Website owners receives an email about the creation
3) The website owners logs on to staging author instance, previews the event/ abstracts. Assume NL website owner previewed the event and finds every thing okay and approves using medichannel event/ abstract paragraph. This will trigger the workflow. This workflow will publish the content node to all subscribers (staging public) without using INBOX.
4) So after the above step, the meta-data of the event/ abstracts gets uploaded into NL specific folder under staging public, and the document is also published to staging public to a shared magnolia folder.
5) But another website (FR) owner rejects the event for what ever reasons
6) EMEA admin modifies the same event and uploads a newer version of the same document. This will trigger emails to all website owners.
7) After receiving the email the FR admin, logos on to staging author, previews event/ abstracts and he approves it. This should activate version 1.1 of the document to public instance.
8) The web application which is configured to use magnolia-jndi will pick up respective versions of the document based on the value in site-key. If the JC2.0 medichannel site is NL then version 1.0 will be available for download if the JC2.0 medichannel site is FR then version 1.1 will be available for download.

Sunish

[ Permlink | « Hide ]

Sunish Abraham added a comment - 30/Sep/08 04:19 PM

When we use admin central of public instance, we are able to upload multiple versions of the document. So it is not the public instance that prohibits versioning, it is the subscriber that is not versioning the incoming content.

Just thinking on these lines....

The JCRs are meant for storing versioned documents. (This comment is irrespective of magnolia author or public)
The versioning can be enabled or disabled in magnolia public using admin central.

So if public instances are not meant for versioning, then why do we have the feature of enabling/ disabling versioning in public instance?

[ Permlink | « Hide ]

Olivier Marti added a comment - 03/Oct/08 09:29 AM

Hey Sunish

Well, there is no difference from an author to a public instance, expect the fact that it is configured as a public instance.
The "problem" with versioning is just that on an activation of a document (data, website) only the current version is the one which get's activated.
Think of like you activate a document which has ten versions...not the best approach for a performant activation process though.

For your scenario it may be a better approach to upload the different document versions seperately (as 1.0, 1.1, ...).

[ Permlink | « Hide ]

Sunish Abraham added a comment - 03/Oct/08 11:43 AM

we are not activating 10 versions of a document at once...we just need the activation process to take the document (version) being activated and not just replace the document in the target. Since the Public instance supports versioned documents, the activation should be able to just save the document being activated and not replace.

[ Permlink | « Hide ]

Jan Haderka added a comment - 03/Oct/08 11:58 AM

Hi Sunish,
as I explain earlier, Magnolia versions content only on the instance where editing happens (the Author instance). If you need document to be also versioned on the Public instance (instance from which content is served after activation), it is technically possible to do, but you have to replace ReceiveFilter (/server/filters/activation) on such public instance with your own that would version the document before receiving new copy of it from the Author instance.
Should you need some developer support to help you develop such filter, please let us know what concrete assistance you need on support.

[ Permlink | « Hide ]

Sunish Abraham added a comment - 03/Oct/08 12:08 PM

Hi Jan,

Yes I understand your previous statements on the current functionality (by design) of saving current version during activation of a DMS document. We need the functionality to be extended to save the version information of the document being activated and save new version not replace existing document. Yes we have found the class which is handling the saving during activation...does the class which is doing the activation send full information about the document (that is version information) so that the ReceiveFilter can process it?