Hi Grant, >> When a master event doesn't have any occurrences, it isn't included in >> masterEvents, causing it to >> not appear in the calendar. > > So, I guess this is happening because the code that splits up events > into recurring/non-recurring events in the calendar probably just checks > for rruleset -- i.e. is inconsistent with osaf.pim's definition of > masterEvents. So, could one approach be to remove the use of > 'occurrences' in the filter for masterEvents? e.g. could the filter be > (suitable translated into findValue(s) calls: > > event.rruleset is not None and event.occurrenceFor is None
That seems like a good plan. > To be picky, for non-recurring events, the master and occurrence are one > and the same. It does seem odd to require that at least one occurrence > be generated. However, IIRC reminders don't work so well if we don't > generate the occurrence. Perhaps that's a reason to try to ensure that. > (It could be done around line 300 of Sharing.py, where we already have > to work around other issues in importing/updating recurring events). Yup, I think we need to generate at least one occurrence if there's an alarm. Sincerely, Jeffrey _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ Open Source Applications Foundation "chandler-dev" mailing list http://lists.osafoundation.org/mailman/listinfo/chandler-dev
