Ticket #9302 (closed PLIP: duplicate)

Opened 7 years ago

Last modified 6 years ago

Improving the event type with recurrence, etc.

Reported by: regebro Owned by: ajung
Priority: minor Milestone: 4.1
Component: General Version:
Keywords: calendar, recurrence Cc: regebro@…, natea@…, steve@…, kaeru, plip-advisories@…, schiele, massimo

Description (last modified by ajung) (diff)

Overview

The current event type is in need of a major overhaul. The datetime widgets are hard to use, and makes it hard to enter such things as all day events. Recurrence is a recurring feature request, that has been solved many times.

Proposal

Many of these things have been done in vs.event by Andreas Jung. It uses a better datetime widget (with potentially full i18n support and support for different date formats), and has fields for recurrence. In addition vs.event provides a more natural and working support for all-day events or events with no end date. Plone 4 would greatly benefit from these features.

 http://pypi.python.org/pypi/vs.event

To use the recurrence fields, a field with the recurring days, as implemented by several recurrence implementations already, and proven to work well, should also be implemented.

Lastly the calendar portlet needs to be updated to support recurrence.

Deliverables

  • Updates to the schema of the Event type including a new improved widget.
  • A field indexing the recurrences of an event.
  • An updated Calendar portlet that uses the recurrence index.

Migration

Adding the recurrence support field to the catalog.

Risks

Of these things, only the portlet is code that doesn't already exist, so this is mostly a question of merging existing features into Plone 4. It's therefore quite risk-free.

Change History

comment:1 Changed 7 years ago by regebro

  • Keywords calendar, recurrence added

comment:2 Changed 7 years ago by regebro

  • Description modified (diff)

comment:3 Changed 7 years ago by ajung

  • Description modified (diff)

comment:4 Changed 7 years ago by ajung

  • Description modified (diff)

comment:5 Changed 7 years ago by ajung

  • Description modified (diff)

comment:6 Changed 7 years ago by regebro

  • Cc regebro@… added

comment:7 Changed 7 years ago by albieback

Calendar portlet should also allow a restrict set of events to be shown (maybe events from current folder and below, or events with an specific category or events from a specific collection).

When you have a big site, with dozens of content editors for tens of folders, and hundreds of users, if you are not able to select the events, pretty much everyday is an event day.

comment:8 Changed 7 years ago by alecm

Is this a package that extends the functionality of the current event type, e.g. via sub-typing? Or does it simply provide a replacement type? If this affects all events, shouldn't the changes be integrated directly into ATCT, rather than through patch products shipped with Plone? Are there side-effects for custom types which inherit from ATEvent or repurpose its schema?

The package seems to provide a custom type, installed by default. It doesn't make sense, IMHO, to ship Plone with two event types (especially one as confusingly titled as VSEvent). If we were to disable the ATEvent type and re-title this new type, I think a content migration may be necessary.

comment:9 Changed 7 years ago by regebro

It currently subtypes, but the changes should be moved to ATCT, yes. We don't want two content types.

comment:10 Changed 7 years ago by nateaune

  • Cc natea@… added

comment:11 Changed 7 years ago by smcmahon

  • Cc steve@… added

Note that (at least in the US), monthly recurrence is a week/weekday pattern like "third Tuesday." It is nearly never taken to mean the day of the month (like the 17th). No matter what it's called, we need a week/weekday recurrence option.

I have some week/weekday pattern code if it would help.

comment:12 follow-up: ↓ 13 Changed 7 years ago by regebro

dateutil.rrule supports all kinds of weird recurrences, including this (and recurrings relative to easter sunday, etc) so the programming aspect of it is solved. The problem that remains is how to get all these different types of recurrences into one nice and useable UI. I think vs.event currently supports this type of recurrence, but the UI could be more intuitive. It would be a good excersize for somebody who likes Javascript to implement a recurrence widget that does this. Google Calendars UI for this is pretty good.

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

Replying to regebro:

dateutil.rrule supports all kinds of weird recurrences, including this (and recurrings relative to easter sunday, etc) so the programming aspect of it is solved. The problem that remains is how to get all these different types of recurrences into one nice and useable UI. I think vs.event currently supports this type of recurrence, but the UI could be more intuitive. It would be a good excersize for somebody who likes Javascript to implement a recurrence widget that does this. Google Calendars UI for this is pretty good.

Indeed - the Google UI supports the most common recurrence usecase. From the implementation point of view, it would requires to write a RecurrenceField (keeping all recurrence related parameters in a common datastructure) and a nice Javascript supported widget...a bit of work but not so horribly complicated.

comment:14 Changed 7 years ago by kaeru

  • Cc kaeru added

comment:15 Changed 7 years ago by erikrose

Clearing Owner field of 4.0 PLIPs so we can use it to mean "implementor". (Many of these owners were automatically assigned from choosing a Component that had a default owner.)

comment:16 Changed 7 years ago by smcmahon

  • Cc plip-advisories@… added

comment:17 Changed 7 years ago by MatthewWilkes

FWT Vote: +1

comment:18 Changed 7 years ago by rossp

FWT vote is +1, so long as this has an owner. I think there are risks in this, yet to be discovered edge cases, changes to user expectations, but I think they're exactly the kind of risks that are appropriate for a major release.

comment:19 Changed 7 years ago by davisagli

FWT vote: +1.

This seems like a big undertaking to me, but a very desired one. Given the ambitious schedule of Plone 4, I would advise you to identify which changes if any are backwards-incompatible and make sure we at least get those in, even if other parts have to be postponed to a later 4.x release. Of course if it is all done for 4.0, all the better. :)

comment:20 Changed 7 years ago by regebro

I don't see anything that is backwards incompatible.

comment:21 Changed 7 years ago by raphael

FWT vote: +1!

comment:22 Changed 7 years ago by calvinhp

FWT Vote: +1

comment:23 Changed 7 years ago by esteele

Approved by FWT vote.

comment:24 Changed 7 years ago by schiele

  • Cc schiele added

comment:25 Changed 7 years ago by esteele

  • Owner set to regebro

comment:26 Changed 7 years ago by regebro

  • Status changed from new to assigned

comment:27 Changed 7 years ago by regebro

All I have had time to do so far is create a buildout config and a branch. There is no way I'm going to have the time to implement this for the deadline.

comment:28 Changed 7 years ago by alecm

Thanks for letting us know in advance. Hopefully you'll be able to get this ready for 4.1. Unless it breaks existing APIs, it should be fine for that release.

comment:29 Changed 6 years ago by esteele

  • Milestone changed from 4.0 to 4.x

comment:30 Changed 6 years ago by massimo

  • Cc massimo added

comment:31 Changed 6 years ago by deo

Hello,

a few months ago, based on the initial feedback from regebro and ajung, I designed a prototype for the 'recurrence-widget', it's on PyPI:

 http://pypi.python.org/pypi/archetypes.recurringdate

It got some attention during the PloneConf2009, but definitively it needs more visibility so we can discuss about the good and bad UI elements in-place...

comment:32 Changed 6 years ago by davisagli

  • Owner changed from regebro to ajung
  • Status changed from assigned to new
  • Milestone changed from 4.x to 4.1

Andreas Jung proposed this (via the FWT mailing list) for 4.1.

comment:33 Changed 6 years ago by vincentfretin

Johannes created an updated version of this PLIP at #10886.

comment:34 Changed 6 years ago by ldr

  • Status changed from new to closed
  • Resolution set to duplicate

See the replacement plip #10886

comment:35 Changed 4 years ago by davisagli

  • Component changed from Infrastructure to General
Note: See TracTickets for help on using tickets.