Config overrides remain hidden on the /admin/config/ai/providers/amazeeio form
>>> [!note] Migrated issue <!-- Drupal.org comment --> <!-- Migrated from issue #3560029. --> Reported by: [mxr576](https://www.drupal.org/user/315522) Related to !24 >>> <h3 id="summary-problem-motivation">Problem/Motivation</h3> <p> The Amazee AI provider configuration page at <code>/admin/config/ai/providers/amazeeio</code> currently serves a dual purpose: it acts both as a regular configuration form and as a status page once credentials are set. This mixed responsibility causes configuration overrides to remain hidden from the status information shown on the page. </p> <p> Because the form class declares <code>ai_provider_amazeeio.settings</code> in <code>getEditableConfigNames()</code> and retrieves configuration via <code>$this-&gt;config()</code>, it always reads the non-overridden configuration object. As a result, in setups that use configuration overrides (for example in combination with the config_override module or environment-specific overrides) the "status page" part of the UI never reflects the overridden values, even though the system effectively uses them. </p> <h3 id="steps-to-reproduce">Steps to reproduce</h3> <ol> <li>Install and enable the <code>ai_provider_amazeeio</code> module.</li> <li>Configure Amazee AI provider credentials via a configuration override (for example using <code>settings.php</code> or a module like Config override) instead of storing them directly in <code>ai_provider_amazeeio.settings</code>.</li> <li>Ensure that the Amazee provider is functional and actually using the overridden credentials (for example by running an AI operation that succeeds).</li> <li>Visit <code>/admin/config/ai/providers/amazeeio</code>.</li> </ol> <p> Observe that the form&rsquo;s status / summary section displays empty or default values for credentials and related status fields, even though the overrides are present and active. </p> <h3 id="proposed-resolution">Proposed resolution</h3> <ul> <li>Long term: Separate concerns between configuration editing and status display: <ul> <li>A pure configuration form that works only with editable configuration.</li> <li>A dedicated status/diagnostics page that exclusively uses override-resolved configuration values.</li> </ul> </li> <li>Short: term Use editable configuration (via <code>$this-&gt;configFactory-&gt;getEditable()</code> / <code>getEditableConfigNames()</code>) only for form elements that are meant to be stored and changed. Use non-editable, override-aware configuration (for example via <code>$this-&gt;configFactory-&gt;get()</code> outside the editable context) for status display so that overrides are honoured.</li> </ul> <h3 id="summary-remaining-tasks">Remaining tasks</h3> <h3 id="summary-ui-changes">User interface changes</h3> <h3 id="summary-api-changes">API changes</h3> <h3 id="summary-data-model-changes">Data model changes</h3> > Related issue: [Issue #3559849](https://www.drupal.org/node/3559849) > Related issue: [Issue #3559845](https://www.drupal.org/node/3559845)
issue