Removal of *DAV


(Cédric Krier) #1

Rational

I have been thinking about the all DAV modules we have: webdav,
calendar, calendar_classification, calendar_scheduling, calendar_todo
and party_vcarddav. They have many issues:

  • They are stuck in Python 2 because of pywebdav
  • They are not really tested
  • They do not pass all the Litmus tests
  • They have open issues

Indeed I think there is very few interest for those modules and it seems
logical because they do not fit well in core business of Tryton.

Proposal

My proposal is to drop those modules and replace some features with a
different implementation.

Implementation

webdav

I think the only nice feature is the possibility to share attachment
with non-user using a key. For me, this feature could be implemented
using a route for attachment and manage authentication using the key or basic.

calendar*

This can be replaced by dedicated CalDAV software like CalendarServer, DAViCal or Radicale. Most of them support LDAP for user authentication, so there is a way to share authentication with Tryton.

party_vcarddav

This module has a useful feature of exporting all the parties as VCard. I think we could expose via an HTTP route those VCards and use Basic Authentication to control access.


(Mark Shane Hayden) #2

I have used Calendar functionality in the past, though the calDAV aspect of it was secondary. It was used to implement an online booking application, where users could purchase a paid service (which was set up as a product) and the calendar module was used to keep a schedule of events/appointments. It was quite convenient to have such a feature that was easily integrated with sales.

That said, I can see how it would be a burden to maintain a calendar server within the Tryton modules from a developer perspective. Perhaps if calendar modules were replaced by different ones that acted as calDAV clients rather than a server? There are a lot of business use cases for integrating ERP with calendars…hotel and restaurant reservations, events like seminars and conference sessions, appointment booking for tradespeople like plumbers, mechanics, etc. So I think Tryton should still have core modules that can manage to at least integrate relatively seamlessly with a good calendar server.


(Cédric Krier) #3

Indeed I do not think there are so much. What we often have is documents with date and the willing to show them on a calendar view. And this is already supported by both Tryton clients.

Of course there are python libraries that implement CalDAV clients and they could be used in trytond. But I doubt this is something really manageable because the nature of a CalDAV is to be editable by the user and so very fast you will have de-synchronized records.
Indeed I think there could be some module that export a ics file like I propose to do to replace party_vcdardav.


(Thierry Bruyere) #4

We tested the calendar module with Thunderbird as a synchronization client. We use a sharing calendar for logistics.
10 people use this sharing calendar to encode arrivals and shipments.

When installing with Tryon 4.2, we found different problems with the python package vobject (version 0.9.x). We also have problems with event deletion and rights management on calendars (permission only for reading).

It is true that Tryton does not have the mission of being a calendar server and that other solutions already exist.

It would be a waste of time to review the module to correct the various problems.

At first we wanted to display tryton data in calendar events (link to the purchase order, link to the sales invoice …),
but after analysis this data is difficult to link to an event Because the records in the calendar are free for the user (no format imposed).
The idea of ​​having the possibility to export a calendar in ICS is interesting to take the information in another client like Thunderbird.

I also confused the calendar view and the calendar module which are two different things. The calendar view will remain in Tryton.


(Sergi Almacellas Abellana) #5

After digging a little bit about it found the icalendar python pacakge which is in active development and supports py27 and py33+. This package can be used to generate a ics file for any data in the tryton database. They have examples on their documentation.

I found this interesting to expose calendar using a custom route (and manage authentication if required) to third party users (or to mobile devices). I don’t know if we should have some example module in base (like we do with authentication_sms).

And I agree to the proposal about replacing party_vcardav


(udono) #6

for me this is a good idea, because we would be able to persist dates into an
external *DAV server and communicate with it.


(Cédric Krier) #7

I’m not sure to understand. Are you talking about implementing a CalDAV client inside the Tryton client?


(udono) #8

No, I don’t think so. It reduces to just using a python client lib[1] to store dates from Tryton to a separate CalDAV-Server, if needed.
Migration from Tryton CalDAV to another Server could be done in a similar way.

[1] https://pypi.python.org/pypi/caldav


(dimitrisand) #9

Is it possible to integrate tryton with another open souce collaboration type software like owncloud or nextcloud(more complete in my opinion) ?


(Cédric Krier) #10

It depends of your definition of “integrate”.
If they support LDAP, it is possible to share users thanks to the ldap_authentication module.


(dimitrisand) #11

I think this might help.
https://docs.nextcloud.com/server/10/admin_manual/configuration_user/user_auth_ldap.html

I would like to add that I am an accountant with some very basic knowledge of programming and some things are difficult to understand.
Thanks for your help


(Felipe Morato) #12

Having Tryton behave as a Caldav client seems interesting, even if it would be a one way only sync.

Is there already some work on this being done? I couldn’t find.


(Cédric Krier) #13