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 743131 - “Personal” calendar can’t be removed
“Personal” calendar can’t be removed
Status: RESOLVED DUPLICATE of bug 442398
Product: evolution-data-server
Classification: Platform
Component: general
3.12.x (obsolete)
Other Linux
: Normal normal
: ---
Assigned To: California Maintainers
California Maintainers
Depends on:
Blocks:
 
 
Reported: 2015-01-18 16:10 UTC by Profpatsch
Modified: 2015-02-15 15:41 UTC
See Also:
GNOME target: ---
GNOME version: ---


Description Profpatsch 2015-01-18 16:10:57 UTC 
I don’t want to have an offline calendar, but cannot remove it (delete button is greyed out).
Comment 1 Jim Nelson 2015-01-20 21:34:41 UTC 
This is a limitation of Evolution Data Server, not California.  I believe it's non-deletable because EDS needs one "default" calendar in case no other are available.
Comment 2 Profpatsch 2015-01-24 11:46:01 UTC 
I don’t agree with this being resolved.

This is definitely a bug, since I don’t want that calendar and have four others. Even if it is a transitive bug, it is still a bug in California.
Comment 3 Jim Nelson 2015-01-26 20:14:29 UTC 
Then file a new ticket or re-open this one, but mark it for Evolution-Data-Server.  Their library will not allow for us to remove that calendar, it's as simple as that.
Comment 4 Profpatsch 2015-01-28 00:27:23 UTC 
Done, if I did everything right it should now be on evolution-data-server.
Comment 5 Milan Crha 2015-02-10 18:34:51 UTC 
Thanks for a bug report. All the On This Computer/Personal books, calendars, tasks lists and memo lists are built-in sources, with which the code counts as the last resort, just as Jim said in comment #1. Except it's not a limitation, but a design.

There is a bug #442398 opened for Evolution to be able to reorder and eventually hide sources which users do not like. I guess, if you want to hide certain sources in California, then they should have implemented this hiding on their own. There can be used e_source_get_uid() to know the unique identificator for this purpose, but definitely nothing to be done on the evolution-data-server side.

I think you can disable the ESource, but that would influence all other applications as well, which is not what you want for sure, thus the only option is to provide a per-application (client) functionality for this hiding for now. Maybe the above mentioned bug will introduce new properties of some ESource extensions which might be shared between clients, I do not know yet.
Comment 6 Profpatsch 2015-02-11 17:40:38 UTC 
So, should I move it back to California? :)
Comment 7 Jim Nelson 2015-02-11 21:43:27 UTC 
No, California supports hiding calendars.  Use the checkbox beside the calendar name.
Comment 8 Milan Crha 2015-02-12 07:51:18 UTC 
(In reply to Jim Nelson from comment #7)
> No, California supports hiding calendars.  Use the checkbox beside the
> calendar name.

Nice, in that case I close this in a favor of bug #442398 for evolution. It also allows hiding events from any calendars, but not those calendars in the list of available calendars.

*** This bug has been marked as a duplicate of bug 442398 ***
Comment 9 Profpatsch 2015-02-15 15:41:44 UTC 
@Jim Nelson:

Ah, I had missed that, thanks!