| mlaurent | |
| smartins | |
| vkrause |
| KDE PIM |
This is an elaborate hack to get multi-calendar support.
All uid's in memory calendar are namespaced by calendar, so the same event
can appear multiple times in various Akonadi::Collection's.
This was so far not handled at all.
A cleaner solution would either move all this functionality into KCalCore::Calendar,
since this patch breaks most operations that work with uid's directly,
or make the the MultiCalendar a wrapper for several KCalCore::Calendars.
| No Linters Available |
| No Unit Test Coverage |
please give a use case
For kolab, in kde4 and kde3 there's Incidence::schedulingId() and X-KDE-LIBKCAL-ID, which should be good enough for most use cases, or maybe it isn't.. lets discuss it first :)
| src/calendar.h | ||
|---|---|---|
| 613 | s/isValid/contains | |
The use case is you have one event with multiple attendees and this is reflected that this event takes part inside multiple akonadi collections. If you display these akonadi collections together inside korganizer, the current behaviour is, that memorycalendar randomly selects one item ( the first that populates) and all other are not inserted into the calendar.
This is quite buggy, becuase the events in the differnet collection can have different status, becuase maybe someone has already accepted an invitation and one other has declined the event... Thats why the underlying structure must give the GUIs (korganizer) the possibility to work with the different akonadi items through the calendar interface.
the SchadulingId isn't used by our current design anymore because:
The main reason is that akonadi/calendar has one ETM for all collections, so the uid of one event must be valid for all collection. This holds for one collection, But doens't hold if you have any shared calendar, and you copy events to it.
Hopyfully this explains the need of a additional layer of changing the uid.