[MGNLUI-3900] Show the root node in the "move" dialog Created: 31/May/16  Updated: 27/Mar/17  Resolved: 21/Mar/17

Status: Closed
Project: Magnolia UI
Component/s: dialogs
Affects Version/s: 5.4.6
Fix Version/s: None

Type: Improvement Priority: Neutral
Reporter: Andreas Weder Assignee: Hieu Nguyen Duc
Resolution: Won't Do Votes: 0
Labels: usability, ux, working-with-items
Remaining Estimate: 0d
Time Spent: 6d 5h
Original Estimate: 6d

Attachments: PNG File 1 Selected root folder.png     PNG File workaround-move-before-or-after.png    
Issue Links:
relation
is related to MGNLUI-4170 Move Before and Move After buttons ar... 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)
Date of First Response:
Epic Link: AX: "Move" dialog imprv
Sprint: Saigon 87, Saigon 88
Story Points: 2

 Description   

It is currently not clear how to move an item to the top-most folder in the hierarchy (the root folder). The "move" dialog doesn't show the root folder and requires to deselect any folder in order to "select" the root folder. The latter point is also confusing, as the dialog mentions that "no item is selected", but has the "move inside" button enabled.

To fix this, we're going to expose the root folder in any "move" dialog:

  • The root folder is marked with a root folder icon.
  • The root folder is always open and can't be closed.
  • As a result of this, the icon doesn't show an arrow.
  • The node name of the root folder is "root folder". It does not have a title (show "-").

The root folder acts like any other potential destination for the "move" operation: it can be selected and moved into.



 Comments   
Comment by Aleksandr Pchelintcev [ 05/Oct/16 ]

A fundamental problem that seems to make this effort so complicated is that the ticket suggests to *reveal the JCR workspace root* in a tree and in the status bar whereas all the rest of the content app components like BrowserPresenter, JCRContainer, StatusbarPresenter kind of conceal the presence of the ws root - there's a number of places where we explicitly work around the case of a root node selection (e.g. when status bar sees that there's one item selected, it assumes that it is a root and renders a no selection label).

I propose that we do not try to resolve this issue with all the tech debt that the associated PR brings in, but rather keep it in mind and consider when we next approach the content apps:

  • JCR root node handling should be done on a different level (data presentation, i.e. JCR container?)
  • we should look into breaking down the content app parts from being so inter-dependent: in order to override something in some class, a lot of upstream classes might need to be overriden as well, we should consider to adopt some less-coupled approach and easier ways to assemble the trees/grids and actionbars into content app customisations.
Comment by Mikaël Geljić [ 05/Oct/16 ]

Totally second that. For the sake of completeness, even with as many wrappers around config of the target app, there still is high discrepancy between the various content views; they all use different containers but do synchronize selection. So as a result of toggling view-types, selection and status bar react differently and add up to the confusion.

Solving that with the current ways would be overkill (as highlighted by the amount of effort put in there already).

Generated at Mon Feb 12 09:11:14 CET 2024 using Jira 9.4.2#940002-sha1:46d1a51de284217efdcb32434eab47a99af2938b.