Inplace editing consolidation A: Bug-fixing (MGNLUI-259)

[MGNLUI-270] Going to next edit field using TAB doesn't work if renaming changes item order Created: 29/Nov/12  Updated: 08/May/13  Resolved: 03/May/13

Status: Closed
Project: Magnolia UI
Component/s: forms, user interaction
Affects Version/s: 5.0
Fix Version/s: 5.0

Type: Sub-task Priority: Neutral
Reporter: Mikaël Geljić Assignee: Mikaël Geljić
Resolution: Fixed Votes: 0
Labels: dialog, frontend
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Template:
Date of First Response:
Sprint: Iteration 2013-17, Beta 2

 Comments   
Comment by Christopher Zimmermann [ 03/May/13 ]

Implemented behaviour is not as expected and could be very confusing to the user, maybe resulting in them changing data on the wrong property.

Problem:
If, by hitting tab, I rename a property such that its position moves - then I DO NOW STAY in inplace editing - but all of a sudden I am editing a different row - the one that it has taken the position of the old.

ie if i have two properteis - "appId" and "class", If i rename appId to ZappId - then after hitting tab I will be in inplace-editing in the value field of the class row.

Recommend fixing problem or reverting to previous behaviour.

Comment by Mikaël Geljić [ 03/May/13 ]

Reverted to previous behavior without index-based lookup for new itemId.
+ minor improvements

until UUID-based container helps there (at least for JCR nodes)

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