User Roles (Remove Sidebar & 3-Dot Menu)

[Yves_IF (Yves)]

With the project stop of custom-header (@mayker thanks for your great work) I’m missing some functions in Home-Assistant.

• Remove the menu sidebar for defined users
• Remove the 3-Dot menu for defined users (menu top right)

In my opinion, most of the options in the profile-settings should also be able to be set by the “administrator” (depending on the authorization set, the user cannot change them).

When I think of the future of home assistants, it makes sense to expand with a central user administration. Something like this:

This ensures that you don’t ban yourself (if you deactivate the sidebar-menu):
The sidebar-menu could only be activated in the ‘Users’ group. This option should be deactivated for the Administrator groups. The two groups (Administrator & Users) already exist.

Here are the different settings in the overview:

[paulstronaut (Paul)]

There’s a new plugin that can do this: Kiosk mode

[Yves_IF (Yves)]

Thanks. I’ve already tried the kiosk mode. But I haven’t found any ways to control this per user.
If it is possible, please put me on the right track.

Either way, I think a central user administration should be added to the core system.

[paulstronaut (Paul)]

Correct. I use this for displaying to a tablet, though, and it works great for that purpose. There are other requests for ACL-like control over items, but that’s a really involved bit that likely won’t happen for a very long time.

[Yves_IF (Yves)]

@paulstronaut

Correct.

Then the function of these feature requests does not yet exist. So, let’s vote

@paulstronaut

There are other requests for ACL-like control over items, but that’s a really involved bit that likely won’t happen for a very long time.

The feature requests Control Sidebar items (I assume you mean this) are only about the content of the menu sidebar. In the meantime, this is possible, but also only per device. In my feature requests, the admin should also be able to define the content of the sidebar for the other users.

[finity]

@paulstronaut

, but that’s a really involved bit that likely won’t happen for a very long time.

I don’t know why it should be. That functionality already existed (and still works yet) in custom header. They could incorporate that work into core.

My understanding is that the devs don’t want to do it because it’s too complicated for users.

[mayker (maykar (pronounced "maker" with a southern accent))]

Per user controls on kiosk-mode exist now. Also, be on the lookout for another project in the works that will do the same for the 3 dot menu and more in the header no ETA yet.

[Mariusthvdb (Marius)]

sounds good…

for kiosk mode, in CH we could use this

kiosk_mode: >-
  {{is_state('input_select.mode','Kiosk')}}

is this in the works too? Meaning, if we select the input , Kiosk mode is entered, and vice versa. Very nice to use in automated settings

[Mariusthvdb (Marius)]

@mayker

be on the lookout for another project in the works that will do the same for the 3 dot menu and more in the header no ETA yet.

I am!

did you see this Allow using templates for Header icons · home-assistant/frontend · Discussion #7569 · GitHub, maybe things can come together…

haha thanks Ryan.

[mayker (maykar (pronounced "maker" with a southern accent))]

That one is a bit more complicated, but I am thinking on the best way to add something like conditional configs based on entities. This won’t be handled with template rendering, but could be handled with a template sensor.

Ultimately, I would like to create a simple way for some of my projects, and any project that wants to steal the code, to be able to use certain conditions to change config based on:

• If user is admin
• If user is not admin
• Per user conditions
• Entity state/attribute conditions (only one not implemented in kiosk-mode yet)

Once that is done I want to add it to some of my other projects and create an example for others to use. No ETA of course, lot’s of stuff on my plate.

No Jinja in the frontend kind of stuff, maybe js, but probably just config driven.

[Mariusthvdb (Marius)]

wow, yes, that’s really what we need with the demise if CH.
hope you get around to it, and please throw it at us in a beta state so we can help testing it.
btw, the example above could of course be written in a non template way, if you want to prevent overloading the add-on with templates

kiosk_mode:
  entity_conditions:
    input_select.mode: Kiosk

is that what you have in mind?

[mayker (maykar (pronounced "maker" with a southern accent))]

That’s pretty much how I’d like it to work, something like (rough ideas here):

kiosk-mode:
  state_confg:
    - "input_select.mode": kiosk
       kiosk: true

or even:

kiosk-mode:
  entity_confg:
    - "input_select.mode.state": kiosk
      kiosk: true
    - "light.livingroom.attribute.some_attribute": 56
      hide_header: true

Sorry, kind of hijacking this thread here. If you have further questions, hit me up on discord or message me.

[Mariusthvdb (Marius)]

great. can’t wait. since that is the functionality I use for kiosk mode, I’ll wait for that to happen. thanks for continuing the works and securing the CH legacy.

[Yves_IF (Yves)]

@mayker

Per user controls on kiosk-mode exist now.

@mayker Thanks a lot! That’s exactly, what I (and I Think o lot of other users) looked for.
About the implementation in the HA-core: If you bring your nice tool on the core, maybe you can influence the core-team, to exband the user-roles (like my picture upper)

@mayker

Sorry, kind of hijacking this thread here.

@mayker no matter - the stage is yours.

[paulstronaut (Paul)]

An ACL is quite different than what you’re asking for, but I’m pointing out that it may already be on a roadmap.

An ACL (Access Control List) does more than just hides icons from people; it prevents them from actually being able to take certain actions. Right now, just hiding something like the Configurator doesn’t make it completely inaccessible, it just means you have to know how to get to it. This is an extreme example, but it can be used for more minor things, like preventing guests from being able to arm or disarm the alarm system, unlock doors, or turn on/off certain switches/lights, etc.

From a security perspective, an ACL will be much better to both hide things from the user and prevent them from accessing or modifying all-together. Thinking about the long-term, it’d be better to put efforts into a system like that than throwing some insecure band-aids and trying to support those.

[Yves_IF (Yves)]

@paulstronaut

From a security perspective, an ACL will be much better to both hide things from the user

I absolutely agree with you. If something is going on (even if not implemented tomorrow) I am satisfied. Especially with the current solution from @mayker . It would be cool if @maykers “hidden solutions” were integrated into the ALC. Can someone make the connection to the ACL-project-team for @mayker ?

[paulstronaut (Paul)]

There’s some developer docs https://developers.home-assistant.io/docs/auth_permissions/, but the system is not finished or fully enforced

[mayker (maykar (pronounced "maker" with a southern accent))]

That’s all backend stuff, I’m more of a frontend guy. I’m sure they don’t need me for anything

[finity]

@paulstronaut

Thinking about the long-term, it’d be better to put efforts into a system like that than throwing some insecure band-aids and trying to support those.

I really don’t care how it’s done as long as it is done.

[Yves_IF (Yves)]

@mayker

That’s all backend stuff, I’m more of a frontend guy.

I was happy too soon. I also hoped for more from ACL in the front-end. So back to my picture at the very top of this feature request