Bug 1029105 - evolution calendar colour setting for owncloud calendar breaks on each load
evolution calendar colour setting for owncloud calendar breaks on each load
Status: CLOSED NEXTRELEASE
Product: Fedora
Classification: Fedora
Component: evolution (Show other bugs)
19
Unspecified Unspecified
unspecified Severity unspecified
: ---
: ---
Assigned To: Matthew Barnes
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2013-11-11 11:50 EST by J
Modified: 2014-04-23 02:53 EDT (History)
4 users (show)

See Also:
Fixed In Version: evolution-data-server-3.12.2
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2014-04-22 07:25:08 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
Broken colour settings - three different colours being used for same calendar? (45.74 KB, image/png)
2013-11-11 11:50 EST, J
no flags Details

  None (edit)
Description J 2013-11-11 11:50:00 EST
Created attachment 822498 [details]
Broken colour settings - three different colours being used for same calendar?

Description of problem:
The colour tag as part of evolution for a calendar view is lost on first loading of evolution for an owncloud calendar added via Gnome online accounts.

Version-Release number of selected component (if applicable):
evolution-3.8.5-2.fc19.x86_64
evolution-data-server-doc-3.8.5-6.fc19.noarch
evolution-data-server-devel-3.8.5-6.fc19.x86_64
evolution-data-server-3.8.5-6.fc19.x86_64
evolution-bogofilter-3.8.5-2.fc19.x86_64
evolution-rss-0.3.93-3.fc19.x86_64

How reproducible:
This behaviour has been present since I linked my owncloud server to Gnome.

Steps to Reproduce:
1. Link owncloud server to Gnome
2. Open evolution go to calendar, set default colour for calendar by right-clicking and selecting properties
3. Close evolution and shutdown workstation or do evolution --force-shutdown
4. Start workstation and evolution or just start evolution if --force-shutdown used
5. Go to calendar find calendar entries being shown with faint pink colour.
6. right-click on calendar select properties calendar colour shown as black (different to small square shown in calendar list) but the calendar entries are not given black colour nor was black the selected colour previously.
7. Select a new colour "purple"

Actual results:
Loss of calendar colour selection which effects the calendar entries and the properties menu.

Expected results:
Calendar colour does not change once selected.

Additional info:
Closing and restarting evolution does not lead to colour loss. However closing evolution and then doing evolution --force-shutdown from the cmdline does.
Comment 1 J 2013-11-12 11:46:32 EST
I've noticed this appearing:
(evolution:2138): Pango-CRITICAL **: pango_color_parse: assertion `spec != NULL' failed
When I move to the calendar could it be related to the issue?
Comment 2 Milan Crha 2013-11-15 14:41:17 EST
Thanks for a bug report. The color chosen in Calendar Properties should stick, maybe the thing that you have it configured through GOA makes the difference.
I would even try Fedora 20, with evolution 3.10.x, which might have this fixed (though I do not have on mind any particular fix).
Comment 3 Dominik Grafenhofer 2014-04-19 05:05:28 EDT
I have the same problem on Fedora 20 (under gnome 3.10 and 3.12). As Milan suspected, I also use the calendar via GOA (owncloud).
Comment 4 Milan Crha 2014-04-22 03:59:46 EDT
Ah, I see from the code that the ownCloud calendars use color as defined on the server, it tries to keep the calendar color consistent with the server side, thus the color changed locally is dropped on a resynchronization. I'd guess from the comment #1 that your ownCloud calendar doesn't have assigned any color on the server.

It would be interesting to see what color your server supplied, as the parsing routine failed to decode it, but there is currently no extra debugging for ownCloud discovery.

Anyway, I think I can handle the issue with incorrect/unknown color format. I do not want to disable calendar color sync with the server, because I think it's a nice feature to get the color synchronized with the color being set on the server and being used in the web UI of ownCloud.
Comment 5 Milan Crha 2014-04-22 07:25:08 EDT
I made some changes in evolution-data-server to address this, though it would be still interesting to know what colors are returned by the server, whether the claim is correct or not. My ownCLoud server returns correctly encoded colors, they look like #rrggbb, where rr, gg, bb are 2-digits hexadecimal numbers.

Created commit 02cf0bb in eds master (3.13.1+) [1]
Created commit 546cd59 in eds evolution-data-server-3-12 (3.12.2+)

[1] https://git.gnome.org/browse/evolution-data-server/commit/?id=02cf0bb
Comment 6 Dominik Grafenhofer 2014-04-22 08:14:20 EDT
Milan, you are right! After picking colors in owncloud calendar, evolution correctly set the colors as well. For me that is good enough! In case you want me to hunt down your remaining question: How can I check which colors are returned by the server?

Still, (a part of) the original bug persists and has not been fixed: color changes in evolution are not synced with the server.
Comment 7 Milan Crha 2014-04-23 02:53:22 EDT
(In reply to Dominik Grafenhofer from comment #6)
> Milan, you are right! After picking colors in owncloud calendar, evolution
> correctly set the colors as well. For me that is good enough! In case you
> want me to hunt down your remaining question: How can I check which colors
> are returned by the server?

That's OK, the information that you had not chosen any color for the calendar on the ownCloud server is sufficient.

> Still, (a part of) the original bug persists and has not been fixed: color
> changes in evolution are not synced with the server.

Evolution doesn't "upload" the calendar color change, to be honest, I do not know how to do it. Let's have this done this way for now.

Note You need to log in before you can comment on or make changes to this bug.