Fix/UI settings overrides

[joshuarrrr]

Description

There are a couple different fixes here, which can be viewed separately by looking at the separate commits. But the root cause of #6704 was primarily the fact that the implementation of getOverridesOrDefault assumed the wrong object shape for the overrides property, when it tried to access a value property instead of just the value itself. Note that the existing unit test also had this same error.

Because the ui_render_mixin is an old legacy .js file, there's not much help from typescript, so I also added some enforcement to make sure we're always sending boolean values to the template.

Additionally, I realized that the validation for the theme:version setting was not correct, and needed updating to match our current themes.

Finally, as requested, I updated the new user theme controls to be deactivated by default.

No changelog necessary, as the previous PR this fixes has not yet been released.

Future work

@AMoo-Miki @manasvinibs - The past discussion and this TODO comment seem to indicate that we don't actually want to maintain support for these overrides long term. But even if we do, I don't think the schema definition for overrides makes much sense:

overrides: schema.object({}, { unknowns: 'allow' }),

We probably want users to be aware of if they specify invalid overrides and not silently ignore (which is what was happening with an incorrectly set value in @BionIT 's configuration.

Issues Resolved

Fixes #6704

Screenshot

Testing the changes

The linked issue only surfaced when deploying https://future.playground.opensearch.org/ , and only when not yet authenticated, because the configuration file specified overrides such as:

uiSettings:
  overrides:
    'theme:darkMode': false

To validate these fixes, test with authentication enabled, a non-authenticated user, and theme UI Settings overrides.

Changelog

• skip

Check List

• All tests pass
  • yarn test:jest
  • yarn test:jest_integration
• New functionality includes testing.
• New functionality has been documented.
• Update CHANGELOG.md
• Commits are signed per the DCO using --signoff

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 67.43%. Comparing base (48144c8) to head (13e3e05).
Report is 230 commits behind head on main.

Additional details and impacted files

@@           Coverage Diff           @@
##             main    #6730   +/-   ##
=======================================
  Coverage   67.43%   67.43%           
=======================================
  Files        3443     3443           
  Lines       67806    67806           
  Branches    11031    11031           
=======================================
  Hits        45727    45727           
  Misses      19413    19413           
  Partials     2666     2666           

Flag	Coverage Δ
Linux_1	33.09% <0.00%> (ø)
Linux_2	55.06% <100.00%> (ø)
Linux_3	45.21% <0.00%> (+0.01%)	⬆️
Linux_4	34.88% <0.00%> (ø)
Windows_1	33.11% <0.00%> (ø)
Windows_2	55.03% <100.00%> (ø)
Windows_3	45.21% <0.00%> (ø)
Windows_4	34.88% <0.00%> (ø)

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[ashwin-pc]

Thanks for these changes Josh!

[ashwin-pc]

@joshuarrrr Dont we want a changelog entry for this change?

[joshuarrrr]

@joshuarrrr Dont we want a changelog entry for this change?

Well... originally I was thinking no, in terms of fixing the new theme controls, which haven't yet been released. But now I'm remembering that this was actually a latent bug in the UI settings client, so I'll add a changelog entry.

[AMoo-Miki]

The failures indicate substantial visual diff. Putting a hold so we don't accidentally merge before examining the diff.

[ananzh]

Remove 2.15 label since the #5652 has not yet been released in 2.14.

[ananzh]

ciGroup9 Failure Research

Currently there are 9 failed tests. From debug, I found there are two issues.

Issue 1: default dark mode

From debug I found the change of default mode is caused by !! order. For await !!uiSettings.get('theme:darkMode’), the !! operator is applied before await, causing the following steps:

1. uiSettings.get('theme:darkMode') returns a Promise.
2. !! tries to coerce the Promise object to a boolean.
3. Since any non-null object in JavaScript is truthy, !! converts the Promise to true.
4. await then resolves the true value, but this doesn't make sense in the usual await context.

So if we move !! before await !!(await uiSettings.get('theme:darkMode'));, the operations are correctly ordered:

1. await uiSettings.get('theme:darkMode') resolves the Promise and gets the actual boolean value (false in your case).
2. !! then converts this resolved boolean value to true or false.

But why do we need !!? Do we see any cases that we will receive truthy or falsy value? If not, maybe go back to await uiSettings.get('theme:darkMode')?

Issue 2: can't find advancedSetting-saveButton

after resolve the first one, there are 4 failed tests left, all due to

Error: retry.try timeout: TimeoutError: Waiting for element to be located By(css selector, [data-test-subj="advancedSetting-saveButton"])
         │ Wait timed out after 10024ms

This is because when we set up like below:

await PageObjects.settings.toggleAdvancedSettingCheckbox('theme:enableUserControl');
await PageObjects.settings.toggleAdvancedSettingCheckbox('theme:darkMode');

The enableUserControl will block admin to set up darkMode.

This is a bit wired cuz this means admin now can't control admin's own mode. If this is expected, then we could test

it('admin's customized dark mode logo for opensearch overview header is applied', async () => {
        await PageObjects.common.navigateToApp('management/opensearch-dashboards/settings');
        await PageObjects.settings.toggleAdvancedSettingCheckbox('theme:darkMode');
        await PageObjects.common.navigateToApp('opensearch_dashboards_overview');
        await testSubjects.existOrFail('osdOverviewPageHeaderLogo');
        const actualLabel = await testSubjects.getAttribute(
          'osdOverviewPageHeaderLogo',
          'data-test-logo'
        );
        expect(actualLabel.toUpperCase()).to.equal(expectedMarkLogoDarkMode.toUpperCase());
      });

it('if enable user control, admin's customized dark mode logo for opensearch overview header is not applied', async () => {
        await PageObjects.common.navigateToApp('management/opensearch-dashboards/settings');
        await PageObjects.settings.toggleAdvancedSettingCheckbox('theme:enableUserControl');
        const button = await testSubjects.find('advancedSetting-editField-theme:darkMode');
        const isDisabled = await button.getAttribute('disabled') !== null;
        expect(isDisabled).equal(true);
        await PageObjects.common.navigateToApp('opensearch_dashboards_overview');
        await testSubjects.existOrFail('osdOverviewPageHeaderLogo');
        const actualLabel = await testSubjects.getAttribute(
          'osdOverviewPageHeaderLogo',
          'data-test-logo'
        );
        expect(actualLabel.toUpperCase()).to.equal(expectedMarkLogo.toUpperCase());
      });

[ananzh]

Resolving ciGroup9 to run correct light mode will automatically resolve ciGroup3.

[AMoo-Miki]

After talking to Ashwin, I would also like to understand why the original override mechanism is not working as expected because that bit is ancient code and we might need to make other changes accordingly.

[ananzh]

Close this as tests are fixed in #7776