-
-
Notifications
You must be signed in to change notification settings - Fork 34.2k
Add ConfigFlow to Prowl integration #133771
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
base: dev
Are you sure you want to change the base?
Conversation
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.
Hello @mgust,
When attempting to inspect the commits of your pull request for CLA signature status among all authors we encountered commit(s) which were not linked to a GitHub account, thus not allowing us to determine their status(es).
The commits that are missing a linked GitHub account are the following:
1ff6a502565d58d3a3e0675296999ef2cd7ec89c
- This commit has something that looks like an email address ([email protected]). Maybe try linking that to GitHub?.
Unfortunately, we are unable to accept this pull request until this situation is corrected.
Here are your options:
-
If you had an email address set for the commit that simply wasn't linked to your GitHub account you can link that email now and it will retroactively apply to your commits. The simplest way to do this is to click the link to one of the above commits and look for a blue question mark in a blue circle in the top left. Hovering over that bubble will show you what email address you used. Clicking on that button will take you to your email address settings on GitHub. Just add the email address on that page and you're all set. GitHub has more information about this option in their help center.
-
If you didn't use an email address at all, it was an invalid email, or it's one you can't link to your GitHub, you will need to change the authorship information of the commit and your global Git settings so this doesn't happen again going forward. GitHub provides some great instructions on how to change your authorship information in their help center.
- If you only made a single commit you should be able to run
(substituting "Author Name" and "
git commit --amend --author="Author Name <[email protected]>"
[email protected]
" for your actual information) to set the authorship information. - If you made more than one commit and the commit with the missing authorship information is not the most recent one you have two options:
- You can re-create all commits missing authorship information. This is going to be the easiest solution for developers that aren't extremely confident in their Git and command line skills.
- You can use this script that GitHub provides to rewrite history. Please note: this should be used only if you are very confident in your abilities and understand its impacts.
- Whichever method you choose, I will come by to re-check the pull request once you push the fixes to this branch.
- If you only made a single commit you should be able to run
We apologize for this inconvenience, especially since it usually bites new contributors to Home Assistant. We hope you understand the need for us to protect ourselves and the great community we all have built legally. The best thing to come out of this is that you only need to fix this once and it benefits the entire Home Assistant and GitHub community.
Thanks, I look forward to checking this PR again soon! ❤️
Please take a look at the requested changes, and use the Ready for review button when you are done, thanks 👍 |
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.
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.
Honestly, looking at this PR...
I'm not fully following the reasoning on why? As in, this integration needs to move to the UI. It would way better effort spent in putting development time into that.
../Frenck
On the practical side, I was adding the tests first to make sure I don't make things incompatible with the current setup. I wasn't too sure of how split up you normally do PRs, the developer docs seemed to encourage just adding tests as a separate PR rather than just one PR to replace the entire component (the current component is tiny, so to move it to pyprowl, change to the non legacy setup method and add ConfigFlow a will essentially be a complete rewrite), but very happy to do it all in one go if it makes it easier to review. |
…different base classes and added the reauth config flow
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.
I just checked with @jbouwh who introduced the notify entity and we agreed that ideally we have the config flow in 1 PR and add the migration to the notify entity in a followup PR.
Ok. I was attempting to support both the legacy YAML configuration at the same time as the ConfigFlow one where the YAML one would set up the legacy notify service and the ConfigFlow would do the new notify entity. And then in a later PR remove the legacy one in its entirety. But sure, I'll just change the ConfigFlow to use the legacy service. |
We should completely migrate the current yaml to a config flow and also import existing config into a config entry. I love these migrations, so happy to help |
Oh, I see, so remove the YAML config entirely and just treat it as a breaking change for those who use it? I was playing around with using the YAML config to create a ConfigFlow entry as part of the startup to help with the migration (and hopefully the users would upgrade to that version before we remove the entire YAML parsing). But then again, maybe it gets too involved if it is easier just to mention it as a breaking change. Thanks for the offer to help, it took me quite a while to get my head around the various initialization paths, so I wouldn't be at all surprised if I misunderstood something. |
Ah, just remembered why I was struggling. When using the And if I remove the Any suggestions @joostlek of how to move from the YAML to ConfigFlow without adding the new style of base class? (Or, perhaps I've misunderstood how the two initializations work, wouldn't be at all surprised if that is the case 😄 ) |
Config entries added by this PR should use the modern In follow-up PRs which implement migration from yaml to config entry, a config entry should be created per API key with a subentry for each configured notify. @mgust please reach out on Discord, I'm@emontnemery there too, if you're stuck and need some help to get the PR moving again |
…r a later PR)" This reverts commit 9105bf7.
… to allow the new ProwlNotificationService to co-exist).
) | ||
|
||
|
||
@pytest.mark.asyncio |
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.
We don't need this, we have configured pytest for asyncio. Please remove it from all tests.
@pytest.mark.asyncio | ||
async def test_send_notification(hass: HomeAssistant, mock_pyprowl_success) -> None: | ||
"""Sending a notification message via Prowl.""" | ||
prowl = ProwlNotificationService(hass, TEST_NAME, TEST_API_KEY) |
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.
Don't test this class directly. Instead, set up a config entry, then call the notify service and check that the mocked API was called. In that way, tests make sure we can set up a config entry and the config entry creates entities which are working as expected.
@@ -76,3 +84,72 @@ async def async_send_message(self, message, **kwargs): | |||
) | |||
except TimeoutError: | |||
_LOGGER.error("Timeout accessing Prowl at %s", url) | |||
|
|||
|
|||
class ProwlNotificationService(NotifyEntity): |
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.
class ProwlNotificationService(NotifyEntity): | |
class ProwlNotificationEntity(NotifyEntity): |
|
||
|
||
class ProwlNotificationService(NotifyEntity): | ||
"""Implement the notification service for Prowl.""" |
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.
"""Implement the notification service for Prowl.""" | |
"""Implement the notification service for Prowl. | |
This class is used for Prowl config entries. | |
""" |
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.
Rename to test_notify.py
to match the implementation.
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.
To ensure the PR doesn't break existing user setups, could we add tests which mimic prowl set up via configuration.yaml?
Ideally, add those tests in a preliminary PR.
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.
I did, but Frenck suggested we add the ConfigFlow first. (#133771 (review))
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.
yaml setup should still work (via import) after migrating to a config flow. With the tests we can ensure nothing breaks.
I suggest to start with a PR (before his one) that adds tests for the YAML setup.
After switching to discovery the YAML config can be passed via discovery during the entry setup.
The same config then can be used to setup the entity.
The import ensures a smooth migration.
A repair issue should shown as long the YAML is configured.
"config": { | ||
"step": { | ||
"user": { | ||
"description": "Enter name of Prowl key and the API key.", |
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.
Perhaps we can avoid repeating "key" here? For example by using:
"description": "Enter name of Prowl key and the API key.", | |
"description": "Enter the Prowl API key and its name.", |
Just a suggestion, perhaps the "name" can be explained differently, too.
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.
Hmm, fair shout. Maybe "Identifier" might clearer here. "Enter the Prowl API key and an identifier for it."?
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.
I don't know about the workflow to obtain the API key and the name the user should enter here. I'm just a translator so I check if the string is easy to understand for translation in Lokalise where we don't see any additional information.
Perhaps you can describe where to get them by adding a few words. This should make clear if you should also replace "name" with "ID" or "Identifier".
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.
The identifier/name is just so the user can have multiple API keys simultaneously (In case they have several users that need different notifications). It isn't used in the calls to the Prowl service. It'd correspond to the "name" parameter in the YAML config.
I suggest we add the config flow first, and add a |
"""Get the Prowl notification service.""" | ||
return ProwlNotificationService(hass, config[CONF_API_KEY]) | ||
return LegacyProwlNotificationService(hass, config[CONF_API_KEY]) |
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.
May be we can deprecate the legacy notify service, and start a repair flow, when the legacy service is still being used?There is a helper you can use:
core/homeassistant/components/notify/repairs.py
Lines 12 to 53 in b52a248
@callback | |
def migrate_notify_issue( | |
hass: HomeAssistant, | |
domain: str, | |
integration_title: str, | |
breaks_in_ha_version: str, | |
service_name: str | None = None, | |
) -> None: | |
"""Ensure an issue is registered.""" | |
if service_name is not None: | |
ir.async_create_issue( | |
hass, | |
DOMAIN, | |
f"migrate_notify_{domain}_{service_name}", | |
breaks_in_ha_version=breaks_in_ha_version, | |
issue_domain=domain, | |
is_fixable=True, | |
is_persistent=True, | |
translation_key="migrate_notify_service", | |
translation_placeholders={ | |
"domain": domain, | |
"integration_title": integration_title, | |
"service_name": service_name, | |
}, | |
severity=ir.IssueSeverity.WARNING, | |
) | |
return | |
ir.async_create_issue( | |
hass, | |
DOMAIN, | |
f"migrate_notify_{domain}", | |
breaks_in_ha_version=breaks_in_ha_version, | |
issue_domain=domain, | |
is_fixable=True, | |
is_persistent=True, | |
translation_key="migrate_notify", | |
translation_placeholders={ | |
"domain": domain, | |
"integration_title": integration_title, | |
}, | |
severity=ir.IssueSeverity.WARNING, | |
) |
For some examples on how to use it:
https://github.com/home-assistant/core/pull/118855/files
To implement the priority option, you could either add this to the option flow (follow up PR), en extra entity, or a subentry flow that allows to configure priority.
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.
Oh, neat, that sounds like a great way to do the actual migration. I'll do that in a follow-up PR once I've managed to get this one through. :)
…ocstring tweaks, removed unneeded asyncio from pytest
Proposed change
Planning to modernise the Prowl component by moving to use pyprowl and give it a ConfigFlow UI rather than the legacy YAML config. As the component seems unmaintained and legacy, I am starting with adding tests for the existing code.
Type of change
Additional information
N/A
Checklist
ruff format homeassistant tests
)If user exposed functionality or configuration variables are added/changed:
If the code communicates with devices, web services, or third-party tools:
Updated and included derived files by running:
python3 -m script.hassfest
.requirements_all.txt
.Updated by running
python3 -m script.gen_requirements_all
.To help with the load of incoming pull requests: