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:
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.
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.
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.
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.
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
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.
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