[MGNLUI-4824] Control of dependencies between CTs (within one module) Created: 15/Nov/18  Updated: 30/Nov/18  Resolved: 26/Nov/18

Status: Closed
Project: Magnolia UI
Component/s: None
Affects Version/s: None
Fix Version/s: 5.7.2, 6.0

Type: Bug Priority: Critical
Reporter: Christoph Meier Assignee: Mikaël Geljić
Resolution: Fixed Votes: 1
Labels: None
Remaining Estimate: 0.25d
Time Spent: 0.75d
Original Estimate: Not Specified

Attachments: PNG File tourOffices-linkedItems-corect-version.png     PNG File tourOffices-linkedItems-issue.png    
Issue Links:
Relates
relates to MGNLCT-61 Reference fields to CT-retrofitted ap... 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:
Epic Link: Content Types finalization
Sprint: Saigon 158, Saigon 159
Story Points: 3

 Description   

The loading order of content type definitions (CTs) within one module seems unpredictable.
This leads to problems, when one CT has relations to other CTs (=> a property of a CT points to another CT), If the loading order is unfavorable.

Probably it would be more precise to say:
The Loading order of CTs and CT based apps of the same module is unpredictable, this leads to not properly "initialized" (registered) apps, if there are relations between its CTs.
However - on this ticket we should focus on CTs only.

While developing the CTs (and its apps), adding definitions step by step, one by one, there is no problem.
But on start-up of an instance with a module with multiple CTs with relations, most probably not all CTs are properly "initialized".

Work arounds

  1. On the running system, touch the CT def. files in the "proper" order. ... or ...
  2. Create distinct modules, one module with only one CT and its related (CT based) app; define load order with dependencies in module.yaml.

Example
3 CTs in one app: tourVehicle, tourGuide, tourOffices
Tour-offices may have links to both tour-vehicles and tour-guides.
The Tour-office app, when showing an item, cannot properly "resolve" / show the linked items.
(To reproduce, e.g. use https://git.magnolia-cms.com/users/cmeier/repos/content-type-examples).
See attached screenshot for not properly displayed linked items. 

Discussion
1st workaround is not an option on prod. system.
2nd workaround is doable but quite a restriction.
I would prefer a solution where "the system is clever enough to load in correct order" ... if the system can figure out this ... or if the system could be instructed via config somehow ... or to quote Mika:

content-types could/should build a mini, CT-specific, dependency-graph



 Comments   
Comment by Mikaël Geljić [ 24/Nov/18 ]

Turns out this had little to do with dependencies between content-types:
—although it could indeed be worked around with a light module descriptor to enforce definition loading order.

In the case above, app descriptors are loaded alphabetically. Link fields' appName values are generated against the AppDescriptorRegistry entries.
If generated app bison referenced app albatros, all fine; but albatros couldn't create a link-field reference to bison since that app was not registered yet.

In fact, link fields' appName is a mere lazy reference, and is only activated when the select button is pressed. As such, value doesn't have to be an accurate app name at registration time. There is no "definition validator" for that property either.
Deferring the app-matching logic to "select-time" solves the issue. PR incoming.

As a bonus, MGNLCT-61 may in fact be the exact same issue.

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