Is an implementation of this part of the GNOME plan/roadmap?

If not I don't have a problem at least trying to do something about it if someone can point me to the best place to get started, but I have zero GNOME development experience (I'm mostly a Python/web guy), so it would likely take me quite a long time!

It would be nice in any case to see expanded support for standards rather than just specific services, although I appreciate that many users will have Google/Yahoo/MSFT accounts etc.

I'd also be interested to know if there is a plan to switch away from Evolution piece by piece, given Notes and Contacts as existing applications, and gnome-calendar as a WIP (though from https://git.gnome.org/browse/gnome-calendar/log/ it seems this hasn't seen much attention since last May?) If so I guess that would imply an eventual Tasks application, and obviously email (Geary?)

+1 +1 +1

As there is "Owncloud Connector" it should be quite easy to strip the carddav and caldav components to seperate account connectors. Not everybody is using Owncloud but a lot of opensource Groupwares do have a carddav + caldav interface.

At least:
* groupoffice
* zimbra
* zafara
* eGroupware

This would be really a great improvement!

Just a little references:
addressbook-home-set CardDAV property [1], similar to calendar-home-set CalDAV property. The evolution's detection code [2] can find there, tested with Zimbra and Kolab, it's only not using them. I tried to separate the code out of evolution, by changing the ownCloud stub, but Zimbra server doesn't talk to me the same way as it does from evolution (even I do not see any difference in requests I send towards the server), thus I have only this evolution code reference. (My test code did work with Kolab, though.) I couldn't test against an ownCloud server, it currently returns 503 Service Temporarily Unavailable.

Please note that the collection detection code can be fairly complex, thus the ideal way for GOA would be to provide detected sources with direct URLs, rather than a generic server address, as is done in the ownCloud case, forcing each interested party to duplicate the code for the source detection.

[1] http://tools.ietf.org/html/rfc6352#section-7.1.1
[2] https://git.gnome.org/browse/evolution/tree/modules/cal-config-caldav/e-caldav-chooser.c

*** Bug 737684 has been marked as a duplicate of this bug. ***

Agreed.
I need this feature too.

(In reply to Milan Crha from comment #3)
> ... thus I have only this evolution code reference...

This statement changed. There is a shared code available in evolution-data-server [1][2] now, which could be reused, if the evolution-data-server wouldn't depend on goa (circular dependency is not good). Feel free to pick it and change it as needed for GOA. Once it's done, I can add necessary code into the evolution-data-server, thus such GOA accounts will be understood by evolution and other clients of evolution-data-server.

This code is currently used (in the development git master version) by both evolution-data-server and evolution itself, and works (was tested) with Google, ownCloud, Zimbra and DAViCal servers, where it can find all calendars, memo lists, task lists and address books (for example I  didn't know that Google offers a CardDAV address book too).

[1] https://git.gnome.org/browse/evolution-data-server/tree/libedataserver/e-webdav-discover.h
[2] https://git.gnome.org/browse/evolution-data-server/tree/libedataserverui/e-webdav-discover-widget.h

I really miss this feature too. Just add an other generic online account like the IMAP-SMTP one but with CardDAv-CalDav should be easy right?

Created attachment 320435 [details] [review]
caldav-carddav-providers.patch

This patch will add two new providers: CalDAV and CardDAV. As you may see, both are based on the OwnCloud provider. The new providers are separate because almost all implementations I’ve seen of these protocol from commercial providers and open-source software use different URLs for CalDAV and CardDAV. Each of the new providers takes one URL to a address book or calendar resource, username, and password.

A future version of this should implement auto-discovery of resource collections (multiple calendars and address books) from DNS-SD and .well-known URLs, but we’ve got to start somewhere so manually entered URLs are a big improvement over not being able to add your calendar and contacts in GNOME.

There is no provider group for calendar providers in GOA. A new group could be added, but I believe it would be better to repurpose the contacts group and relabel it “Groupware” or something similar. For now, the CalDAV provider appears in the contacts group along with CardDAV.

The providers don’t do anything just yet, but Milan Crha have told me on IRC that evolution-data-server will support these two new providers once this is integrated.

I hope the patch holds up to GNOME standards. This is my first patch to GNOME (and first time working with GTK).

Example of accounts from the new providers:

[Account account_1454592276_0]
Provider=caldav
Identity=example@fastmail.com
PresentationIdentity=https://caldav.messagingengine.com/dav/calendars/user/example@fastmail.com/93b21a71-601a-6666-abc4-a4f572f7898b
CalendarEnabled=true
Uri=https://caldav.messagingengine.com/dav/calendars/user/example@fastmail.com/93b21a71-601a-6666-abc4-a4f572f7898b
AcceptSslErrors=false

[Account account_1454592321_1]
Provider=carddav
Identity=example+Default@fastmail.com
PresentationIdentity=https://carddav.messagingengine.com/dav/addressbooks/user/example@fastmail.com/Default
ContactsEnabled=true
Uri=https://carddav.messagingengine.com/dav/addressbooks/user/example@fastmail.com/Default
AcceptSslErrors=false

This would be great, would allow support for Cozy as well: https://cozy.io/en/

Can someone with commit access to GOA chime in with what's needed to get Daniel's patch reviewed and added?

There's an ongoing irony that one of the leading free software desktop has full integration for several proprietary groupware services but doesn't support long-standing open protocols...! Hopefully Daniel's commendable effort to change this won't languish - it really shouldn't!

is there any activity in this regard?

Review of attachment 320435 [details] [review]:

The patch looks quite good for a first attempt. There are some niggles that I have pointed out below. I have one high-level question, though. We discussed various service discover options over email. eg., DNS SRV records and .well-known paths. Did you get to explore any of them?

::: src/goabackend/goacaldavprovider.c
@@ +1,3 @@
+/* -*- mode: C; c-file-style: "gnu"; indent-tabs-mode: nil; -*- */
+/*
+ * Copyright (C) 2012, 2013, 2014, 2015 Red Hat, Inc.

Are you sure you don't want to claim the copyright?

@@ +68,3 @@
+{
+  // TODO: Add new GOA_PROVIDER_GROUP_CALENDAR group
+  return GOA_PROVIDER_GROUP_CONTACTS;

I have submitted some changes to gnome-control-center (see bug 767401) that will help with this. Once those are in place, we can just return GOA_PROVIDER_GROUP_INVALID. (We will eventually get rid of the GoaProviderGroup APIs.)

@@ +154,3 @@
+          g_object_set (G_OBJECT (calendar),
+                        "accept-ssl-errors", accept_ssl_errors,
+                        "uri", uri,

This is incorrect. 'uri' is a pointer to a SoupURI, and the "uri" property expects a string.

Also, nowadays we have some helpers to simplify this code. eg., goa_object_skeleton_attach_calendar.

@@ +164,3 @@
+        goa_object_skeleton_set_calendar (object, NULL);
+    }
+

We are not listening to "notify::calendar-disabled". We should.

@@ +611,3 @@
+
+  g_cancellable_reset (data.cancellable);
+  goa_http_client_check (http_client,

Shouldn't we do a bit more than just checking if there is an HTTP server? The user specifically wants CalDAV, so we should check if it is actually that and not just a simple HTTP server. eg., GVfs' WebDAV backend sends OPTIONS and looks for "DAV" in the response headers.

ownCloud is a bit more complicated since it can have all these different things (WebDAV, CalDAV, CardDAV), but this one should be simpler to implement.

::: src/goabackend/goacaldavprovider.h
@@ +1,3 @@
+/* -*- mode: C; c-file-style: "gnu"; indent-tabs-mode: nil; -*- */
+/*
+ * Copyright (C) 2012 Red Hat, Inc.

Ditto.

I too need this feature. It seems weird that is omitted while smtp, imap are there :/

I also need this feature!

CalDav would be great! I sync thunderbird with EDS via Mozilla's add-on, but that is only read-only stuff and gnome-calendar cannot be used to modify the calendars.

BTW, "owncloud" type of online account does not seem to work with Nextcloud.

Looks like Daniel lost his motivation to continue working on his patch.

Re. ownCloud, seems like in GNOME 3.24 the account type has at least changed in name to Nextcloud; I can't attest to its functionality though.

Hi, I this is the first time I have touched on some gnome related code, but also attempted to add a caldav provider. Unfortunately I only saw Daniels patch afterwards, but it looks like we started from the same base file. I will upload my patch, which adds a caldav account, however I was so far unable to test if the calendar actually works. gnome-calendar does not list it nor could I find out how to debug this further, any pointers would be great. 

Currently this does only a basic PROPFIND and does not actually evalutate if the response is a valid caldav resource. Also potentially the provider may offer multiple calendars on that resource or only one. To be honest I haven't fully understand where the actual caldav handling happens once added, I assume this will be similar to the nextcloud/owncloud provider, but also there I was not able where caldav calls happen as the provider only seems to add the uri and credentials.

I am using SOGo and radicale, thus my motivation to add this. So far I am adding the calendars with the evolution UI.

Created attachment 352755 [details] [review]
WIP add caldav provider

(In reply to Johannes Zellner from comment #19)
> Created attachment 352755 [details] [review] [review]
> WIP add caldav provider

I'm not reviewing this, as I'm not the maintainer of the GOA, but after a brief look:
a) please change your server password, you just exposed it into the public
b) pronounce the "CalDAV" word properly in user-visible strings and comments,
   that way it'll look more proper for those whom care.

Oops, I also wanted to answer this:

(In reply to Johannes Zellner from comment #18)
> To be honest I haven't fully understand where the actual caldav handling
> happens once added

That's all done in evolution-data-server, from which evolution, gnome-calendar, gnome-shell and others read available sources/calendars/.... You are right about the ownCloud part, it'll be exactly the same code [1][2]. The evolution-data-server part can be done (and tested) only after GOA part is done.

I'd prefer to avoid code duplication, but it's highly out of scope of this bug report, thus I'd might do some evolution-data-server preparation later, before or after GOA is ready.

[1] https://git.gnome.org/browse/evolution-data-server/tree/src/modules/owncloud-backend?h=gnome-3-24
[2] https://git.gnome.org/browse/evolution-data-server/tree/src/modules/gnome-online-accounts/module-gnome-online-accounts.c?h=gnome-3-24#n91

Oh dear about the hardcoded creds, luckily that is only a test server but still should not have happend :-/

Thanks for the explanation with the links to the owncloud part for caldav. Will try to get that built so I can test the flow until further cleanup. 

Is the usual process to keep uploading patch revisions or is there some kind of merge-request style flow to iterate on proposed changes?

Created attachment 352765 [details] [review]
WIP add caldav provider

Incorporated some remarks for Daniel's very similar patch and put the provider in the hidden provider section.

Review of attachment 352765 [details] [review]:

Only two minor comments.

::: configure.ac
@@ +614,3 @@
         Pocket provider:                ${enable_pocket} (id:${with_pocket_client_id})
 	Last.fm provider:               ${enable_lastfm} (id:${with_lastfm_client_id} secret:${with_lastfm_client_secret})
+	Caldav provider:                ${enable_caldav}

one of user-visible strings (users, whom run ./configure)

::: src/goabackend/goacaldavprovider.c
@@ +53,3 @@
+/* ---------------------------------------------------------------------------------------------------- */
+
+static const gchar *CALDAV_ENDPOINT = ".well-known/caldav";

Not every server supports this, that's why I mentioned e-webdav-discover above, though it might be too much to be included in GOA as well (GOA cannot depend on eds, because eds depends on GOA). On the other hand, e-webdav-discover can find all of calendars, task lists, memo lists and address books, if the server is able to advertise them properly.

Would it make sense instead of somehow pulling in e-webdav-discover, to perform the following logic?

if (url contains a path) attempt with the url as is
else 
  test url + "/.well-known/caldav"
  test url + "/principals"
  test url as is

That way we could capture two somewhat common known urls as well as allow the user to give the server specific path (possibly even to only one calendar, when provided the specific calendar url).

*** Bug 767206 has been marked as a duplicate of this bug. ***

After trying further and looking into the e-webdav-discover code, it seems to me that instead of adding some half baked magic discovery into this provider, simply asking the user for the webdav resource uri instead of just the server origin, would work best and avoids unnecessary confusion. At least for radicale and SOGo, the user then can simply copy and paste the calendar url from the webinterfaces into the dialog form, similarily like thunderbird or davdroid work.

Created attachment 352793 [details] [review]
WIP add caldav provider

Use the same indentation style like in other files.
Do not append any predefined paths, as servers behave differently, but ask the user for the CalDAV Url instead.

Ideally this requires some header check if any DAV related headers are present. Not sure how this can be done with the goahttpclient implementation easily.

Unfortunately this introduces a new translatable string, to indicate "CalDAV Url" instead of "Server" to the user. Maybe could be renamed to "Resource Url" to make that reusable for a potential CardDAV provider.

(In reply to Johannes Zellner from comment #27)
> After trying further and looking into the e-webdav-discover code, it seems
> to me that instead of adding some half baked magic discovery into this
> provider, simply asking the user for the webdav resource uri instead of just
> the server origin, would work best and avoids unnecessary confusion. At
> least for radicale and SOGo, the user then can simply copy and paste the
> calendar url from the webinterfaces into the dialog form, similarily like
> thunderbird or davdroid work.

I would highly appreciate if there would be reasonable auto-discovery logic in the feature.
Usually CalDAV leads to more than one calendar being used. All reasonable implementations of CalDAV basically take a base-URL, discover all available Calendars from it and just give the user an option to select the calendars he wants integrated.
I use quite a lot of calendars and had to spend almost an hour to add all of them to Evolution manually, repeatedly entering the same information over and over, although there is at least some minimal way of discovery - base-URL and selection of *one* calendar per time.
The discovery logic present in DAVdroid for Android actually works pretty well from a user perspective.
Maybe some of that could be taken as a model for further work.

(In reply to Haley S. from comment #29)
> I would highly appreciate if there would be reasonable auto-discovery logic
> in the feature.

This discovery of available sources is done on the evolution-data-server side, for Google and ownCloud accounts provided by GOA/UOA (Ubuntu Online Accounts). This functionality is not used by evolution itself unfortunately, in a sense of being able to add multiple sources at once (yet).

GOA itself is pretty dumb (no offence meant) :) , in time of adding Microsoft Exchange accounts, which has a special server address for autodiscovery, there had been decided to provide only server entry point by GOA and all consumers should duplicate the autodiscovery code. That's the dumb part, the code duplication, but on the other hand makes also sense.

The CalDAV/CardDAV (the bug summary asks for both, not only for one) should behave similarly. Personally, both are WebDAV extensions, thus I'd make it simple for users and call the account type "WebDAV" in GOA (or advertise it as WebDAV by GOA). Then the consumers, like evolution-data-server, can use EWebDAVDiscover to search for both CalDAV and CardDAV sources at once. Of course, some servers provide different URIs for them, one for CalDAV, one for CardDAV, but this is already covered with ownCloud, which is just a specialization of this feature request (ownCloud uses CalDAV and CardDAV sources and GOA advertises URL for each separately). The trick is to figure out correct entry points on the server and verify credentials, which is the only work GOA does. You can issue OPTIONS request towards the server and as long as it returns DAV-related headers you can use that URL, because the user provided URL which points to DAV collection or resource (most of the servers require credentials to return OPTIONS, except of Google, from which I tried; iCloud's CardDAV server is not good with OPTIONS either, sadly [1], thus maybe your simple PROPFIND would be better option (by the way, what does that PROPFIND without body return? According to [2], it returns all properties and the Depth header is required. If I give it a calendar with 1000 events it'll give me all properties for all items in it, which might not be what you want to just verify credentials)). In any case, being it this way, evolution-data-server would do the discovery like with ownCloud, thus add all found (and advertised by the server) Calendars, Task Lists, Memo Lists and Address books.

[1] https://git.gnome.org/browse/evolution-data-server/tree/src/addressbook/backends/webdav/e-book-backend-webdav.c#n92
[2] https://tools.ietf.org/html/rfc4918#section-9.1

I agree with the argument to combine carddav and caldav into a single provider. I guess that is anyways the most common usage. I will try to adjust the patch for that. I am however not sure if webdav should also be combined into the same given that files as such conceptually don't have much in common with calendars and addressbooks in my opinion. At least I would not intuitively add a webdav account when trying to add a calendar.

Also good point about the request body. I have not thought of that.

For my understanding, does evolution-data-server handle files through webdav as well and if, how is that used within various gnome apps?

Right, "WebDAV" account name in GOA would be confusing, unless something like Nautilus handles it to read general resources. I cannot think of any better name though. Would be "CalDAV and CardDAV" account name in GOA too confusing for users, while they could left either of the two empty?

I do not want to make this overcomplicated though, even there are great features which can be used to lookup server entry points. The UI could look like with other accounts:

   Server:   [       ]
   Username: [       ]
   Password: [       ]

   [-] Advanced settings
   CalDAV URI:  [       ]
   CardDAV URI: [       ]

Maybe? The simple settings should discover the sources. You can use SRV records for the Server (you can find an example code in bug #750564), apart of /.well-known entry points. GOA should be able to use OAuth2 for the CalDAV/CardDAV sessions as well, when discovering URIs (I guess it's satisfied when using that GOA SoupSession wrapper).

As I said, I'm not the maintainer of GOA and I do not want to make this overcomplicated, thus I can imagine that the maintainer will be satisfied with some initial commit, then the feature could be enhanced later.

> For my understanding, does evolution-data-server handle files through webdav
> as well

Evolution-data-server uses only CalDAV and CardDAV extensions, one for Calendars/Task Lists/Memo Lists, the other for Address Books. It doesn't read general WebDAV resources/collections, neither advertise them to the public.

An EWebDAVSession [1] I added recently can do many interesting things with WebDAV servers, which I'd like to use within Evolution (one day).

[1] https://git.gnome.org/browse/evolution-data-server/tree/src/libedataserver/e-webdav-session.h

Milan:

Re. naming: "CalDAV/CardDAV" should work. It can mean "both" or "either" when written like that I think.

I don't think the proposed UI is clear in terms of a) overriding paths; b) enabling either/both components.

Presumbably the options would be:

* detect paths and available components (CalDAV/CardDAV) automatically
* specify components and paths manually.

Should there be an option for "detect paths automatically, but select components manually"?

What about something like:

Server:   [       ]
[-] Advanced settings
   [x] CalDAV
      Custom path:  example.com/ [       ]
   [x] CardDAV
      Custom path:  example.com/ [       ]

Username: [       ]
Password: [       ]

Given that ewebdavdiscovery anyways will do its own discovery, wouldn't it make more sense to let the user specify the URI pointing to the *dav root (most likely the server only, possibly the .well-known or principals/ paths) and then give the user the typical checkboxes if this online account should be used for Calendar and/or Contacts?
If we add more sophisticated logic into this provider, then it will eventually add corner-cases which clash with the ewebdavdiscovery mechanism, at least how I understand the connection between those two components.

(In reply to Stephen from comment #33)
> What about something like:

Sure, that would work for me too.

(In reply to Johannes Zellner from comment #34)
> Given that ewebdavdiscovery anyways will do its own discovery, wouldn't it
> make more sense to let the user specify the URI pointing to the *dav root
> (most likely the server only, possibly the .well-known or principals/ paths)
> and then give the user the typical checkboxes if this online account should
> be used for Calendar and/or Contacts?

Definitely allow specifying also paths, not only server names, because not every server has a root path capable of WebDAV. I'd say that most servers are in sub-paths. Even the ownCloud is, to name the one already covered in GOA.

> which clash with the ewebdavdiscovery mechanism

Yes, that's true, code duplication, as I mentioned above with Exchange (comment #30). The reason to do that in GOA is to verify that the credentials the user provided are correct. All the rest (real discovery) is left up to the consumer of GOA accounts (like evolution-data-server).

Just a note, I made some changes in evolution-data-server in preparation for this, it's for 3.25.90+. I've it ready in a state of a one-liner (for evolution-data-server) to be done to make this working there.

The important things:
a) provider type name. The latest proposed patch calls it "caldav". I suggest
   to use "webdav" instead, which can cover both CalDAV and CardDAV.
b) let it behave the same as ownCloud, which is, the GOA will provide either
   or both of CalendarURL and ContactsURL and evolution-data-server will use
   these to search for available sources (CalendarURL for calendars, memo
   lists and task lists; ContactsURL for contacts).

If you want to test this in evolution-data-server, then you can pretend the provider type to be "owncloud" and have set the URLs appropriately.

If we agree with the a) above, then I can make that one-liner immediately and it'll wait for the GOA change, while it'll start working for free, without a need to change anything further on the evolution-data-server side, once GOA bits are finished (supposing we'll agree with the b) above as well).

Add me to the list of supporters for this... I use (the hosted version of) Horde Groupware and this is one of my biggest gripes with Pop!_OS (which uses GNOME and many of its components/programs) - I can't synchronize my contacts (CardDAV)/calendar (CalDAV) with (GNOME) Contacts/Calendar.

I've managed to work around this by relying on the Web-based version of my contacts/calendar and my mobile devices (which DO support CardDAV/CalDAV)... But I shouldn't need to; I should be able to rely on my operating system's own contacts and calendar.

(In reply to Gregory Opera from comment #37)
> I should be able to rely on my operating system's own contacts and calendar.

You can do that, by manually entering them into Evolution. After that they will be available for anything using evolution-data-server, which includes GNOME Calendar and GNOME Contacts. If I'm not mistaken, then at least GNOME Calendar allows to add CalDAV calendars, thus you can do it there as well.

It's surely not that convenient as having a GOA account which would provide you all the configured Books/Calendars/Task Lists/Memo Lists automatically (which Evolution can do now too, with a Collection Account (3.28 material)), but it is possible at least.

Using that method, you would need to install Evolution (let's face - how many distros actually include Evolution these days?), THEN configure your respective CalDAV/CardDAV settings, THEN access said data in (GNOME) Calendar/Contacts, whilst keeping Evolution installed "just to make things work".

Sure it's a work-around... But it's a silly way of doing things and just complicates things for the sake of complicating things.

In fact, it's that sort of a work-around that is exactly WHY we need to be able to independently configure CalDAV/CardDAV in GOA...

Don't get me wrong, I'm not having a dig at you - I appreciate your suggestion - but it serves to demonstrate better than I did exactly WHY CalDAV/CardDAV support needs to be independently available.

Let's face it - many, maybe just not install /by default/. </offtopic>

*** Bug 791749 has been marked as a duplicate of this bug. ***

What is the status of this issue?

I cannot speak for GOA, but in Evolution itself Edit->Accounts->Add->Collection Account, fill there a server address (eventually with path to the CalDAV/CardDAV entry points) and then "just click forward".

Once the GOA part is done, evolution-data-server can be extended to listen to that account information too.

Wow, that's a very well-hidden feature, haha ;) When was that added?

It's really buggy though.

I have an email server where usernames are just the local part (i.e. someuser, not someuser@domain.com).

If I use the "SRV" and "CalDav/CardDAV" discovery options:

* If I enter just the email address:
  * It discovers all advertised SRV services (IMAP, SMTP submission, CalDAV, CardDAV)
  * It attempts user@domain as a username (and fails since that's the wrong username)
  * It *doesn't* then attempt the local part as username (which is a "SHOULD", per https://tools.ietf.org/html/rfc6186#section-4)
  * It prompts for username/password. Correcting the username and entering the password doesn't work
  * Looking in Accounts, it has created a "webdav" account, but with only an email sub-entry (no contacts, calendar, tasks or memos)
  * Looking in sending settings for the account, the account has *not* been configured to require auth (!)
  * Correcting the username in the account settings seems to fix IMAP auth.

* If I enter the (correct) username and enter the server separately:
  * It fails to discover the IMAP service per its SRV record, but finds the rest
  * Attempting this breaks subsequent account addition attempts - trying from scratch again with user@domain with no separate server still results in no IMAP discovery (until at least an Evolution restart)!

Other issues:

* Does "Look up for a CalDAV/CardDAV server" actually mean "use .well-known paths"? Since SRV/TXT are also a *DAV lookup method.
* "Look up *DAV" doesn't specify what server it will contact - the DAV server? GNOME's provider directory?
* The "Add" button on the accounts window is split, but the whole thing is a dropdown - should be a single button with arrow.
* Esc on the "Add account" window doesn't work
* When Evo is first run, the first-run wizard doesn't offer the "collection account" option at all.

Let's discuss Evolution issues in Evolution bug reports (ideally one report per issue), not in the GOA bug report (which is already quite long and quite hard to follow). Also, using the latest Evolution version (which is 3.30.2) with the same version of evolution-data-server is better, because there had been made related changes, like at least for the one about changed user name by the user.

By the way, when you hover mouse above the Server entry/label, you get a tool tip about a possibility to write more server addresses there.

> * Does "Look up for a CalDAV/CardDAV server" actually mean "use .well-known
> paths"? Since SRV/TXT are also a *DAV lookup method.

They are split.

> * "Look up *DAV" doesn't specify what server it will contact - the DAV
> server? GNOME's provider directory?

It talks to the server you entered.

> * The "Add" button on the accounts window is split, but the whole thing is
> a dropdown - should be a single button with arrow.

It depends, it looks like a combo (or as a combo used to look like).

* Esc on the "Add account" window doesn't work

True.

> * When Evo is first run, the first-run wizard doesn't offer the
> "collection account" option at all.

This is inaccurate. It's "when the Mail view is opened for the first time". It's from times when a mail account had been required, thus it want's to enter a mail account, not a generic account.

I'll raise separate issues :)

The intention wasn't to get answers for myself on BZ - rather it's that the information isn't being communicated effectively in the UI.

> It depends, it looks like a combo (or as a combo used to look like).

At least on 3.28.x, it's a combo with a divider, which is different from e.g. the undivided Show:[All Messages] combo in the mail view.

Hi there,

I made an interesting discovery today. I am using fastmail as DAV-Provider and thought: "Hey, what if I wrote my own server that pretended to be ownCloud and just redirect to fastmail?"

Long story short (and a few minutes coding later): https://gist.github.com/apollo13/f4fc8f33a2700dffb9e11c1b056c53ba

Run this server anywhere under your control and point gnome-online-accounts to it. The ownCloud provider tries to discover the DAV Urls and automatically follows the redirects to fastmail. It properly syncs contacts & calendars now!

I have deployed the app to heroku: https://davredirector.herokuapp.com/ -- you can use it if you are using fastmail. If not, redeploy it yourself and put in the proper DAV discovery URLs. Since my server does not require authentication no credentials are sent from goa to my server (at least I didn't see anything during development) -- but I fully understand if you do not trust me.

If you want to try it locally yourself you need python3.7 & poetry (https://poetry.eustace.io/). Then type:
poetry install
poetry run uvicorn --reload app:app

The server URL will be http://localhost:8000 -- enjoy :)

GNOME is going to shut down bugzilla.gnome.org in favor of gitlab.gnome.org.
As part of that, we are mass-closing older open tickets in bugzilla.gnome.org
which have not seen updates for a longer time (resources are unfortunately
quite limited so not every ticket can get handled).

If you can still reproduce the situation described in this ticket in a recent
and supported software version, then please follow
  https://wiki.gnome.org/GettingInTouch/BugReportingGuidelines
and create a new ticket at
  https://gitlab.gnome.org/GNOME/gnome-online-accounts/-/issues/

Thank you for your understanding and your help.