On Apr 19, 2006, at 8:32 AM, Mimi Yin wrote:
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?
Per Mimi's point the end user release or "dogfood scooby calendar"
will focus on read only access and less on users editing events.
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
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Open Source Applications Foundation "Design" mailing list
http://lists.osafoundation.org/mailman/listinfo/design
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Open Source Applications Foundation "Design" mailing list
http://lists.osafoundation.org/mailman/listinfo/design
