Thanks for a bug report. This is related to bug #795197. Where/how to use that from within evolution itself I'm not sure yet.

With respect of descriptions, those are not stored anywhere in the ESource-s, neither there's a place where to show it. They are shown only when searching for DAV calendars/books.

Why isn't ESource extended to store the description?

The description could be shown both as a tooltip, when the mouse is over the calender/address book, and in the 'Properties' dialog.

On an account containing collections, the 'Refresh' button is supposed in addition to synchronizing the properties of the individual collections, also to synchronize the list of collections: addimg/removing CardDav and CalDav collections, to whatever the server state is.

(In reply to Дилян Палаузов from comment #2)
> Why isn't ESource extended to store the description?

Because there was no need for it yet? Because nothing but CalDAV has it, and it's rarely used, from my point of view?

(In reply to Дилян Палаузов from comment #3)
> On an account containing collections, the 'Refresh' button is supposed...

Is it? Those nodes are not selectable in Calendar/Tasks/Memos/Contacts views at all, but I agree with you, it's a good candidate for that functionality.

WebDav collections have properties, in particular description, display-name, colour.

CardBook, a CardDav client for Thunderbird, lets users choose colour per address book starts typing recipients, the autocomplete suggestions are coloured with the corresponding address book.

So it is not only CalDav but also CardDav, where description and colour would make sense.

(In reply to Дилян Палаузов from comment #5)
> WebDav collections have properties, in particular description, display-name,
> colour.

Please, do not mix things together. WebDAV, CardDAV and CalDAV are three different things. All WebDAV collections (and resources) have displayname property. CardDAV has addressbook-description property. CalDAV has calendar-description and calendar-color properties.

> CardBook, a CardDav client for Thunderbird, lets users choose colour per
> address book starts typing recipients...

Then they use something non-standard, or they do not save it on the server, because there is no color property in CardDAV (RFC 6352), there's only addressbook-description available.

> So it is not only CalDav but also CardDav, where description and colour
> would make sense.

Right, I wasn't specific enough, it's CalDAV and CardDAV, where the description can be used, but nothing else. Evolution(-data-server) can work with more than these two.

Ah, now I see it:

Going to Edit > Accounts, opens a window with title "Evolution Accounts".  Expanding there a collection account, selecting a webdav or caldav type, clicking on 'Browse', opens a new aspect of the window called again "Evolution Accounts" with the features I was looking for - updating the properties on the server.

Moreover, selecting a CardBook on the first window and choosing 'Edit' opens one set of properties, but selecting a CardBook on the second windows and choosing 'Edit' show other properties.

Hence the functionality I asked for is available, but it is however quite hidden and not intuitive.  

Could you change the 'type' for CardBooks from 'webdav' to 'carddav' in the first window, in the same way 'CalDav' is shown as type?

What is the point of the button "Create collection", that exists new "Create Book"?  In my case "creating a collection", when address books are selected, creates a new address book, and "creating a collection", when calendars are selected, creates a new calendar.

Would it be possible to unify both windows:

* 'Browse' and 'Refresh' are enabled, when a user clicks a collection account.
* When a user clicks 'Edit' on a collection, she can change Name, Colour, Mark as default, Copy Content Locally, Use Secure connection, (NEW) Server handles invitations, (NEW) Description, Refresh period.
* Show two colour and two name properties, called "Local colour", "Remote Colour", "Local Name" and "Remote Name".  If the user wants to manage local and remove colours for the collection, these shall be shown in the same window, the current state is very confusing.
* The buttons "Create Book", "Create Calendar", "Create Collection" are enabled, whenever a collecion or a webdav/caldav/carddav accounts are selected.

What is the point distinguishing between local and remote colour and local and remote name?

When the remote Name or Colour of a collection is  is changed, there shall be means to update automatically also the local name.  In particular, when the name over the second window is changed,

The 'Browse' window doesn't show what is configured on the local machine, but what is available on the server. There's a big difference between the two. The 'Browse' interface works directly with a WebDAV server. It's not supposed to be easily accessible, I think, because users can break things easily there.

The "caldav"/"webdav" source types (backend names) come from the .source files. See bug #788370 (but do not reopen it, please).

Adding a collection account g@aegee.org offers "Collection" > "CalDav server", type "caldav", which creates account of type "caldav", and >" CardDav server", where as type is written "carddav", but the created account types are of type "webdav".  Why does a "CardDav server" write as type "carddav", but creates accounts of type "webdav", whereas a "CalDav server" shows as type "caldav" and creates accounts of type "caldav"?  Shouldn't the server offerning webdav account be also called 'WebDav'?

What exactly can a user break easily on the server?

Let's take a user having Evolution on two computers with the same collection account, e.g. at home and at work, containging a caldav collection, set up on both computers.  Now the user wants to change the colour and name of a calender, that is displayed in evolution on one the computer and synchronize the changes on the other computer.
1. The displayed name in Evolution cannot be changed, only using by "Browse" the name on the server can be changed.  So the user has to go to "Browse", change the name, then to delete the collection on both computers, and install it again on both computers with the new name.
  
2. The user has to change not the name, but the colours used for the caldav collections on both machines.  The user can change the colour on the server using 'Browse', but apart from this she has to change the local colours individually.  So to change a colour of a caldav collection, the user has to change it on three places, or more, if she uses more clients.

Are these workflows in the interest of the users in order to protect them from breaking something?

Now the user wants to create a new remote caldav collection.  The user clicks "Browse", then creates the collection.  The goes "Back", then installs a new account, different from the initial colleciton account which hosted "Browse", and installs there the new caldav collection, instead of clicking just on a "Create a new remote calender", which is immediately afterwards displayed also as locally syncrhonized caldav collection within the collection account.

Do not mix multiple things in the same bug, please. I know those things are related, but this is getting long and will be hard to follow soon. For webdav/caldav source types see the bug I referenced in comment #8. I do not have more to say for it.

For changes on the server, that's this bug about, no need to repeat it several times here. Once the Refresh for the collection account is implemented, or when you restart evolution-source-registry process, or when the whole machine goes offline for more than 5 seconds and then back online, you get the new/changed/deleted collections you did in the 'Browse' function. Again, changes for this bug are going to improve this situation.

With respect of syncing the name/color pair with the server, there are always two opinions on this. Some users prefer to be able to change both/either of these on each machine, some want them all synchronized. The current situation is that users can have names/colors stored independently from what is on the server. I do not say it cannot change, but it's not the task for this bug report for sure, neither the discussion where and how this should be done.

I am not sure on what there is already a consensus in regards of what shall it be at the end and as consequence of the unclear consensus, I wrote quite a lot.  

- What shall be the workflow in evolution to change the colour of a caldav calendar in one instance and have the change sinchronized on another computer?

- What shall be the workflow in Evolution to change the name/description of a caldav-calendar/carddav-addressbook in one instance and syncrhonize the changes on an Evolution running on another computer?

I also don't understand why users what to change properties only locally.

https://bugzilla.gnome.org/show_bug.cgi?id=788370  is about user invisible changes - how source files are organized, here I am asking modalities visible by the user - why a CardDav server creates accounts of type webdav, but a Caldav server creates acccounts of type caldav?  Shouldn't the former be called webdav server, if the accounts created on it are "webdav accounts"?

With the below changes, users can click Refresh in Edit->Accounts when a collection account is selected, the same as they can right-click the account name in the Contacts, Calendar, Memos and Tasks views and when it'll be a proper account an option to refresh list of account sources is offered. It only initiates the refresh, but it doesn't wait for the real result of the operation.

I'm not answering the other questions from comment #11, because I do not want to add more confusion to this bug report. There should be "one bug one issue" ideally and you mix here things from bug #788370 and from bug #795869. Maybe I'll reopen bug #795869, I think I can make it work for both use cases.

Created commit 1a05ba089e in evo master (3.29.3+)
Created commit_ba57c43 in ews master (3.29.3+) [1]
Created commit_4767237 in ema master (3.29.3+) [2]

[1] https://gitlab.gnome.org/GNOME/evolution-ews/commit/ba57c43
[2] https://gitlab.gnome.org/GNOME/evolution-mapi/commit/4767237

(In reply to Milan Crha from comment #12)
> Created commit 1a05ba089e in evo master (3.29.3+)

Err, I made a mistake in the error message indexing, which is corrected with:

Created commit d664c17079 in evo master (3.29.3+)