- First commit to issue fork.
- Merge request !10990Issue #3161345: Options allowed values cache pollution → (Open) created by vidorado
- 🇪🇸Spain vidorado Logroño (La Rioja)
Created a MR, applied the patch from #5 and added a kernel test.
- First commit to issue fork.
- 🇬🇧United Kingdom oily Greater London
Updated the test, added comments to clarify each step.
- 🇬🇧United Kingdom oily Greater London
All pipeline tests are green. Except test-only test which fails as it should.
- 🇺🇸United States smustgrave
Added some additional comments after doing some code standard reviews. I didn't resolve any of the open threads but if we can do that next please.
- 🇪🇸Spain vidorado Logroño (La Rioja)
@smustgrave I've replied to your comments.
Thanks for the review!
- 🇬🇧United Kingdom catch
@berdir's points in #7 and #9 still haven't been adequately answered. Should the cache key instead use the entity ID?
- heddn Nicaragua
From re-reviewing the docs on
options_allowed_values
, I think we need to cache it on both, yes. Leaving at NW for this. - 🇪🇸Spain vidorado Logroño (La Rioja)
About Berdir's comments above
I believe they have been taken into account. We now understand that we can only add a callback function to a bundle definition to restrict the options or customize the labels, but the
allowed_values
setting must not be overridden.Regarding this, I think the only unanswered comment is
#11
, which asks what would happen if we did override it.I tested this scenario, and it turns out that it is possible. I created a custom test entity with an options_field that has a default allowed_values setting of
['Foo', 'Bar'
], two bundles, and an overriddenallowed_values
setting of['Baz']
for the second bundle. I was able to create entities for both bundles, and the values in theoptions_values
field dropdown were displayed as configured, with no errors thrown.I'm not sure what action, if any, we should take regarding this.
About adding the entity ID to the cache ID
This is a separate question, and I assume you're suggesting adding the entity ID to the cache key because the
allowed_values
callback function receives the entity as a parameter, meaning it could depend on any part of the entity, not just the bundle.In that case, I agree that we should add the entity ID to the cache key. It's unfortunate, as this will result in a large number of cache entries—one per entity—but I don't see another way of handling it since the callback function does not return any cacheability metadata.
Please confirm that we're all on the same page, regarding to this, and I'll proceed with adding the entity ID to the cache key.
Thanks!