After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 264206 - fallback when BPROPFIND is blocked
fallback when BPROPFIND is blocked
Status: RESOLVED WONTFIX
Product: Evolution Exchange
Classification: Deprecated
Component: Connector
1.5
Other All
: Normal minor
: 2.5
Assigned To: Connector Maintainer
Ximian Connector QA
gnome[unmaintained]
Depends on:
Blocks: 327514
 
 
Reported: 2004-08-26 19:46 UTC by Dan Winship
Modified: 2013-07-23 14:30 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Dan Winship 2004-08-26 19:46:05 UTC
Connector could be made to fall back to using SEARCH and PROPFIND
when BPROPFIND is blocked:

    * e-cal-backend-exchange-calendar.c:get_changed_events() could
      just skip the BPROPFIND part, and rely on the loop of
      e2k_context_gets() afterward to get all of the body content.
      (IIRC, SEARCH will never return the PR_INTERNET_CONTENT
      property, so we can't just use SEARCH here.)

    * mail-folder-exchange.c:refresh_folder_internal() could be made
      to fetch both new_message_props and mapi_message_props in the
      initial SEARCH.

    * e2k-autoconfig.c:e2k_autoconfig_check_exchange() could be
      fixed to use PROPFIND after determining that BPROPFIND won't
      work.

    * e-cal-backend-exchange-calendar.c:book_resource(),
    * exchange-delegates.c:get_user_list()
      do not actually need to be using BPROPFIND. They could be
      rewritten to always use PROPFIND.

    * exchange-delegates.c:get_folder_security()
    * exchange-hierarchy-somedav.c:scan_subtree()
    * exchange-hierarchy-webdav.c:rescan()
      could use a series of PROPFINDS.

Most of these would result in decreased performance, so we'd only
want to do them if we knew BPROPFIND was going to fail. So we'd
probably want to still detect this in e2k-autoconfig, and set a
flag on the account or something saying to use the slower methods.
Comment 1 Rupesh Kumar 2009-03-08 02:17:38 UTC
Hello, any update on this bug? Lot of people can not convince their admins to enable BPROPFIND
Comment 2 André Klapper 2012-09-20 14:50:44 UTC
The "evolution-exchange" package only supports Exchange 2000 and 2003 servers. Newer versions such as Exchange 2007 and 2010 are not supported by "evolution-exchange". It is required to use the package "evolution-ews" (or to some extend "evolution-mapi") for newer version fo Exchange servers.

If the problem/request described in this report still happens with a recent version of "evolution-ews" or "evolution-mapi", please add a comment to this report (and update the "product" setting accordingly if possible).

There are currently no plans to continue the development of the package "evolution-exchange", so this report will soon be closed as WONTFIX.
Thanks for your understanding and sorry that the reported problem was not solved in time in the package "evolution-exchange".
Comment 3 André Klapper 2013-07-23 14:30:56 UTC
evolution-exchange only supports the older Microsoft Exchange server versions 2000 and 2003. The last stable release of evolution-exchange was 3.4.4 which took place a year ago.

evolution-exchange is now deprecated and not under active development anymore.

It is unlikely that there will be any further active development.

Closing this report as WONTFIX as part of Bugzilla Housekeeping.

Please feel free to reopen this bug report in the future if anyone takes the responsibility for active development again.

Also feel free to reopen this ticket and change the "Product" field accordingly if the reported issue still happens with a recent version (newer than version 3.6) of one of those Exchange backends that are still supported.
Please see https://help.gnome.org/users/evolution/3.8/exchange-connectors-overview.html for more information on available backends.