GNOME Bugzilla – Bug 783348
Add 'Edit as New' event context menu option
Last modified: 2017-06-08 08:02:32 UTC
Appointements cannot be moved nor being copied into the same calendar. There is the requirement to duplicate an appointement and make little changes afterwards like title and date, but keeping all the other settings of the original. Sometimes even the title isn't to be modified. There is also the requirement to move appointements quickly by drag and drop. The most intuitive feature would be to support drag and drop for moving and Control+drag/drop for copying within the same calendar, without changing the title, but only the date. I wonder if bug 328633 is still on the map as it wasn't touched for years.
Thanks for a bug report. If bug #328633 is opened, then it is also to be done. It can be addressed by anyone, this is Open Source, aka patches are welcome. I do not know whether it's the same thing you actually want, because most of the description speaks about being able to copy (move doesn't make sense) an event within one calendar, while the other bug is just about adding drag&drop into other views, not only in the Day and Work Week view, where drag&drop already works and is used to change the start time of the event. In case you think this is the same request as bug #328633, then filling a new request is not ideal and would result in a mark as duplicate of the older bug report. (Why to have two reports requesting the same thing?)
I agree, duplicate tickets are useless. The other bug is about moving, this one is about copy and move, so we could rename it to copy only and manage the moving in the other bug 328633. Moving as well as copying absolutely makes sense. Copying an appointement creates a duplicate and modifies the date to the new target date. Moving only modifies the date to the new target date. Both are often required in calendars like re-scheduling (moving) and creating new appointments similar to existing ones.
The difference between copy and move is very tiny (code-wise speaking), it's only about a flag saying "delete the source event after it had been successfully copied into the destination". It complicates things in several ways. I believe the best option is split between changing time and changing calendar. When changing the time only, the copy may cause confusion. You rarely want to have duplicate events in one calendar being done this way (I imagine a Day View and drag&dropping an event from 10AM to 1PM). Thus the time change should be always a move. That also helps with recurring events, where you either make a detached instance (an exception) or you move whole series. Move© between calendars makes more sense, that would be done by drag&drop above the tree of calendars on the left, even it can already be done by right-click->Copy/Move to Calendar, only the destination calendar cannot be the same as the source calendar. I'd say that changing that (allow the same calendars for the source and for the destination for copy function) might not be a problem. That means, if this bug can be simplified to "Allow copy to the same calendar" through right-click->Copy To Calendar..., then it's easily achievable. Implementing real drag&drop in all views is significantly bigger issue and would require much more time (that's also the reason why that old bug exists).
"Allow copy to the same calendar" would partially solve this issue, yes. However it would then be better to have a context option like "Duplicate" without the requirement to choose the same calendar of the current "Copy to calendar" dialog. However duplicate alone is never a requirement, but only the first step for adding another appointement. Making duplicates almost always needs the date to be adapted. For my usecases there are for instance: * Vacation: I have a template for creating vacations. For a new vacation I usually like to duplicate an older and then change the date and description * face2face meetings: I usually just copy an older to have all the text template, and then change the person in the subject and date. So for making copies, a ->Duplicate option would better open a dialog like the "Edit", where you can just make changes for description and date without changing the original but creating a new copy. From filemanagers and calendars I just thought CTRL+Drag-and-Drop to make a copy would be the most intuitive to get a copy, then editing the new one. Disadvantage of Drag and Drop usually is that the target needs to be visible in the context if not making it scroll when reaching borders. But this is not an issue when having another Evolution view and copying between views is allowed.
> So for making copies, a ->Duplicate option would better open a dialog like > the "Edit", where you can just make changes for description and date without > changing the original but creating a new copy. This makes sense to me, and the dialog also lets you change the destination calendar, thus if you want, then we can change this bug report into this "Duplicate" request.
I finally turned this info "Edit as New" context menu option for events. This option is visible only for non-recurring events, because editing recurring event with detached instances is no fun. [*] Created commit 8378caa in evo master (3.25.3+) [*] I also allowed to pick the same calendar as the destination when copying event, the "Copy To Calendar" menu option, which can be used as the complementary option. As the former adds new translatable strings I cannot commit it to the stable version, but the later can be done there as well, thus I did so: Created commit 26edb3f in evo master (3.25.3+) Created commit db4176b in evo gnome-3-24 (3.24.3+)