feat: config flow with YAML import and global settings (phase 1, draft for #60)#136
Draft
lollox80 wants to merge 2 commits into
Draft
feat: config flow with YAML import and global settings (phase 1, draft for #60)#136lollox80 wants to merge 2 commits into
lollox80 wants to merge 2 commits into
Conversation
Implements the first phase of the UI configuration discussed in rhizomatics#60: - config_flow.py: user step (guided setup for a fresh install), one-shot YAML import (existing setups appear in the UI unchanged), and reconfigure flow for global settings. Single entry enforced. - __init__.py: config entry lifecycle. A YAML-imported entry only mirrors settings for the UI (the legacy notify platform keeps owning notify.supernotify - no duplicate service). A UI-created entry loads the legacy notify platform via discovery, so a user with no YAML still gets notify.supernotify. - notify.py: async_get_service accepts config from the legacy YAML path or from a config entry via discovery_info; when starting from YAML it triggers the one-shot import. Non-JSON-serializable YAML artifacts (e.g. Jinja Template objects) are converted to their source strings before being stored in the entry (regression-tested). - strings.json + 11 translations for the new steps. - tests: config flow (user/import/reconfigure/serialization) and entry lifecycle. Deliveries, scenarios, recipients and cameras stay YAML-only in this phase; the flow only covers environment/global settings, by design, so the phasing can follow the plan in rhizomatics#60.
for more information, see https://pre-commit.ci
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Motivation
First concrete step for #60. SuperNotify is currently YAML-only, which HA flags as legacy and which raises the entry barrier for new users. This draft implements the smallest phase that moves the basics to the UI without touching deliveries, scenarios or the
notify.supernotifycontract - so the phasing discussion in #60 can happen on real code.Opened as a draft on purpose: happy to reshape it to match your phased plan whenever you get a chance to share it.
Changes
userstep (guided setup for a fresh install, no YAML required), one-shot YAML import (existing setups show up in the UI unchanged), and reconfigure flow for the global settings (paths, archive, dupe check window/policy, discovery toggles). Single entry enforced (single_config_entry+ unique_id guard).notify.supernotify, so there is no duplicate service and zero behaviour change for existing users. A UI-created entry loads the legacy notify platform via discovery, so a user with no YAML still getsnotify.supernotify.async_get_servicenow accepts config from the legacy YAML path or from a config entry viadiscovery_info; when starting from YAML it triggers the one-shot import. YAML artifacts that are not JSON-serializable (e.g. JinjaTemplateobjects produced by schema validation) are converted to their source strings before being stored in the entry - otherwise the first entry update crashes withType is not JSON serializable: Template(regression-tested).config_flow: true,single_config_entry: true.test_config_flow.py(user / import / reconfigure / serialization regressions) andtest_init.py(imported-entry lifecycle, options-update reload).Out of scope (by design, next phases)
Deliveries, scenarios, recipients and cameras stay YAML-only in this phase. The import keeps them in
entry.optionsuntouched so later phases can migrate them incrementally.Testing
pytest-homeassistant-custom-component(user/import/reconfigure flows, serialization and update-listener regressions).notify.supernotifyunchanged, reconfigure form pre-filled and localized; deliveries keep working (Alexa announce verified end-to-end).ruff check/ruff format/codespellclean with the repo config.