Show rotating category name in event summary if pickup is scheduled

[kylehakala]

Breaking change

This update changes the text that appears in the event summary (i.e., event title) of a scheduled Ridwell Pickup event. Now, the event will display your chosen Rotating Category for that pickup instead of displaying "scheduled", such as "Ridwell Pickup (Holiday Lights)". Automations which rely on the presence of the word "scheduled" in the calendar event summary may need to be updated to use the other event states (any of: skipped, notified, initialized, or unknown).

Proposed change

Having calendar events created by the Ridwell integration is very helpful for seeing a birds eye view of "pickup events" happening soon. When a user has scheduled/opted-in to a pickup, the calendar event summary will now display the name of specific "Rotating Category" that you selected for that pickup event, such as "Ridwell Pickup (Electronics)" or "Ridwell Pickup (Holiday Lights)" instead of just "Ridwell Pickup (scheduled)". If it is not opted-in to (not scheduled), the event states will show in the event name as they currently do (skipped, notified, etc).

With the main difference between each pickup being the Rotating Category (notwithstanding optional add-ons), having the Rotating Category item name displayed on the event summary can offer more "ambient utility" to the calendar event summary when quickly glancing at the information (or when sending a notification about the upcoming calendar event), without needing to parse through the additional attributes and creating separate entities to track that.

Type of change

• [ ] Dependency upgrade
• [ ] Bugfix (non-breaking change which fixes an issue)
• [ ] New integration (thank you!)
• [x] New feature (which adds functionality to an existing integration)
• [ ] Deprecation (breaking change to happen in the future)
• [x] Breaking change (fix/feature causing existing functionality to break)
• [ ] Code quality improvements to existing code or addition of tests

Additional information

• This PR fixes or closes issue: fixes #
• This PR is related to issue:
• Link to documentation pull request:

Checklist

• [x] The code change is tested and works locally.
• [x] Local tests pass. Your PR cannot be merged unless tests pass
• [x] There is no commented out code in this PR.
• [x] I have followed the development checklist
• [x] I have followed the perfect PR recommendations
• [x] The code has been formatted using Ruff (ruff format homeassistant tests)
• [ ] Tests have been added to verify that the new code works.

If user exposed functionality or configuration variables are added/changed:

• [ ] Documentation added/updated for www.home-assistant.io

If the code communicates with devices, web services, or third-party tools:

• [ ] The manifest file has all fields filled out correctly.
  Updated and included derived files by running: python3 -m script.hassfest.
• [ ] New or updated dependencies have been added to requirements_all.txt.
  Updated by running python3 -m script.gen_requirements_all.
• [ ] For the updated dependencies - a link to the changelog, or at minimum a diff between library versions is added to the PR description.
• [ ] Untested files have been added to .coveragerc.

To help with the load of incoming pull requests:

• [ ] I have reviewed two other open pull requests in this repository.

[home-assistant[bot]]

Please take a look at the requested changes, and use the Ready for review button when you are done, thanks :+1:

Learn more about our pull request process.

[home-assistant[bot]]

Hey there @bachya, mind taking a look at this pull request as it has been labeled with an integration (ridwell) you are listed as a code owner for? Thanks!

Code owner commands

Code owners of ridwell can trigger bot actions by commenting:

• @home-assistant close Closes the pull request.
• @home-assistant rename Awesome new title Renames the pull request.
• @home-assistant reopen Reopen the pull request.
• @home-assistant unassign ridwell Removes the current integration label and assignees on the pull request, add the integration domain after the command.
• @home-assistant add-label needs-more-information Add a label (needs-more-information, problem in dependency, problem in custom component) to the pull request.
• @home-assistant remove-label needs-more-information Remove a label (needs-more-information, problem in dependency, problem in custom component) on the pull request.

[bachya]

I'm struggling to understand the value of this. How do we know that all users want to show the rotating pickup in the calendar title name? What if, say, some users want to show the number of extras they've purchased in the title?

I'm totally open to discussing!

[kylehakala]

What if, say, some users want to show the number of extras they've purchased in the title?

Good question! The use case I’m solving for value-wise is to see the category shown in the upcoming events list I have on a standalone dashboard display I have sitting in my kitchen.

I suppose I was viewing this as a change that would be applicable to all pickups, since every scheduled pickup always has a [nonzero] rotating category included, so the usefulness of seeing the extra info would be available to all subscribers/users regardless if they pay for additional add-ons. But I like your idea of having other choices of what is displayed in the event title!

Do you think it would better to reshape this as a user-selectable dropdown with options of what could be placed in the title? I’m not sure how common it is to include add-ons in a pickup to say with much confidence how that would be best implemented as a choice. I’d love to hear your thoughts on how this could be made more flexible!

[bachya]

Do you think it would better to reshape this as a user-selectable dropdown with options of what could be placed in the title? I’m not sure how common it is to include add-ons in a pickup to say with much confidence how that would be best implemented as a choice. I’d love to hear your thoughts on how this could be made more flexible!

I like that idea: make a configuration dropdown that allows you to pick how the title is displayed in the calendar. 👍🏻

[kylehakala]

Just touching base on this; I’ve got an implementation I’m testing out locally that rides atop the options flow for customizing the calendar title name.

I’ll try to get something pushed up here for feedback in the coming week or so once I get a chance to tidy it up a bit.

[kylehakala]

So I've been running this for about a month now (and the recently updated ConfigFlow changes for the last couple days as well) and it's been unremarkable and stable.

I ran through a handful of iterations on various parts of this, and I almost certainly have some mental burn-in on thing. Happy to pull it back and make modifications if I ended up implementing something in a weird way here. Odds are it's probably just something that is just sitting there waiting for fresh eyes to catch it.

I opted for putting this inside of the OptionsFlow—it felt a lot more like a rarely modified config option and not so much something that is worthy of displaying on the services info page.

Cheers!

[emontnemery]

@kylehakala This PR can't be merged without tests which cover the options flow. Please hit the "Ready for review"-button when you've added tests 👍

[github-actions[bot]]

There hasn't been any activity on this pull request recently. This pull request has been automatically marked as stale because of that and will be closed if no further activity occurs within 7 days. If you are the author of this PR, please leave a comment if you want to keep it open. Also, please rebase your PR onto the latest dev branch to ensure that it's up to date with the latest changes. Thank you for your contribution!