[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: |
|
||||||||
| Issue Links: |
|
||||||||
| 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 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:
|
| 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). |