Ticket #10886 (closed PLIP: fixed)

Opened 6 years ago

Last modified 2 years ago

plone.app.event - new eventtype for plone

Reported by: thet Owned by: thet
Priority: major Milestone: 5.0
Component: General Version: 4.1
Keywords: event, recurring, date Cc: deo, tom_gross, plip-advisories@…, vitaliypodoba@…, eleddy, ken.wasetis@…, trs22, keul

Description (last modified by thet) (diff)

Proposer: Johannes Raggam
Seconder: None as yet

Motivation

The current event type is in need of a major overhaul. The intention of this PLIP is to provide a new event engine by a major refactoring and reimplementation:

  • [a] Encapsulation and independence: All event related code should reside in a seperate package (splitted into other packages, where appropriate). Plone should be least dependend on plone.app.event. Best would be that one can deinstall this feature completly.
  • [b] Archetypes and Dexterity awareness: plone.app.event should provide the ATEvent content type (factored out from ATContentTypes) and also Dexterity behaviors, which can be used in Dexterity types.
  • [c] Standards compliancy: the iCalendar / RFC5545 standard is wonderful flexible, so plone.app.event should provide support for it by allowing ical exports. This is also available for the current ATContentType based implementation, but plone.app.event aims to improve it. Sometime it might also support iCalendar import and Plone could also act as a caldav server.
  • [d] Recurring events support based on the RFC5545 standard.
  • [e] A modern dateinput widget.
  • [f] Features like whole-day-events.
  • [g] Timezone support.

Proposal & Implementation

Encapsulation and independence: plone.app.event provides the Archetypes based type and the Dexterity behaviors via two other subpackages in that package: at and dx. Based on installed features (Products.ATContentTypes or plone.dexterity, respectively), eather of those subpackages are included via the zcml:condition statement. The calendar and event portlets were moved from plone.app.portlets into plone.app.event, where they belong semantically - thus improving encapsulation and independence. The calendar portlet was completly refactored. The functionality of the CalendarTool (portal_calendar) was reimplenented. Important settings from the calendar-controlpanel are now available in the event configlet. Since the calendar portlet was the only consumer of the CalendarTool, the CalendarTool, the calendar controlpanel and the dependency to Products.CMFCalendar can be dropped. The new plone.formwidget.datetime implements archetypes and z3cform based widgets, so the old datetime widget can be dropped. Python-dateutil provides recurrence calculations based on the RFC5545 standard - plone.formwidget.recurrence provides a awidget for recurrence and Products.DateRecurringIndex an appropriate index as a drop-in replacement for Zope's DateIndex. The iCalendar package was improved and is now used for plone.app.event to provide icalendar serialization. The timezone support is based on the pytz package. Plone has to define a portal timezone now and every event can define another timezone, if wished. User timezones are planned. Whole day events get their starttime set to 0:00 and endtime set to 23:59:59 - thats should be feasable in most cases (excluding any scientific events...).

Deliverables

  • plone.app.event: ATEvent, DX behavior, Configlets, iCal export, timezone support, util functions.
  • plone.event: Recurrence calculations, util functions, base timezone support. Might be dropped, if we decide to provide everything in plone.app.event.
  • Products.DateRecurringIndex: Drop in replacement for DateIndex with recurrence support. Every occurence of an event gets an index entry, so events for a specific date range can easily be searched.
  • plone.formwidget.datetime: Datetime widgets for Archetypes and z3cform based on JQuery utils Dateinput.
  • plone.formwidget.recurrence: Recurrence widget, which generates an RFC5545 compatible recurrence definition string.
  • icalendar: iCalendar serialization/deserialization library.

Plone.app.event adapted branches of core packages:

  • Products.CMFPlone
  • Products.ATContentTypes
  • plone.app.portlets
  • Products.PloneTestCase (not needed, if Plone drop's its dependency on it)

Risks

  • Third party packages which rely on ATCT internals may break (although ATCT should still provide BBB imports from plone.app.event).
  • Third party packages which rely on portal_calendar may break.

Documentation

Code

Use:  https://github.com/plone/plone.app.event

For the other packages, look into:  https://github.com/plone/plone.app.event/blob/master/sources.cfg

For the PLIP buildout, use:  https://github.com/plone/buildout.coredev/blob/4.3/plips/plip10886-event-improvements.cfg

Notes

This PLIP is an update of  http://dev.plone.org/plone/ticket/9302

Sprints, where plone.app.event was developed:

  • Snowsprint 2007, Vorarlberg, Austria (Dateable, a predecessor of plone.app.event).
  • Cathedral 2010 sprint, Cologne, Germany (start of the package plone.app.event based on vs.event and ATEvent).
  • DZUG Tagung 2010, Dresden, Germany.
  • Plone Conference 2010 Bristol, United Kingdom.
  • Artsprint 2011 Vienna, Austria.
  • Buschenschanksprint 2011, Berghausen, Austria.
  • BarSprint 2011, Ljubljana, Slovenia.
  • Artsprint 2012 Vienna, Austria.

Change History

comment:1 Changed 6 years ago by vincentfretin

I suppose we should close #9302 as duplicate.

comment:2 Changed 6 years ago by vincentfretin

Johannes, you forgot to add "An updated Calendar portlet that uses the recurrence index." in the deliverable.

Finally we don't use collective.calendarwidget at all. We use collective.js.jqueryui which ship with all jqueryui (except the tabs plugin which conflicts with plone.app.jquerytools), it includes the functions needed for the i18n of the datepicker and will contain soon a new theme more integrated with sunburst.

comment:3 Changed 6 years ago by vincentfretin

(In [38685]) Copied PLIP cfg for event improvements (refs #10886)

comment:4 Changed 6 years ago by deo

  • Cc deo added

comment:5 follow-up: ↓ 6 Changed 6 years ago by vincentfretin

jquerui-min.js has a size of 192KB.

I think collective.js.jqueryui should be splitted into two packages:

  • collective.calendarwidget which contains UI Core, the datepicker widget, the date i18n functions, the theme. Total of 47KB.
  • all other plugins in collective.js.jqueryui: 144KB

And only collective.calendarwidget will be needed in a default Plone installation.

comment:6 in reply to: ↑ 5 ; follow-up: ↓ 7 Changed 6 years ago by hannosch

Replying to vincentfretin:

jquerui-min.js has a size of 192KB.

I think collective.js.jqueryui should be splitted into two packages:

  • collective.calendarwidget which contains UI Core, the datepicker widget, the date i18n functions, the theme. Total of 47KB.
  • all other plugins in collective.js.jqueryui: 144KB

And only collective.calendarwidget will be needed in a default Plone installation.

47kb for a date picker is still a lot.

I think the framework team decided earlier that jqueryui is not an acceptable dependency as a whole. So it might be good to explain in more detail which date picker solutions have been considered and what their pros/cons are.

comment:7 in reply to: ↑ 6 Changed 6 years ago by ajung

The datepicker JS code is only 3KB or so + some CSS (which is currently 21KB but obviously containing a lot of unrelated styles) + a language specific JS file with the translation (1KB)...so with some cleanup and language-specific loading of JS files it should be possible to bring the complete datepicker code to under 10KB or so.

Replying to hannosch:

Replying to vincentfretin:

jquerui-min.js has a size of 192KB.

I think collective.js.jqueryui should be splitted into two packages:

  • collective.calendarwidget which contains UI Core, the datepicker widget, the date i18n functions, the theme. Total of 47KB.
  • all other plugins in collective.js.jqueryui: 144KB

And only collective.calendarwidget will be needed in a default Plone installation.

47kb for a date picker is still a lot.

I think the framework team decided earlier that jqueryui is not an acceptable dependency as a whole. So it might be good to explain in more detail which date picker solutions have been considered and what their pros/cons are.

comment:8 follow-up: ↓ 9 Changed 6 years ago by ajung

I think there are some open points and risks with the recurring support (however I don't have a detailed overview over recurrence issues (Johannes knows best)). I think it should be safe to ship Plone 4.1 with plone.app.event as ATEvent replacement (w/o recurrence support) and address recurrence support in Plone 4.2. So recurrence should not block the acceptance of this PLIP.

comment:9 in reply to: ↑ 8 Changed 6 years ago by thet

Replying to ajung:

I think there are some open points and risks with the recurring support (however I don't have a detailed overview over recurrence issues (Johannes knows best)). I think it should be safe to ship Plone 4.1 with plone.app.event as ATEvent replacement (w/o recurrence support) and address recurrence support in Plone 4.2. So recurrence should not block the acceptance of this PLIP.

Well, i go with that. Recurrence should not block the acceptance of this PLIP. The more important step is to synchronize ATContentTypes and plone.app.event and get it fully working.

But recurrence support can be implemented in a somehow transparent way. Reindexing would be the major migration step, as far as i can see. But i guess, some other difficulties will arise.

comment:10 Changed 6 years ago by thet

  • Description modified (diff)

comment:11 Changed 6 years ago by esteele

Your PLIP has been accepted for consideration for Plone 4.1.

Framework Team voting on this PLIP was: Alec +0 Craig +1 Elizabeth +0 Laurence +1 Martijn +1 Matthew +1 Rob +1 Ross --

The initial implementation deadline for your PLIP is October 1st, 2010. The Framework Team would certainly appreciate you finishing beforehand so that they may begin evaluating it as soon as possible. Announce its readiness here once your implementation is ready for review.

comment:12 Changed 6 years ago by tom_gross

  • Cc tom_gross added

comment:13 follow-up: ↓ 14 Changed 6 years ago by ldr

Implementation note. FWT is against adding a jQuery-UI dependency to Plone at this time.

comment:14 in reply to: ↑ 13 ; follow-ups: ↓ 15 ↓ 16 Changed 6 years ago by tom_gross

Replying to ldr:

Implementation note. FWT is against adding a jQuery-UI dependency to Plone at this time.

Is it because of the size, or are there other reasons? There is a standalone implementation of the datepicker-widget, which could be used.

comment:15 in reply to: ↑ 14 Changed 6 years ago by tom_gross

Replying to tom_gross:

Replying to ldr:

Implementation note. FWT is against adding a jQuery-UI dependency to Plone at this time.

Is it because of the size, or are there other reasons? There is a standalone implementation of the datepicker-widget, which could be used.

 http://marcgrabanski.com/articles/jquery-ui-datepicker

comment:16 in reply to: ↑ 14 Changed 6 years ago by esteele

Replying to tom_gross:

Replying to ldr:

Implementation note. FWT is against adding a jQuery-UI dependency to Plone at this time.

Is it because of the size, or are there other reasons? There is a standalone implementation of the datepicker-widget, which could be used.

Steve McMahon has a good summary on his blog, here:  http://www.stevemcmahon.com/steves-blog/tools

comment:17 Changed 6 years ago by cah190

  • Cc plip-advisories@… added

comment:18 Changed 5 years ago by piv

  • Cc vitaliypodoba@… added

comment:19 Changed 5 years ago by thet

  • Description modified (diff)

PLIP ready for review. For an updated information what was done, please see:  https://svn.plone.org/svn/plone/buildouts/plone-coredev/branches/4.1/plips/plip10886-event-improvements.txt

comment:20 Changed 5 years ago by eleddy

some how there are two tickets with this number. review here: (In 46012) initial review for event improvements, refs #10866

comment:21 Changed 5 years ago by cah190

(In [46346]) Review for PLIP 10886. Refs #10886

comment:22 follow-up: ↓ 23 Changed 5 years ago by thet

about the current status:

vincent fretin, rok garbas and me attended at the artsprint [1] in vienna in the first week of february this year and made some good progress:

  • fixed many bugs, mentioned in the plip reviews
  • optimized archetypes.datetimewidget behavior
  • discussed some plans, how to further improve the package and code

structure

  • partly migrated the test infrastructure to plone.(app.)testing
  • solved the timezone troubles with Zope's DateTime (by using pytz and

introducing a timezone field for the event object and storing DateTimes in UTC only...)

  • prepared some javascript testing stuff to be used for

js.jquery.recurrenceinput recurrence widget.

there are still some things to be done - see the current todo list [2].

[1]  http://www.coactivate.org/projects/artsprint2011 [2]  https://svn.plone.org/svn/plone/plone.app.event/trunk/TODO-artsprint.txt

comment:23 in reply to: ↑ 22 Changed 5 years ago by thet

sorry for the square-brackets-links

comment:24 Changed 5 years ago by vincentfretin

Please see #9353 and #11564 for timezone issues.

comment:25 Changed 5 years ago by eleddy

  • Cc eleddy added

comment:26 Changed 5 years ago by esteele

  • Milestone changed from 4.1 to 4.2

Moving to 4.2 milestone. I want this one. :)

comment:27 follow-up: ↓ 28 Changed 5 years ago by thet

status update:

vincent fretin, rok garbas and johannes raggam attended at the artsprint [1] in vienna in the first week of february 2011 and made some good progress:

  • fixed many bugs, mentioned in the plip reviews
  • optimized archetypes.datetimewidget behavior
  • discussed some plans, how to further improve the package and code

structure

  • partly migrated the test infrastructure to plone.(app.)testing
  • solved the timezone troubles with Zope's DateTime (by using pytz and

introducing a timezone field for the event object and storing DateTimes in UTC only...)

  • prepared some javascript testing stuff to be used for

js.jquery.recurrenceinput recurrence widget.

there are still some things to be done - see the current todo list [2].

[1]  http://www.coactivate.org/projects/artsprint2011 [2]  https://svn.plone.org/svn/plone/plone.app.event/trunk/TODO-artsprint.txt

comment:28 in reply to: ↑ 27 Changed 5 years ago by eleddy

Thanks for all the work on this! Let us know when it's ready for another review. This PLIP is long overdue :)

comment:29 follow-up: ↓ 31 Changed 5 years ago by vincentfretin

Hi,

I sold the recurrence functionality to a customer, so I quickly needed something functional. I continued the plone.formwidget.reccurence widget, it serializes and deserializes the rfc string perfectly now, but it's not internationalized and there is no automated tests on it. The widget will be normally reimplemented by Rok for the next sprint ( http://www.coactivate.org/projects/buschenschanksprint-2011/project-home)

The plone calendar portlet is not functional with recurring events. Instead of using the portlet I use Solgema.fullcalendar which now supports recurring events from plone.event. This works really well.

There are issues with the timezone field on the event content type, it is handled after the start and end dates, so it always default to the portal timezone. So for now, I only enable one timezone for the portal to not have weird issues.

I will put a Plone 4.1b1 + plone.app.event site on production the next week with the current work status.

comment:30 Changed 5 years ago by ctxlken

  • Cc ken.wasetis@… added

comment:31 in reply to: ↑ 29 Changed 5 years ago by thet

thank you vincent! awesome work. i'm looking forward for the buschenschanksprint.

comment:32 Changed 5 years ago by eleddy

hey guys - we are looking at a feature freeze on June 30th. Are you guys close to being ready for reviews yet?

comment:33 Changed 5 years ago by rossp

FWT has approved a delay of one week for the implementation. So happy coding and have the implementation done next Monday!

comment:34 Changed 5 years ago by eleddy

Any update here? We are considering pushing this to 4.3 if there are a lot of changes.

comment:35 follow-up: ↓ 36 Changed 5 years ago by thet

hey, sorry for replying late... i'm going to summarize the status tomorrow in more detail.

but yes, please push it to 4.3. we've made a lot of progress, but not ready yet. we did a lot of refactoring, because we rethought some design decisions and want to ship a solid product.

we want to push out a usable release canditate *before* any plip implementation deadline of 4.3 - i promise. so people can use it in the wild and report bugs.

comment:36 in reply to: ↑ 35 Changed 5 years ago by eleddy

Replying to thet:

hey, sorry for replying late... i'm going to summarize the status tomorrow in more detail.

but yes, please push it to 4.3. we've made a lot of progress, but not ready yet. we did a lot of refactoring, because we rethought some design decisions and want to ship a solid product.

we want to push out a usable release canditate *before* any plip implementation deadline of 4.3 - i promise. so people can use it in the wild and report bugs.

Glad to hear it! No worries. Look forward to the details and we'll just plan on reviewing it later.

comment:37 Changed 5 years ago by thet

i wrote a blog article which gives more details about the ideas and the status of plone.app.event. see here:  http://bluedynamics.com/articles/johannes/whats-up-plone.app.event

comment:38 Changed 5 years ago by eleddy

  • Milestone changed from 4.2 to 4.3

thanks for the update! looking forward to reviewing the changes for 4.3. whenever its ready, we are ready to do reviews!! just change the status.

comment:39 Changed 5 years ago by trs22

  • Cc trs22 added

One of my users has a case where they have a recurring event that happens at multiple locations. For example:

  • Date A, Location X
  • Date B, Location Y
  • Date C, Location Z

After reading this PLIP and the accompanying documentation, it doesn't look like the RFC specifies any date/location correlation, so this may not be within the scope of the implementation.

However, I figured I'd present the idea to see if anyone else had a similar use case, or if it struck a chord with anyone!

Thanks!

--Tim

comment:40 Changed 5 years ago by rossp

The FWT has wrapped up work on 4.2 and can start work on 4.3 whenever we have PLIPs to review. So can you as proposers or implementers please check in on your PLIPs and let us know what the status is and when we can expect issues to be addressed and implementations complete so we can review them for merge in 4.3.

comment:41 Changed 4 years ago by thet

  • Description modified (diff)

comment:42 Changed 4 years ago by thet

We had much progress in the last months here. Lennart worked on a recurrence widget and an alternative Recurring Date Index, Rok adapted the icalendar library, i dropped CalendarTool and CMFCalendar dependency, refactored calendar portlet and recently i began developing dexterity behaviors (out of original PLIP scope, but a need for a current project).

The biggest stuff left to do now is:

  • Finishing plone.formwidget.datetime (tests, z3cform integration, localization).
  • Tests (new ones, refactoring old ones).
  • Removing/deprecating legacy code from CMFPlone, including tests (CalendarTool, datetime widget, calendar controlpanel from plone.app.controlpanel, etc.).

I expect this PLIP to be ready in Q1, 2012.

Last edited 4 years ago by thet (previous) (diff)

comment:43 Changed 4 years ago by thet

  • Description modified (diff)

comment:44 Changed 4 years ago by eleddy

  • Priority changed from minor to major
  • Status changed from new to confirmed
  • Version set to 4.1

how is this going guys?

comment:45 Changed 4 years ago by thet

  • Description modified (diff)

comment:46 Changed 4 years ago by thet

there is an api-refactoring branch, which nearly ready to be merged with master notable changes:

  • all generic interfaces moved into plone.event
  • IEventAccessor for setting/getting attributes on IEvent implementations (archetypes and dexterity)
  • roman joost's changes (occurrence traverser, occurrence type, IEventAccessor for occurrences)

it's just that i need some more tests and while writing tests i figured out, that the timezone handling in archetypes ATEvent is completly messed up. i want to fix this first...

i think most changes are backwards compatible, except the forthcoming switch from AnnotationStorage for attributes back to storing attributes directly on the context. i think it's better to store attributes directly on the context, because 1) it's faster and needs less ZODB object loads 2) some functionality depends on it (e.g. DateRecurringIndex wasn't indexing the occurrences of DX based types, because it couldn't find any recurrence definitions on the context itself... wohoo! the IEventRecurrence behavior doesn't use annotation storage any more. the switch for the other behaviors is going to come).

for reference:

 https://github.com/collective/plone.app.event/tree/api-refactoring

 https://github.com/collective/plone.event/tree/api-refactoring

Last edited 4 years ago by thet (previous) (diff)

comment:47 Changed 4 years ago by eleddy

hey guys - the fwt things that this won't make it to the 4.3 release. If it can be ready for review by June 30th we'll review it and give it a try for 4.3 but otherwise we are pushing to 4.4 (or whatever is next). thoughts on this change?

comment:48 Changed 4 years ago by davisagli

  • Component changed from Infrastructure to General

comment:49 Changed 4 years ago by eleddy

  • Milestone changed from 4.3 to 4.4

comment:50 Changed 4 years ago by thet

hey, i think 4.4 is more realistic than 4.3. in the last weeks we had some significant progress coming for at least 4 different companies/projects. but there are still some issues to be solved until we can submit it for review.

comment:51 Changed 3 years ago by seanupton

+1 on 4.4 target.

What's the thinking on (assuming we have parity between at and dx implementations, there is minor work to do that I can do) shipping the content type for 4.4 based on plone.app.event.dx.event instead of AT version? What blocks this choice as a longer-lasting investment (migrations, something else)?

comment:52 Changed 3 years ago by davisagli

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

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

PLIP buildout:  https://github.com/plone/buildout.coredev/blob/4.2/plips/plip10886-event-improvements.cfg

Feedback:

  • 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 blocker.)
  • 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 it.
  • 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 settings?)
  • Figure out what to do with the old event implementation

Conclusion:

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.

comment:53 Changed 3 years ago by thet

  • Description modified (diff)

comment:54 Changed 3 years ago by thet

thanks for reviewing!

this tickets' docs weren't up-to-date and wrongly referenced the old plone.app.event location in collective and the 4.2 buildout file instead of the 4.3. didn't you use the new one  https://github.com/plone/buildout.coredev/blob/4.3/plips/plip10886-event-improvements.cfg ?

comment:55 Changed 3 years ago by davisagli

I used the one in the 4.3 branch, and accidentally mistyped it as 4.2 above.

By the way, supton pointed out that there's a branch of plone.app.users ( https://github.com/plone/plone.app.users/tree/plip10886-event-improvements) to add the per-member timezone setting, which is not included in plone.app.events' sources.cfg currently.

comment:56 Changed 3 years ago by thet

ah, i forgot about this one.

i'll integrate it tomorrow.

comment:57 Changed 3 years ago by keul

  • Cc keul added

comment:58 Changed 3 years ago by esteele

  • Status changed from confirmed to closed
  • Resolution set to fixed

Merged for Plone 4.4

Nice work!

comment:59 Changed 3 years ago by thet

wow, it's merged! thanks for it.

i'll have a look tomorrow and see, if there are some leftovers to do.

comment:60 follow-up: ↓ 61 Changed 3 years ago by rochecompaan

  • Status changed from closed to reopened
  • Resolution fixed deleted

On behalf of the UI team I did a review of plone.app.event on the latest coredev buildout, ie on the 4.4 branch. Awesome work, the functionality looks great! The UI needs attention in quite a few places though. I don't have solutions for all the issues, we are still exploring UI solutions to some of the problems in the UI team. Some issue below are low hanging fruit and should be easy to fix though.

  1. When installing a new Plone site without selecting any extensions, there is no event type. I would expect the plone.app.event dexterity extension to be installed by default.
  1. Not convinced we should have the calender portlet installed by default.
  1. Bold styling for month days in Calendar portlet is too overbearing.

Editing an event:

  1. One can specify start and end time even if "Whole day" is checked.
  1. The description for the recurrence widget reads "RFC5545 compatible recurrence definition". I guess this must still be fixed.
  1. The checkbox combined with "Does not repeat" is confusing UI. One would expect that ticking a checkbox is a confirmation of what is shown on the label, so a user will click on "Does not repeat" if the user really does not want the event to repeat. Instead, what happens now, is that the label toggles and the event now repeats with 10 occurrences by default.
  1. I'm not convinced we should have 10 daily repeats for an event by default. It shouldn't really be necessary to show 10 daily repeats just to show the user that the event can repeat, the UI for creating repeating events should be obvious enough. I'll try and think of better solution.
  1. Batch navigation is shown "[1 - 10]", even if the batch is smaller than 10.
  1. The date format (dd/mm/yy) for the "Until" input in the recurrence widget is not really human readable. Rather format with full month name, including the week day, eg Saturday January 05, 2013.
  1. If I edit the start date of the event, the recurrence widget doesn't update the start of the occurrence.
  1. The heading style for "Repeat", "Selected Dates" and "Add" in the recurrence overlay is inconsistent with the heading styles in public.css. #888888 is too subdued, just use plain black. I think the bottom border helps to separate the sections so keep that on the heading style.

Event view:

  1. The view of occurences in the "View" of the event needs some love. The first few events is shown as a bulleted list and then the gap is indicated with 3 dots below each other and then suddenly the final event is shown. There doesn't seem to be a way for a user with only view permission to see all occurrences on an event. I don't think actual occurrences should be shown in the "eventDetails" view, describing the occurrence would be much more helpful, eg "This event repeats weekly on a Wednesday for the next 10 weeks." Additionally one can perhaps link to "Show all occurrences" which pops up and overlay showing a view with all occurences.

comment:61 in reply to: ↑ 60 Changed 3 years ago by esteele

Replying to rochecompaan:

Roche, Thanks for looking at this. Since it's now merged, can we create new tickets for each of those items you've mentioned, reffing this ticket. That should increase the chances of all of them getting fixed.

comment:62 Changed 3 years ago by thet

thanks rochecompaan for the review! i've moved your issues to  https://github.com/plone/plone.app.event/issues/77 so that i have everything on one place.

comment:63 Changed 3 years ago by esteele

  • Milestone changed from 4.4 to 5.0

The Framework Team has decided to move on to Plone 5. Updating milestones accordingly.

comment:64 Changed 2 years ago by davisagli

  • Status changed from reopened to closed
  • Resolution set to fixed

This has been merged for Plone 5!

Note: See TracTickets for help on using tickets.