GNOME Bugzilla – Bug 789899
EWS: Intance of a recurring event is duplicated, if it is modified
Last modified: 2018-02-05 19:53:35 UTC
When using evolution-ews and I modify a single instance of a recurring event (either meeting or appointment), I end up with two instances - the modified one and the original one. Additionally I get an error message, that the object cannot be found. Deleting one of the copies deletes both of them. See attached screenshot.
Created attachment 362956 [details] screenshot with duplicate instance of an appointment You can see a Test appointment with two occurences, the first one is to be modified. When saving the modifications, I get an error message and a second copy of the instance appears.
Two additional comments: Version are - evolution-3.26.1-1.2.x86_64 - evolution-ews-3.26.1-1.1.x86_64 on an openSuSE Tumbleweed system with latest snapshot installed. The problem occurs *every time* when modifying a single event out of a series. So if you need debug information, it should be easy to create some.
Thanks for a bug report. I tried to reproduce this, but no luck. I do not get any error when saving the modification, which eventually explains why I do not see the issue as such. I tried with Office365 server, Exchange 2013 and Exchange 2010 and all of these work properly. My exact steps: a) File->New->Appointment b) fill summary, time and recurrence for 5 occurrences c) save it d) double-click the 3rd occurrence, which opens an editor e) change time and into Summary add " modified" text f) save it Once the server notifies about the changes being saved, I see a short flash of the whole series and the week/month view contains all what it is suppose to contains and nothing more. Could you try with those steps, please? Do you know the version of the Exchange server you connect to? Could you capture a debugging log of the evolution-calendar-factory, to see what exchange is done between the server and the client, please? It would be ideal to capture the log for the whole test (all test steps from the above). The log can be caught when the factory is run from a terminal like this: $ EWS_DEBUG=2 /usr/libexec/evolution-calendar-factory -w &>log.txt The actual path to the process can be different in your distribution. Note that the log contains a raw communication between the server and the client, thus it can expose your events and such. Be careful before attaching it here. If you are unsure, then feel free to send the log only to me, only mention this bug report in the message subject, thus I'd not overlook it in my spam folder. Once you have the factory running run evolution and repeat the steps. Ideally use some unique event summary, thus it'll be easy to search for it in the log.
Exchange Server is Version 15.1 (Build 845.34) aka Exchange Server 2016 Enterprise with Exchange Server 2016 Cumulative Update 5 (CU5). I reproduced all your steps (see attached screenshots) and got the error messages and a duplicate appointment again.
Created attachment 364138 [details] screenshot series from reproducing the suggestes steps
Regarding the debug output: I started evo with the calendar factory in debug mode, but after about 10 minutes evo showed a message "Unable to connect to "Kalender": Timeout was reached". I have about 10.000 appointments (lots of series) from about 20 years in my calendar, so it may be a bit too much to log when starting?
I noticed one thing in your screenshot series, you didn't set a reminder for the event. Is the reminder added automatically by evolution, or by the server? I ask this, because some servers (like Google) can change the event when added. The code (CalDAV in case of Google) counts with such option and reads the event back, before it confirms it for the UI. I do not recall whether I ever saw such behaviour with Exchange EWS servers, though I do not have Exchange 2016 server available. The closest I have is outlook.office365.com, which may or may not be exactly the same as the one for Office365 users (whom pay for the service). Your server supports NTLM and Negotiate (Kerberos/GSSAPI) authentications, while the outlook.office365.com only Basic authentication. Maybe it's not related. Going through your log you, I see only two errors there (search for ResponseClass="Error") about "Id is malformed" and looking into the response evolution-ews made it makes sense, because it used ID generated by Evolution, not by the Exchange server. I believe it's due to an attempt to read the event back. I'll investigate it further, it can be related to the error message you see. I beleiv eonce we fix the error the rest will work just fine. I only need to figure out how to reproduce it here, thus I could investigate the cause and correct it.
This Exchange Server is my own server and it is an on premise machine, so I'm sure it is different from the office365 servers. But if you want me to test anything regarding the server, I'd be willing to do so. The reminder is added by evo. Exchange doesn't set reminders on its own. In Outlook you always have to set a reminder manually or configure a default reminder - nearly the same behaviour as in evo.
I tried to reproduce this locally, but no luck. I do not receive the error as you. I see the "Id is malformed" in my EWS log, but it doesn't propagate into UI. I do not know, maybe, is your sever reachable from outside? If it is, could you create a test account for me, just for a little time, thus I'd be able to try to reproduce the bug with your server, please? I do not want you to share the server address here, neither the credentials, better if you'd send them to me privately, to my bugzilla email similarly as before, with the log. It seems to me that the server does something differently that those mine, while I do have older servers than yours for testing. I tried to modify the event in OWA, while evolution-ews didn't know about the change, but it was no problem for it, it accepted my local change anyway and overwrote changed I made in OWA with no error thrown.
Sorry for that, but my Exchange server is not reachable from outside 8-( I'd never dare to expose Exchange to the internet. Setting up a second test machine also would be difficult, because I'd have to install an Active Directory Domain controller, too. Doesn't Red Hat provide such an environment?
Okay, no problem, it was just an idea. See comment #3, I have some servers on which I can test, but not the 2016. For me, when I change one of the instances, I see the whole series quickly flash, which is done due to it being updated with the version received from the server. Could you test one thing for me, please? It's with steps from comment #3. After the step c), right-click one of the events from the series and choose "Save as iCalendar". I'd like to see the file content, with anything private removed. You can remove X-EWS-ORIGINAL-COMP as well, there's a base64-encoded content of the event. After you save it, try to right-click the EWS calendar in the left tree and pick "Refresh". Wait a bit, the event may eventually flash. Then continue with the steps. Will it work this time, or it'll break the same as if you didn't Refresh the calendar?
I attach the modified ics file. Your suggested alternative way to modifying the appointment led to the same result as before - a duplicate entry.
Created attachment 364342 [details] testappointment
Thanks for the update. The attached event looks fine, it has expected UID and also X-EVOLUTION-ITEMID and X-EVOLUTION-CHANGEKEY, thus everything it should have. I'm out of idea what to try next.
I retried with evolution 3.26.3 and evolution-ews 3.26.3, but still no luck. I do not see any event duplicated in the Month view after I edit it in evolution. The only error I can get out of it is with these steps: a) create new recurring event, say with 5 recurrences b) edit the 3rd event and pick "This instance only" c) edit the 3rd event and pick "All instances" this time It results in: Cannot modify calendar object: Invalid object Which makes sense, but the error message itself can be smarter, or the UI should not offer to modify all instances on a detached instance. d) retrying to save the event with "This instance only" works correctly. Unfortunately it's nothing what you see. There had been released 3.26.4 this Monday, but there's nothing important for your issue. Does your distribution offer you at least 3.26.3 of both, please? Could you retest with it, if it does, please?
Thx for trying with 3.26.3. 3.26.3 got installed on my client last week. Unfortunateley the problem remained. I tested it again a few minutes ago, just to be sure.
Tested with evolution-3.26.4-1.1.x86_64 today - same results 8-(
Could you capture the EWS_DEBUG log, as stated at comment #3, please? That's important to see what the server returned. Are you able to rebuild evolution-ews locally with any test patch, to gather more detailed and focused debugging, please? Building evolution-ews is pretty simple (with compare of evolution-data-server and evolution significantly), you might only install development packages for evolution-data-server and evolution, and also libmspack, and then it should just build [1] (supposing the development packages will bring in also their dependencies). You might build into the system prefix, which means that building through the package system might be easier, with less manual steps. Also, what is your libical version, please? [1] https://wiki.gnome.org/Apps/Evolution/Building#Build_evolution-ews
As for the DEBUG log - do you mean activating it and reproducing the errorneous behaviour by repeating the same steps? libical version is libical2-2.0.0-3.3.x86_64. In the meantime I'll go and try to compile evolution :)
Compiling exchange-ews gives "enchant/enchant.h: No such file or directory". I searched the net, but couldn't find this header file. I installed the devel package for evolution and libmspack before, then ran the script from the linked page. ----------------------------------------------------------------------- zypper in evolution*devel The following 16 NEW packages are going to be installed: evolution-data-server-devel evolution-devel gsettings-desktop-schemas-devel libgnome-desktop-3-devel libical-devel libsecret-devel mozilla-nspr-devel mozilla-nss-devel typelib-1_0-Camel-1_2 typelib-1_0-EBook-1_2 typelib-1_0-EBookContacts-1_2 typelib-1_0-EDataServer-1_2 typelib-1_0-EDataServerUI-1_2 typelib-1_0-GnomeDesktop-3_0 typelib-1_0-Secret-1 webkit2gtk3-devel 16 new packages to install. ----------------------------------------------------------------------- zypper in libmspack-devel The following NEW package is going to be installed: libmspack-devel 1 new package to install. ----------------------------------------------------------------------- What am I missing here?
ok, succeeded - the package enchant-devel package was missing
Next step – I tested a lot with the newly compiled evolution-ews version. And, tata - good news: The tests from my original report now work like a charm :) - created a new appointment with three occurrences - modified subject of the second one and saved it - no errors at all and no duplicate entry - modified time of the second one and saved it - again no errors at all and no duplicate entry One small problem remains: Deleting the modified entry deletes it from the Exchange calendar, but it remains in the local cache until Evo is restarted; if I delete one of the non modified entries they disappear immediately. Don't know, though, if this all happens because of a newer version (it has 3.24.7 in the version info) or if the improvements simply stem from compiling it on my local machine? In the next step I will start a test series for the problematic meeting requests I mentioned in the mailing list. Thx a lot for your help so far!
Grmbl, I reinstalled the original openSUSE version of evolution-ews, tested again and got even better results - everything works as described in comment 22 plus deleting the modified entry also works and the occurrence disappears immediately. So I have to apologize for all the trouble. As you presumed already, the problem has probably been caused by my Exchange Server - I updated Exchange to 2016 CU8 the same day I described the problems with meeting requests in the mailing list. Obviously the solved the problem. One difference between the openSUSE version and the version I compiled exists, though: In the openSUSE version a few calendar elements show up, that can't be deleted. Trying to do so results in an error the element doesn't exist. In my version those elements don't show up any longer. I can switch between the two versions, and the visibility of those elements also switches forth and back. So I have two working versions with different small flaws: In openSuSE's evo modified and deleted elements disappear immediatley, but I have elements that can't be deleted. With the other version the latter works, but the former does not.
Ah, okay, no problem. Knowing what the server did wrong, there could be added another workaround, thus users of such Exchange version(s) would not be affected (it depends on the actual issue, of course). With respect of different behaviour, unless you made a typo in the version numbers, then the compiled version was 3.24.7, but your system version is 3.26.3 or later, which contains significant change in the inner data storage, which explains why they both show different content.
The log entry says: User-Agent: Evolution/3.24.7 But I used your instructions to clone and build evolution-ews, so I wonder why it is such an old version - and why it still works with evolution core being version 3.26.3. I ran these commands: ------------------------------------------------------ $ cd $HOME/sources/ $ git clone git://git.gnome.org/evolution-ews $ cd evolution-ews $ git checkout -b gnome-3-24 origin/gnome-3-24 $ mkdir _build $ cd _build $ cmake .. -G "Unix Makefiles" \ -DCMAKE_BUILD_TYPE=Debug \ -DCMAKE_INSTALL_PREFIX=$PREFIX \ -DLIB_SUFFIX= \ -DWITH_MSPACK=ON $ make && make install ------------------------------------------------------- Should I have changed the gnome version in the checkout command?
Right, those instructions had been written in time of 3.24.x being the latest stable version. I'm not updating the Wiki page each 6 months. Thus to get different version you might adapt the checkout command, like the gnome-3-26 branch will pick the 3.26.x evolution-ews. Staying at master will give you the development version. The build of older/newer plugin against newer/older dependencies can work as long as there is no API change. It's good to stay with the same versions, because some changes land to evolution-data-server or even to evolution itself, even they can be reported against evolution-ews. As this got resolved by the Exchange server update, I'd say that you can safely use your system evolution-ews.
Did it and for the moment most things work as expected. I have to check for modified invitations from outside, though. Nevertheless I'll close this bug now. Many thx for your help and patience.