Copying events: changing event dates relative to new start date
When copying an existing event to create a new one, it would be even better if the process would be able to change all the dates related to the event relative to the new event date.
Currently, you have to go in and change all the Registration type open or closing dates which can easily be overlooked when copying an event. It would be great if the system could maintain the same dates relative to the new date of the event being created.
-
jim commented
When an event is copied from a previous year, and the default invitation or reminder has been modified in some way, that modification carries over into the copied event. This has caused multiple issues because the assumption is that the emails should be default. WA has made the creation of annual events super easy by allowing duplication, but not reverting emails that are not readily visible can have a disastrous effect. The info on the event page says one thing and then the follow-up invitation or reminder emails may say something completely different. (Provided someone modified the email follow-up in the previously created event)
-
Armelle Loghmanian commented
I do agree with what we stated previously. I do make copy of event also to keep all the different registration types.
A suggestion: what if we could setup the available period not as a fixed date but relative tothe event? I mean for the From it could be : now, or x days before events, and to can be n days before event for exemple.
This will solve my problem!
-
VCOMA commented
It's true that copying is a lifesaver.
Where I run into trouble is having to remember to update all the dates associated with it to the new event dates. For example, we offer registrations at different prices based on whether they register early or late. Currently this is set by selecting an exact cutoff/change date such as valid until January 3rd. A simple change to make it more useable for copying would be to change the selection to change the price or valid until "X days before event" instead of having to put the actual date in. Then even after copying the date would be updated correctly on the registration types.
-
SWEAtlanta commented
Agree with Cheif Apricot on this one - for us, we have 3 different types of registration types for our monthly event that all have different prices. Copying the event relieves us from having to repeat that effort. Other settings get saved too, like showing a list of attendees. Unfortunately you do have to change the cutoff date, but this is a minor annoyance. It would be nice to have this fixed so that my more beginner-level officers don't get confused as to why they created an event but registration is closed.
-
Dmitry Buterin commented
In this scenario I would suggest not to copy the event but create new one from scratch.
From what I have seen, the biggest benefit of copying people get is from:
1) registration types
2) Event-specific customized announcements and/or reminders
About dates - we were not able to figure out how to automatically and transparently change all the dates when copying - I would appreciate ideas in this regard.
-
David Jacobs commented
Currently if I want to copy an event, I can do so, but with some limitations. Here is how we use that function.
We host a program or event on a monthly basis. We try to copy a previous event so we don't have to duplicate our efforts.
The only piece that we can use over again is maybe location and part of the event description.
Like mentioned in the original comment posted everyone has to go in a update the event dates and times.
It just adds additional items that we have to create or recreat to the long list of items.
So what is the point of copying something if you have to almost recreate the entire event again anyway?
-
Dmitry Buterin commented
Sorry, I do not get your point, can you elaborate?
-
David Jacobs commented
What is the point of having a copy feature if you can copy and have it tied to this.
We are talking about ease of use.....
-
Dmitry Buterin commented
After an internal discussion we realized that this is no a simple change and there is a variety of scenarios. So it's not something we can jump in and change quickly - but we would appreciate votes/comments/insight from other users - it would be of great help.
-
Evgeny Zaritovskiy commented
You're absolutely right - current behavior is actually an oversight, almost a bug :) I will add this into our internal system so we can change this - this is a very simple change.