[MGNLRES-230] Improve handling of masking JCR folders Created: 30/Sep/15  Updated: 29/Mar/22  Resolved: 15/Oct/15

Status: Closed
Project: Magnolia Resources Module
Component/s: None
Affects Version/s: None
Fix Version/s: 2.4.2

Type: Improvement Priority: Critical
Reporter: Andreas Weder Assignee: Aleksandr Pchelintcev
Resolution: Fixed Votes: 0
Labels: ux
Remaining Estimate: 0d
Time Spent: 2d
Original Estimate: Not Specified

Attachments: PNG File Select folder 3 (JCR masking other origins).marked.png    
Issue Links:
causality
caused by MGNLRES-196 Add actions to add and remove folders... Closed
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)
Epic Link: Phase out in-place templating app
Sprint: Basel 14
Story Points: 5
Team: Nucleus

 Description   

The concept for the Resource files differentiates between folders, which can be edited (those created only in JCR) and those, which can't. However, we've discovered there's a third type of folder we have to handle separately.

When I add a resource file under a non-editable folder (i.e. a folder from the filesystem or classpath), our current implementation also implicitly creates folders to map the existing folders also in the JCR origin. Such "masking JCR folders" can also be created explicitely - their characteristic is that they exist in JCR and that equally named folders with the same path exist in a read-only origin.

As a result, such masking JCR folders are currently marked as editable, which is probably wrong: a user shouldn't delete them and (in the future) not move or rename them (would result in very confusing behavior). However, having a "publish with sub items" actions on such folders could proof to be very handy.

Solutions I see are:

  1. We treat masking JCR separately: they're not editable, but have a set of actions different from non-editable folders and which includes publish actions. UPD: after discussion it was also pinpointed that such folders should not be marked as editable in the resources app table (pen indicator).
  2. We change the current implementation of how we store JCR resource files: we no longer implicitly create folders when adding a resource file, but store a "path" or similar alongside it.

I've set the severity of this issue to "critical" as we* should resolve this before the next release* of the Resource files app, as the current behavior will cause confusion and lead to questions.



 Comments   
Comment by Andreas Weder [ 01/Oct/15 ]

Comment from mgeljic on Hipchat:

Solution 1 would be valid.
Solution 2: I wouldn't say "no longer implicitly create folders", because I don't see much way around that, given the workspace structure and implementations we have (JCR resource loading, app actions). But we could generally expose less the 'folder' nature of those nodes, in favor of 'paths' or maybe even 'packages' natures. Admittedly, if we go this way, it's still going to be very challenging to specify in the details. If you think the "blurriness" of it makes it a de-facto no-go, then we could simply pick solution 1. It's probably not as simple as we could wish, but still sounds solid enough to me.

Comment by Andreas Weder [ 01/Oct/15 ]

I've designed mockups for solution 1: https://wiki.magnolia-cms.com/display/UX/The+Resource+files+app#TheResourcefilesapp-Availableactionswhenselectingafolder

Comment by Andreas Weder [ 01/Oct/15 ]

I've changed the term of these folders to "masking JCR folders", because - as Jan pointed out correctly - it's possible that such folders would also be created explicitely.

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