- First commit to issue fork.
- last update
about 1 year ago 8 pass - @lind101 opened merge request.
- Status changed to Needs review
about 1 year ago 9:54am 5 September 2023 - 🇬🇧United Kingdom lind101
Ran into a similar issue when storing user login credentials. I used a `user_password` KeyType to store the key data and needed to override a `credentials => ['username' => '', 'password' => '']` config structure with the key.
Decided to go a slightly different route in MR15 than that suggested approach, and just allow whole sections of config to be overriden by a key if needed rather than picking out individual values.
- 🇬🇧United Kingdom lind101
MR15 will be a breaking change for anyone using a serialized mutivalue key in it's entirety as a config override (Not sure if this would actually work in reality, but it can currently be configure that way).
Unfortuantly there is no easy way to address this. I did explore adding a new field to the KeyConfigOverride and only unseriaziling if it was set, but by the time the override value is actually set in KeyConfigOverride::loadOverrides we have lost context of which KeyConfigOverride entity supplied to override, meaing we can't use any of it's properties to influence the setting of the value.
Incidently this also means that the suggested approach of mapping to a specific field on a multivalue key will also not work.
The only way that I can see around this is to change the KeyConfigOverride::getMapping method to store the KeyConfigOverride id rather than the Key ID and then retrieve the key id (and any associated config we need) in KeyConfigOverride::loadOverrides. But that would probably result in all existing KeyConfigOverride breaking, very much a bigger change.