“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:
- Real/Centralized User and Security Management for admins
- 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.
4 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
Home Assistant 2023.10.5
Supervisor 2023.10.1
Operating System 11.1
Frontend 20231005.0 - latest
I followed your instructions. But when I refresh the page the Console says, “Settings are up to date” even though I haven’t added them to custom.js. And everything that I configured has been reset.
Not working anymore?
It doesn’t work quite the way it is described here, but I defiantly managed to squeeze some usefulness out of it.
Here is my code, it may help someone figure out the naming convention of the sidebar links:
const settings = {
defaultPanel: '"lovelace"',
dockedSidebar: '"docked"',
enableShortcuts: "true",
hiddenTabs: "{}",
selectedLanguage: "null",
selectedTheme: '{"dark":true}',
sidebarHiddenPanels: '["energy","map","overview","core_configurator"]',
sidebarPanelOrder:
'["dashboard-time","dashboard-basement","1st-floor","2nd-floor","dashboard-spacer","config/devices","config/integrations","config/automation","dashboard-spacer-2","config/logs","logbook","hassio/dashboard","hacs","developer-tools/yaml","a0d7b954_vscode","7094bb28_docker_wyze_bridge","cebe7a76_hassio_google_drive_backup"]',
suspendWhenHidden: "true",
vibrate: "true",
};
Here’s what I found works.
I added that code to www/config.js as described above. And then call it as an extra_module_url: in configuration.yaml.
Make some tweaks to config.js as desired. See the tweaks by emptying the browser cache (hard refresh).
But some settings can’t be set this way and will be reset every time you hard refresh. For example, Primary and Accent colors keep resetting.
So once I was happy with the sidebar order I disabled the script by commenting out the line in configuration.yaml and then reboot HA.
Now I can set the colors and they won’t get reset by a hard refresh.
So then I go to another browser or device and log in to my HA instance. The sidebar is a mess because, of course, the custom profile settings do not roam between devices.
So now I uncomment the line in configuration.yaml (which means custom.js is being called again).
I reboot HA and refresh device #2 and bingo my custom sidebar order is now carried over to the 2nd device.
Once again I comment out that line in conguration.yaml and reboot HA.
I can now set my custom colors on device #2 and I’m done.
Clear as mud?
This sounds a bit convoluted but, speaking for myself, it is actually much easier than to constantly reorder all of my sidebar items each time I use a new browser, device, URL, clear my cookies, etc.
Thanks for sharing, @ndbroadbent.
I am surprised that this thread isn’t garnering more attention. The need to configure the sidebar for each session is a major HA pet peeve of mine.
3 Likes
‘cause it’s a flogging a dead horse.
Is it dead? Or just sleeping?
Agreed, this would most logical and very beneficial function.
Anyone is able to add this functionality, just takes a volunteer…
I must be completely dense… I’ve tried for an hour now to find out how to find these updated settings in the developer tools console and I can’t figure out how to find them. Any way you can maybe make a short video? I’m assuming this is in chrome? Thank you!
Those settings only appear if you use the attached JS that he posted. They will only appear after you add the resources and restart.
Hello, it would be great to have progress with this issue. I think general rights settings and settings for users is very important for the real usage of the system.