WTH: Why most settings are browser instance dependant

It’s one of the WTH features I found in HA. I know no other software which doesn’t offer user preferences settings saved for a user but instead offers to store it per browser.

If I want to change some settings like theme, language, units, items in side-bar etc I have to set it up in every end-user application on every computer my HA is in-use. A multi-user environment obviously requires access to personal end-user devices which in general is considered unwanted.

To summarize: I would like the HA stores user settings for each user. Not for the current browser.

Agreed. I thought I was losing my mind and not saving or something.

4 Likes

Agreed, I would love a “Account dashboard” that is the default for my account everywhere—same with theme and colours.

2 Likes

What’s even more annoying is needing to reconfigure these settings after every system update.

There needs to be a hierarchy to it. Load the defaults settings by the admin for all logins, then load user’s browser independent settings on top of that.

I would argue almost none of it should be browser based. Store the user settings on the server, not in cookies.

9 Likes

agree. no need to have settings stored per browser at all.
if there is indeed such a need it has to be opted in explicitly. likely be available for superusers only.

This is super annoying, I was hoping I can define a profile with all of those settings on the server and only the changes made in the browser are lost.
What is even more annoying is that if I connect by IP or URL or short URL it will treat them as 3 separate instances and have configure each and every one separately.

Such user template can also help if you need to provision a new user and simplify/limit the settings they can see/edit.

1 Like

I think it should still be per-device, but my issue is the settings don’t even persist on the same device. I shouldn’t have to redo the settings on my iPad every week.

because per-device means per-browser instance where settings are cookie based. Snd cookies might be wiped out depending on their settings or browser policy.

And no. definitively it shouldn’t be per instance. With more users you, as admin, have no control over all devices users use.

One could argue it’s needed when using tablets mounted on walls, but this can be achieved with use of user per tablet.

1 Like

“Per device” would be better served as multiple profiles per user, where the profile name is about the only thing saved in the cookie as a default.

1 Like

but once you as admin want to control other user settings it’ll break into pieces. Usually you don’t want to give to users a freedom of changing those settings.

of course I’m ok with that once there will be option to disallow changes set by users

The user would just have control within their profiles of what the admin allows them to see in the first place.

From the posts, there seems to be two wants:

  1. Real/Centralized User and Security Management for admins
  2. Simple/Consistent device to device settings within the current framework.

#2 would be the easier to implement, basically just copy restore the existing cookie info for the user. A second step could be saving the info into separate user specific profiles. A step further could allow admins to “view as user” and make changes and/or copying profiles between users. I’d have no problem with a flag not allowing users to make most changes. Still not real security, but big step in user experience.

The most basic “cookie copy” implementation would be relatively simple and address a real annoyance.

User/role based management could come later. Doing it right would be much more involved, but maybe not if the something like this has been planned on and structures are in place. I’m thinking an afternoon project for “cookie copy” vs days/weeks/? for “real user admin.” I’m sure I’m oversimplifying, especially on the low end, but expect the principles are sound.

but there is no anything like cookie-copy, since cookie is browser object. If you want to pass data from cookie to the HA in order to store it and recreate on other devices it turns into the same as storing settings in the system first, then recreate/modify from any frontend.

in system design you never rely on data from cookies first. You have to have a data model allowing storing particular settings in the system. You then provide those data to FEs, eventually allowing overriding on particular FE. Never opposite .

one of the reasons why FE application should not use data stored in cookies - because a user may exploit it storing manually anything. Those are just basics.

but we are unnecessarily talking about details. At first devs have to find this WTH valuable and start to work on it. At the end I doubt our opinion about implementation will be taken into account. They have their own strategy.
Most important is that current state is insufficient for all of us who voted for this WTH

To satisfy the thread title and OP, all you need is to do is store centrally what is currently local.

I’m using the term cookies generically. Looks like HA uses local storage and not cookies, but that is mostly irrelevant.

User changes always coming from the front end, it’s only the path to the back end that changes. Hopefully the storage write/read calls are abstracted enough to make writing more directly to the back end relatively simple, and that would be the best option. If not, I don’t see anything inherently evil for code to replicate desired keys from local instance to the back end under a storage change event or a “save profile” UI element.

Logic determining if the user changes should usurp eventual admin level settings is another issue and can come later.

1 Like

I agree that this has been really annoying. I want to configure my user profile settings once and then save them permanently, so that I can use them across multiple devices and sessions.

@jerrm Thanks for the tip about HA using localstorage. I was able to hack together a workaround that will restore my settings from custom.js.

You’ll need to set up custom.js as an extra_module_url option in config/configuration.yaml:

frontend:
  extra_module_url:
    - /local/custom.js

Then you can add this JS to www/custom.js:

// Persistent settings across multiple devices / sessions
// ------------------------------------------------------
(function () {
  // Visit /profile?edit=1 to change your settings, then update them here.
  const settings = {
    defaultPanel: '"lovelace"',
    dockedSidebar: '"docked"',
    enableShortcuts: "true",
    hiddenTabs: "{}",
    selectedLanguage: "null",
    selectedTheme: '{"dark":true}',
    sidebarHiddenPanels: '[]',
    sidebarPanelOrder:
      '["lovelace","hacs","logbook", "..."]',
    suspendWhenHidden: "true",
    vibrate: "true",
  };
  let settingsUpdated = false;
  const currentSettings = {};
  Object.keys(settings).forEach((key) => {
    currentSettings[key] = localStorage.getItem(key);
    if (currentSettings[key] !== settings[key]) {
      localStorage.setItem(key, settings[key]);
      settingsUpdated = true;
    }
  });
  const urlSearchParams = new URLSearchParams(location.search);
  if (!settingsUpdated) {
    console.log("Settings are up to date.");
    return;
  }
  if (urlSearchParams.get("edit") === "1") {
    console.warn(
      "Settings updated:\n",
      JSON.stringify(currentSettings, null, 2)
    );
  } else {
    console.warn("Settings updated, reloading page...");
    location.reload();
  }
})();

Now you can visit /profile?edit=1 to change your settings. Once you’re finished, open the developer tools and reload the page (make sure you uncheck “Disable cache” in the Network tab). You’ll see your updated settings in the logs:

Copy this and paste it into custom.js, then refresh the page. You should now see Settings are up to date. in the logs. Now your settings will be restored automatically whenever you sign in.

Note: The same settings will be used by all users. I couldn’t figure out how to get the current user ID.

This will also be really nice for my wall-mounted dashboards, I couldn’t figure out any other way to set the dark theme by default. People have been complaining about that for years as well

8 Likes

I realize we are a long way from the month of WTH, but this issue of user management and ability of the administrator to manage what each user sees regardless of what device/browser they log into is pretty fundamental to having Home Assistant work for multiple users. Splitting what is stored on the frontend profile and the server profile may be a bit of work, but is fundamental for user management.

In my case, I really would like to have my “guest” account show only what I want it to. I can control that to some extent by putting the guest dashboard in overview. However, I also want to hide the sidebar but it always defaults to on when a user signs in from a new browser. Having my home automation system usable by guests with little intervention on my part is the goal.

3 Likes

Hi @ndbroadbent, what a solution haha! Quite unfortunate that this is not (yet) configurable within HA itself, but still, thanks a lot.

I made a Custom Card with some inspiration from this post. It’s been working good so far. If everyone wants to try: GitHub - ajagnanan/lovelace-settings-sync: Home Assistant Settings Sync

2 Likes

Now 2023.11, and user settings are not possible to save across devices, there must be a good reason for this?

1 Like