[FR] Additional actions

[FezVrasta]

Is your feature request related to a problem? Please describe.
I have a door lock I want to protect with a PIN, with this card I can ask for a PIN but then I have to press the card/button again to actually unlock the door.

Describe the solution you'd like
It would be nice if the card allowed to specify an action to execute after the card is unlocked. It would be useful also to have an option to instantly lock the card again once locked.

Describe alternatives you've considered
I can't think of anything.

Additional context

[ildar170975]

Sorry, this will only have sense for a row-like element on Entities card, or an element on a Glance card, or a Tile card, or a Button card. All these examples have ONE tap_action associated with an element.
But the restriction-card have a wider use - it can protect cards/stacks which may have many inner cards/elements with plenty of tap_actions defined.
So, implementing your FR will bring an inconsistency.
Will not close this FR, but honestly it will be not prioritized from my side.

[FezVrasta]

Thanks for the reply. I think adding these options could have wider use cases. They are pretty generic, it could be used to toggle some state to alter the dashboard.

For the "auto lock" it could be tied to a Boolean entity so that for example a card can be auto unlocked while at home and locked while away or stuff like that.

[ildar170975]

There are at least 2 possible scenarios:

1. Unlocking causes a calling of a tap-action defined for an element behind the restriction card. See my objections above.
2. Unlocking causes a call of OWN actions defined for the restriction card. Is it more interesting for you?

[FezVrasta]

I think unlocking should call an arbitrary action, not a "click" on the restricted elements. It would be way more flexible

[FezVrasta]

For clarity, I'm thinking about this:

type: custom:restriction-card
restrictions:
  pin:
    code: 1234
    exemptions:
      - user: wifeid
      - user: adminid
  unlock_action:
    # List of actions to perform when unlocking
    - action: call-service
      service: homeassistant.turn_off
      service_data:
        entity_id: boolean.your_lock_entity  # Entity representing the lock state
    # Additional service call for unlocking, e.g., logging or notifications
    - action: call-service
      service: another_service
      service_data:
        parameter: value  # Additional parameters for the service
  lock_action:
    # List of actions to perform when locking
    - action: call-service
      service: homeassistant.turn_on
      service_data:
        entity_id: boolean.your_lock_entity  # Entity representing the lock state
    # Additional service call for locking, e.g., logging or notifications
    - action: call-service
      service: another_service
      service_data:
        parameter: value  # Additional parameters for the service
  lock_state:
    entity_id: boolean.your_lock_entity  # Boolean entity to monitor for locked/unlocked state

This would make this card extremely flexible imho

[ildar170975]

Could be like:

type: custom:restriction-card
actions:
  on_locked:
    ... some options
  on_unlocked:
    ...
  on_error:
    ...

where:
-- on_locked is executed after a card is locked;
-- on_unlocked is executed after a card is successfully unlocked (by a user or by a condition OR only by a user - to be discussed);
-- on_error - if a wrong password is inputted (could be useful?)

As for "some options" entries (see above) - to be discussed; could be just a script and possible variables for simplicity.
And of course could be a list of entries (like in your example).

As for your lock_state option - not clear what you wish to achieve with that?
To be used just as a flag "a card is locked"?
Note that that boolean entity may be changed outside which probably SHOULD cause the card to be locked/unlocked. But in this case it becomes same as already available conditions for locking/unlocking.

[FezVrasta]

As for your lock_state option - not clear what you wish to achieve with that?

I was thinking of that as a flexible way to allow to instantly lock a card after it's locked, if needed. But maybe you could provide a service to lock/unlock a card by its id maybe so it's safer as it would require the pin to unlock it.

[ildar170975]

Let’s move that lock_state into another FR, please create a separate issue for it. We will discuss possible approaches there. I will copy paste our discussions about this feature there.
As for actions - I will think about a possible implementation when will have an access to PC. No promises that it will be implemented soon, unfortunately.

[ildar170975]

Also, are you agree with my proposals about actions, any ideas?