Thanks for a bug report. I'm afraid it's not possible to backport just evolution-ews, because it depends on evolution and evolution-data-server and the evolution-data-server changed its API heavily in time of 3.34 development (move to libecal-2.0, using libical-glib instead of libical, D-Bus APIs also changes in an incompatible way), thus that would mean to rebase also anything what depends on libecal, libedata-cal, libebook and libedata-book, which starts with gnome-shell and continues across other not only GNOME applications, like gnome-todo, gnome-calendar, gnome-notes, gnome-contacts and so on. Some close-to-complete list of affected applications can be found here: 
https://gitlab.gnome.org/GNOME/evolution-data-server/issues/33

That the D-Bus API changed means that applications which rely on evolution-data-server D-Bus services (like those in Flatpak) cannot run unless they are built against the same version of evolution-data-server as the host machine has. It brings a lot of trouble, both ways.

Thus the rebase is not an option unless doing a lot of other things together with it.

If you can specify what exactly is missing, then I can check whether it can be backported. Note that some features/fixes in evolution-ews can mean changes on either (or both) of evolution and evolution-data-server sides.

The Fetch URL is not necessary to add an EWS account, it's used only to populate OAB URL (Offline Address Book), and even its usage is disabled by default (it's at the bottom of the Receiving Options tab, "Cache offline address book" option).

I can find the commits related to autodiscovery and backport them. I would ideally provide a test package with those changes added, to have it tested on the user's side, because different servers can behave slightly differently.

Hi guys.  My TAM customer provided the privately attached video with the following details:

"Configuring using the following steps (shown in the attached video). We need to kill evolution before it picks up the settings. Does not see what is configured."

Ah, I see, the problem is elsewhere, not in the autodiscover. The video shows that the autodiscover worked properly, the OAB URL was found as expected, furthermore, even you left the Host URL filled with an artificial value provided by evolution-ews itself, the evolution-ews was able to pick the correct host and fill the settings.

Did you install evolution-ews within the same GNOME session? Or did you restart the machine after installing evolution-ews? There used to be a problem with added modules for running background services, but the related code is part of the 3.28.5 of evolution-data-server, thus it's either not it, or the code doesn't work for some reason.

Is /usr/lib64/evolution-data-server/ directory on a local machine? Anything like ext4 or similar partition type? Not all partitions support the directory content monitoring.

I tried to reproduce it here, but no luck. What I did:

a) uninstall evolution-ews and update packages
b) create a new user
c) restart the whole machine (also [*])
d) log in as the new user (GNOME Standard Wayland session)
e) open a terminal and install evolution-ews
f) run evolution - since now it looks like in your video, I'm greeted with a new mail account wizard, where I created an EWS account
g) once I finish the wizard, the account is shown immediately in the account list, below the On This Computer, on the left side of the Mail view

Either what you face is not related to the later install of evolution-ews, or I do something differently. I use glib2-2.56.4-7.el8.x86_64 , if it makes any change, and the partition type I have is plain ext4, no LVM or anything like that.

Could you confirm that when you install evolution-ews and then restart the machine it adds the mail account properly immediately after the new mail account wizard is finished, please? The other questions from comment #7 still apply.

Thanks in advance.

------------------------------------------------------------------------------------

[*] before doing the restart, I also renamed
    /usr/libexec/evolution-source-registry
    to 
    /usr/libexec/evolution-source-registry.orig
    and created a new /usr/libexec/evolution-source-registry file with this content:

#!/bin/bash

FILESUFFIX=`date +%Y%m%d-%H%M%S`

export G_MESSAGES_DEBUG=all

ESR_DEBUG=1 /usr/libexec/evolution-source-registry.orig "$@" &>/var/tmp/esr-${FILESUFFIX}.log

   and then set executable attribute on the new file:

   $ chmod a+x /usr/libexec/evolution-source-registry

This enables debugging for the source registry and writes it to the log in /var/tmp/ the next time it is started.
The log should contain "ews:Collection" (quotes for clarity only), when evolution-ews is installed. The install of the evolution-ews also triggers reload of the evolution-source-registry, which is indicated in the log with "Reloading..." line (quotes for clarity only).

There had been filled a similar bug report upstream [1] from Arch Linux with evolution-ews-3.34.2. I'm afraid something misbehaves with respect of the folder content change notifications, or something around the module loading (notification received before all needed libraries are on their places or anything like that?).

Paul, do you have the information I asked for above, please?

[1] https://gitlab.gnome.org/GNOME/evolution-ews/issues/82

Sorry for the delay on responding. 

The issue is to do with the various evolution processes not running.
Install and restart it is possible to setup Evolution-ews.

However I am seeing 2 other issues.

- username on setup screen gets truncated (grant_williamson.com becomes grant_williamson) minor but I do not see this with the flatpak build.
- the calendar fails to load on the el7 build, hangs the evolution-ews client

Created attachment 1643810 [details]
EWS log requested

We are actually performing the testing on EL 7.7.

- On 8.1 we see the same issue where the calendar fails to load and evolution hangs.

This issue is not present on the upstream flatpak version.

(In reply to Grant Williamson from comment #10)
> The issue is to do with the various evolution processes not running.

Which of them do you mean, please? They are autostarted on demand.

> However I am seeing 2 other issues.

I'd prefer not to mix different things into one report. Let's keep this one for "configure account after having installed 3rd-party plugin, without restarting background processes".

> - username on setup screen gets truncated (grant_williamson.com
> becomes grant_williamson) minor but I do not see this with the flatpak build.

That's intentional and expected.
https://gitlab.gnome.org/GNOME/evolution-ews/commit/bb75f62b9d96e07a

> - the calendar fails to load on the el7 build, hangs the evolution-ews client

How does it hang it? If you mean evolution itself, then could you install debuginfo for evolution-data-server, evolution, evolution-ews, glib2 and gtk3 (make sure the package versions will match those already installed), and then get a backtrace of the stuck process(-es), please? You can get the backtrace with command like this:
   $ gdb --batch --ex "t a a bt" -pid=`pidof evolution` &>bt.txt
Please check the bt.txt for any private information, like passwords, email address, server addresses,... I usually search for "pass" at least (quotes for clarity only).

(In reply to Grant Williamson from comment #11)
> EWS log requested

If I read the evolution-source-registry log properly, then it was made after the account was configured and evolution-ews already installed, which is the working state. I hoped to see a log of:
a) remove all EWS accounts from Evolution
b) uninstall evolution-ews
c) restart machine
d) start evolution-source-registry with debugging on
e) install evolution-ews (after completed, the log should have stored something like "reload")
f) start evolution
g) configure Exchange Web Services account
And now it should not be visible in Evolution, if it'll misbehave like before. Or was there a different reproducer for you, please?

If evolution-ews is installed and the machine is rebooted. Evolution ews configures email correctly.

"Which of them do you mean, please? They are autostarted on demand."
On EL7 we do not include evolution or evolution-ews in the base image. If the processes are autostarted correctly on demand, why must I logout/login or reboot after installing evolution-ews, even on a clean system? Is this a bug or working as designed?

If the layer we could work around this by including evolution-ews in our EL8 base image or inform users to logout/login or reboot after installing.

On the calendar issue, I will open a new ticket.

typo "If the layer" "If the later"

Opened a new bug - https://bugzilla.redhat.com/show_bug.cgi?id=1782177

(In reply to Grant Williamson from comment #15)
> On EL7 we do not include evolution or evolution-ews in the base image.

That should not be a problem, because the background processes I talk about, which start with 'evolution-', are not from Evolution itself. Evolution is "just" a front end (one of several) for evolution-data-server, which provides those background processes. That is installed by default, especially when GNOME is installed, because gnome-shell package depends on evolution-data-server package.

> If the processes are autostarted correctly on demand, why must I logout/login
> or reboot after installing evolution-ews, even on a clean system?

That's this bug about, from my point of view and I'm still gathering the information (from you).

> If the layer we could work around this by including evolution-ews in our EL8
> base image or inform users to logout/login or reboot after installing.

I would not do that, having evolution-ews preinstalled will bring in also the evolution package.

> On the calendar issue, I will open a new ticket.

Thanks.

Could you give me an exact reproducer, please? Ideally in a form as I wrote above, at the end of the comment #14.

(In reply to Grant Williamson from comment #12)
> We are actually performing the testing on EL 7.7.

Hmm, I just noticed this bug is filled against RHEL 8. Should I change it to RHEL 7 instead?

Reproducer

a) Install EL7 Workstation from kickstart excluding evolution and evolution-ews
b) Configure machine, login to gnome desktop
c) install evolution-ews
d) start evolution
g) configure Exchange Web Services account
Issue is seen as in the film.

The issue is present on EL7.
Please change it to EL7.

Thanks, I'll try it here. I've more recent RHEL7, but I hope it won't have much influence on this.

I am able to reproduce this, with your steps from comment #20. I left most of the things in the defaults during the installation, especially the LVM partitioning. My other machine, with ext4, doesn't suffer of this.

Looking into the journalctl log I see this:

Dec 11 09:41:52 localhost.localdomain yum[3670]: Installed: highlight-3.13-3.el7.x86_64
Dec 11 09:41:53 localhost.localdomain yum[3670]: Installed: gtkspell3-3.0.3-4.el7.x86_64
Dec 11 09:41:54 localhost.localdomain yum[3670]: Installed: evolution-langpacks-3.28.5-8.el7.noarch
Dec 11 09:41:54 localhost.localdomain gnome-software[2526]: failed to rescan: Failed to parse /usr/share/applications/org.gnome.Evolution.desktop file: cannot process file of type application/x-desktop
Dec 11 09:41:55 localhost.localdomain gnome-software[2526]: failed to rescan: No valid root node specified
Dec 11 09:41:55 localhost.localdomain yum[3670]: Installed: evolution-3.28.5-8.el7.x86_64
Dec 11 09:41:55 localhost.localdomain yum[3670]: Installed: evolution-ews-langpacks-3.28.5-5.el7.noarch
Dec 11 09:41:55 localhost.localdomain evolution-sourc[2265]: module_load: libevolution-ews.so: cannot open shared object file: No such file or directory
Dec 11 09:41:55 localhost.localdomain org.gnome.evolution.dataserver.Sources5[2024]: Failed to load module: /usr/lib64/evolution-data-server/registry-modules/module-ews-backend.so
Dec 11 09:41:55 localhost.localdomain gnome-software[2526]: failed to rescan: No valid root node specified
Dec 11 09:41:55 localhost.localdomain yum[3670]: Installed: evolution-ews-3.28.5-5.el7.x86_64
Dec 11 09:41:55 localhost.localdomain evolution-calen[2555]: e_intervaltree_destroy: assertion 'E_IS_INTERVALTREE (tree)' failed
Dec 11 09:41:55 localhost.localdomain gnome-shell-cal[2260]: The calendar backend for 'Birthdays & Anniversaries' has crashed.
Dec 11 09:41:55 localhost.localdomain gnome-shell-cal[2260]: The calendar backend for 'Personal' has crashed.
Dec 11 09:41:55 localhost.localdomain gnome-shell-cal[2260]: The calendar backend for 'Personal' has crashed.

If I read it properly, then while yum was still installing evolution-ews, the evolution-source-registry noticed the new file (module-ews-backend.so) and wanted to load it, but it failed, because the required library (libevolution-ews.so) was not installed yet. That means that the disk notifications work properly, it only tries to load the new module too early, before all of its dependencies are also installed.

That would explain why the processes need restarted.

I made a change upstream [1] for 3.35.90+ and 3.34.4+, where I set 10 seconds delay to load newly detected modules. That gives enough time to the installer to copy all the required files to the directories where the new module expects them (like private libraries, which happened here).

Another option would be to manage this on the .spec file level, to invoke restart of the background processes after the installation is finished (it can have similar side effects, like eventually losing not saved data on the factory side when the reload/restart is requested).

The upstream change can be backported.

[1] https://gitlab.gnome.org/GNOME/evolution-data-server/commit/07609c656

Unable to reproduce with evolution-data-server-3.28.5-5.el7

Does that mean the issue is fixed in evolution-data-server-3.28.5-5.el7 ?

Yes, the issue is fixed in evolution-data-server-3.28.5-5.el7

Sounds great! When can we have them test it on their machines?

I see on our site the current available version is 
Package - evolution-data-server-3.28.5-4.el7.x86_64.rpm

https://access.redhat.com/downloads/content/rhel---7/x86_64/2456/evolution-data-server/3.28.5-4.el7/x86_64/fd431d51/package

Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory (evolution-data-server bug fix and enhancement update), and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHBA-2020:3995