New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Allow chaining contexts #21028
Allow chaining contexts #21028
Conversation
LOL, you should not check the 3rd checker then. |
self.hass.bus.async_fire(EVENT_AUTOMATION_TRIGGERED, { | ||
ATTR_NAME: self._name, | ||
ATTR_ENTITY_ID: self.entity_id, | ||
}, context=trigger_context) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Shall use context=context
here?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
No, we want the automation triggered to be with the new context, that way we will be able to attach automation metadata to the context.
70b936c
to
7514fde
Compare
As resulted from a forum feedback: * [Context was indeed originally introduced to trace the cause of a change](home-assistant/core#15674) * [The user_id is used for permission checking] (https://developers.home-assistant.io/docs/auth_permissions/#the-context-object) * [Automations generate a child-context such that their actions are not run with user access](home-assistant/core#21028)
Description:
When an automation is triggered, we were re-using the context from the event that triggered the automation. However, this has the unintended side effect that the automation will run with the permissions of the user triggering the automation.
It also would have caused issues in the future when doing machine learning, because although the result of an automation should be linked to the triggering event, it should not be fully attributed. It is the automation that is doing things now.
So to cover this partial relationship I'm introducing a
parent_id
forContext
. This will allow a context to optionally point at a previous context that caused this context to start, without conflating the concerns that the actions of the automation get attributed to the triggering event.The first thing being done with the context is firing an
automation_triggered
event, so that it's clear that it's an automation.We need to store the context parent ID in the database. I want to do that, but I want to group a couple of more migration changes together (like increasing event type size), so have commented it out for now.
Checklist:
tox
. Your PR cannot be merged unless tests passIf the code does not interact with devices: