[PLIP-Advisories] [Plone development workspace] #10886: plone.app.event - new eventtype for plone

Change notifications for Plone PLIPs on Trac. plone-plip-advisories at lists.plone.org
Tue Jan 8 18:59:48 UTC 2013

#10886: plone.app.event - new eventtype for plone
  Reporter:  thet     |      Owner:  thet
      Type:  PLIP     |     Status:  confirmed
  Priority:  major    |  Milestone:  4.4
 Component:  General  |    Version:  4.1
Resolution:           |   Keywords:  event, recurring, date

Comment (by davisagli):

 PLIP 10886: plone.app.event, new event type for Plone

 Framework Team Review by David Glick, 2013-01-08

 PLIP buildout:


 - Creating a site with the AT profile, then adding a recurring event seems
 to work. Checking 'whole day event' hides the time fields. Defaulted to my
 current timezone. The recurring event shows up correctly when viewing the
 event and in the calendar and event port lets.
 - plone.formwidget.datetime needs to do 12-hour (am/pm) input when
 appropriate for the current locale. I am working on a pull request to add
 this since it doesn't seem fair to ask Europeans to implement it. :)
 - (Reported as issue 70) The recurrence widget is confusing. It has a
 checkbox labeled 'Does not repeat." Clicking the checkbox changes the text
 to "repeats every Daily". This would be clearer if there were 2 radio
 buttons labeled 'does not repeat' and 'repeats'
 - It's nice that the recurrence widget shows future occurrences, but it
 would be easier to confirm they're correct if they were shown as a mini
 calendar with days highlighted rather than a list of textual dates. (Not a
 - It's mildly annoying that entering an 'until' date in the recurrence
 widget doesn't offer the same date picker as elsewhere.
 - (Reported as issue 69) I tried making a recurring "New Year's Day"
 event. When I opened the recurrence widget and set it to yearly, the date
 defaulted to Dec. 31. It should be set to Jan. 1 (which is the date I had
 selected in the event form.). Even after I changed it to Jan. 1, the
 "Selected dates" shows future occurences of Dec. 31. After saving and re-
 editing though, it is correct as Jan. 1.
 - (Reported as issue 71) I opened the ical export for my New Year's Day
 event in iCal, where it shows up as a 2-day event on Jan 1 and 2.
 - It would be nice if selecting a start date would force the end date to
 be after the start date, and selecting an end date would force the start
 date to be before the end date. This is validated on form submission so
 not a serious issue; just would be a usability improvement.
 - (Reported as issue 72) On the US west coast my timezone is not being
 detected correctly. I get this warning on startup: "WARNING plone.event
 The timezone PST is not a valid timezone from the Olson database or pytz.
 Falling back to UTC."
 - collective.elephantvocabulary is used to make sure that timezones stored
 on events can still be selected if the admin removes that timezone from
 the portal's list of available timezones. Is this still necessary given
 the changes in z3c.form 2.9.0 re missing terms?
 - s/formated/formatted/
 - It looks like the code has some support for per-member timezones, but I
 don't see this on the member preferences page. Is this feature incomplete?
 - Values are stored as Zope DateTimes for the Archetypes type and Python
 datetimes for the Dexterity type. Stored as UTC with a separate timezone
 field and converted to the right zone when accessed. Excellent.
 - Is there a compelling reason to have plane.event in addition to
 plane.app.event? Should the former just be merged into the latter?
 - I'm not exactly sure why plone.formwidget.datetime was created instead
 of fixing the existing widgets, but it has good test coverage so I'll take
 - Includes sphinx documentation -- yay!  The code is also very well
 internally documented (docstrings/comments) and seems well-tested, though
 I still need to check exact coverage.

 Things I still need to review:

 - performance implications of DateRecurringIndex
 - security
 - check items from Liz's and Craig's earlier reviews
 - check migration path
 - run tests and check coverage

 Integration steps needed when the merge happens:

 - Move DateTime monkey patch to DateTime or CMFPlone
 - Make Plone depend on plone.app.event and hide its profiles.
 - Add upgrade step to convert old events.
 - Link documentation into developer manual (including note that it applies
 to Plone 4.3 and above).
 - Remove the Calendar control panel. (Maybe the new Event Settings control
 panel should be called Calendar for consistency, since it has similar
 - Figure out what to do with the old event implementation


 This isn't perfect yet, but it is really really good. I think the
 remaining issues are minor and can be addressed during integration. I
 recommend this PLIP for inclusion in Plone 4.4.

Ticket URL: <http://dev.plone.org/ticket/10886#comment:52>
Plone development workspace <https://dev.plone.org/>
Plone Enterprise Content Management System

More information about the PLIP-Advisories mailing list