Support nested relational values in conditional fields

[Michael-Nussbaumer]

Preflight Checklist

• I have completed all Troubleshooting Steps.
• I'm on the latest version of Directus.
• There's no other issue that already describes my problem.

Describe the Bug

My test case is, that I want to hide a field if there is a item selected in a m2m relation:

{
    "instruments": {
        "instruments_id": {
            "_eq": "1"
        }
    }
}

To Reproduce

1. Create Collection A & B
2. Add m2m Relation between both collections
3. Add some items to both collections
4. Add field name to Collection A
5. Add a condition to field name :

{
    "collection_b": {
        "collection_b_id": {
            "_eq": "1"
        }
    }
}

6. Select that name should be hidden if the condition matches

What version of Directus are you using?

v9.0.0-rc.93

What version of Node.js are you using?

v14.17.5

What database are you using?

MySQL 8

What browser are you using?

Chrome

What operating system are you using?

Windows

How are you deploying Directus?

Linux VPS

[joselcvarela]

At first look, it seems you are not using the right filter.
I think you want to use _nempty or _nnull.
The way you are doing, you are strictly checking if Instruments has a item with id = 1.

[Michael-Nussbaumer]

It is exactly what I want in this case. I need to show fields only for a certain item on an other collection.

[rijkvanzanten]

I think you're running into #7123

The problem currently is that the app form itself only contains the "top level" field values (what you'd get from the api with the default fields=*. This means that by default, that condition won't work as the values don't exist.

When the user edits the value, the value will now exist, which in turn allows the condition to work, but then there's an interesting divide between "select existing" and making edits to the nested item. When the user selects an existing relational item, the staged value from the app will be the primary key of the related (what you're currently using in your condition as well), though when the user edits that item, the staged value will turn into an object with the changes applied.

Long story short: right now conditional fields doesn't support nested relational fields reliably, though I agree you'd expect it to work the same as regular filtering setup.

[rijkvanzanten]

We can solve for the missing data on load by keeping track of a special "Conditional values" object on first load of the item, which uses the filter object to deconstruct what data is needed on load. That will solve for the missing data on first load problem.

The second problem is a little more difficult to solve for, as there's 2 different "shapes" we expect to exist in the lifecycle of the page. Either we require the user to configure two conditions (for example "ITEM = 5 OR ITEM.ID = 5"), or we figure out some way to do that a little smarter ("if condition is string/number, compare to item[primarykey]")

[ulvidamirli]

We can solve for the missing data on load by keeping track of a special "Conditional values" object on first load of the item, which uses the filter object to deconstruct what data is needed on load. That will solve for the missing data on first load problem.

The second problem is a little more difficult to solve for, as there's 2 different "shapes" we expect to exist in the lifecycle of the page. Either we require the user to configure two conditions (for example "ITEM = 5 OR ITEM.ID = 5"), or we figure out some way to do that a little smarter ("if condition is string/number, compare to item[primarykey]")

I tried this solution but it doesn't work on version 9.8.0. My problem is the same as the OP

[rijkvanzanten]

@ulvidamirli This is an open issue 👍🏻 If there's any updates to this setup, you'll hear about it here first 🙂

[claytongulick]

Running into this now, and it's a pretty big problem for me, I have a "configuration" table that has rules for which fields to show.

I understand that only top level fields are selected on form load, but wouldn't it make sense to hydrate the form with the related fields when the user selects the relation?

[rijkvanzanten]

but wouldn't it make sense to hydrate the form with the related fields when the user selects the relation?

No, cause it changes the data structure of the input data for the individual interfaces, and therefore hinders the data that's available for sub-fields in drawers and the like. It used to work like that in v8 actually, and caused massive issues around nested relational data editing 🙂 That being said, yes, it should fetch the nested relational data that is used in the conditions (but not in the whole form context) 👍🏻

[claytongulick]

Well, looks like I have a meeting set up with Kendyl and Rob tomorrow at 3 to discuss sponsoring this work 🙂

[rijkvanzanten]

Linear: ENG-291

[curtisburns]

Are there any updates on this, please? I've just been following this tutorial (https://www.youtube.com/watch?v=AqBYC39Nu2c&list=PLUBR53Dw-Ef9ZRA0QkaSKlcpotqbzQSv0&index=7) to get a feel for the CMS and its capabilities, and while you see the host encountered their own issues which can be attributed to an earlier version of Directus, my issue is that I'm not getting relational fields appearing in the dropdown at all, which the reasoning for has been mentioned here #15300.

So, when I edit the raw value to build my own, I've tried the following according to this #11920 (comment), so:

{
	"_and": [
		{
			"product_categories": {
				"_contains": 3
			}
		}
	]
}

and:

{
	"_and": [
		{
			"product_categories": {
                                "product_categories_id": {
                                       "id": {
                                           "_eq": 3
                                       }
                                }
			}
		}
	]
}

Neither seem to be working. I'm currently looking for a go-to CMS for my own projects and I've enjoyed my experience with Directus up to now.

Is it likely to be fixed in the near future? This was first raised in Sep 21, and we're Mar 23 now, I'm just curious how high up on the priority list this is i.e. did you ever manage to get sponsorship for this one. Cheers!

[rijkvanzanten]

@curtisburns _contains is "string contains value", so that won't work as expected for relational validation. This open issue is the intent to implement support for that. There's currently no further updates.

This was first raised in Sep 21, and we're Mar 23 now

This doesn't really mean anything! There's issues that have been open longer that most likely won't be resolved any time soon, and issues that are raised more recently that are resolved already. It's not a first-in-first-out system 👍🏻

As for timelines, the only thing I can leave you with is our default blurb around estimates in open source issues:

Unfortunately, we can not provide estimates on features or fixes. As of now, the only way to get an accurate timeline or release date is to sponsor this task. We recognize that this may be an important feature/fix, but we are a small open-source organization with a lot to triage and complete. If you can't sponsor this ticket, then the next best thing is to increase its priority by giving it a 👍

[curtisburns]

@rijkvanzanten I see, understood! Thanks for the heads up on _contains, still getting to grips with it all. Appreciate that fixes won't appear overnight, I'll bear that in mind though. Have gone with the suggested workaround of using checkboxes to show and hide certain fields for the time being. Thanks again.

[phazonoverload]

On February 22 we're inviting you to come and have a chat with us about this feature request at our Request Review in our Discord server. This will help us have some dedicated time to talk about what implementation would have the most sense. Please feel free to join us as https://directus.chat/ (the event is already listed and you can set a reminder)

[w0kyj]

Notes from Request Review Feb 22, 2024:

Three considerations:

• App data context and availability for condition validation
  • App doesn't get relational data currently until navigating to the data (in drawer, ...)
  • Nested depth of the data can be deep and consequently very large
• Permissions: is the data/field/etc available to the current user at all
  • eg user doesn't have permissions to a field that is source or target of the condition

Brain storming:

• App needs to get all the data in the conditional tree ... (permissions will be an issue here)
• whenever a change is made by user, how do we implement the condition validation/updates:
  • could send data to server for processing to then return updates
    • processing, latency, debouncing, etc - would need to be considered
  • websockets usage...?
    • websockets are great but we cannot rely on them as they're not a hard requirement to run Directus
    • plus if you want to do edge things like scaling to 0 then yeah you cannot maintain a persistent connection
  • caching options:
    • changes to current caching needed to prevent stale, performance, ...
• permissions approach that allows conditions per "policy/role"
  • complex solution and could create admin nightmare
  • server side calculations required for current global conditionals applied
  • conditionals tightly coupled to roles to require field access permissions for each role that touches the conditional
    • eg prevent admin from removing permissions needed for the user+app to implement
  • add a new "form" per role that uses custom conditionals
    • could we make groups configurable per role? Rather than making a whole form per role, keep it a bit more modular . Aka presentation option
    • can you make it so you can have the same field in different presentation sections configured per role?

Scope Back Down:

• Nested conditional rules:
  • require that permissions include all fields included in a conditional rule
  • app would then pull full data set including relational conditional data
    • need to consider the different relational data structures (m2o, o2m, m2m, m2a, ...)
    • allows the app to function as it does today with fast updates to the form...?

[michelegranatiero]

any updates?

[markarenz]

I currently work around this with a set of custom extensions. However, the solution is more brittle than I'd like, and I would prefer to resolve the issue the Directus way. Also, we have to create a new extension for every collection that requires this type of nested collection conditional display of fields, which is not ideal. If there were a way to add an alias for a given field within a translation collection that updated live when the parent value updated in the UI, for example, we could use the existing conditions feature to affect the changes we need in the UI.

[intensr]

any updates on this ?

[MarkBurvs]

Also would love this. 👀