SplunkWeb users may experience different behaviors for the UI preferences that used to persist and show latest preferences by updating ui-prefs.conf on the fly. Now after upgrade to 9.0.5+ or 9.1.0+ its behavior changed and no longer uses ui-prefs.conf to remember the user's UI level preferences, but instead, uses the url in the request or localStorage/Web Storage. However the ui-prefs.conf is still used to set the initial values up - simply became read-only mode.
Due to this change you will find the user level changes on the search page may not persist.
Here are some examples you can experience by this changes:
- The search mode, fast/smart/verbose mode you set just now is discarded.
- The chart type, line, bar or pie, you chose just now is not persisting and changed to one type whenever logging in back.
- Some features, such as the time ranges you used to use in time range picker is reverted back after the browser cache clean-up.
- Or you have to set your own search page preferences to each browser or different PCs you use.
Reason for the change:
This change was decided to improve the slow UI loading time issue for a large deployment with thousands of users. Instead of using central location, ui-prefs.conf on the Search Head the load has been spread to the user level.
Affected versions : 9.0.5+, 9.1.0+
What's the expected with the new behavior:
With this change each parameter in the ui-prefs.conf has been implemented basically to remove POST method, either added into URL in GET request or stored in the localStorage of the user browser.
If it’s stored in the URL as a parameter it lasts the length of the current workflow. ie. . Once you load the page again without the parameter in the URL, it is discarded.
If it's in localStorage it will last until it gets deleted from the Web Storage. You can find more detailed conditions for different browsers here; How the data in localStorage get deleted.
How can I go back to the previous behavior although it's not recommended:
If the customer would like to re-enable the old workflow temporarily (this will result in poorer performance for web page loads - the reason why this change was made), optimize_ui_prefs_performance in web-features.conf can be set to false as a temporary workaround.
In web-features.conf:
[feature:ui_prefs_optimizations]
optimize_ui_prefs_performance = false (true by default)
