Ticket #9302 (closed PLIP: duplicate)
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: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: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: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: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: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: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