You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
In administration, switching from light to dark mode updates the global configuration setting admin_theme, meaning all administrators have dark OR light mode. If you have several administrators, they must share the same color scheme. Not good.
Still in the administration, in the user manager, you can switch between compact/tile/line views. The value is stored in a cookie. This time the setting can be different for each user BUT it's lost when the cookie expires and you lose it if you use another computer. Better, but still not good.
To have the best of both situations, we need the setting to be a user setting, stored in the database. We already have some, like user_infos.show_nb_hits or user_infos.recent_period. The drawback is that we need to create a new column in user_infos for each setting. It can become a mess considering plugins would also like to use this possibility.
I suggest we add a new column user_infos.preferences which would store a serialized array of preferences. It would be more flexible and usable by plugins. In addition to the table column, we would need dedicated function userprefs_get_param, userprefs_update_param, userprefs_delete_param (just like the conf_get_param functions for the global configuration).
The text was updated successfully, but these errors were encountered:
In administration, switching from light to dark mode updates the global configuration setting
admin_theme
, meaning all administrators have dark OR light mode. If you have several administrators, they must share the same color scheme. Not good.Still in the administration, in the user manager, you can switch between compact/tile/line views. The value is stored in a cookie. This time the setting can be different for each user BUT it's lost when the cookie expires and you lose it if you use another computer. Better, but still not good.
To have the best of both situations, we need the setting to be a user setting, stored in the database. We already have some, like
user_infos.show_nb_hits
oruser_infos.recent_period
. The drawback is that we need to create a new column inuser_infos
for each setting. It can become a mess considering plugins would also like to use this possibility.I suggest we add a new column
user_infos.preferences
which would store a serialized array of preferences. It would be more flexible and usable by plugins. In addition to the table column, we would need dedicated functionuserprefs_get_param
,userprefs_update_param
,userprefs_delete_param
(just like theconf_get_param
functions for the global configuration).The text was updated successfully, but these errors were encountered: