feat: config flow with YAML import and global settings (phase 1, draft for #60) - #136
feat: config flow with YAML import and global settings (phase 1, draft for #60)#136lollox80 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
|
Apologies for taking so long to reply, was away sailing for a long time, and any spare dev time spent on signalk fixes and improvements. Plus I couldn't find my original phasing doc I'd worked on, so have tried to reconstruct it, based on memory, and also going back over your findings and ideas https://github.com/rhizomatics/supernotify/blob/main/design/roadmap/configflow_approach.md |
I've updated this approach now to minimise the amount of the 'legacy' notification setup mechanisms used, without completely changing it into a Notify Entity integration, which I don't yet trust. The new code is on https://github.com/rhizomatics/supernotify/tree/configflow |
|
First beta now at https://github.com/rhizomatics/supernotify/releases/tag/v2.0.0-beta1 I've pulled in as much of your pull request as I could |
|
Manually merged with changes |
|
Thanks for pulling this in, and for the fast turnaround on the betas today. I've just installed v2.0.0-beta6 on my production instance (YAML config with ~20 deliveries and 25 scenarios) and the import path works cleanly on the first try: the mirrored entry is created with only the scalar settings, event_selection/diagnostics come through as "NONE"/"ERROR" strings, housekeeping_time as "00:00:00", and the deprecated_yaml repair is correctly not raised since my YAML still carries deliveries and scenarios. notify.supernotify stays owned by the YAML platform as documented, all my automations and dashboards are untouched. Two tiny things I noticed while testing, neither blocking: The user step form shows supernotify/templates as the template path placeholder, while the code default is /config/templates/supernotify (TEMPLATE_DIR). Looks like a translation/constant mismatch. Happy to open small PRs for either if you'd like — otherwise I'll keep them on my list. I'll put the Phase 2 thoughts (deliveries/scenarios in the UI) in a separate issue so they don't get lost in a closed thread. |
|
I'd have added a changelog per beta if I'd known there was anyone else trying them! By beta13 the config changes a bit, mainly to have sections to organize Archive Options and some HA weirdness about how they work. Also the templates path now gets mkdirred and is relative to working directory to be consistent with other paths. So far it's been working fine on my system, with good variety of notification types. Going to let it run a while longer before promoting. Thanks for the feedback, I'm hoping some of that fixed already by the later betas |
2 participants
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.