We need to refactor the config approach on AI APIs

[jdotcms]

Parent Issue

No response

User Story

As an user, I want to be able to save changes on the config and get them automatically on the IA apis

Acceptance Criteria

Currently it is not working properly, my thought is that the approach used to handle the config is not right, we need to refactor it

Proposed Objective

Core Features

Proposed Priority

Priority 3 - Average

External Links... Slack Conversations, Support Tickets, Figma Designs, etc.

No response

Assumptions & Initiation Needs

No response

Quality Assurance Notes & Workarounds

No response

Sub-Tasks & Estimates

No response

[john-thomas-dotcms]

Slack thread: https://dotcms.slack.com/archives/CQNF9PCFQ/p1723151016456439

[john-thomas-dotcms]

Initial thoughts (from the Slack thread):

There are a few ways we could handle defaults and fall-throughs from the site config to the System Host config in Apps (in general, not just for dotAI).

When a site doesn't have all required fields filled in:

1. The entire site config is inactive.
   • Use the System Host config in it's entirely, ignoring any values in the site config.
2. Use default values for all blank fields.
   • IOW, don't fall-through to the System Host config for individual fields.
3. Use values from the System Host config for all blank fields.
   • IOW, fall-through to the System Host config on a field-by-field basis.
   • If both the site config and the System Host config have blank values for the same field, then use the default value.
4. Make the fall-through behavior configurable between # 1 and # 3.
   • The SAML App has this capability - you can mark a site config as Active, even if it's missing some required fields, and then it will fall through. But this isn't a general capability for all Apps.

Here's my current take on these:

• I think the best default behavior right now is # 1.
  • Currently, when a config doesn't have all required fields filled in, it's shown as inactive.
  • Since visually inactive configs will likely not even be clicked into by a user, it's best to treat that config as if it doesn't exist.
• Option # 2 doesn't actually make sense, because when the site config doesn't have all required fields, it's invalid.
  • So, we can eliminate this from the list of options.
• For # 3 and/or # 4 to work without causing confusion (and support tickets), we'd need to be able to show incomplete site configs as Active even when all required fields are not filled in.
  • To be more specific, we'd need show them as active only if the System Host config has values for the required fields that the site config is missing.
  • This simplest and most maintainable way to do this would be to only show the site config as active if the entire System Host config is already active.

My current preference would be to implement # 4 as it's implemented for the SAML App, but to make that a general feature that applies to all Apps.

• To do this properly, we'd need the App portlet to show site configs which fall through as active, even if they don't have all required fields filled in (see the last op-level bullet in the previous list).