While experimenting with using a DynamicLookupListField for our app I have it setup something like this.
<DynamicLookupListField propName="resource"
parentPropName="category" >
<subLists>
<subList subListName="staff" parentListValue="Personnel" />
<subList subListName="cars" parentListValue="Vehicle" />
</subLists>
I have a test that persists an the type that is the parent, and it sets the “category” to be “Vehicle” but then sets the “resource” to be one of the cars. I wrote the test with an assertThrows but I don’t get any error. Is it expected for this to only be checked by the UI?
We are using mongo, but I thought it might be that LEAF would check this since it has the metadata.
We are utilizing LEAF 3.1 currently, is this the same behavior in later revisions as well?
Good morning! I was able to recreate your issue and find the problem. We’re gonna take a stab at fixing that this morning. Since it’s just missing validation, I’m guessing it’s not a blocker, but if it is, could you let me know the urgency, specifically how soon you’d need a patch available.
In the meantime you could disable that test probably, and re-enable once you get on the patch with the fix.
Good morning! Thanks for taking a look at this.
This isn’t a blocker. I’ve already got the new test disabled on my branch.
Let me know if you need anything else. Thanks for looking at this so quickly!
Hey @mark.a.alvaro I was taking a look at the test that has a comment leading to this discussion. We’re using LEAF 3.12 and it appears to still fail our test. Do you know if there a newer version of LEAF that fixes this issue? Or should I put in a ticket to track this?
Hey there, we must have lost track of this somehow, so I’d maybe put in a ticket and reference this post.
Also just to check: if I read the question correctly, I think you set category=Vehicle and then chose an item in cars and expected an exception. I don’t think that should fail, but I’m guessing that’s not what you meant.
Whoops redacting this as I didn’t realize the original post was from 2022 when I was looking to see if I had made a ticket to fix it. See Beth’s reply below.
Ah, sorry. I mistyped this originally. Our test locally sets the category=Vehicle but then sets the resource to something like Pharmacist for example.
The important part just being that there is a mismatch of an item being picked from a sub-list that does not match the parent property picked.
I’ll put in a case to track this. Not that big of a deal, I just figured it might be useful if LEAF could sanity check the data.
Hi Kai,
I’m having trouble recreating this issue. It looks like we did fix it on version 3.6 and forward. Did you switch from using Mongo to SQL? If so, to fix DynamicLookupListFieldMetadata for SQL was a breaking change, so you have to opt into the fix using LeafCompatibilityPlugins.enableDynamicLookupListSqlFix(). Let me know if that fixes the issue, if not I’ll reach out for more info so I can work on recreating it.
@Kai.L.Boschma Here was the response I mentioned in the message back to you! 
We are using SQL in production, but this fails in a test that is backed by a DataServiceTransient.
Looking at this again, I think I made a mistake. Here is the chain of how our metadata looks.
category (LookupListField)
subCategory (DynamicLookupListField)
resource (DynamicLookupListField)
My test had something like this being saved:
{
category: "Vehicle",
subCategory: "Car",
resource: "Pharmacist"
}
But importantly the resource field has the customValueAllowed=“true” in the metadata. I think I must have mixed up which field I needed to mismatch. When I remove that attribute so it uses the default, my test passes.
Sorry about the mix-up. I can close the ticket if you’d like me to.
2 Likes