search

home-assistant / architecture

Repo to discuss Home Assistant architecture
310 stars 101 forks source link

Add "status" as an attribute to CalendarEvents #803

Closed Olen closed 1 year ago

Olen commented 1 year ago

Context

The current calendar component does not contain a "status" field for events. https://www.rfc-editor.org/rfc/rfc5545#section-3.8.1.11

Proposal

Add a new attribute status to the CalendarEvent class. There is a PR here: https://github.com/home-assistant/core/pull/77917

Consequences

This attribute could be very useful for the frontend to distinguish between how the calendar displays e.g. "confirmed" and "tentative" events. The attribute can also be used in automations, to modify the behaviour of notifications and other actions based on the status of the event.

With this field in place, different calendar integrations could also be extended with a configuration parameter to include or exclude e.g. cancelled or declined events based on the users preferences to allow more flexibility in how HA calendars are used. If a calendar implemetation allows for read/write access to a calendar, one idea would be to set a calendar event status to confirmed, declined or cancelled based on triggers in Home Assistant.

As it only adds an attribute in accordance with RFC5545 there is very little risk. The different calendard integrations need to set the attribute, but they can be modified in their own time as the attrribute is not mandatory.
The same thing with the frontend. If a calendar card is updated to handle the attribute, it has no consequences outside of that card. The implementation just need to handle both the case where the attribute is set and if it is not set or empty.

The details of how the frontend and the different calendar integrations decide to implement the attribute is outside of the scope for this discussion. But any way they would want to use it, it is first required in the core CalendarEvent class.

allenporter commented 1 year ago

Today we don't have integrations in core that would use this because they filter out deleted events. (I mentioned this in the PR also, but offered to solicit more opinions here, thanks for following through). My assumption is that we're not going big into group calendaring system use cases here and calendar is targeted more to simple single user use cases.

As I was thinking about this more I could imagine exposing a "trash" somehow for local calendar and extendable to remote, but I don't think I see the use cases really vs delete as perm delete.

Perhaps motivating with the end user home assistant use cases can help.

decompil3d commented 1 year ago

I can see the value of exposing tentative vs confirmed statuses -- that's definitely something common in calendar systems. Especially when you receive an invitation to a new event but haven't seen or accepted yet. As such, I'm in favor of this change.

I agree with @allenporter, however, that we shouldn't show deleted or canceled events. Just expose tentative vs. busy vs. free.

@allenporter The Google calendar integration would benefit from showing tentative status too, right?

allenporter commented 1 year ago

@allenporter The Google calendar integration would benefit from showing tentative status too, right?

Yes, fair I was fixated on the cancelled status. So the use case is to omit events that I haven't accepted from automations? Yeah, you are right, that works.

allenporter commented 1 year ago

Typically architecture discussions are in https://github.com/home-assistant/architecture/discussions and not tickets (so maybe we can convert this to a discussion.)

I think it makes sense to proceed with this an approve assuming you plan to add this to core integrations like google calendar, local calendar, caldav. The current PR does not do this.

allenporter commented 1 year ago

Oh and i think we should have another member approve.