- Issue created by @dieterholvoet
- Merge request !42Issue #3345507: Add support for Config Override Inspector → (Open) created by dieterholvoet
- Status changed to Needs review
about 2 years ago 2:45pm 2 March 2023 - 🇧🇪Belgium dieterholvoet Brussels
I added all #config keys. I also moved the generation of the webhook hash to an install hook so that it's automatically generated during module install. Otherwise, if hiding the webhook hash field with COI, it would be regenerated every time the settings form loads.
- 🇦🇺Australia dpi Perth, Australia
Grouping these together for coi and the prime core issue.
- First commit to issue fork.
- last update
10 months ago 17 pass, 2 fail - Status changed to Needs work
10 months ago 10:10pm 21 June 2024 - 🇺🇸United States xenophyle
Looks like WebhookHashTest needs updating since the hash now gets set upon installation.
- Status changed to Needs review
4 months ago 12:54pm 11 December 2024 - 🇧🇪Belgium dieterholvoet Brussels
I fixed the test. The failing tests are also failing on the dev branch.
- 🇺🇸United States xenophyle
I'm just realizing there is some relationship between COI and core config validation. We plan to eventually support the core config validation and I'm wondering if applying this MR will create any kind of conflict. If we have both "#config" and '#config_target" attributes will that cause any weirdness or is it simply that if your suggestion in 📌 Drupal >=10.2: Use the new #config_target Form API property Active is followed we will need to update the code to remove the "#config"s?
