Ticket #230 (new Defect)
Declined events block time for auto-accept resources
| Reported by: | cdaboo@… | Owned by: | cdaboo@… |
|---|---|---|---|
| Priority: | 3: Important | Milestone: | Later |
| Component: | Calendar Server | Severity: | Other |
| Keywords: | Cc: | ||
| Port: |
Description
If a resource has a declined event stored in its calendar, the server will not allow another event to be booked at the same time via auto-accept, even though the time slot is effectively free.
Strictly speaking this is the correct iCalendar behavior - a "declined" event by itself does block time. To not block time it should either be marked as cancelled or have transparency set.
If iCal caused the declined event to be left in the calendar it should have set transparency on it.
Change History
comment:3 Changed 5 years ago by wsanchez@…
I'm having a hard time thinking up a use case where one would want an declined event to block out time. I think the iCalendar spec may be dropping the ball here.
comment:4 Changed 5 years ago by wsanchez@…
- Priority changed from 2: Expected to 3: Important
- Milestone changed from 1.2 to Later
No technically a server bug here; if the client does the right thing, everything is good. I'm wondering whether the server should play an enforcement role here.
Deferring until we know we have clients misbehaving.
12/6/07 5:28 PM Wilfredo Sanchez:
If it is declined, it there a reason to mark it as busy on any calendars?
12/10/07 3:13 PM Wilfredo Sanchez mailto:wsanchez@…:
ie. isn't transparency irrelevant if it's declined?
12/10/07 6:48 PM Cyrus Daboo mailto:cdaboo@…:
No. iCalendar says nothing about declined status affecting transparency. I believe iCal does mark declined events as transparent - which is the correct behavior - but that was a relatively recent change. It could be the event causing this problem was manually declined before that fix.