GNOME Bugzilla – Bug 633566
EWS Evolution appointments are not shown
Last modified: 2020-11-06 20:22:18 UTC
I'm using gnome-panel-2.32.0.2-2.fc14.x86_64 and evolution-2.32.0-2.fc14.x86_64 from Fedora 14. None of my appointments in Evolution's local Personal calendar show up in the clock's appointment list like they used to in Fedora 13. The days with appointments are bold in the calendar, but clicking on them doesn't bring up the list. I asked about this on Fedora's testing list and got a couple of answers (http://lists.fedoraproject.org/pipermail/test/2010-October/095164.html). I quote Kåre Fiedler Christiansen, as he has been able to test this with remote calendars as well: "I tested a little, and my appointments from Google Calendar show up in the applet, but the ones in calendars on this computer do not. The days with appointments are marked with bold, but they do not show up in the list of appointments."
Is this anyhow about recurring events which recur for ever? If so, then it's bug #632771.
No, this is all appointments in my local calendar, be they recurring or not. In fact, I just tested a bit more, and in my current setup I have four calendars: Two remote Google calendars. Both work and show appointments One Local calendar (the default calendar): No appointments are shown, although the days are marked with bold One remote Exchange calendar connected with MAPI: Same behavious as the local calendar (no appointments are shown) I would be happy to provide any requested information.
Ah, then might be related to the migration not done properly. When you open in GConf: /apps/evolution/calendar/sources (and similar for tasks and memos), then one row should be with an "On This Computer" group, which should have "base_uri" set to "local:". There used to be a problem that this one was kept to "file:///home/<user>/..." which is apparently wrong. The other issue might be with the source under this group as well. Does it contain a "uri="file://..." key? If so, then please remove it, it might not be there. (I know it's pretty hard to edit these keys, but it's doable with an external editor or something.) All changes to this should be done with evolution and e-calendar-factory closed. I also recall fixes to the evolution-data-server in 2.32.1, though in fedora is also built evolution-data-server-2.32.1-2 (in updates testing) with another fix, which might be related as well. It's about bug #635673.
Created attachment 176188 [details] [review] proposed gp patch for gnome-panel; Nah, even when everything is as expected from the above mentioned then it doesn't work, because eds renamed local sources to "local:system" from "file:///home/.../system", which filtered them out. This patch fixes appointments issue in the clock applet. If you wonder, the other chunk is about a white-space after the backslash, there was a warning from autotools shown to me, thus I fixed it as well.
I rebuilt the gnome-panel package in Fedora 14 with the patch from comment 4, I had to remove the Makefile chunk, though, since it didn't apply. The calendar-window.c patch works here. Thanks, Milan.
Created attachment 176258 [details] [review] Updated proposed patch that also displays MAPI events The proposed patch works just fine for local calendars, thanks. However, to make my events from my MAPI calendar connected from Exchange 2007 also work, I had to also add a line for mapi URLs. I have added a new patch with this line included. I don't know if this makes the list exhaustive, though.
The patch works here too with gnome-panel 2.32.1-2
Thanks, committed to master!
Created attachment 182260 [details] [review] More general fix This patch takes a different approach, since this problem occurred again for the Exchange Web Services back end. For now, it simply assumes that all back ends other than "weather" and "contacts" are to be treated as appointments. So it won't just silently leave *any* of them out. But more generally, it moves that horrid incestuous knowledge about the names of the various back ends... from the filter function itself, to the code which obtains the information about the esources in the first place. We store the *type* in the gtk_tree_model, not the base uri. In future, this could be further improved by removing the horrid name comparisons altogether, perhaps using e_source_has_extension() to see the capabilities of each source?
Re-opening, since this really is the same bug in a slightly different form.
Comment on attachment 182260 [details] [review] More general fix Please commit, looks good. Thanks!
To ssh://git.gnome.org/git/gnome-panel 8cda45d..7ebee9d master -> master Leaving open and assigning to mbarnes, who is working on the esource API and should be able to eliminate the knowledge about special names altogether.
I've modified the patch (id=182260) to be applied with any junk to 2.32.1 source.
Created attachment 182328 [details] [review] clock-app-show-ews-HEAD.patch
Comment on attachment 182260 [details] [review] More general fix [Setting patch status to committed as per http://git.gnome.org/browse/gnome-panel/commit/?id=7ebee9d9aeea4adcdfe89382ca0f27a964ab5ed2 ]
bugzilla.gnome.org is being replaced by gitlab.gnome.org. We are closing all old bug reports in Bugzilla which have not seen updates for many years. If you can still reproduce this issue in a currently supported version of GNOME (currently that would be 3.38), then please feel free to report it at https://gitlab.gnome.org/GNOME/gnome-panel/-/issues/ Thank you for reporting this issue and we are sorry it could not be fixed.