CardDAV implementation in Tryton

Support Developer
21

I made a very basic version of a vcard export

here is the commit on my github repo: add very basic vcard export · LordVan/tryton-modules@0bf92a0 · GitHub

(i think for thunderbird to be able to connect i need to also route .well-known,… if i look at the request log:

Thu Jun 01 11:44:37 2023] INFO:trytond.wsgi:<Request 192.168.69.1 'http://192.168.0.9:8000/tryton_test/party/carddav' [GET]>
Thu Jun 01 11:44:41 2023] INFO:werkzeug:192.168.69.1 - - [01/Jun/2023 11:44:41] "GET /tryton_test/party/carddav HTTP/1.1" 200 -
Thu Jun 01 11:45:46 2023] INFO:trytond.wsgi:<XMLRequest 192.168.69.1 'http://192.168.0.9:8000/tryton_test/party/carddav/' [PROPFIND] (invalid WSGI environ)>
Thu Jun 01 11:45:46 2023] INFO:werkzeug:192.168.69.1 - - [01/Jun/2023 11:45:46] "PROPFIND /tryton_test/party/carddav/ HTTP/1.1" 405 -
Thu Jun 01 11:45:47 2023] INFO:trytond.wsgi:<XMLRequest 192.168.69.1 'http://192.168.0.9:8000/tryton_test/party/carddav/' [PROPFIND] (invalid WSGI environ)>
Thu Jun 01 11:45:47 2023] INFO:werkzeug:192.168.69.1 - - [01/Jun/2023 11:45:47] "PROPFIND /tryton_test/party/carddav/ HTTP/1.1" 405 -
Thu Jun 01 11:45:48 2023] INFO:trytond.wsgi:<XMLRequest 192.168.69.1 'http://192.168.0.9:8000/tryton_test/party/carddav/.well-known/carddav' [PROPFIND] (invalid WSGI environ)>
Thu Jun 01 11:45:48 2023] INFO:werkzeug:192.168.69.1 - - [01/Jun/2023 11:45:48] "PROPFIND /tryton_test/party/carddav/.well-known/carddav HTTP/1.1" 405 -
Thu Jun 01 11:45:51 2023] INFO:trytond.wsgi:<XMLRequest 192.168.69.1 'http://192.168.0.9:8000/tryton_test/party/carddav/' [PROPFIND] (invalid WSGI environ)>
Thu Jun 01 11:45:51 2023] INFO:werkzeug:192.168.69.1 - - [01/Jun/2023 11:45:51] "PROPFIND /tryton_test/party/carddav/ HTTP/1.1" 405 -
Thu Jun 01 11:45:52 2023] INFO:trytond.wsgi:<XMLRequest 192.168.69.1 'http://192.168.0.9:8000/tryton_test/party/carddav/' [PROPFIND] (invalid WSGI environ)>
Thu Jun 01 11:45:52 2023] INFO:werkzeug:192.168.69.1 - - [01/Jun/2023 11:45:52] "PROPFIND /tryton_test/party/carddav/ HTTP/1.1" 405 -
Thu Jun 01 11:45:53 2023] INFO:trytond.wsgi:<XMLRequest 192.168.69.1 'http://192.168.0.9:8000/tryton_test/party/carddav/.well-known/carddav' [PROPFIND] (invalid WSGI environ)>
Thu Jun 01 11:45:53 2023] INFO:werkzeug:192.168.69.1 - - [01/Jun/2023 11:45:53] "PROPFIND /tryton_test/party/carddav/.well-known/carddav HTTP/1.1" 405 -
Thu Jun 01 11:46:39 2023] INFO:trytond.wsgi:<XMLRequest 192.168.69.1 'http://192.168.0.9:8000/tryton_test/party/carddav/' [PROPFIND] (invalid WSGI environ)>
Thu Jun 01 11:46:39 2023] INFO:werkzeug:192.168.69.1 - - [01/Jun/2023 11:46:39] "PROPFIND /tryton_test/party/carddav/ HTTP/1.1" 405 -
Thu Jun 01 11:46:40 2023] INFO:trytond.wsgi:<XMLRequest 192.168.69.1 'http://192.168.0.9:8000/tryton_test/party/carddav/' [PROPFIND] (invalid WSGI environ)>
Thu Jun 01 11:46:40 2023] INFO:werkzeug:192.168.69.1 - - [01/Jun/2023 11:46:40] "PROPFIND /tryton_test/party/carddav/ HTTP/1.1" 405 -
Thu Jun 01 11:46:41 2023] INFO:trytond.wsgi:<XMLRequest 192.168.69.1 'http://192.168.0.9:8000/tryton_test/party/carddav/.well-known/carddav' [PROPFIND] (invalid WSGI environ)>
Thu Jun 01 11:46:41 2023] INFO:werkzeug:192.168.69.1 - - [01/Jun/2023 11:46:41] "PROPFIND /tryton_test/party/carddav/.well-known/carddav HTTP/1.1" 405 -

this is of course no carddav yet … just a vcard export, but it could be used for one-way sync already. I am still reading cardDAV RFC / looking for libraries

improvement suggestions / comments welcome. - also I can make this a seperate module later on if others are interested. - That said I think most people would want to customize stuff here anyway for custom fields,…

22

Should there be an interest in a more generic module/approach I would likely split it into sperate methods, so things can be overwritten per “line/attribute”

23

There is an interest to have such feature in standard (probably in a module party_carddav) with authentication.
About extensibility, it will probably be better to use a library like vobject so each party’s card can be easily extended.
The best would be to propose a merge request.

2 Likes
24

I’m a little bit concerned about vobject usage as it seems it has not have any new release in 5 years, nobody is answering issues and the organization behing it has no members. So it seems the project is no longer mantainded.

25

Indeed we plan to migrate our stack to icalendar

26

The discussion is related to contacts, not to calendars.

If there is no other library to generate the events. I think we can just return the raw text of each contact card in an extensible method (so it can be customized by third party modules).

27

I would prefer to use vobject than raw text even if vobject is not maintained for now (it can still be revived or forked).

28

Yeah I wasn’t sure about using vobject cuz of the last updates to it. but I guess it might be worth it (rather than starting with something similar from scratch … as you said it can be forked.