Different sets of availability

How to use GitHub

• Please use the 👍 reaction to show that you are interested into the same feature.
• Please don't comment if you have no relevant information to add. It's just extra noise for everyone subscribed to this issue.
• Subscribe to receive notifications on status change and new comments.

Availability

The option to provide availability and based on that toggling DND is very helpful in my daily usage. However there is a problem with the availability times as for me they quite differ over the year and adjusting them every time is quite cumbersome. But for me they are easily groupable and being able to define different sets of availability and then being able to pick which one should be active atm would already solve it.

My life example

• normal work:
  • 6:00 - 7:30
  • breakfast + bringing kids to kindergarten/school
  • 8:30 - 12:45
  • fetching kids + lunch
  • 14:00 - 17:00
    • tuesday only until 16:00 due to kids soccer and similar activities
    • friday not available due to kids soccer and similar activities
  • family time
  • 20:30 - 22:00
  • recovery time
• kindergarten/school holidays
  • breakfast
  • 7:30 - 12:15
  • lunch
  • 13:00 - 15:30
  • family time
  • 20:30 - 22:00
  • recovery time
• Conference /contributor weeks:
  • 8:00 - 0:00
  • recovery time

Problem

As you can see reconfiguring this multiple times per month can be quite cumbersome:

• From conf to work it's 8 time pickers per day (6 for friday) => 38 times picking an hour + minute slot and then outside to close the picker
• Work to school holiday => delete 1 slot and adjust 4 time pickers per day => 20 times picking
• One week later: school holiday to work => adjust 4 time pickers per day and add a new slot with 2 time pickers per day => 30 time pickers

So every time there is school holidays for a week, I wonder if ~50 time picker selections are worth it, or if I just leave my colleagues hanging with not being available/responsive although they checked my availability in the calendar and the user status right before reaching out.

Solution proposal

As far as I can see we store the data in oc_properties with {urn:ietf:params:xml:ns:caldav}calendar-availability. Not sure if that would allow to have {urn:ietf:params:xml:ns:caldav}calendar-availability-backup1 things in parallel and when switching the availability we simply do an update on the propertyname to enable/disable another set?

Other solutions I considered

I configure the availability once store the propertyvalue into files locally and am using browser dev tools/curl to send a manipulated requests using the availability property I want for this week

Start by tracing how {urn:ietf:params:xml:ns:caldav}calendar-availability is stored in oc_properties and how the availability setting is selected and applied. The issue proposes multiple named availability sets that can be switched without repeatedly editing time ranges; done should include a workable selection mechanism and preserved sets.