Closed davesmeghead closed 1 year ago
This architecture issue is old, stale, and possibly obsolete. Things changed a lot over the years. Additionally, we have been moving to discussions for these architectural discussions.
For that reason, I'm going to close this issue.
../Frenck
Context
The current Alarm Control Panel Entity has a code_format property to return a single value to the frontend that determines whether to display a keypad in the frontend or not. The keypad allows the user to enter the code to arm/disarm an alarm panel.
Proposal
As HA now has Users, the frontend for the alarm panel needs to be updated to include the ability for different users to see the keypad or not. This proposal adds an additional property called code_format_per_user to get a dictionary of user identities so the frontend can differentiate particular users to display a keypad or not. This discussion is related to a PR I created and a comment by frenck to start a discussion thread here This proposal leaves the existing mechanism in place and adds this as a new feature. All other use of the existing entity will still work after this change, This proposal is an override feature, if the current (frontend) users id is in the dictionary returned by the new code_format_per_user property then the value is used (this is the same value as returned by the existing code_format).
Example use
This will be used when a tablet or touch display is used on the wall in the hallway of a house, this could be logged in as a user that always displays a keypad. The other "normal" users on their mobile phones may not want the keypad shown.
Change to Frontend
This proposal needs to be in place before a change is made in the Frontend. For your information I have included the main change in the frontend hui-alarm-panel-card.ts (but there are a few other changes as well)
The returned value from code_format_per_user would be a dictionary of the user id mapped to the same values used by code_format i.e FORMAT_TEXT, FORMAT_NUMBER or None
Alternatives
Alternatives to this mechanism that I considered:
Consequences
There are no risks associated with this change, it will be made backwards compatible with all other alarm panel entities/integrations. The existing code_format property will remain as it is now.