-
Improvement
-
Resolution: Fixed
-
Neutral
-
None
-
6.2.1
-
None
Tested:
On current 6.2.2-SNAPSHOT
Situation:
- Content app using contentType (here events app using event contentType)
- two types existing: 'event' node and 'mgnl:folder' node (as all apps usually have, folders additional to an custom type)
- The node name should be editable for both types: event & mgnl:folder
The code of the field:
subApps:
browser:
workbench:
contentViews:
tree:
columns:
name:
name: jcrName
editable: true
editor:
availability:
nodeTypes:
- event
- mgnl:folder
field:
$type: textField
Problem of the node-renaming/behavior:
The behavior between editing a custom node (events) and a folder (mgnl:folder) is extremely inconsistent:
- Editing custom node name (event):
- 'esc' key must be used to save the change.
- when hitting 'enter' the detail-subapp of the event opens (data lost of the editing).
BUT even worse: It opens the one wich is green highlighted, and not the one actually editing (when moving with tab the editing one is != the green one)
- Editing mgnl:folder node name:
- 'esc' key must be used to save the change does not react in opposite to an custom node (event)
- It saves the value only on 'enter', BUT only if its also green highlighter. If an event is still green, but the folder is being edited (moved via tab to folder) then the event's detail sub app opens.
- Moving around with 'tab':
-
- Behaves completely different, if the initial node editing (green highlighted) is a custom node, or a folder. If folder, you can move with enter form one to the oder as also a tab. If starting with an event, enter opens the event's sub app and only tab moves.
- I found more little inconsistence which makes i hard to use, can't describe all in detail, must demonstrate it.
Acceptance criteria
- is related to
-
MGNLUI-6041 Column Editor's availability: Non available node-type node should not react on editing.
- Open