[9.0.5] ui-prefs.conf, Why my default search mode in search page on UI is not getting updated or discarded?

[sylim_splunk]

In GUI > Search app > search page  I used to change the search mode to verbose which I knew it persists after the sessions. Such as, when I change the mode to "Fast" and log out. Once I log in back it shows "Fast".

But not any more after we upgraded to 9.0.5 from 9.0.4.  Why?

[ui-prefs.conf, url or localStorage]

[sylim_splunk · Accepted solution]

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)

[verbal_666]

They did a real great mess, after 7.0, and some 8.x release 😤
Also with false in optimize_ui_prefs_performance, i'm now on 8.2.12 version,

1) optimize_ui_prefs_performance to true destroyes all old users customization on search tab

... also with optimize_ui_prefs_performance to false,

2) new ui-prefs.conf are not created anymore, only old ui-prefs are managed
3) also etc/users/launcher/local/ui-prefs.conf to remove "Explore Splunk Enterprise" banner has gone away!
4) users can't change Alerts/Reports/Dashboards object view modality (general/owner/app), since it's defaulted and reverted back to "All" next time you load the page!!!

5) seems ui-prefs is right managed only in "app/search/search|alerts|reports|dashboards" (default search App)

This is really a great mess!!! 😩😰😱

Check here,
https://community.splunk.com/t5/Splunk-Enterprise/quot-ui-prefs-conf-quot-no-more-working-from-Versi...

We have had many users complain about this poor UI management!!! 🤢🙈