[Chandler-dev] generating an occurrence

[Grant Baillie]

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