[Design] [Proposal] Recurring events in Cosmo

[Mimi Yin]

Can we hide the end-date and behind the scenes generate more  
occurrences on the fly *if and when* the user browses ahead in the  
calendar?

Perhaps we don't need to worry about editing the end-date for the  
TargetUser Release, since we're not supporting full editing anyway?

But I agree with Priss that a 1 year end-date would be worrisome to  
users...and wouldn't make much sense for annual events either.

Mimi

On Apr 18, 2006, at 2:53 PM, Priscilla Chung wrote:

> Yes I understood about the temporary work around. I agree setting a  
> default end date should be ok for 0.2. Just to be clear, this  
> restriction should not be in place for the target user release.
>> * In Chandler and/or Scooby, just make the "recurrence end date"  
>> UI element default to one year in the future. If the user wants to  
>> change it, they can.
> What happens when a user deletes the end date? Would the user not  
> be able to submit the event? Personally one should be able to  
> delete the end date as certain events just don't have end dates,  
> ie. birthdays.
>> No hidden anything, no changes to Cosmo, just a temporary  
>> workaround until the Cosmo issue is sorted, which it might be soon  
>> anyway.
> To BCM's point, the best thing may be to do nothing in code, until  
> the bug is investigated. In the meantime we document the bug and  
> and document the work around, ie. to add an end date to recurring  
> events.
>
> -Priscilla
> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
>
> Open Source Applications Foundation "Design" mailing list
> http://lists.osafoundation.org/mailman/listinfo/design