[MGNLDMS-137] Magnolia public instance does not contain versioned documents Created: 29/Sep/08  Updated: 04/Nov/15  Resolved: 04/Nov/15

Status: Closed
Project: Document Management System (closed)
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Improvement Priority: Critical
Reporter: Sunish Abraham Assignee: Philipp Bärfuss
Resolution: Won't Do Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Template:
Acceptance criteria:
Empty
Date of First Response:
Visible to:
Giancarlo Berner, Naresh gangapur, sampath

 Description   

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



 Comments   
Comment by Jan Haderka [ 30/Sep/08 ]

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?

Comment by Sunish Abraham [ 30/Sep/08 ]

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

Comment by Sunish Abraham [ 30/Sep/08 ]

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?

Comment by Olivier Marti [ 03/Oct/08 ]

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, ...).

Comment by Sunish Abraham [ 03/Oct/08 ]

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.

Comment by Jan Haderka [ 03/Oct/08 ]

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.

Comment by Sunish Abraham [ 03/Oct/08 ]

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?

Comment by Michael Mühlebach [ 04/Nov/15 ]

Given the thousands of other issues we have open that are more highly requested, we won't be able to address this issue in the foreseeable future. Instead we will focus on issues with a higher impact, and more votes.
Thanks for taking the time to raise this issue. As you are no doubt aware this issue has been on our backlog for some time now with very little movement.
I'm going to close this to set expectations so the issue doesn't stay open for years with few updates. If the issue is still relevant please feel free to reopen it or create a new issue.

Generated at Mon Feb 12 00:48:47 CET 2024 using Jira 9.4.2#940002-sha1:46d1a51de284217efdcb32434eab47a99af2938b.