[MAGNOLIA-5975] Versioning does not work if a workspace is not in the same repository as mgnlSystem and mgnlVersion Created: 23/Oct/14  Updated: 13/Jul/15  Resolved: 30/Jun/15

Status: Closed
Project: Magnolia
Component/s: None
Affects Version/s: 4.4, 4.5, 5.2, 5.3
Fix Version/s: 5.4

Type: Story Priority: Critical
Reporter: Magnolia International Assignee: Milan Divilek
Resolution: Fixed Votes: 0
Labels: support
Σ Remaining Estimate: Not Specified Remaining Estimate: Not Specified
Σ Time Spent: Not Specified Time Spent: Not Specified
Σ Original Estimate: Not Specified Original Estimate: Not Specified

Attachments: XML File repositories.xml    
Issue Links:
Relates
relates to MGNLDEMO-30 Create users and roles for demonstrat... Closed
dependency
is depended upon by MGNLACTIVATION-101 Activation does not work if a workspa... Closed
is depended upon by MGNLBACKUP-87 Backup action backups only one reposi... Closed
is depended upon by MGNLXAA-89 Transactional activation does not wor... Closed
is depended upon by MGNLUI-3461 Adjust check if workspace is version ... Closed
is depended upon by MGNLTOOLS-76 Purge versions functionality should o... Closed
relation
Sub-Tasks:
Key
Summary
Type
Status
Assignee
MAGNOLIA-6093 Create mgnlSystem and mgnlVersion wor... Sub-task Closed Jan Haderka  
MAGNOLIA-6094 Support versioning for multiple works... Sub-task Closed Milan Divilek  
MAGNOLIA-6242 Avoid losing wrappers when working wi... Sub-task Closed Milan Divilek  
Template:
Acceptance criteria:
Empty
Task DoD:
[ ]* Doc/release notes changes? Comment present?
[ ]* Downstream builds green?
[ ]* Solution information and context easily available?
[ ]* Tests
[ ]* FixVersion filled and not yet released
[ ]  Architecture Decision Record (ADR)
Date of First Response:

 Description   

Using a transactional activation, Magnolia creates a new version in the mgnl-version workspace on the author and a backup of the activated node on the public.

Those two workspaces are in the default magnolia repository. If the activation is triggered on an asset (in the dam) and the dam workspace is located inside another repository, then Magnolia won't be able to clone this node.

Steps to reproduce:
1. Configure one author and public instance, out of the box config is ok.
2. Add the transactional activation module:

   <dependency>
          <groupId>info.magnolia</groupId>
          <artifactId>magnolia-module-exchange-transactional</artifactId>
      </dependency>

3. Make sure activation works.
4. Now move the dam workspace to a different repo (see attachment)
5.a. Try the activation again using command versioned:activate => Author will failed cause mgnl-version and dam are not in the same repo
5.b. Try the activation again using command default:activate => Public will failed cause mgl-system and dam are not in the same repo

Note: This issue can be reproduced with any kind of ws

Why it does not work

To retrieve the root node of mgnl-system, CopyUtil.copyToSystem needs a hierarchyManager. This hm is given by the method MgnlContext.getSystemContext().getHierarchyManager(SYSTEM_REPO) (ReceiveFilter l.881) which points to the one in the default magnolia repo.



 Comments   
Comment by Roman Kovařík [ 31/Oct/14 ]

Cause of the issue:

  • A workspace in a different repository than magnolia can't access mgnlVersion or mgnlSystem from magnolia repository.
  • Duplication of these workspace doesn't help because Magnolia can instantiate only one workspace per name (adds only the first one, others are ignored).
  • Shared workspaces between different repositories are probably not possible.

Solutions

  • A] make all hardcoded calls for mgnlVersion or mgnlSystem configurable so we could use different workspaces per repository(This would include at least core, activation and XAA modules).
  • B] Change repository management API to support same name workspace in different repositories.
    Both solutions would need to break API which is no doable in a minor release.
Comment by Jaroslav Simak [ 23/Feb/15 ]

What has changed:

  • The mgnlSystem and mgnlVersion workspaces are created automatically for each defined repository in the repositores.xml file. This means that definitions for these two workspaces are no longer needed in the mentioned config file.
    • If someone leaves them there, warning will be printed to the log file and those definitions will not be taken into account.
  • Since it will be possible to have multiple mgnlSystem and mgnlVersion workspaces, we need to distinct which workspace belongs to which repository. This is done by the following pattern: <repositoryId>-<workspaceId> (for example to get a mgnlSystem session for magnolia repository, we will use MgnlContext.getJCRSession("magnolia-mgnlSystem").
    • The <repositoryId>-<workspaceId> is just a logical name used internally by Magnolia, physical names remains the same as before.
    • If any customer directly worked with either mgnlSystem or mgnlVersion workspace, they will need to update their code accordingly.
  • This change will probably break tests in some of our modules, as it is now required to pass RepositoryManager to DefaultContent, MgnlVersioningNodeWrapper and some other classes.

Feedback from Greg:

i haven't delved into this in a while, but i wonder why we need all those Wrapper implementation that do nothing except take a specific type of Decorator and pass it to their super's constructor ?

Those decorators are here to ensure, that we will get correct workspace name if we call MgnlContext.getJCRSession("magnolia-mgnlSystem").getWorkspace().getName() or node.getSession().getWorkspace().getName() etc. I had problems with physical name being returned instead of logical one by those calls without wrappers. I can dig into it again and see if it can be done in simpler way.

i'm afraid your changes to NoSameNameSiblingsCondition won't work in real life (e.g i'm not sure we'll be able to pass the RepoMan to the condition from an MVH)

I had no problems on fresh install, but i will definitively try to do an update to see if any problem will arise or not.

Comment by Federico Grilli [ 29/Jun/15 ]

While doing some tests on latest CE bundle I noticed that only superuser seems to be able to publish whereas users peter and eric can't no matter if they have write grants on the workspace they want to use (e.g. website, tours, categories). On the EE instance it looks like it works fine. While we're at it, it might worth adding a test similar to info.magnolia.integrationtests.uitest.PageEditorPublishingAndVersioningUITest.publishAndCheckAuthorAndPublic() but run it with user peter instead of superuser.

Comment by Christopher Zimmermann [ 29/Jun/15 ]

Contacts and Tours apps also have failures on Publish. But the rest of the apps work.

I looked at the definition of the Activation Action for these apps and they both specify:
catalog: versioned

Peter trying to publish a tour:
2015-06-30 09:15:27,328 ERROR info.magnolia.cms.core.version.BaseVersionManager : Node /magnolia-travels/Kyoto-PETER was never versioned

Peter trying to publish a contact:
2015-06-30 09:20:42,806 ERROR info.magnolia.cms.core.version.BaseVersionManager : Node /mmonroe was never versioned

Comment by Milan Divilek [ 30/Jun/15 ]

Resolved under MAGNOLIA-6094

Generated at Mon Feb 12 04:10:08 CET 2024 using Jira 9.4.2#940002-sha1:46d1a51de284217efdcb32434eab47a99af2938b.