GNOME Bugzilla – Bug 787418
Add a way to create event from command line
Last modified: 2017-09-26 06:42:29 UTC
Various meeting providers provide Outlook plugins, which fill in a new meeting request with stuff like dialin information. It would be useful to be able to do something similar with Evolution. For the one I'm working on (in Pidgin), it would be best to be able to just invoke evolution with a partial ical event, to invoke a new meeting editor for the user to fill in the rest. On the command line or over D-Bus, we'd provide: • Account email address for the meeting owner (i.e. me) • Default invitee addresses • Default meeting invite body (including dialin info etc.) • Default Location All of this could be part of an ical that's provided.
The more I think about it, especially when you pass the iCalendar object (pure VEVENT/VTODO/VJOURNAL, not the VCALENDAR), the more I believe it'll be easier to provide command line option for it. The only downside is that there's no standard for it, like for the mailto:, which breaks interoperability and eventual replacement with other application of users choice. Or I'm not aware of it. Thus what about something like: calendar:?new-ics=/tmp/ical-tmpl.ics&source-uid=XXX&attendees=true/false where * the 'new-ics' argument is mandatory and contains a filename on the local machine to read the iCalendar object template from * the 'source-uid' is optional and can reference an ESource UID of the destination calendar/memo list/task list to preselect in the editor * the 'attendees' is optional and can be either 'true' or 'false', to eventually force showing attendees when the 'new-ics' file doesn't have any; it won't hide attendees when there are any set in the 'new-ics'. The URI scheme "calendar:" can be changed to "memo:" or "task:" and it will still work the same, because the iCalendar object dictates what the actual component type is (and because the code is reused between these three). I'll cook something for testing, on which we can iterate.
Looks good; thanks. Thinking about it some more, for my purposes I would quite like it to be something I could ship in a plugin/module for existing releases without having to wait for a new release to reach my users. But I can live with command line if that's the best/only way to do it. If no ESource UID is provided but an organiser field is present in the ical, it would be good to pick a suitable calendar based on that organiser. Can we do that?
Created attachment 359388 [details] [review] proposed evo patch for evolution; This makes it slightly more strict, if you call the new-ics with calendar: scheme, then it requires the file being VEVENT, when with memo: scheme, then VJOURNAL and finally when with task: scheme, then VTODO. It also allows "true" or "1" for the 'attendees' argument. It does some error reporting, but only on the console, with no new translatable strings added, thus it can be eventually committed to the stable branch as well. Let me know your opinion, whether this is sufficient, thus I can either add what you'd might find missing or commit it. Thanks in advance.
I've been testing this with an organizer whose mail was not between my accounts and evo claimed that the user is not an organizer and that I cannot edit it fully. Picking a different calendar also changed the organizer, which "cured" it. There are caveats, but not that much relate to the command line, because it's the same when opening the event from the calendar too. I didn't try, but I do not think prefilling organizer right in the .ics file will choose the corresponding calendar as well. That would need fixing.
The way the mail-to-task plugin does it is to make the user select a calendar first.
Yes, it's for bulk processing. The command line just opens the editor for one event and that's all. Nothing is saved until user saves it.
Can I commit the patch now? I do not want to left this waiting forever. We can eventually iterate on the change, if needed, though, on the other hand, I'd prefer to commit final solution at one shot, not multiple.
I've approached this a different way — in my Pidgin back end I build an Evolution module which does listen on DBus. ISTR you didn't like this approach, but it does mean I can react appropriately to success/failure of the DBus call, and display the existing "Go add this stuff into your calendar manually" dialog when it fails. It also means I have it working in versions of Evolution back to 3.18. It might even make sense to make a freedesktop.org standard DBus API for this, and other calendar applications can support it too.
Created attachment 360357 [details] event-from-template.c (hacked up from mail-to-task.c) Needs a little more cleanup but here's the module I have for reference.
Note that I've made an attempt to choose the correct calendar based on the organizer. It's not perfect but it works in my own testing.
Sure, works for me. Thus the command line may or may not be committed, it's up to me now, right? I guess I can add it, it won't hurt.
Yeah, the command line is a good idea too, just not quite what I needed for my use case (where users might not actually be using Evolution anyway). Thanks.
Sure, makes sense. Created commit 59dad90040 in evo master (3.27.1+)