* Describe the bug
I created a Transportation (Перевозки - rus.) collection and a Cargo Locations (Места груза - rus.) collection, which has a many-to-one relationship with Transportation (one Transportation has many Cargo Locations). On the version 2 (Modern) page, I displayed the Transportation list and the built-in Cargo Locations subdetail (displayed in each Transportation row).
I also displayed the Edit button in each row of the Transport list. The Cargo Locations sub-form is also displayed in the edit form.
BUG: If you make changes in the sub-form and save (submit) them, the changes will be displayed incorrectly in the list - in the Cargo Locations subdetails. An incorrectly linked record is displayed there (the screenshot shows that the ID in the editing form and in the list details are different).
At the same time, everything is displayed correctly on version 1 (Classic) page, and changes are saved “on the fly.”
There is a problem with relationships when displaying a list of related records in subdetail mode.
* Environment
- NocoBase version: v2.0.0-alpha.54
- Database type and version: PostgreSQL
- OS: Linux
- Deployment Methods: Docker
- Docker image version: nocobase/nocobase:2.0.0-alpha.54
* How To Reproduce
I have shown screenshots above in the description.
Hello, I couldn’t reproduce your problem. Please reproduce it in the demo and provide the link to reproduce it.
https://a_8hwne7u84ho.v13.demo.nocobase.com/admin/
Hello, @hongboji! I have recreated the issue in your database. I have described the steps in more detail in a video (link to Google Drive) https://drive.google.com/file/d/1MNsroMPAhb4mgjXSraoH8A56D-nVLsdp/view?usp=sharing
It turns out that in Pages 2.0, the data in the sub-details is not updated when submitting a record with a subform.
As for the incorrect ID in the subform record (which was shown in the screenshot above), I haven’t noticed any problems yet, and I don’t know what caused it, maybe some kind of glitch. I deleted the incorrectly linked record, and that part of the problem disappeared.
Hello, the data has been updated, but the page data not refreshing is a known defect. Thank you for your feedback.
1 Like
@hongboji, but I still have a problem with sub-detail rendering (as far as I understand). Below, I made a video so you can see what my problem is. Is this only My side Problem? I don’t know what is goin on…
I output the result to the browser console (attached file)
NB-Sub-detail-fields-rendering-issue.zip (2.0 KB)
and asked the AI assistant about it. His response is below:
The problem, according to the logs, is not in the data itself but in the Flow / Display model schema: the engine reports a circular reference for DisplaySubListFieldModel and related Display*FieldModels, plus many “Invalid input parameters” errors.
What exactly is breaking
- The console contains many errors like “FlowEngine: resolveUse circular reference detected on ‘DisplaySubListFieldModel’” and similar messages for
DisplayTextFieldModel / DisplayNumberFieldModel / DisplayEnumFieldModel.paste.txt
- There are repeated “Invalid input parameters” messages during
beforeRender for multiple Flow nodes.paste.txt
- Because of this, the “Cargo Places” sublist renders but cannot correctly fetch and display field values.
What to check in the schema
It looks like in the Flow for the Shipment screen:
- The
DisplaySubListFieldModel (the “Cargo Places” sublist) uses use/inputs that directly or indirectly reference itself, creating a cycle.paste.txt
- The
Display*FieldModels inside the sublist (ID, Name, Description) are also tied to some use/inputs that create circular dependencies or provide values of an incorrect type.paste.txt
Because of this, when the engine tries to resolve use, it loops and fails on normal rendering.
How to quickly verify and localize
Suggested minimal checklist:
- Open the Flow designer for this Shipment tab and locate the
DisplaySubListField block (“Cargo Places”).
- In its settings, temporarily:
- Remove all custom
use / inputs, leaving only a direct binding to the relation (many‑to‑many / one‑to‑many) without formulas.
- If there are
fork nodes (with targetIsFork=true in the logs), disable or remove them for testing.paste.txt
- For the sublist columns (ID, Name, Description):
- Open each
DisplayText/DisplayNumber/DisplayEnum field and check that its use does not reference another Display*Field or the sublist itself.
- Temporarily set
valueSource = currentRecord.fieldName only, without additional use hooks.
Then reload the page and see whether the circular reference errors disappear and the sublist values appear.
How to make the schema stable
- In the sublist, use only “raw” fields from the related collection (for example,
cargo_places.name) without use chains that read from the same sublist.
- If you need a calculated value (a combination of fields), either:
- Create a computed field at the collection/model level, or
- Use a separate
Display*Field outside the sublist that does not read itself or sibling Display* components through use.
- Avoid patterns where:
A.use → B, B.use → C, C.use → A (typical circular chain), or
DisplaySubListFieldModel.use reads data that ultimately depends on the sublist’s own output.paste.txt
If you want a targeted fix
If you send the Flow schema export (JSON) or screenshots of the DisplaySubListField settings and one sublist column, it is possible to point out exactly which use/inputs need to be changed so that “Cargo Places” starts displaying correctly.
It’s only in Page v2.0 (Modern), in Classic Page - is all right.
May be You give most correct response?