[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: PNG File Screen Shot 2016-09-23 at 11.28.11.png     PNG File Screen Shot 2016-09-23 at 11.28.33.png     PNG File Screen Shot 2016-09-23 at 11.33.10.png     PNG File Screen Shot 2016-09-23 at 11.41.46.png     PNG File error.png    
Issue Links:
Relates
relates to MAGNOLIA-7005 It's possible to create same name sib... Closed
causality
relation
is related to MAGNOLIA-5433 As a developer it's clear that I cann... Closed
is related to MGNLUI-1292 Drag-and-drop in workbench tree allow... 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)
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.

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