Proposal: event type duplication

[MinosChatzidakis]

Hello, I would like to propose a new functionality that I think would benefit this project's users by saving time during event type creation.

More specifically, I would like to suggest that hosts be given the option to duplicate an already existing event type in the "event types" tab. This would be helpful when they wish to create multiple but similar event types by removing the need to create them all by hand, thus saving them time. For example, a host might need to create multiple event types with common characteristics (location, duration, buffers etc.) but distinct differences such as title or price. As of right now, the only way to achieve that is to manually create all event types, which could prove quite time consuming for a number of event types.

Thank you for the consideration.

[shockalotti]

Agreed, this one is straightforwardly useful and I'd like to build it. Configuring buffers, minimum notice, booking window, location and hosts from scratch every time is exactly the kind of repetition software should absorb.

One thing worth saying out loud, because it's where a naive version of this feature goes wrong.

An event type isn't just a row in a table. It also owns:

• its intake questions (the booking form)
• its hosts, along with their roles and round-robin priority
• availability rules scoped specifically to it, which are distinct from your global weekly availability
• its per-event email and reminder copy

If duplication only copies the event type's own fields, you get a clone that looks completely correct in the editor while having no questions, no hosts, and having silently fallen back to your default availability instead of the custom hours you set on the original. That's actively worse than not having the feature, because you'd reasonably assume it worked and only find out when a booker hits the page or a booking lands with the wrong person on it. So the version I build will copy the whole graph, and I'll write tests that assert each of those pieces came across rather than just checking the row exists.

Two smaller decisions I'll make unless anyone objects:

The copy starts inactive. Slugs have to be unique, so a duplicate needs its own (intro-call becoming intro-call-copy or similar), which means it's immediately live at a guessable URL the moment it's created. Since the entire point is that you're about to change things about it, having it default to inactive until you've finished editing seems clearly right. One toggle to publish.

Everything else copies, including price. You mentioned price as one of the things that differs between your variants, and that's true, but I think it's still better to bring the original's value across and let you edit it than to blank it and risk someone publishing a paid event type at zero. Copy faithfully, edit deliberately.

Thanks for the suggestion, and for spelling out the use case. "Same shape, different name and price, several times over" is a much more useful framing than just "add a duplicate button", and it's what makes the availability and questions part obviously necessary rather than optional.

[MinosChatzidakis]

Sounds great! I completely agree with your approach to copy every detail about the event, this is exactly how I imagined the feature would work. I'm also perfectly fine with the copy starting as inactive until all changes have been made.

Thanks for taking the time to implement this and for listening to the users' needs. Should you need assistance in developing this or some other feature I would be happy to open a PR under your guidance.

[shockalotti]

Tracking issue opened: #17, with the full list of what a duplicate has to carry across (questions, hosts with their roles and priority, event-scoped availability, and the per-event email copy) so none of it gets missed.