I have created a Schema called “grades”. It has a reference to another schema called “models”. I am enforcing a 1:M relationship on this reference by restricting the number of linked items as configured below.
The problem is, when this is displayed in the content section of the front end, the Model reference data is displayed as “1 Reference(s)” instead of some sort of clear indicator as to what single record was selected. See below.
As you can see, this is going to be very confusing as the grades have the same names, but refer to a different model. It would be good if I could select a single field to be displayed from the referenced data (the name of the model in my instance), and that if the field was setup as a 1:M relationship, this field got displayed in the content section of the related content. So instead of “1 Reference(s)”, it displayed the name of my model when looking at grades.
I am evaluating Squidex right now, but this is the only real issue I have found so far. But, this could be a deal breaker as the plan is to have our client be able to configure data through the front end, and this level of confusion wouldn’t be acceptable. Is this something I could get on your roadmap, and if so, when would it likely be updated?
Hi, sounds very useful, but it is actually complicated because I have dynamically fetch the referenced items.
I will definetly put it on the list, but don’t know when I can work on it. Hopefully still in March.
As a workaround you could make an field that shows a display item, just for management and set it to Hidden. This means it will not be delivered in the public API.
If you could address this in March, that would be perfect.
The hidden field requires a lot more work. We were planning to import the data from a spreadsheet using the API, which means we wouldn’t be able to update this hidden field until after the data was imported from the API.
Hi Sebastian, just wondering if this is still on your roadmap to improve the UI for having reference fields as list columns?
The hidden field option doesn’t sit well with me, especially as it is redundant and has the potential to get out of sync (particularly as our client will be adding in records as well).
The main problem is how the cloud is priced…it is per request. If you would request 20 items with 20 difference references, you would be billed for 20 api calls. This does not make sense. Furthermore you would need the referenced schema for the for the content overview which is also not the best idea. So the best approach would be to give the normal some enrichment functionalities, similar to graphql.
For the asset it would be much easier. I can probably implement that very soon.
I see. We decided to implement the additional field option for the moment anyway as a work around. It has the potential to get out of sync, but should do the job.
