[MGNLUI-6007] Dynamic generated contentType based apps: Usage of 'jcrName' and 'name' property unclear Created: 01/Jul/20  Updated: 09/Nov/20  Resolved: 15/Oct/20

Status: Closed
Project: Magnolia UI
Component/s: app, app framework, content app, content types
Affects Version/s: 6.2.1
Fix Version/s: 6.2.4

Type: Bug Priority: Major
Reporter: Christian Ringele Assignee: Roman Kovařík
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: 7h 19m
Original Estimate: Not Specified

Attachments: PNG File Case 1&2 - Detail Form.png     PNG File Case 3 - Detail Form.png     PNG File Events App - Dynamic generated view column using name.png     PNG File Events App - node name.png     PNG File JCR App - node name-1.png     PNG File JCR App - node name.png     PNG File validation showing node-name.png    
Issue Links:
Relates
relates to MGNLCT-143 jcrName field added in m6 content-typ... Closed
relates to CONTTAGS-90 'Tag name' is incorrectly applied to ... Closed
relates to MGNLUI-6259 ContentType based App & Column Editor... Open
relates to MGNLUI-6029 Dynamic generated contentType based a... Open
causality
dependency
is depended upon by MGNLDEMO-346 Migrate Tour Categories app to new UI... Closed
relation
is related to MGNLUI-6031 JCR Browser App: Do not use 'jcrName'... Closed
is related to MGNLUI-6073 Name property in content types does n... Closed
supersession
supersedes MGNLCT-143 jcrName field added in m6 content-typ... 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
Documentation update required:
Yes
Date of First Response:
Epic Link: nodeName
Sprint: UI FW 11, UI FW 12, UI FW 13
Story Points: 8

 Description   

Tested:

On current 6.2.2-SNAPSHOT

Situation:

contentType 'event' contains a model.
App 'events' uses contentType 'event' with: !content-type:event

Scope of questions:

  • Detail-Form of App always gets a field 'jcrName' labelled 'Tag Name'
    Its behavior, why etc, I find strange and I'm not sure about:
  • how its behavior really should be (is it bug or not?).
  • how to achieve old & simple use cases as its behaviour changed (using property 'name')

Strange things I observed:
-> JCR app shows always 'jcrName' prop value as Node name, and not the physical node name itself.
-> Export of the nodes of course have the node name with dashes
-> Content App (here 'events') shows the 'physical node name' or 'name' property as node name, but ignores completely 'jcrName' (in opposite to JCR app). 

Former use case:

One defines via 'name' property in the contentType's model the possibility to:

  • Define the jcr-node name (automatically with dashes) and also a "display name" of the node without dashes
  • Apps use the value of 'name' property to show its "display name"
    For example: an Event name could become "Event One" and its jcr node name was aligned to "Event-One"

Only one field in the details form is the goal!

Problem now:

  • One will always get the field "Tag Name" which is in the end the property 'jcrName'
  • One can not not have this field 'jcrName', but using 'name' instead.
  • But some apps use once 'jcrName' (JCR APP) others 'name' (content App) to display the nodes name.
  • Dynamic ContentType based apps create the initial view in the workbench wrong using 'name' instead of 'jcrName':

No proper way to define an "Event Name".
Just a name of a custom content type based data set where the node name should be kept aligned to the items name.
Formerly done over the 'name' property.

Situation:

Case 1 & 2 behave absolutely the the same (always yellow in print screens):

Case 1:

#Case 1 - no 'name' or 'jcrName'
datasource:
 workspace: events
 namespaces:
 mt: https://www.magnolia-travel.com/jcr/1.0/mt
 autoCreate: true
model:
 nodeType: event
 properties:
 - name: location
   required: true

 Case 1: 

#Case 2 - only 'jcrName'
datasource:
 workspace: events
 namespaces:
 mt: https://www.magnolia-travel.com/jcr/1.0/mt
 autoCreate: true
model:
 nodeType: event
 properties:
 - name: jcrName
   required: true
 - name: location
   required: true

Case 3:

#Case 3 - all possible names. Especially former working 'name'
datasource:
 workspace: events
 namespaces:
 mt: https://www.magnolia-travel.com/jcr/1.0/mt
 autoCreate: true
model:
 nodeType: event
 properties:
 - name: jcrName
   required: true
 - name: name
   required: true
 - name: eventName
   required: true
 - name: location
   required: true

 

Case 1 & 2 in the dynamic generated Detail's Form:

Case 3 in the dynamic generated Detail's Form:

Case 1 & 2 (yellow) and Case 3 (Orange) in JCR App:

Case 1 & 2 (yellow) and Case 3 (Orange) in Content App:

 

Related problem

  • -Bad auto labelling of the field created out of 'jcrName' -> "Tag Name"-
    -Should be "%ContentType-Name% Name" -> on event it would be "Event Name"--  ticketized as CONTTAGS-90

What is the mean/wanted behavior

To handle name for nodes including special characters (display, rename, duplicate operations):

  • 'name' property/field is used for content type autogenerated apps
  • 'jcrName' property/field is used by default for any other (manually created) JCR based app

JCR browser shows only real node names, doesn't synchronise any property during previously mentioned operations (reminder: JCR browser is an app for developers, manipulation of content via this app should be avoided in production environment).



 Comments   
Comment by Christian Ringele [ 01/Jul/20 ]

The problem is out if my view not the auto created 'jcrName' field, but that the auto created dynamic app uses the field 'name' to display the nodes name.

What should be either:
a) auto ‘jcrName’ in Form, AND dynamic app uses in view for node name the ‘jcrName’
b) auto ‘name’ in Form, AND dynamic app uses in view for node name the ‘name’
But not vise versa is it is:
Wrong: auto ‘jcrName’ in Form, BUT dynamic app uses in view for node name the ‘name’

Have a look into MGNLUI-6007:

 

Update, this is wrong:
"Because the BIG problem  is:

One can not get rid or overload the auto created view column using 'name'

So  you always have it there for nothing in the end. It just hurts."

I was now able to overload it with this code:

subApps:
  browser:
    workbench:
      contentViews:
        tree:
          columns:
            name:
              name: jcrName

I fell into the trap of this bug: CFGUI-119

Comment by Christian Ringele [ 14/Jul/20 ]

Using now a contentType based app with a model, I'm pretty sure it should display and use 'name', as all others also do OTB.

Having to use '' is also very cumbersome in all templating.
All notes, not created by an ContentType based app have a 'name' (getName()), but when having a 'jcrName' this code fails.

Comment by Christian Ringele [ 30/Sep/20 ]

Out of my view this is resolved since 6.2.3.

Instead of this code (6.2.2):

            name:
              name: jcrName ## Needed until MGNLUI-6007 is resolved.
              nodeTypeToIcon:
                  event: icon-datepicker

I can now use this proper code (6.2.3):

            jcrName:
              nodeTypeToIcon:
                event: icon-datepicker
Comment by Roman Kovařík [ 15/Oct/20 ]

For documentation:

new JcrDatasourceDefinition#nodeNameProperty configuration:

  • name of a JCR property which stores node name including special characters
  • this property is synchronised with JCR node name on rename and duplicate operations
  • this property is displayed by jcrTitleColumn
  • default value is jcrName
  • when changing this property, make sure forms (dialogs or detail subapps) have a field with this name (e.g. "name" field)
Comment by Ashraf Khamis [ 15/Oct/20 ]

Added the new nodeNameProperty to https://documentation.magnolia-cms.com/display/DOCS62/JCR+data+source. Reviewed by Roman.

No entry required for the 6.2.4 release notes.

Comment by Šimon Demočko [ 20/Oct/20 ]

(MGNLUI-6337)

Copying from slack: Trying to rename item in JCR to another item with the same name does not validate, but throws an exception instead. Also, the rename is editing jcrName instead of node name, but that's intentional, I guess

Gif in this thread: https://magnolia-cms.slack.com/archives/CKSC4TJQK/p1603194523192000?thread_ts=1603194482.191800&cid=CKSC4TJQK

Comment by Šimon Demočko [ 20/Oct/20 ]

(MGNLUI-6333)
Rename in JCR browser shows jcrName in dialog, but applies change to node.  Repeated renamings always show the jcrName, never the node name which is being edited.

If you rename the jcrName property to sth else like "jcrNamea" then the rename node dialog shows the node name, not the jcrName anymore. The same problem occurs when inline editing

Gifs in thread: https://magnolia-cms.slack.com/archives/CKSC4TJQK/p1603207729201100

Comment by Šimon Demočko [ 20/Oct/20 ]

(MGNLUI-6336)

Rename item action in a content-type generated app shows node-name in the dialog instead of the actual name of the content. (escaped with dashes etc.) 

Gif: https://magnolia-cms.slack.com/archives/CKSC4TJQK/p1603209386201800?thread_ts=1603207729.201100&cid=CKSC4TJQK

Comment by Šimon Demočko [ 20/Oct/20 ]

(PAGES-363)

When you create a page, if the name has spaces, it will store it with dashes instead of spaces. This was there before. But now when you rename, you can rename it so it has spaces.

When you create a page, there is no name nor jcrName property to it. When you rename a page using rename item action in Pages app, jcrName property is created under that page

Gif: https://magnolia-cms.slack.com/archives/CKSC4TJQK/p1603210957202600?thread_ts=1603207729.201100&cid=CKSC4TJQK

Comment by Šimon Demočko [ 20/Oct/20 ]

For the sake of completeness, I'll add my note here about dialog validation showing node-name instead of name when failing validation during renaming of a Persona to a name that already exists.  

Comment by Roman Kovařík [ 21/Oct/20 ]

Closing this as split into follow up issues under MGNLUI-6334.

Generated at Mon Feb 12 09:32:13 CET 2024 using Jira 9.4.2#940002-sha1:46d1a51de284217efdcb32434eab47a99af2938b.