[FR] User-driven object display; affect #149

[progro1]

Following up on issue #149, I would like to suggest the introduction of user-driven objects.

It should be possible for an admin to view and control all sensors.

For a specific user, it should be possible—regarding a displayed object—to:

hide it completely

view objects and values ​​but not be permitted to click on them;

view objects and be permitted to click on them.

Further explanation:

The floor plan view is presumably intended to make operating the devices easier.

In this context, it would certainly be helpful if certain users did not have to deal with the full level of complexity.

For instance, a small child should only be able to turn the lights and radio on and off, without seeing controls for the air conditioning or motion and other sensors.

An older child might be allowed to view the air conditioning settings and readings but should not be permitted to make changes or toggle controls.

Similarly, a typical adult in the boiler room should be able to view all the various sensors and readings but should only be permitted to operate specific controls.

Creating a separate floor plan for every user would not be very practical, especially when it comes to making changes.

[tsioukas]

@progro1, I agree that this would be a useful feature, however I think a system like this should be based on the Home Assistant Permissions System, rather than implementing a separate permission system internally in Easy FloorPlan.

Home Assistant already has a permission model that supports different access levels, such as read, control, and edit. Developers can follow the rules described here: https://developers.home-assistant.io/docs/auth_permissions/

However, as far as I know, Home Assistant currently does not provide a frontend UI for configuring these permissions on a per-device/entity basis. At the moment, this requires manually modifying ".storage/auth", which is not practical for most users and could also be dangerous for users who are not familiar with Home Assistant's internal storage.

Therefore, I think the best approach for Easy FloorPlan would be to respect and follow Home Assistant's existing permission system, rather than creating another access-control layer.

Until Home Assistant provides a proper frontend UI for configuring these permissions, Easy FloorPlan could simply be prepared to work with the existing authorization rules. Then, once Home Assistant exposes these permissions through the frontend, it could automatically benefit from them without requiring its own separate user-permission configuration.

This would also avoid having to maintain two different permission systems and would make the behavior consistent with the rest of Home Assistant.

[nicosandller]

@progro1 thank you for the feedback. I definitely see the value in what you are proposing. Is this something you would benefit from now? Can you explain more about your specific use of this? Is this your home or an office space? Kids? etc! It helps to know.

I agree with @tsioukas . Implementing a permissions system sounds challenging, Im driving most of the implementations unfortunately with limited time. I would much rather implement things based on HA's existing infrastructure code.

@tsioukas is there anywhere (issue or else) that tracks progress in HA for permissions?

[tsioukas]

@nicosandller, the most recent discussion I read on this, which outlines a really interesting approach, is here: home-assistant/architecture#1374. It goes beyond just devices and entities, it proposes a properly expanded, comprehensive permission system.

Home Assistant carries some historical architectural trade-offs because it was originally designed for a fully trusted local environment where everyone in the household had access to everything. The team has been trying to implement a robust RBAC system for a while, but maintaining backward compatibility makes it a complex task.

This isn't just a frontend issue (which I think is actually the easy part 😉). Even if you restrict a card's visibility in the UI, an unauthorized user could still bypass those restrictions via WebSocket or even easier with LLM prompts if voice/AI assistants are enabled. The backend itself needs to enforce the rules.

I hope they eventually implement a true, dynamic permission's engine so custom modules (like Easy Floor Plan) can leverage it natively.

Personally, I've given up on trying to maintain view-level rules on individual cards, it's messy, and it's almost impossible to be 100% sure who has access to what. For now, I'm just sweeping it under the rug and trusting that my family members won't try to 'hack' my setup. The good news is that their knowledge is only how to open a light and thermostat 😉.

P.S. Just read this part on renck answer "This means the resource commitment goes far beyond what a community contribution alone can carry. It is not just about reviewing and merging code; it involves ongoing security monitoring, audit processes, and long-term maintenance responsibility from our side. These are resources we currently do not have allocated, and this work does not align with the goals we have set out for this year.".

[progro1]

@nicosandller
Thank you for your reply.

I could actually use this for my current home setup. While I don't have small children anymore (that example was just to illustrate the benefits, which would surely help other users too), the point about issues when using it in the boiler room is definitely relevant to my situation.

When I first used EF, I made the mistake of sticking with the default room size. Now—and I would face this same issue in the boiler room—I want to display too many sensors with clickable values. It very quickly becomes cluttered; the sensors (and their labels) overlap and become unreadable.

This happens even when I group multiple entities into a single object.

For me as the admin, this is merely an annoyance, but there are certain sensors that shouldn't be visible or clickable for my wife and son.
They could mess up the entire heating control system.
With so many sensors, it’s easy to click on the wrong one and accidentally change its settings.
Since I’m new to Home Assistant, I’ll likely come up with other ideas during configuration regarding which sensors I want to see versus those that shouldn't be visible for others. Before I integrate all the sensors I’m interested in, however, it would be helpful to be able to hide some of them from others without having to resort to a second floor plan.
Especially in cases where user restrictions are not initially expected from the HA-Team.
Thanks for your work at all.

[nicosandller]

@tsioukas thank you! that's very informative actually. It sounds like for HA we don't have a roadmap sow e shouldn't depend on it. That makes me think if there isn't something simple and quick we could implement on our add on to help on the case @progro1 described. Like something extremely basic, and not a holistic system of permissions thats robust.

@progro1 the details you provided are very helpful. Like I said above, maybe there's something very simple we could do. Whats better for you?

• hiding the sensors from all but one user?
• blocking click ability from all but one user but still showing it?

something else?

In other words whats the easiest solution to your problem? If you can help me think, in plain English and without getting into HA lingo, what are some solutions to your problem you can help a lot.

Also, if you can please share a screenshot of your sensor madness at the boiler room on another issue here on GitHub. Thats a hole other problem that I think is worth addressing!

[progro1]

@nicosandller I am glad you are considering implementing something here.
However, to make the feature truly useful—both for me (later) and for others—I believe the options I discussed regarding the "children" (in first post) are necessary for the reasons previously outlined.
To recap briefly:
Even though the admin has included it in the plan...
1.The sensor is not visible to the user.
2.The sensor (with values ​​and description) is visible but cannot be clicked.
3.The sensor is visible and clickable (the standard behavior up to now).

I would need something along these lines:
I select a sensor (whether combined or not).
Then, I select an existing HA user from a list and assign an attribute to them:
1.Sensor not visible and therefor not clickable.
2.Sensor not clickable.
... Of course, if there are other interesting possibilities I haven't considered, those would be useful too.

Naturally 😅, it would also be helpful to generate a (clickable) list showing all user objects and their selected settings.
Or, as an admin editing the plan, I could see from an object's color that user restrictions are in place.
But those two features would just be the icing on the cake (german user,google translation), provided I can already see the configured restrictions in the settings in EF for each individual sensor.
Thanks

[progro1]

@nicosandller

Sorry for closing. Wrong button edit in chrome wirh german translation .
And it is early morning (not really 😅) but i am in hurry to see my doctor (nothing serious).
And many thanks to @tsioukas 🙏🏻
You are great to think about those features.
especially on the post below this.

[tsioukas]

Following up, I searched again to see if there are any new community tools for managing Home Assistant permissions from the frontend, and I came across this plugin: user-rbac (also on HACS).

While the frontend UI looks very interesting, PLEASE BE EXTREMELY CAREFUL BEFORE TRYING IT.

⚠️ CRITICAL WARNINGS:

• Not Stable: The developer explicitly warns: "This application is under active development and is not stable yet!"
• Potential Lockouts: A user reported that installing this "destroyed admin permission." (but he didn't provide it details)
• Inactive Development: The repository shows little activity, with the latest pull request dating back over 3 months ago.

Testing Approach & Advice: I am going to test this sometime in future on a secondary, isolated Home Assistant OS VM to see if it functions without issues. DO NOT install this on your main or production Home Assistant server. Proceed only on a disposable test instance!

I haven't looked into the code yet to see whether it operates as a middleware with its own custom permission system or leverages Home Assistant's existing RBAC.

@nicosandller, regarding ideas, I'll follow up later with a concept that might solve this. It involves using Tap, Hold, and DoubleTap actions combined with a global switch to show, hide, or gray out (disable) options for specific users on a list. I don't know how easy can implement, but I just need to flesh out the details first and provide you with a YAML schema as concept.

EDIT : I checked the README again, and sometimes late at night you miss a few words even if you read it. 😊 Even though I haven’t dug into the code, this part caught my attention: “Service Call Interception: Automatically intercepts all Home Assistant service calls.”. That sounds a lot like a “firewall”-type middleware sitting between the user and Home Assistant Core. If that’s indeed how it works, it could potentially be fragile with future Home Assistant updates. So, based on that alone, I’d be twice as cautious about relying on this solution.

[tsioukas]

@nicosandller, can this pull #184 be applied to this request? I tried to find a way to change the options of the “hide by conditions”, but I couldn’t find a way to add user profiles.