[MAGNOLIA-6893] Move action doesn't check for possible 'same name' siblings Created: 23/Sep/16 Updated: 07/Apr/17 Resolved: 20/Dec/16 |
|
| Status: | Closed |
| Project: | Magnolia |
| Component/s: | None |
| Affects Version/s: | 5.4.9, 5.5 |
| Fix Version/s: | 5.4.11, 5.5.1 |
| Type: | Bug | Priority: | Neutral |
| Reporter: | Bradley Andersen | Assignee: | Maxime Michel |
| Resolution: | Fixed | Votes: | 1 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| 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)
|
||||||||||||||||||||||||
| Bug DoR: |
[ ]*
Steps to reproduce, expected, and actual results filled
[ ]*
Affected version filled
|
||||||||||||||||||||||||
| Date of First Response: | |||||||||||||||||||||||||
| Sprint: | Basel 75 | ||||||||||||||||||||||||
| Story Points: | 8 | ||||||||||||||||||||||||
| Description |
|
It is possible to create 'same-name' siblings, at least in the Pages app, and at least in Magnolia 5.4.8. Please see attached images, and connected SUPPORT-6660. While technically the siblings do not have the same name in the system ('page', 'page[2]' will be created, for example), the user is provided no visual cues to that effect (sees 'page', 'page'), and is permitted to create an Nth page with the 'same name' as an existing page. |
| Comments |
| Comment by Maxime Michel [ 29/Nov/16 ] |
|
I can easily disable the Move buttons in such cases, however, from an UX point of view, I have doubts whether the cause would be easy enough to understand for the user. Shouldn't we perhaps leave the permission as is, but then rename the new node as it's actually being named under the hood (`sportstation[2]`)? weder? |
| Comment by Bradley Andersen [ 29/Nov/16 ] |
|
mmichel FWIW, IMO, that works, and feels to me consistent with similar, existing UX behavior. |
| Comment by Andreas Weder [ 30/Nov/16 ] |
|
mmichel I would not disable the Move buttons, no. First, it's unclear why you can't continue with the move - there's no clear way to signal the cause. Second, we've typically been somewhat forgiving in the past in similar cases and have permitted an operation to continue, but made sure that it doesn't lead to conflicts. For me, a good solution would be to rename the moved node using a similar algorithm we already use when adding or duplicating nodes (e.g. "sportstation2", if "sportstation" and "sportstation1" exists already). Please make sure that the moved node remains selected and in-view, even though it gets renamed. It's important that we have this visual confirmation that the move operation has concluded successfully. It also helps you to understand that the moved node is the one that got renamed. |
| Comment by Maxime Michel [ 01/Dec/16 ] |
|
After discussing it in architecture, we ended up deciding that while duplication naturally leads to the creation of new names such as 'sportstation0', this isn't such a case. This is about moving, which is a different operation. One use case that somebody mentioned during the meeting was that: if you move a node someplace else, and then move it back, you don't expect that it would be renamed, which it could with the current suggested approach. Therefore the solution we want to go for is to actually still prevent the move when it would result in a same-name siblings situation. The Move button will still be actionable, but the following error is going to show up (which it already does in one case): Also, the same problem was spotted with properties. In that sense, it becomes a main ticket, and I increase its Story Points to 8. |