Added homeassistant.disable_user + homeassistant.enable_user

[alec-pinson]

Description

These options allow you to enable/disable users, i.e. toggle this setting:

Motivation and Context

I have home assistant in my car, it can open my gate. I don't want someone to steal my car and be able to press the open gate button... so I lock the account and unlock it based on certain automations.

How has this been tested?

I tested on my own environment and the user switches between Active enabled and disabled.

Screenshots (if appropriate):

Types of changes

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to not work as expected)
• Other

Checklist

• My code follows the code style of this project.
• My change requires a change to the documentation.
• I have updated the documentation accordingly.

[coderabbitai]

📝 Walkthrough

Walkthrough

Adds two new Home Assistant services, homeassistant.disable_user and homeassistant.enable_user, implemented as SpookService classes that accept one-or-more user_id values, validate and fetch users via the Home Assistant auth API, and toggle each user's is_active state.

Changes

Cohort / File(s)	Summary
User Management Services custom_components/spook/ectoplasms/homeassistant/services/disable_user.py, custom_components/spook/ectoplasms/homeassistant/services/enable_user.py	New SpookService classes for disable_user and enable_user. Each defines domain = DOMAIN, service name, and schema requiring user_id (list). Handlers iterate over user_id values, fetch users with hass.auth.async_get_user(), raise HomeAssistantError for missing/system users, and call hass.auth.async_update_user(..., is_active=...).
Service Definitions custom_components/spook/services.yaml	Added two service entries: homeassistant_disable_user and homeassistant_enable_user, each exposing a user_id text selector.
Documentation documentation/users.md, documentation/actions.md, documentation/_toc.yml	New documentation page for user management and added action docs and TOC entry describing the enable/disable user services, payload examples, and usage guidance.

Estimated code review effort

🎯 3 (Moderate) | ⏱️ ~25 minutes

Suggested labels

new-feature

Suggested reviewers

• frenck

Poem

🐰 I hopped through code to flip a switch,
Enable, disable — neat and quick,
IDs gathered, checks so slick,
A tiny service, a clever trick,
The Spook rabbit gives a cheerful click.

🚥 Pre-merge checks | ✅ 3

✅ Passed checks (3 passed)

Check name	Status	Explanation
Title check	✅ Passed	The title accurately and concisely describes the main change: adding two new Home Assistant services for disabling and enabling users.
Description check	✅ Passed	The description is directly related to the changeset, explaining the purpose of the new services and providing relevant context about the use case and testing performed.
Docstring Coverage	✅ Passed	Docstring coverage is 100.00% which is sufficient. The required threshold is 80.00%.

_{✏️ Tip: You can configure your own custom pre-merge checks in the settings.}

✨ Finishing touches

• 📝 Generate docstrings

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Post copyable unit tests in a comment

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[coderabbitai]

Actionable comments posted: 3

🤖 Prompt for all review comments with AI agents

Verify each finding against the current code and only fix it if needed.

Inline comments:
In `@custom_components/spook/ectoplasms/homeassistant/services/enable_user.py`:
- Around line 26-33: The async_handle_service handler currently enables users
from call.data["user_id"] without checking for system accounts; update
async_handle_service to fetch each user via hass.auth.async_get_user, then if
user is None raise HomeAssistantError as before, but also check
user.system_generated and either raise HomeAssistantError (or skip with a logged
warning) when true to prevent modifying internal HA service accounts, only
calling hass.auth.async_update_user(user, is_active=True) for
non-system_generated users.

In `@documentation/actions.md`:
- Around line 395-405: Add the missing MyST anchor label for the "User: Disable"
heading so the cross-reference from the "User: Enable" section resolves;
specifically, insert the anchor `(user-disable)=` immediately before the `##
User: Disable` heading (the pair of headings referenced are the `## User:
Disable` and `## User: Enable` entries) so the `[](`#user-disable`)` link in the
enable section points to the correct target.

In `@documentation/users.md`:
- Around line 56-62: The Jinja2 template snippet contains invalid constructs for
Home Assistant templates—specifically using await and
hass.auth.async_get_users()—so remove the entire code block that iterates with
`{% for user in (await hass.auth.async_get_users()) %}` and replace it with
either (a) no template block (delete the snippet) or (b) a clearly labelled
alternative that uses the REST API or a backend Python script to list users
(e.g., note “Use Home Assistant REST API or a Python script to fetch users;
templates cannot call hass.auth or use await”). Ensure the replacement text
explicitly states templates cannot access hass or async functions and points
readers to the REST API/Python script option.

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud

[alec-pinson]

Made changes requested by CodeRabbit, also tested

[coderabbitai]

Actionable comments posted: 2

🤖 Prompt for all review comments with AI agents

Verify each finding against the current code and only fix it if needed.

Inline comments:
In `@custom_components/spook/ectoplasms/homeassistant/services/enable_user.py`:
- Around line 26-36: The service currently only blocks system-generated accounts
in async_handle_service (uses hass.auth.async_get_user and
hass.auth.async_update_user); add a guard that also prevents acting on the owner
account by checking the user's owner flag (e.g., user.is_owner) and raising a
HomeAssistantError with a clear message like "Cannot enable the owner account"
(and similarly "Cannot disable the owner account" in disable_user.py) before
calling async_update_user so both enable_user.py and disable_user.py
consistently protect the owner.

In `@documentation/users.md`:
- Around line 54-62: The template example under "Developer Tools → Template" is
misleading because it iterates states.person and therefore only shows
person-linked users and will yield state.attributes.user_id as None for person
entities without linked users; update the copy to either (A) qualify the
sentence that it only lists user IDs for person entities (mentioning
states.person and state.attributes.user_id) and warn that standalone
auth/API/integration users are omitted, or (B) remove the template block
entirely and instead rely on the previously described UI path; modify the
introductory sentence on Line 54 accordingly to reflect the chosen approach.