Karen,

Currently as repeating dates stand, it's a single node that stores all the calculated dates from the repeat rules correct? So for instance, when I click on that event in the cal a month later, the node view still shows the "first" date. It'd be cool to be able to reference specific instances of that repeating date. Basically, when the event is viewed, on it's page could have references to nodes, attachments, text, for that specific date, without having to create separate events for each instance.

Perhaps when one sets up a repeating date, it would actually generate that many nodes, one for each date, and there would be a table that links them all together, so you could still edit the repeat rules, enter exceptions, or delete all instances from editing any of them. Then any instance of that repeating event could be modified & referenced specifically. I think it would offer far greater flexibility.

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

KarenS’s picture

As you already figured out, you need to create other nodes for each date for this to work. I'm intending to add this feature at some point, but not before the first official release. I need to get the basic functionality of all this code working first. If there isn't already an issue for this, this can be it, but there may be another issue already. I don't have time to look, so I'll leave this open, but if you see another, mark this as a duplicate.

michaek’s picture

i'm also not sure if this is a duplicate issue, but there is some discussion on groups.d.o that's relevant to the feature request: http://groups.drupal.org/node/3598#comment-42029

stefan_seefeld’s picture

Here is another duplicate (from me): http://drupal.org/node/293912

Here is a UI I can imagine that would be in line with that:

Let users create repeated dates. In this creation phase a single node would be generated.
Then, whenever a user attempts to edit this node, he should be asked whether he wants to modify all (repeated) instances, or only one. If one, he needs to select the date, at which point a new node gets instantiated (spawned off) from the repeat set.

Specific use-case: I prepare rehearsals for the upcoming year. In a first pass I create rehearsals by a single rule: something like "every Thursday between September 5th and June 13th".
Then, some weeks later, I come back and add specific data (scores, say), but I only want to do that for a specific day.

I hope this makes sense, and gives some ideas what work-flow to use.

Many thanks !
Stefan

tyromind’s picture

Yeah that would work. I have a somewhat similar position. I have a repeating event every week - which works fine for the single-node approach most of the time for future dates, however past dates will act as archives, linking to various media related to that date. I'm also waiting for the ical import stuff to come together.

michaelschutz’s picture

subscribing - I would love to have this feature as well. I have a lot of repeating dates that would benefit from being able to edit only one instance at a time as needed.

I'd also like to say a big thank you to KarenS in advance for this (and for all your work, really). I wish I could help contribute, but I'm not a programmer by any stretch of the imagination. It pains me to ask for a feature request without being able to help be a part of the solution, since I work in an environment where I generally expect that of other people. But trust me, you don't want me trying to help with code! :) So I will leave it as a humble request for now, and will be grateful when you are able to work on it.

arcane’s picture

Hi Karen,

I would like to volunteer some of my time and energy in working on this functionality. I had hacked together a very ugly version of this in the past that worked with the Event module when I first started learning drupal. The module let you add repeating arbitrary dates associated to a parent node through the use of a popup calendar that let you select multiple dates. The module would then add those dates as nodes to trick out the event module and display in the calendar. I also had a separate table with extra properties that I wanted to display. Given that this was a total hack and could be much cleaner, and that I want to do things the right way now, I would be willing to work on some generic solution to this problem given the proper guidance.

What is the best way for me to proceed?

KarenS’s picture

The big issues with doing this that I see so far are:

1) You need a way to keep track of the nodes that are part of the same repeat -- like the table Event Repeat uses with a repeat id and a node id and an entry for each node created. It could be a separate table or might be a 'parent' date node with multiple values like the current date repeat nodes that doesn't go on the calendar itself, but just is used to store the nids of the related nodes.

2) We may need a new date type rather than trying to squeeze all the new functionality into the existing type. Or we may need a 'parent' type that creates the repeats and stores the repeating information and links to the nodes, and a 'child' type for the nodes that are created. A module might be the way Feed API works -- I've been working on patches to that to get ical parsing and date mapping into it -- but it has two content types, one where you set up a node that holds all the feed parameters and another content type for the resulting nodes (or the resulting nodes can be added to an existing content type). Anyway, that may be the right sort of framework for this.

3) We need a way to update/edit/delete the repeating nodes, with a way to keep common information synched up and to be sure we don't destroy data when repeat rules change in a way that would remove one or more dates. This last task has been one of the biggest problems that Event Repeat has -- it's quite hard to do. Again, Feed API has a way of doing this that maybe we can use, it allows you to click a button to update or delete the feed nodes.

The more I work with Feed API, the more I think a lot of what we will need is there. Maybe we should just think of a repeat as a special kind of feed? The other possible module is nodereference, where we are creating a node that has references to all its repeating nodes, and we could maybe use the nodereference module to do some of our work.

Anyway, that's as far as I've gotten.

shaisachs’s picture

KarenS and arcane -

I'd like to work on this too, and plan to dedicate some cycles in the near future.

My first draft idea is to create a simple solution to generate all of the necessary nodes when the repeating event is first created; the user will have no opportunity to go back and edit those generated nodes as a group later. That should be easy enough with hooks, I guess the main bit of trickiness will be in suppressing the repeating display of the first node. Any thoughts on that? In any case, obviously, this solution would have to be improved later on, but at least it would be a start.

In terms of a long-term solution, I think it's something like this: each node with a date field can be associated with a repeating rule. A "repeating rule" isn't a node per se, it's just an abstract object specifying a pattern of repetition.

When a user creates a node with a repeating date, what she is actually doing is creating both the node and the repeating rule, with a relationship between the two.

There can then be a variety of ways to generate nodes (aside from the first node) from that repeating rule - all at once when the series is first created, with a one-month look-ahead window in cron, through a simple button somewhere, etc. Furthermore, there can be options for how those nodes are generated: Is the body copied from the originating node? How about the other fields? etc.

When a user edits any node generated from the repeating rule, she has the opportunity to edit the details for the rule. This is a bit deceptive, in that it makes the user think that the repeating rule somehow "belongs" to the node, but it conforms to pretty well-established UI behavior a la Google Calendar, Outlook, etc. There will have to be some sort of way to ask the user whether to apply changes to future events, leave them alone, or what, as well.

I hope all of this makes sense! Seems to be quite a thorny nest of issues here...

shaisachs’s picture

Title: Date Repeat generate Nodes » New module - first draft
Status: Active » Needs review
FileSize
193 bytes
3.97 KB

Here is a first draft of a new module I wrote based on the simple idea I posted above. It needs a little work, but it seems to work in the sense that it creates a bunch of nodes with one-off dates, rather than a single node with a series of dates.

I'm not sure whether - once this module has been reviewed and seems to be in good shape - this should be released as its own little module, added to date_repeat as a patch, or included in the date package as another utility module. Any thoughts?

shaisachs’s picture

FileSize
3.97 KB

Whoops - there was a little bug in the module above. Here's the corrected version.

tyromind’s picture

Awesome - I'll check it out on a test site asap

tyromind’s picture

Lots of warnings on creation of nodes. Nodes were generated, & content of orig copied to each. Date field changed on each - however I set it to repeat daily for a couple weeks, and it generated every-other day, instead of every day.

Lots of potential here! Excited about it.

KarenS’s picture

Title: New module - first draft » Repeating dates in separate nodes
Status: Needs review » Needs work

Changing the title to better reflect this. I have a client who needs this, so I'll be getting involved in moving this along.

I think it would make sense to include the module in the Date package since all the other related modules are here. That will make it easier to be sure versions match up, i.e. if there is a change in Date API or Date Repeat that this module stays coupled to the right version of those modules. If it's in this package, it needs a name that starts with 'date_', like 'date_repeat_nodes'.

I'll be reviewing this in the next day or two.

chakrax’s picture

I'm interested in this too. The Date Repeat feature is great - it has many different repeat frequencies, with exceptions. However, I have a Boy Scout troop calendar that has a Troop Meeting one week, patrol meeting the next, and repeat. Easy, you say, with date repeat? Unfortunately, there are holidays, and breaks - and meetings move from even weeks to odd weeks, etc. I tried making each meeting weekly and add exception dates - that was a drag. Best would be a way to arbitrarily select a bunch of dates for the meeting (instead of specifying repeat and exceptions). Seems like what you want to end up with is a list of dates of the meeting - why not let the user specify the list by picking each date? That way I can enter one node for the meeting for the entire year and select whichever dates I want.

Ideally I'd want a single node with an arbitrary set of dates that don't follow any of the existing repeat patterns, but I could live with multiple nodes created from a single form.

Thanks - Karen, tyromind and shaisachs - for all your community work.

tyromind’s picture

Awesome glad to hear the sound of progress!

@chakrax - sounds like a start would be having 2 events that repeat every two weeks, just setting them on alternate weeks, but that's not a bad idea in itself - though I'd imagine it'd take some work. But just thinking how that would work... When you create/edit the node where the date is it could show something like the date-popup or the cal block. Clicking on a day adds/removes it from the list. If you select a repeating option, the dates all get highlighted on the cal, and then you can still click to add "exceptions", either additions or subtractions from the repeat rule. Then you can of course check a box to have them generated as separate nodes. That would be a rockin interface - jquery stuff.

Back to the repeat-nodegen stuff - Karen - and just slap me if this sounds ridiculous... if you chose to have separate nodes generated, could the node you're creating now act as the "parent" to those nodes? As in it currently stores multiple dates for repeat rules - so could it instead store multiple nids - that seams pretty simple, it's the part about those nodes relating back to the parent node. Or I guess there could be another table for all of that and all the related nodes are given some "Date Series id" that allows for modifying the whole series from any of them. Could get messy if not careful... abandoned nodes, etc.

Well you're the pro - so I'll shut up ;)

chakrax’s picture

@tyromind - I did start out with "Troop Meeting" repeating every 2 weeks, and a "Patrol Meeting" repeating every two weeks. That would make Troop Meetings happen on odd weeks, and Patrol Meetings on even weeks. However, after a break, Troop Meetings move to even weeks, etc. It's not easy to capture all that in a repeat rule (I think the repeat rules are already very capable - what I want falls outside the realm of a repeat rule).

The next best think would be to just manually add all the dates (just like exceptions are now added) - I can't see why that can't be done. Just add the dates, instead of repeat rules and exceptions. I'd even volunteer my time - but I'm a relative php/mysql newbie - so I might cause more harm than good :-(.

I still like the idea of having only one node though. If multiple nodes are generated, I think we need a way to track parents and children - otherwise there will be a zillion orphan nodes - very messy.

The other issue is that only the first start date is shown when you click on ANY of the repeats - but that's another issue altogether - dealt in other threads. I can live with that though.
http://drupal.org/node/343978
http://drupal.org/node/351276

I'm extremely grateful to all the community developers who make drupal possible. I recently lauched my Boy Scout troop web site and the response has been very positive. THANK YOU!!!

flickerfly’s picture

sub (sorry, I need to track progress on this issue)

For club like situations where each event is a repeating event with a theme or agenda that might have "bring X to this meeting" this becomes an important feature.

Thanks!

Anonymous’s picture

The facility to have a set of unrelated dates attached to a single node is already there. Ignore Repeated Dates altogether, and just set up the Date field to have a single start Date, and allow multiple values.

Works a treat.

flickerfly’s picture

#18 doesn't solve the problem of having multiple descriptions (one for each date) to specify things like who's bringing the snacks that day or what the agenda is or whether we're all coming in our pajamas or with our clothes turned inside-out.

chakrax’s picture

@maynardsmith - really? You're right! I tried that out without the repeat feature, and it worked like a charm.

Thanks for the suggestion!

fallsemo’s picture

Subscribing.

I am very interested in the developments of this and can help test!
I am creating a broadcast schedule on a site with many nodes repeating on the same day and over the course of a month+. I am having difficulties configuring date settings to enable a single node listing to appear multiple times in a day AND over repeating dates but that's another issue.

Having the ability to change one instance (like a text field for unique episode information) to a node and keep its date pattern would be ... fantastic.

arlinsandbulte’s picture

Subscribing-
The problem with automatically creating a node for each repeated instance is that a never-ending repeating event will create an infinite number of nodes... not a good thing!

Here is my best idea (not necessarily THE best idea!):
Upon creation, pretty much everything is normal. Create the node, specify the repeat rules, etc.

When editing a node with a repeating date, the user/editor must be able to somehow select the exact instance in the repeating series they are working on. For instance, clicking on an event in a calendar view should (somehow) open an edit page for THAT instance and not necessarily the parent node. When saving that instance, options should be given to either apply the changes to:
Option #1: Apply edit Only to this instance. A new node is created in place of the selected instance and an exception is added to the parent node.
Option #2: Apply edit to all events in the series. It is pretty much the same as today.
Option #3: Apply edit to all events following the current instance. The parent node is modified to change the end date and a new node is created to take over where the old one stopped.
Option #4: Cancel. All edits are canceled. Nothing changes.

This is all pretty much exactly how the Google Calendar system works, which works pretty well IMO.

I think all of this could be pretty straightforward to do EXCEPT how to select and edit individual INSTANCES of a repeating series. I think this sort of ties into the issue of not always showing the first date of a series when viewing event nodes (see this issue: #351276: repeating event's date is always shown to be that of the event's first iteration). If a way to select and edit and show INSTANCES of a repeating node can be figured out, this could work.

But then that is a big IF!

ericm’s picture

subscribing

I think this is the only solution to the problem that when you click on an event on the calendar, the node display doesn't show you the actual date of that event, only the date of the first in the series plus a rule. The end users I serve get confused by that, and although they could click the "Repeats" tab, they have to spot it and to understand what "Repeats" means.

georgedamonkey’s picture

subscribing

Anonymous’s picture

I think I have said this before, but I detect (at least) two rather different requirements which Repeat Dates is being used for:

1. E.g. a regular meeting that happens once a month, where the basics are the same each time, but each occurrence is a separate "event" in the mind of the end-user. It is (or may be) convenient to set up as a single node containing the base data, but it should appear to the end user as a series of separate events. (Typically it also needs to be able to have some details changed each time.)

2. E.g. an exhibition that runs from date x to y (except Sundays). This is a single "event" in the mind of the end-user, with a start date and a stop date. When displayed in a View this need to show as a single entry, with the first date being the original start date, and ideally the end date displayed as well (bit not a complex repeat rule). BUT for use with Calendar, each intermediate date also needs to be represented.

I have found it possible to use the Date module for both requirements in a site I am building, but it does need some work with a shoehorn, and some compromise on presentation.

I look forward to a well thought-through reconciliation of these two requirements.

Tony.

sunshinee’s picture

@ maynardsmith,
If I understand correctly, the two cases are:

1. A repeating TIMED event
2. A repeating ALL DAY event

#2 can be accomplished by entering Event1 as 'from: March 3, 2009 at 12am to: March 5, 2009 at 12am'. View settings can be used to hide repeat rules. The calendar will show "Event1 (all day)" on each of the spanned dates (Mar 3, 4, 5), while the upcoming list will show a single entry. I use this regularly, and for most multi-day events, I don't need functionality beyond this.

I'm interested in your method to work with the first example in calendar/date's current form.

Anonymous’s picture

RJOY:

Not quite. I am not using times on any events, since for various reasons that gets too complicated and it is easier just to let the users enter times as free text in another field.

#1 I set using a simple single date (i.e. From/To without the To), and allow multiple entries. Typically this is a series of monthly events for say six months ahead, but the repeat is not regular enough to use Repeated Dates. If more detail has to be added as the individual occurrence approaches, then the user just has to clone that node, and make the changes (and remove the date from the first copy). As I say this is typically once a month, on a few items, so no great problem.

#2 I agree - I use Repeat Dates (not just From/To since I need to exclude e.g. Sundays). My problem with this is that when setting up a View I have to use the Node style rather than Fields, which would be more convenient), because Group Multiple Views does not work on repeated Dates, if there is a Date filter also present, which there is.

Hope this helps.

Regards, Tony.

arcane’s picture

I tried using Karen's latest Date Tools Date Wizard to auto-generate the date cck type and calendar. I found that the repeat_node_gen module is no longer working with the version she presented at Drupalcon 2009 in DC (Date 6.x-2.x dev, CCK 6.x-2.x-dev, Views 6.x-2.x-dev).

It was working in previous versions not using the dev versions. Can anyone help advise a fix for this?'

(And thank you Karen for introducing the Demonstration module, I'm using it practically everyday - what a time saver)

shaisachs’s picture

tyromind and arcane - Could you give me some more details about the warnings you're getting - e.g. warning messages, etc? I haven't gotten anything like that. Also, what versions of Date, CCK, Views and Calendar are you using?

I created a fresh test site with Date, CCK, Views, Calendar - all version 6.x-2.x-dev - and Date Repeat Node Generator (same code as above, just different name to follow KarenS's suggestion at #13 above). I used the Date Wizard to create a new type, field, and view, and kept all of the presets, except that I enabled repeats on the date field. I created two kinds of repeating events - one for every Thursday from March 5 to June 4, and another for every day from March 23 to March 27. Both seemed to work fine, and created all of the separate nodes that I expected, with the correct dates and times. So I wasn't able to recreate the errors in #12 or #28, unfortunately. Any hints?

Meanwhile, as I indicated above, I've renamed the module to date_repeat_nodegen, and I've also added some code to create date sequences and attach nodes to those sequences. So far things seem to work ok, under the rather controlled conditions described above anyway. The new files are attached.

arcane’s picture

Thanks shaisachs for your support,

I installed a fresh copy of drupal with your updated date_repeat_nodegen module and dev versions of date,cck, views, calendar. I found that when I create a new node and set the repeats with nodegen, everything works fine.

In my case I had imported around 70 nodes into my database (the date field was left blank). When I then went back and edited a single node to have a repeating value (with nodegen), the new nodes were never generated. (There are no warning or error messages generated)

However, when try the same operation without nodegen, the repeats are showing up in the calendar correctly.

So it's only on editing an existing node that I get this condition to happen. Maybe there could be a check to see if the node is being updated? In my case I have a really large cck content type with lots of fields so re-creating new nodes manually is not particularly attractive.

shaisachs’s picture

arcane -

Yes, that's a "feature", not a "bug". I wrote the code that way because the notion was that you create the node sequence once, on node creation, and thereafter the node and sequence are completely decoupled (except for, in this latest version, an entry in the date_repeat_nodegen_sequence_member table, that could be used down the line but is currently only there for kicks.) I'm so far just trying to get a concept together and to see if it flies, so I haven't had a chance to really make it a robust solution.

If you want, try changing line 111 so that it reads

if (($op == 'insert') || ($op == 'update')) {

... and see what happens (don't do this on a production site or with data you can't recover). I think that should work, but I don't want to include that in the module code just yet, as I'm not quite ready to add features for updating a series.

Assuming there's more positive feedback here, I'll put together a dev release of date_repeat_nodegen in the next week or so; that way we might be able to get broader feedback and further improvements.

arcane’s picture

Yes, that did the trick for me. Adding an update operation (copying the code of the insert) gave me the desired results.

jackalope’s picture

shaisachs: Just tried date_repeat_nodegen out and it looks really promising. I don't think I'll be able to use it on my production sites until series editing and updating is built in, but this is an excellent start. Looking forward to seeing a dev release; thanks for working on it!

gpk’s picture

Glad to find this discussion as I spent some time last week looking at ways using the current Date/Calendar modules (2.0) to do this kind of thing.

I'm currently deploying a workaround which inhibits display of a repeating event if there is a specific instance of the event on the same date. The workaround uses 2 content types: "repeating event" and "repeating event override" or "instance". The latter has a node reference CCK field which lets you identify the event you are overriding. Then a small custom module uses hook_views_pre_render() to remove the overridden event from the $view->result data structure before rendering.

Happy to post the code (17 lines) in a separate issue (to avoid cluttering up this discussion further) if anyone is interested.

And huge thanks to KarenS for her work on Date/Calendar generally.

couloir007’s picture

Subscribing.

I'm interested, but for the same reasons as jackaponte, I'll need to wait abit. Thanks!

tyromind’s picture

@shaisachs I'll check it out

magnestyuk’s picture

subscribing

shaisachs’s picture

I've turned my contributions above into a module at http://drupal.org/project/date_repeat_nodegen. It's only a development snapshot right now, and I haven't addressed updating date sequences, but take a look and kick the tires!

TomSherlock’s picture

FileSize
57.17 KB

First i would like to thank Karen for all the time, effort, skill and consideration she has put into Date and Calendar. I would also like to thank shaisachs for recent contributions to Date in terms of repeat dates.

I have the following relevant modules:
Calendar 6.x-2.1
Date 6.x-2.x-dev (2009-Apr-01)
Date Repeat Node Generator 6.x-1.x-dev (2009-Apr-04)
Views 6.x-2.4

I have the following problem: Events with repeated dates are all showing up on the first date only in the calendar. I have attached a snapshot.

I have also noticed that the Database Schema module complains about the two tables added by Date Repeat Node Generator.

If i could be pointed to the code where the date repeat is being created, i would gladly debug.

gpk’s picture

Tom, since your problem appears to be with the Date Repeat Node Generator I suggest you post your issue in that module's issue queue: http://drupal.org/node/add/project-issue/date_repeat_nodegen/bug. Be the first there!

mfer’s picture

Is there a spec for this somewhere?

Note: I'm a fan of specs because it lists out what you want, people can review the points easily, and you can test that what you made did everything.

TomSherlock’s picture

Thanks, gpk, for pointing me to more appropriate issue queue.

It seems, however, that this was a configuration issue with the calendar view. I'm still learning my way around here.

I'll retrace my steps and post the configuration steps here (or wherever is more appropriate).

felipe’s picture

subscribing.

Have you guys made progress on this? If I change a node can it change the other nodes as well?

duckjerk’s picture

Subscribing.

Very much interesting in having this functionality.

seattlehimay’s picture

Subscribing.

Osiris Indriya’s picture

Subscribing. Thank you!

dallen’s picture

Subscribing.

People in my office would love to see this.

thrash632’s picture

Subscribing. This would be very beneficial.

pizangdesain’s picture

how to repeat hourly? n what different that node with http://drupal.org/project/node_repeat ?

rustyco’s picture

Oops, maybe I should have posted here:

Repeating Dates Redux

WebCalendar has a functionality Drupal should perhaps emulate.

http://groups.drupal.org/node/3598#comment-130178

that0n3guy’s picture

sub..

gagarine’s picture

This module should fusion with http://drupal.org/project/date_repeat_nodegen

MacaroniDuck’s picture

I'm honestly surprised to see that there's been no resolution to this issue. Our community group has recently done comprehensive research to find a solution for the community web site we are building and decided on Drupal. The ability to create and subsequently edit and have RSVPs for recurring events individually are imperative to us.

I understand one challenge to this being that creating recurring events without an end date would create an infinite number of nodes. One potential solution to this is to require an end data for recurring events, perhaps a year or two into the future? It's not a headache for a user to have to re-create their recurring event once a year or two. It is a headache for a user to have to manually enter their weekly event every single week, however.

Anonymous’s picture

sub..

MacaroniDuck’s picture

I'm pretty new to Drupal so please excuse me if I'm missing something. Couldn't the Rules module be utilized to create a utility where when repeated dates are entered via the Date Repeat API, separate nodes could be optionally created?

mfer’s picture

We have a solution to individual dates being their own nodes in the iCal module.

arlinsandbulte’s picture

Yes, I tried the iCal module a while ago and never did get it working correctly.... I should try it again, though.
I see there is now a feature included to help setup.

mfer’s picture

@arlinsandbulte You may still run into problems. I'll admit, it needs some work and better documentation.

MrPaulDriver’s picture

If I may revive this old thread :-)

The functions provided by 'Date Repeat Node Generator ' and 'Node Repeat' modules are very worthwhile and I really hope that there is some further development for Drupal 7. Either with these modules, or for the Date module itself. I don't develop, but speaking as an event organiser, I would be very happy to test rigorously and provide lots of feedback.

There is quite at bit of discussion going on at www.drupalcomerce.com about booking systems. On the one hand there is the Rooms module, a sophisticated hotel reservation system, which is developing very well. But on the other hand there seems to be a real need for a simple event registration system for Drupal 7.

We can define event registration as the allocation of units of space, for a period of time; whether this is a place, seat, table, display booth etc

Having individual dated nodes would seem to be a pre-requite, because in commerce terms, the date is the product and number of places is the amount of stock. Once the repeat nodes are created, it is then a matter of adding a registration or commerce element which sells units of a pre-defined number, limited by a stock control module.

Sport events, concerts, theatres, markets, fairs, exhibitions - there is a very long potential client list out there.

Gribnif’s picture

The Date Repeat Sequence module also seems to do something similar. I am about to test it out.

KarenS’s picture

Version: 6.x-2.x-dev » 7.x-2.x-dev
Status: Needs work » Active

See http://drupal.org/project/node_repeat as a D6 solution, since I won't be adding new features to D6.

The discussion about how to solve this problem is still pertinent to D7, since perhaps a solution can be rolled into Date module there.

MrPaulDriver’s picture

My I also draw attention to Date Repeat Sequence Module http://drupal.org/project/date_repeat_sequence which again seems to offer some of the functionality needed. This is D6 at present, but a pretty new project if that makes any difference.

I really would like to see a D7 implementation of some sort, as I am sure would others.

MrPaulDriver’s picture

KarenS

May I copy you in on this thread.

http://drupal.org/node/444544

DamienMcKenna’s picture

I built a somewhat custom solution for a D7 site that I'd love to generalize, I'll review the current D6 modules with another developer on our team and see what we can do.

MrPaulDriver’s picture

looking forward to it

DeNelo’s picture

Version: 7.x-2.x-dev » 7.x-2.1

Looking forward to progress in this area for Drupal 7.
I would like to be able to add a number of Services (say, for a whole year), and then later edit each instance with Speaker, Subject, etc. as those details become known.

DeNelo’s picture

Version: 7.x-2.1 » 7.x-2.x-dev

Oups, sorry, changed the Version tag by accident. Changed back to -dev.

KorbenDallas’s picture

I'm developing a site that needs this functionality as well, and Apple's calendaring workflow is simple and easy to use. They allow you to create a repeating event, then when you go to edit one, the system asks "Edit Sequence" or "Edit This Event Only".

Any updates to this for Drupal 7.x?

mitchell’s picture

KarenS’s picture

Status: Active » Postponed

This is another issue that is on the table for the 7.3 re-design.

talisto’s picture

I've been struggling with this issue for a while, and I've come up with a somewhat hackish solution, but it works. Since all the repeating dates reference one node, the node itself has no way of knowing exactly what single date you want to display. So my solution is to pass the node the date's delta index using a GET parameter.

For the sake of this example, I'll assume the following:

  • you're linking to the node from a fields view
  • you're linking from the "Title" field
  • your repeating date field is called "Date" and the machine name is "field_date"

Here's what you need to do:

  • Edit your view, and add a new field of "Content: Nid". Check (enable) "Exclude from display".
  • Add another field of "Content: Date (delta)". Uncheck (disable) "Create a label", and check (enable) "Exclude from display".
  • Add a field of "Content: Title" (or edit it if it's already there). Uncheck (disable) "Link this field to the original piece of content". Check (enable) "Output this field as a link". For "Link Path", enter this: node/[nid]?delta=[delta]. Check (enable) "Use absolute path". That should change your Title link to reference the node, and add the date's delta index as a GET parameter to the link
  • Go to "manage display" for the content type of your node. Configure the format for your Date field to show all values, and change Repeat rule to "Hide repeat rule".
  • Create a template file in your theme called field--field_date.tpl.php, with the following code (modify to suit your needs):
<div class="<?php print $classes; ?>"<?php print $attributes; ?>>
  <?php if (!$label_hidden): ?>
    <div class="field-label"<?php print $title_attributes; ?>><?php print $label ?>:&nbsp;</div>
  <?php endif; ?>
  <div class="field-items"<?php print $content_attributes; ?>>
  	<?php if (isset($_GET['delta'])): ?>
  		<div class="field-item" <?php print $item_attributes[$_GET['delta']]; ?>><?php print render($items[$_GET['delta']]); ?></div>
  	<?php else: ?>
	    <?php foreach ($items as $delta => $item): ?>
	      <div class="field-item <?php print $delta % 2 ? 'odd' : 'even'; ?>"<?php print $item_attributes[$delta]; ?>><?php print render($item); ?></div>
	    <?php endforeach; ?>
	   <?php endif; ?>
  </div>
</div>

That will override your field_date's output to only show the date corresponding to the delta from the GET parameter, if it exists.

That works perfectly for me! Hopefully it helps someone else, while we all wait patiently for a better solution. :)

edit: I originally was passing the full date string, but I realized that passing the delta is a better solution, so I've edited my post accordingly.

chrisarusso’s picture

I have taken an approach to this based on the idea that I wanted to
Create multiple nodes with all the same fields, only differing on a date field

I did this for scheduling purposes of a bicycle-powered compost service I started in Durham, NC. I wanted to create events that people could sign up for, but potentially change in the future (switch from Thursday to Friday due to a holiday, change person doing the route etc.) much like others requested above. I have set intervals (once a week) that these events needed to be spaced from one another.

I went with the relatively simple idea of just using hook_form_alter() on the node creation form that adds a few fields that ask how many nodes to create and at what interval.

A lot of this is not written (yet) to be widely applicable, but if the basic concept is something folks are interested in seeing, I would be happy to work on it in a sandbox. I was even thinking of calling the module to be "node multiplier".

You can see the project code here:
https://github.com/illmasterc/Compost.Chrisrusso.Org/tree/master/drupalr...
I've now deployed and used this on my site.

Thoughts?

steven.wichers’s picture

chrisarusso’s picture

Sounds like you, my friend, are correct.

tmsimont’s picture

I've been working on developing this functionality for a while now and I just found this issue.

I have a sandbox module that takes the repeat logic out of the individual entities and puts it into a "Pattern" entity. I've got a lengthy description about the concepts on the module page:
http://drupal.org/sandbox/tmsimont/1917664

I could really use some help with the "Roadmap" items. It would solve this issue, but it is not quite ready yet. Any help would be appreciated.

I don't want to hijack this thread so if you have any questions about my module please hit me up on the issue queue there.

Thanks.

TechnoTim2010’s picture

This topic has been of interest to me for a while now. The original use case was a requirement to add shifts on a recurring and one off basis for events, specifically volunteer shifts in various roles in a theatre and a UI that allows these shifts to be created simply

I worked on a sandbox project called shift scheduler http://drupal.org/sandbox/mcstrother/1075572 where I added the ability to create shifts for special events.

The problem with this project were twofold (with all due respect to the other drupal devs that worked on the project) the UI was not great and in my instance proved unworkable, and the approach in either D6 or the ported D7 were not node or entity based. This meant that no integration with Views and other calendars was possible.

I discussed this at some length here http://drupal.org/node/1881492 and made the point that special events could be handled via entity inline form and other modules but that recurring shifts required a module that did the following:

Create a shift content type with a date field and a repeating date sequence and a start and finish time. each node created by the content type would be a separate node for each date in the repeating date sequence and thus be usable by views and programmatically and editable allowing unique values for each shift. Start times and finish times for each node would be preserved from the original node the shift was created from.

I created a mostly working prototype in my original Drupal 6 Development system and it worked, it needed some tweaks but the dates in the sequence did break out into nodes and did preserve dates so the concept was good the module that did all the work and did it fairly well was node_repeat ver 6.x-3.x-dev http://drupal.org/project/node_repeat

When I ported my site to D7 there were clearly some positives but the negative was that node_repeat had not been ported to D7 so although I could now create shifts for one off events I could not do so for recurring shifts and events. I tried node_recur but it failed to deliver and I could not see the bug in the code causing failure(s)

Time and other impending projects took my energies and time away from this project (which was pro bono)

Circumstances dictate that I revisit this project and thus the requirement for a working solution to break out repeated date type nodes into separate nodes is now required again.

So this long long running discussion and the many sidetracks interest me.

It strikes me thathttp://drupal.org/sandbox/tmsimont/1917664 may have some of the code to actually deliver this module if not all of it. However I feel his whole module goes way beyond the needs and requirements of a simple module to achieve this aim, I firmly believe in a KISS (Keep it simple stupid) approach, and think this would deliver a more flexible module that could enhance the date module and the date repeat part in particular (the UI can be as simple as a checkbox stating break repeated dates out into nodes or somesuch) and deliver a workable solution.

If not then a port of http://drupal.org/project/node_repeat would be a sensible plan B.

I will over the next few days (assuming I don't get waylaid by other work) look at the code and see if I can extract the relevant parts that achieve this aim. I will not create yet another freakin module (as gagarine points out it is stupid to have five at last count modules doing the same thing) I will report back my findings. If anyone else can help here the more cooks the merrier.

tmsimont’s picture

@TechnoTim2010 -- let me know if i can provide any answer regarding the code in my sandbox. i know it goes a bit beyond what you're looking for, but I really think that the concepts of "dates as entities" and "date patterns as entities" could really solve a lot of issues regarding the sharing of date patterns between entities

TechnoTim2010’s picture

@tmsimont - I had a cursory look at your sandbox yesterday I found navigating it somewhat confusing, but then I haven't picked the bones out of it. I looked at the code for node_repeat in D6 and realised that it is much simpler solution, however so many API changes have happened D6 to D7 that porting it might be a complex task. It takes a partly similar approach to your sandbox in that the patterns are broken out to a table holding sequences so possibly your sandbox may have part of the solution, obviously it has no concept of dates as entities.

I was wondering about dates as entities, there are pluses and minuses to this and obviously it increases complexity. I was wondering how this fits in with a) the current date module and b) the roadmap for the date module. Is this a technical debate that needs to be had. Specifically if a standard calendar is created with events as nodes using a date field (for one event non-recurring) how would this work with the calendars created by your module would this mean a change to the date module itself (so dates are consistent as entities) how would this (quite common) use case be fulfilled.

I am as you can see throwing out ideas and questions to broaden this debate, would be useful if other people added their two penneth.

tmsimont’s picture

i know what i've got so far is pretty confusing to navigate -- lots of work is to be done there on the UX

a) i'm using the date module's fields, and core date_repeat_calc() function. I'm trying to use as much of the date module as possible
b) i've seen a lot of discussions going on about where the date module is going, and i'm not exactly sure which will come to fruition. in many discussions i've seen concerns of a high number of date repeats, or infinite repeats. currently the date module will store as many unique instances of a date that are defined in a repeating range. this could result in thousands of repeats being generated at once.
#1901936: Create only a minimum amount (TBD) of repeats and set the rest to be created on successive cron runs
#272404: Make 'until' field optional

I think that by putting the rules that define dates into their own fields, and then the actual date fields into a separate mechanism (currently just the standard date field in my module) we'd be moving toward a resolution to this issue.

The module I'm working on goes far beyond the simple stuff.. it's geared toward creating a calendar for each user.. that's not really important to your goals. the relevant aspects of my module are the "dateset" module and the "pattern" module (unfortunately at this point all of the UI's are inter-dependent on all of the sub-modules in the DSM package... but i'd be open to ux re-rewrites, or total abandonment of my code in favor for a different execution of the same idea)

how would this work with the calendars created by your module would this mean a change to the date module itself (so dates are consistent as entities) how would this (quite common) use case be fulfilled.

Basically the difference i'm trying to work with is this:
FROM: standard calendar with events as nodes with nodes using a date field instance
TO: calendar with events as any entity reference-able by a dateset entity.
The dateset entity contains fields relating only to date. It has a date field, and a reference to the event entity. The calendar places datesets onto a calendar, and uses the dateset reference field to show the event. The event is what appears on the calendar, on the date, set by the dateset... This way, static information like "event name" or description only are entered once, and can be re-used by new datesets. Variable information like "location" could be assigned to the dateset. (This dateset/event relationship is similar to commerce's product/product display).

Currently , I have my module working so the dateset entity must be a child to the pattern entity. The pattern entity defines "from" and "to" on the repeat pattern, and specifies a range in which the datesets should be repeated. Datesets are then added to days in the pattern container as children... they have pointer fields to the parent container structure, so if the date range of the parent pattern updates, the child datesets also update.

As i mentioned... the UX for all of this is heavy, and currently depends on a user owning a DSM calendar to manage dates, date sets and patterns. All of this is fairly clunky, and could really benefit from a cleanup.

Ultimately, I want to use AJAX all over the place, but for now I am keeping it all server side to ensure that no-JS UX still exists before I go nuts with the AJAX..

At some point, I"m going to look at installing this: http://drupal.org/project/inline_entity_form for dateset-to-event connection and possibly this: http://drupal.org/project/fullcalendar (and possibly this: http://drupal.org/sandbox/tim.plunkett/1427994)

tmsimont’s picture

FileSize
6.55 KB

this is a small snapshot of some of the planning notes i worked from, kinda/sorta showing the schedule/pattern/dateset relationship in UML

Schedule uses Datesets and Patterns, Pattern uses Datesets, Mothly/Weekly patterns inherit Pattern.
dsm basic relationship diagram

tmsimont’s picture

FileSize
13.57 KB

and here's another part of the picture -- showing how event nodes and datesets work, also showing DatesetEvent bundle inheriting basic dateset properties, and adding in location and instructor

in this diagram the Event has "dateset references" but so far in the DSM module i'm making i went the other way with the relationship, and have the datesets referencing "events" (reffered in DSM as "referenceable entities" --- because i wanted to keep "event" as an abstract entity)

i was thinking it may be worthwhile to tie dateset and event with CER but that may overcomplicate the relationships and the fields involved.

dateset relationships

tmsimont’s picture

FileSize
7.62 KB

oops forgot to include in first diagram that the pattern contains fields that define the repeat rule.. updates to the pattern affect all associated Datesets

sorry that these diagrams are not complete...
updated pattern/datest diagram

tmsimont’s picture

lastly.. this screen from the current UI illustrates the pattern/dateset relationship.

the "manage dates" tab of the pattern entity shows "dropzones" for dateset entities. this particular screen shows 1 single dateset dropped onto the pattern.

as you can see, the pattern contains the "length of pattern" and "duration" fields, which then are used to build an RRULE. multiple datesets can be dropped onto the pattern.

i've also created "exclusion" entities to handle "holes" in the pattern, and added another tab on the pattern entity. i set these up as fieldable entities so you could create exclusions, and then show them in a view (rather than just use "exclusions" as "holes" on a calendar without explanation)

pattern UI

TechnoTim2010’s picture

I was going to post my take on how I understood this, but it seems you have done a lot of it right there.

Fantastic work, well done, I will spend tomorrow studying it then post back any thoughts. We will need other input though and am wondering if a) we are the only watcher/participants in this discussion and b) whether anyone has any other input.

One thought though. using the shorthand in code of dsm is probably best avoided to avoid confusion/conflict with drupal_set_message()

Fine work, cheers.

tmsimont’s picture

ya i was worried about using dsm, too because it's also devel module's function...

as you dig into my code.. i have a few notes in my sandbox issue queue that you might find helpful to answer questions you'll likely have.

there are some not-so-perfect aspects of my implementation discussed there.

one other thing to note about the diagrams i posted above -- notice that the pattern contains the repeat rule's start, end and duration, but the actual RRULE data and date repeat data is stored into the individual datesets' fields... this is so because of the way the date module works.

also, for now the calendar UI requires a patched calendar plugin #1908018: Break up large functions of calendar_plugin_style into smaller functions although i'm starting to think about bailing on that plugin or just adding my own to to the DateSetManagement package

MrPaulDriver’s picture

It's great to see this effort gaining momentum. Keep up the good work

TechnoTim2010’s picture

Hi

I created a dev Drupal 7 site and loaded sandbox project http://drupal.org/sandbox/tmsimont/1917664 and added the relevant patches. Then I went to work trying to test it.

It was immediately obvious that what to do was far from being intuitive indeed I had real trouble making sense of the UX. I was unable to make it work completely

These are the issues I could immediately see.

  1. The User interface is just too complex. It requires good and comprehensive documentation to use it, Going into Structure- Dateset Management it was not obvious what the first step was.
  2. The lack of any time fields is a major sticking point, I could see no where to set the time of a repeated pattern. Use cases for a repeated date pattern that exclude any time reference must be quite limited, I can see it used for all day events that happen on a regular basis but the lack of any time reference means further granularity is impossible.
    For example If a user has a maths class on Mondays from 10-11am then the method should ask for a start date, an end date and a start and end time (this latter can of course be optional so it becomes all day as the repeated field works as now). The rrule array can handle times but your code seems to format in m-d-y. Suggestion is to collect the times and then strip out the time using the T delimiter to give you a variable for time and timezone. Then when the dateset entities are created you can put them back with or without timezone recalculation.
  3. Creating Dateset types: This is done from structure-dateset management- dateset types.
    First thing to point out is that I can envisage few occasions when a user will be allowed access to the structure to create a dateset type. If this is to be user-centric this should be on the user menu for the user, it also needs to be clear what a dateset type actually is (This is clearly a documentation/terminology issue)
  4. The date format is hard coded as m-d-y Which is specific to the US and Canada, The rest of the world use different data formats like dd/mm/yyyy here in the UK. I know this is the order that the date is held in i.e mmddyyyyThhmmss but the UX needs to be adjustable to local date formats. The code should allow some date format reference.
  5. The project is user-centric, each schedule is per user, adding the ability for management and others to view schedules is an afterthought.
    This is my biggest concern, this is the wrong way round, make the schedule global and then allow the ability to restrict access by user/role/OG/UR afterwards as an option would be a better way and far more flexible. Consider the case of a teacher, you can then have a calendar the teacher can use to see his classes, the management can see all schedules for all teachers and the pupils/students can then see a calendar of all classes they are signed up to. The dateset and schedule would then become a ubiquitous way of adding repeating date entities.
  6. So I created a content type called Lecture, this can clearly have all the relevant fields added for a lecture then used entity reference to see a dateset entity, Only it didnt i got an empty lookup. Studying the db it is clear no dateset had been created.
  7. I had added a Dateset type called History Lecture with a weekly repeat pattern. but realised there was no way from there to create a dateset from the dateset type and the pattern. Schedule Manager showed (unsurprisingly an empty calendar) I set the default to the only node of the lecture content type I had created to see if that helped, it did not.
  8. At this point it is unclear where to go from here. So not a great test.

Some things in general to improve this.

Why the added complexity of the dateset type. If you create a dateset surely that is enough, adding the dateset type adds a layer of complexity too far certainly as far as UX is concerned, this if needed should be site builder territory.
Having entities for dateset, pattern and exclusions makes sense, using Entity inline form to add a field to add a dateset to a node makes perfect sense, if all the usual patterns, weekly, biweekly and monthly are there as standard patterns then it makes sense that you create a node choose the pattern choose any exclusions and the code goes off and creates a node for every repeat.
The time really has to be included, I noted that the node_recur module struggled with this, is this really difficult, it is I would say essential. I could also not see where the days of week are added, (e.g. a lecture is every monday at 11.00am until 12.00am)

The UX would then be nice and clean, the site builder can build a content type referencing dateset, pattern and exclusion using inline entity form and the user can create a series of nodes based on the settings referenced in these. The site builder can filter by role, taxonomy, user etc and this should in my mind meet most use cases I can envisage, if a user wants a calendar just for his/her related events (e.g. all a lecturers lectures) then they can do so using views (obviously pre-created for them by th site builder) An overview is also possible and other user roles can just read the published data.

I will try and diagram it later.

I conclude that I think this concept is sensible that seperate entities for:
dateset - i.e from/to dates and times
patterns - weekly/monthly/quarterly/etc and days of week makes sense, I would ignore the forever issue, it's a logical nonsense, Even if you have an annual lecture you would always put in an end date, yes conceivably you could have someone create daily events for 20 years but they have not thought things out if that is their issue, 20 years ago there was no viable web who knows what will (if anything) replace it.
Exclusions - again a viable entity type.
So then the issue is importing an ical Rrule or gcal calendar and having the code to break it into dateset, pattern and exclusions AND create nodes for a given content type based on that imported data.

Please tell me what I am doing wrong (I am obviously missing a step and I have no datesets) But also let me know what you thing of my comments and suggestions.

Cheers

Tim

tmsimont’s picture

It was immediately obvious that what to do was far from being intuitive indeed I had real trouble making sense of the UX. I was unable to make it work completely

Indeed. Much work is needed to be done.

1. The User interface is just too complex. It requires good and comprehensive documentation to use it, Going into Structure- Dateset Management it was not obvious what the first step was.

Right. I put up a drupal_set_message after install that says "you need to go to add a new dateset type" (like a content type) but I know that is not sufficient, and if you miss that message you're pretty much lost. But, the first thing you need to do is go to the /admin/structure/dateset (as you have figured out) and then you want to add a dateset type like a content type. You won't initially need any fields, as all of the required time-related fields are attached automatically.

2. The lack of any time fields is a major sticking point, I could see no where to set the time of a repeated pattern. Use cases for a repeated date pattern that exclude any time reference must be quite limited, I can see it used for all day events that happen on a regular basis but the lack of any time reference means further granularity is impossible....

The idea is that the "Weekly pattern" defines a pattern "shell" in terms of days, hence the m-d-y. The "datesets" then define time periods within that "shell". So, if you set up a 2 week pattern from May 1st to August 1st, it creates a 2-week shell of a pattern that starts in the defined range. There are no real dates at this point. You just have a pattern.
You then add datesets into that pattern at specific days in the shell, at specific times. Like "day 1" at "5 am to 7 am" would be May 1st, May 15th, May 29th, etc... The current state of the UI does not do a good job of illustrating this. I need to bring in some AJAX and make this clearer.
The reason it works this way is so you can have numerous datesets all entered at different points in a parent pattern. Then when the pattern updates, the datesets all update.
The only pattern I have coded so far is a "weekly" pattern. I could see use for "daily" patterns, " hourly" and "monthly" but I just haven't gotten there yet.

3. I can envisage few occasions when a user will be allowed access to the structure to create a dateset type.

interesting.. I hadn't thought of that. I was thinking that these are more like content types and an admin would have to configure these. I could see a user configuring them tho, but that would be tough to handle because you'd have to give them access to manage fields... Something to consider tho for sure.

4. The date format is hard coded as m-d-y Which is specific to the US and Canada

I don't think this is true, but it's been a few weeks since I've been in there. The default dates that are brought into entities and "dsm_" fields are definitely MDY by default, but they are just regular date fields. They should be able to be configured to what ever format you'd like via the admin/struture/dateset types interfaces. I'm just pulling out MDY in the processing scripts, after creating Date Module date objects to handle the data.

5. The project is user-centric, each schedule is per user, adding the ability for management and others to view schedules is an afterthought.

Yes I was worried about this.. I've been rethinnking it. However, this is primarily an input management tool. The output could be easily handled by Calendar module and other Date module views plugins. The primary goal of this module is to provide a way to manage dates. Displaying them would simply be a matter of setting up a view to show datesets based on various relationships of the owner and dateset type, etc. But, I'm thinking that by putting the schedules at a user URL, I'm boxing myself into a bad user-specific corner. I'd be open to changing that around.

6. So I created a content type called Lecture...

The concept so far is that you create a dateset type, and then configure the "represented entity reference field" (or something confusing like that) to point to content types. Then when you create the dateset, you reference the content entity. This is kind of backwards now, but I am hoping to embed this whole thing into an inline-entity-form or something so its more streamlined and centered around the content form.

7. I had added a Dateset type called History Lecture with a weekly repeat pattern. but realised there was no way from there to create a dateset from the dateset type and the pattern.

After creating the type, you should create an instance of the type (like creating a content type, then creating a node) via the "add" link on the schedule manager.
If you've created a pattern (not a pattern type, but an actual pattern) then you should get a screen like this:
http://drupal.org/files/project-images/dsm-screen2.png

If not, you should at least have a screen like this:
http://drupal.org/files/project-images/dsm-screen.png

If you don't see those links on each day that say "add" then you need the patch in #1908018: Break up large functions of calendar_plugin_style into smaller functions for calendar.
I had to modify and then extend the calendar plugin to be able to add those links into the calendar output. Unfortunately, the default calendar plugin code is not very extinsible. I had to rewrite most of it. If that patch is totally ignored and never looked at by Calendar maintainers, then I'll just include the modified Calendar plugin as a separate plugin to eliminate the dependency on this patch... But for now, in order to get the "add" links into the DSM UI, you need that patch.

I feel like you must be missing those 'add' links, that would explain your confusion. Let me know.. otherwise maybe you can send me some screenshots, and I should be able to see if anything is missing (like action links, tabs and sub-tabs on management screens that are critical for navigating)

Thanks for your feedback this is all great stuff

eft’s picture

I have created a new sandbox project called Date Repeat Entity. It addresses this need for separate nodes for each instance in a date series. Some of the key points:

  1. When a repeating date is created the deltas in the date field are removed and replaced with entities cloned from the original entity.
  2. Each entity in a date series shares a master UUID that is (for the moment) tracked in a different field.
  3. If the entity contains entity reference fields the underlying entities are replicated also.
  4. When an instance of a repeating date is updated or deleted the user is presented with the option of updating/deleting the scope of the change based on the current instance, the current and all following instances or all instances.
  5. When an entity with a repeating date series is updated, the other related entities are updated also. However this is done with a hook HOOK_repeating_date_update and, by default, only the title of related entities is updated. Developers of other modules can affect additional changes through this hook.
  6. When a repeating date series changes significantly, all entities within the scope of the change are deleted and replaced by new ones. The determination of 'significant change' is made through a hook, HOOK_repeat_entity_repeating_date_has_changed, thus allowing other module developers some control over when data are deleted.
  7. If the entity contains entity reference fields these are checked for existing values and the user is alerted to the potential impact on these values at the time of updates/deletes.
  8. An example feature module in included with date_repeat_entity including an event content type, required additional fields and a calendar view.

Please try out this module and add your questions/comments to the Date Repeat Entity issue queue.

TechnoTim2010’s picture

Hi

Well done. I have had this on the back burner for months. The project that needs it is a pro-bono project I have been working on in my spare time, however spare time is a rare old commodity in my life so I have been unable to progress this.

However given the need for the project is now more pressing than ever It seems it would make sense to make some time for this. So your timing is excellent.

I will be happy to try out your module and feedback and maybe if time allows contribute to your project.

Well done I look forward to testing your project.

Regards

Tim

Gabriel_ARG’s picture

Issue summary: View changes

Allow me to ask: is there an update regarding this? I've encountered the problem that when someone registers to a repeating event, they register to all the dates as opposed to just one. If repeating events would be different nodes I think that would solve the problem.

Thanks!
Gabriel

MrPaulDriver’s picture

Date Repeat Entity as mentioned at #89 allows allows for registrations for separate nodes. It's a sandbox project at the moment although I am using it successfully with the Entity Registration Module.