| Summary | Allow shared calendars to be the default calendar |
| Queue | Kronolith |
| Queue Version | Git master |
| Type | Enhancement |
| State | Rejected |
| Priority | 1. Low |
| Owners | |
| Requester | thomas.jarosch (at) intra2net (dot) com |
| Created | 08/20/2013 (4336 days ago) |
| Due | |
| Updated | 04/02/2014 (4111 days ago) |
| Assigned | 08/20/2013 (4336 days ago) |
| Resolved | 04/02/2014 (4111 days ago) |
| Milestone | |
| Patch | No |
State ⇒ Feedback
1) No way to mark an event as read only. Obviously can be worked
around by limiting only to calendars that the user has PERMS_EDIT to,
but what happens when a shared calendar's permissions are changed so
that the user no longer has access to edit events, but can still read
them? There is no way to indicate this to the client. The only
solution would be to verify permissions on each synchronized calendar
on every sync request.
2) The same event can be represented in multiple calendars. I.e., two
calendars can have an entry that represent the same UID. This happens,
e.g., when a meeting request sent from one user is added to another
calendar. If the event organizer has access to both calendars, and an
event is edited on his/her client - which copy of the event is
modified on the server? What about if the non-organizer edits the
event on their calendar? That change would be picked up by ActiveSync
since you are synching the calendar, so essentially, a non-organizer
would have the ability to change the organizer's copy of the event.
What happens if an external meeting request is accepted on two
calendars the user can sync? They are two separate copies of the same
event. The result of editing the copy on the client would be
undefined. Not to mention that the organizer field in current code is
bound to horde usernames, so from the POV of the ActiveSync client the
current user would be seen as the organizer, and thus editing the
event and sending out itips would be allowed.
tried to attach the patch to the bug report.
Probably an error was logged in horde.log file of bugs.horde.org
Priority ⇒ 1. Low
Type ⇒ Enhancement
Summary ⇒ Allow shared calendars to be the default calendar
Queue ⇒ Kronolith
Milestone ⇒
Patch ⇒ No
State ⇒ Assigned
I had the need to support a shared calendar as default calendar. Other
apps like nag already allow you to configure a shared tasklist to be
the default tasklist of a user.
Attached is my local patch as a basis for discussion. Jan mentioned on
IRC there was a reason why the default calendar can only be a local
one but he couldn't remember the details ad-hoc.
So far it seems to work fine. I'm sure I'm missing something ;)
oh, looking at the my patach again, the getByUid() part is a bugfix
for kronolith IMHO.
Otherwise kronolith would behave differently than the other apps.
Thomas