For repeating Events, the absolute Registration Start / End date is transferred to each of the repeated events which causes future events to be closed for sign-ups on creation

For repeating Events, the absolute Registration Start / End date is transferred to each of the repeated events which causes future events to be closed for sign-ups on creation.

The fields are: Registration Start Date / Time Registration End Date / Time

It makes more sense for repeating events, that these dates need to be set relative to the event date.

This could be an overall enhancement to make these date fields relative for all events, not just repeating. Which would make more sense. Especially since that applies also to copying an event as well as setting up a repeating event.

As it stands now, repeating events with Registration Start and Registration End need to be manually updated after creation. Otherwise, no one can register for those events.

Agileware Ref: CIVICRM-841

changed the description

This seems like a logical change to me - @bgm I think you showed signs of using this recently - also Yashi & JonG but I can't ping them from gitlab?

I have no idea why I'm not showing up in the auto-complete - but I'm @JonGold on here. Regardless - my interest in this was tied to a Palante client. I think Morgan R. would be a better person to ping. I don't think she's on Gitlab, but I'll ping her on Mattermost.

"I have no idea why I'm not showing up in the auto-complete"

I added you to the 'dev' team, which should fix that issue.

@bgm I couldn't ping @yashoda either....

@bgm I couldn't ping @yashoda either....

OK, added. Also upgraded your permissions on 'dev'.

@eileen @bgm we actually don't use online registration for the project Jon mentioned. But I'll weigh in based on some observations from working with those users on recurring events in general. I agree that "make these date fields relative for all events, not just repeating" would open up the most options, and would be much more straightforward when setting an event to repeat/copying. We would probably want the actual calendar date to preview/display in addition to the relative date (which I presume would be formatted like "x months/days/hours before"), at least on the original event.

mentioned in issue #65 (closed)

I think this ties in with #39 (closed)

which also seems like the same proposal.

How would this look in terms of schema change etc?

mentioned in issue #39 (closed)

added needs:concept approval triaged type:proposal labels

@michaelmcandrew @yashodha @GinkgoDOB - I feel like some of you might be placed to collaborate on this

Does any one strongly object to this proposal? Or have any other input?

To clarify I feel like there are 2 proposals

1. Alter the CiviCRM schema to potentially hold 2 additional fields registration_start_date_relative & registration_end_date_relative. Presumably whenever start date or end date are altered they would need altering by code (could get complex "but I the registration start date relative to the event end date not the event start date - duh!"

2. alter the form being used when repeating an event to allow more options at the form level

I think the latter one is probably the safer / easier to implement & I think we should accept that (if well written, tested as appropriate etc). The former would need to be speced out a bit more & I think if that is where you want to go it may be worth emailing the dev list with an invitation to comment

mentioned in issue #339 (closed)

mentioned in issue #613 (closed)

mentioned in issue #723 (closed)

mentioned in issue #978 (closed)

Just a FYI, we're going to add this functionality to an extension.

mentioned in issue #1015 (closed)

mentioned in issue #1183 (closed)

mentioned in commit 382c48e1

mentioned in commit b4355b48

mentioned in commit 1a2ce1d7

closed

mentioned in issue #2089 (closed)

mentioned in issue #2377 (closed)

mentioned in issue #3698 (closed)

mentioned in issue #4267

mentioned in issue #5284 (closed)