Skip to content
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

Merged
merged 2 commits into from Mar 1, 2019
Merged

Allow chaining contexts #21028

merged 2 commits into from Mar 1, 2019

Conversation

balloob
Copy link
Member

@balloob balloob commented Feb 13, 2019

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 for Context. 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:

  • The code change is tested and works locally.
  • Local tests pass with tox. Your PR cannot be merged unless tests pass
  • There is no commented out code in this PR.

If the code does not interact with devices:

  • Tests have been added to verify that the new code works.

@awarecan
Copy link
Contributor

so have commented it out for now.

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)
Copy link
Contributor

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?

Copy link
Member Author

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.

@balloob balloob merged commit 52f337e into dev Mar 1, 2019
@ghost ghost removed the in progress label Mar 1, 2019
@delete-merged-branch delete-merged-branch bot deleted the context-parenting branch March 1, 2019 18:08
@balloob balloob mentioned this pull request Mar 20, 2019
akloeckner added a commit to akloeckner/data.home-assistant that referenced this pull request Mar 10, 2024
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)
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants