Hi, Jeffrey
Comments inline.
--Grant
On 1 Oct, 2006, at 14:55, Jeffrey Harris wrote:
Hey Grant,
I experienced the disappearing events bug today, I think I've
figured out what's happening. I'm not sure if you know about this
so I thought
I'd bounce it off you.
It appears that when recurring events are imported, their first
occurrence isn't reliably being created.
Probably this has to do with that _share_importing flag that gets set
on all items during import (and which disables a bunch of the usual
updating that happens when you change recurrence-related attributes).
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
?
It seems like there are two ways to fix this, we could do a better
job of generating that first occurrence, or better, now that
masters and occurrences are disjoint, we could just set a flag on
masters, and filter on that flag. That would probably be more
reliable.
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).
--Grant
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Open Source Applications Foundation "chandler-dev" mailing list
http://lists.osafoundation.org/mailman/listinfo/chandler-dev
