Hi Milan,
I did some debugging too and I could get it working by fixing some bug
in e_webdav_session_extract_privilege_simple in e-webdav-session.c. I
believe the problem is the following:
When the privlieges are retrieved from the server, the relevant XML
snippet looks like this:
<D:current-user-privilege-set>
<D:privilege>
<D:read />
<D:write />
</D:privilege>
</D:current-user-privilege-set>
As you can see, the privilege node contains the two child nodes,
however when it's passed to e_webdav_session_extract_privilege_simple,
the for loop stops after evaluating the first one due to the break
statement and thus skips any further privileges.
So basically it boiled down to
e_webdav_session_extract_privilege_simple only returning a single
privilege and not the whole set which I think was the bug. Maybe the
for loop in e_webdav_session_current_user_privilege_set_cb was supposed
to deal with this...?
Anyway, my C is pretty rusty so I'd not consider my hacky workaround
code any good but if you think it is of any use to clarify the problem,
I can send you a diff.
Cheers,
Peter
On Tue, 2020-01-14 at 11:28 +0100, Milan Crha via evolution-list wrote:
> On Tue, 2020-01-14 at 07:43 +0000, Krauß, Peter (SCC) via evolution-
> list wrote:
> > I did indeed do several restarts (without success).
>
> Hi,
> just to be clear, I didn't mean restart of the whole machine, but
> restart of the calendar factory only, that is, of the
> evolution-calendar-factory process.
>
> You even do not need to kill the process to be restarted, just close
> evolution, open terminal and execute there:
>
> $ /usr/libexec/evolution-calendar-factory -w
>
> then wait for few seconds and only then start Evolution. Though I
> think
> you captured the log from the initial email in a very similar way and
> it still did not work, thus this won't work as well.
>
> Maybe you can run DBus monitor and search what it passed around. You
> might focus on "writable" and "Writable" (quotes for clarity only)
> signals/properties. The command is:
>
> $ dbus-monitor
>
> then I see for example this after I open a calendar which had not
> been
> opened yet:
>
> > signal time=1578997003.522247 sender=:1.181 -> destination=(null
> > destination) serial=878
> > path=/org/gnome/evolution/dataserver/Subprocess/6081/25;
> > interface=org.freedesktop.DBus.Properties; member=PropertiesChanged
> > string "org.gnome.evolution.dataserver.Calendar"
> > array [
> > dict entry(
> > string "Writable"
> > variant boolean true
> > )
> > ]
> > array [
> > ]
>
> followed by a method invocation response:
>
> > method return time=1578997003.522745 sender=:1.181 ->
> > destination=:1.226 serial=879 reply_serial=42
> > array [
> > string "alarm-email-address"
> > string "''"
> > string "cache-dir"
> > .....
> > string "writable"
> > string "true"
> > ]
>
> this is how the backends notify the clients about their state, one of
> them being writability. It's hard to recognize which calendar the
> response belongs to, that why I'd try on one, which is not opened
> yet.
> Note the dbus-monitor output will be very chatty, quite many things
> sends something over D-Bus all the time, thus expect interleaved
> output.
> Bye,
> Milan
>
> _______________________________________________
> evolution-list mailing list
> evolution-list@gnome.org
> To change your list options or unsubscribe, visit ...
> https://mail.gnome.org/mailman/listinfo/evolution-list
--
Peter Krauß <peter.kra...@kit.edu>
Karlsruher Institut für Technologie (KIT)
Steinbuch Centre for Computing (SCC)
Forschungsgruppe Cloud Computing
Hermann-von-Helmholtz-Platz 1
Gebäude 449/R105
76344 Eggenstein-Leopoldshafen
Telefon: +49(0)721/608-26578
E-Mail: peter.kra...@kit.edu
Web: http://www.kit.edu/
KIT - Universität des Landes Baden-Württemberg und nationales
Forschungszentrum in der Helmholtz-Gemeinschaft
_______________________________________________
evolution-list mailing list
evolution-list@gnome.org
To change your list options or unsubscribe, visit ...
https://mail.gnome.org/mailman/listinfo/evolution-list
