OpenSearch-Dashboards
OpenSearch-Dashboards copied to clipboard
Fix/UI settings overrides
Description
There are a couple different fixes here, which can be viewed separately by looking at the separate commits. But the root cause of https://github.com/opensearch-project/OpenSearch-Dashboards/issues/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 https://github.com/opensearch-project/OpenSearch-Dashboards/issues/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 Report
All modified and coverable lines are covered by tests :white_check_mark:
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%) |
:arrow_up: |
| 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.
:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.
@joshuarrrr Dont we want a changelog entry for this change?
@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.
Remove 2.15 label since the https://github.com/opensearch-project/OpenSearch-Dashboards/pull/5652 has not yet been released in 2.14.
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:
- uiSettings.get('theme:darkMode') returns a Promise.
- !! tries to coerce the Promise object to a boolean.
- Since any non-null object in JavaScript is truthy, !! converts the Promise to true.
- 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:
- await uiSettings.get('theme:darkMode') resolves the Promise and gets the actual boolean value (false in your case).
- !! 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());
});
Resolving ciGroup9 to run correct light mode will automatically resolve ciGroup3.
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.
Close this as tests are fixed in https://github.com/opensearch-project/OpenSearch-Dashboards/pull/7776