[MGNLUI-7421] Inconsistent raising of warnings in app definitions Created: 12/Aug/22  Updated: 12/Aug/22

Status: Open
Project: Magnolia UI
Component/s: framework
Affects Version/s: 6.2.22
Fix Version/s: None

Type: Bug Priority: Neutral
Reporter: Chris Jennings Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

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

 Description   

Form properties incorrectly defined without a $type or class property are not treated consistently.

Case One

When giving a property name with no type or class or any other property, I receive a warning of a major error. eg.

appDefinition.yaml
subApps: 
  detail: 
    form: 
      properties: 
        anotherThing: 

Major error

Failed to process collection entry due to [java.lang.NullPointerException]
Title: Source data processing problem
Path: Reserves/subApps/detail/form/{name=name, i18n=true, label=Name, required=true, $type=textField, type=java.lang.String, validators={0={$type=nodeNameValidator, name=0}}}/3

The subapp, however, still opens and the misconfigured property is completely ignored in the resulting UI.

Case Two

When giving a property name with no type or class but setting a common property, I get a minor error. eg.

appDefinition.yaml
subApps: 
  detail: 
    form: 
      properties: 
        anotherThing: 
          required: true

Minor error

Property [required] not found in class [info.magnolia.ui.editor.ConfiguredEditorPropertyDefinition], property is not assigned

However, the subapp now fails to open correctly and instead of ignoring the misconfigured property, produces an exception. (See attached stacktrace).

Case Three: Composites

If I repeat the misconfiguration with a composite field, the same thing happens.
A field with no properties at all is just ignored.
A field with a property but no $type or class throws an exception on opening the subapp

Case Four: Content Type Composites

If I mix configuration and declare a subtype in a content type which I then extend in a content app without providing a $type or class but setting a common property, I get no warning message from the Definitions app but an exception is still thrown on opening the subapp.

contentType.yaml
datasource: 
    workspace: reserves
    autoCreate: true

model: 
    # Optionally supply a specific nodetype, otherwise 'mgnl:content' will be used.
    properties: 
      name: 
        label: Name
        type: String
      description: 
        label: Desc.
        type: String
      subThings: 
        label: Things
        type: sub-item

    subModels: 
      sub-item: 
        properties: 
          title: 
            label: Title
          description: 
            label: Description
appDefinition.yaml
!content-type:reserve
name: Reserves
subApps: 
  detail: 
    form: 
      properties: 
        subThings: 
          properties: 
            anotherThing: 
              label: Another thing

Expected results

If the the lack of a $type or class was consistently handled and communicated, debugging errors would be simpler.


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