Integrate with Nextcloud CalDAV API [$185]

[juliusknorr]

This issue is about integrating deck with Nextclouds CalDAV API.

Current plan from the discussion below:

Deck	CalDAV	Tasks
Board	VCALENDAR	List
Stack	VTODO without RELATED-TO property	Root-Task
Card	VTODO with RELATED-TO (UUID of the Root-Task / Stack)	Subtask
Tags	CATEGORIES or custom implementation (Nextcloud tagging system)	Currently uses CATEGORIES, integration with Nextcloud tags would be better, see nextcloud/tasks#89
Assigned users	ATTENDEE or custom implementation	ATTENDEE or custom implementation, see nextcloud/tasks#72
Recurring stacks & cards	RRULE	Recurring tasks & subtasks, see nextcloud/tasks#34
Attachments	ATTACH or custom implementation	ATTACH or custom implementation, see nextcloud/tasks#91

Tags, assigning users, attachments and recurrence is not supported by Tasks yet either, but it would make much sense to implement these features. And if we see that it is not really possible to implement this with pure CalDAV I would be open to implement it without syncing it via CalDAV and have it only available in the webinterface. This would still be better than not having it at all in Tasks and would not limit Deck.

1. Expose deck boards as VCALENDAR, try to map as much data from deck to the VTODO (read only access) Expose boards as calendars #1545
2. Allow updating VCALENDAR entries, try to map as much as possible from vtodo to the deck database and store the rest as plain vtodo data, so we can still push it out over CalDAV (write access) Write access over CalDAV #2399
3. Deck data could be moved to the DAV backend.

[joergmschulz]

as sharing the cards is essential, a log of changes to

Activities

would be nice.

[poVoq]

Would it be possible to have a common due date that is linked with the calendar as a shared event between multiple cards as a "milestone" with its own colored label displayed on the card? I.e. some sort of way to link labels to CalDav events?

[poVoq]

Another possible integration would be to link cards to CalDAV task categories, so that if a user creates a new CalDAV task in an external application (lets say OpenTasks on Android) and chooses the right category for it, Deck automatically uses the name of that category to sort it to the card with the same name.

[juliusknorr]

I thought a lot about how to integrate with the Nextcloud WebDAV/CalDAV/CardDAV interfaces, it will be not as simple as i initially thought. I'll take some time next week to write up what i had in mind and publish some kind of roadmap. 😉

[simonpostma]

If subtasks become a thing in Deck, it can easily compete with whatever kanban system out there. Keeping the syncing with Tasks optional would be great imo.

Perhaps a functionality to make multiple decks if that is possible?

[9662]

XMPP group-chat notifications for activities would be also nice.

It is a reasonable idea, but it belongs to the notifications part of Nextcloud, not to Deck.

Would it be possible to have a common due date that is linked with the calendar as a shared event between multiple cards as a "milestone" with its own colored label displayed on the card? I.e. some sort of way to link labels to CalDav events?

Reinventing the bug tracker? They're supposed to complement, not duplicate each other. You can probably do this already via webhooks from your bug tracker anyway.

[poVoq]

@9662:
Regarding the first comment: maybe, but you might not want to spam your group-chat with all the file etc. changes, while deck and task updates might be more interesting.

Regarding the second: no, what have milestone dates to do with a bug-tacker? I think it is worth to have common event linked date labels on the cards so that it is quickly visible to the users what kind of common deadlines might be related to which cards.

[juliusknorr]

nextcloud/server#2829 will allow apps to register custom sabre plugins, if this is in we could create our own CalDAV endpoint at /dav/deck that will allow users to subscribe to within their calendar apps.

Here is a short summary of what I planned for that endpoint:

• A board should exposed as a VCALENDAR
• Cards will be exposed as VTODO
• Due dates can be added and exposed as VEVENT
  My first plan was to just add the due dates to existing calendars, but it looks like there is no easy way to do that at the moment. Also there are to many issues with calendar permissions and adding to much complexity, so I think the above proposed solution will be the best way.

Another possible integration would be to link cards to CalDAV task categories, so that if a user creates a new CalDAV task in an external application (lets say OpenTasks on Android) and chooses the right category for it, Deck automatically uses the name of that category to sort it to the card with the same name.

@poVoq That should be possible with the above solution.

Would it be possible to have a common due date that is linked with the calendar as a shared event between multiple cards as a "milestone" with its own colored label displayed on the card? I.e. some sort of way to link labels to CalDav events?

@poVoq This is a far more advanced feature. Let's just focus on the basics for now.

If subtasks become a thing in Deck, it can easily compete with whatever kanban system out there. Keeping the syncing with Tasks optional would be great imo.

@simonpostm That should not be a problem, if there will be a dedicated dav endpoint for the deck app.

Perhaps a functionality to make multiple decks if that is possible?

@simonpostma Not sure if I understand that correctly. Can you describe that a bit more?

XMPP group-chat notifications for activities would be also nice.

It is a reasonable idea, but it belongs to the notifications part of Nextcloud, not to Deck.

👍

Hope I didn't forgot to comment on something. 😉

[simonpostma]

@juliushaertl

I uninstalled Deck because i need my kanban to have more features at this point in time (cant wait for the next update so i can drop my current Kanban service and start using Deck :D), hasty as i was i didn't remember that Deck already has the feature to make multiple boards. Sorry for that.

[simonpostma]

Is there any ETA on the next update? Not trying to pressure you, just can't wait to exchange kanbanflow with Deck

[juliusknorr]

Sorry for the delay, I've been quite busy this week. It is on my list for the upcoming week.

[simonpostma]

It's clear you're very busy. Do take your time! I'll be looking to donate some to you after it's released.

[andreasjacobsen93]

I think we should explore more how deck and tasks can be integrated? I think it could result in some really valuable features.

[poVoq]

Any update on the CalDAV tasks and calendar integrations?

[e-alfred]

Would a Deck webdav endpoint be automatically added to the Calendar/Tasks app or do users have to manually add them?

[juliusknorr]

nextcloud/server#2829 will allow apps to register custom sabre plugins, if this is in we could create our own CalDAV endpoint at /dav/deck that will allow users to subscribe to within their calendar apps.

I've just updated the PR to nextcloud/server#6835 to get this moving again.

Would a Deck webdav endpoint be automatically added to the Calendar/Tasks app or do users have to manually add them?

The only issue I see after digging a bit into the sabredav/Nextcloud dav code is, that we cannot easily add the boards to the list of a users calendars. Maybe we need some API for that on the server side. Without that you would need to add it manually.

[juliusknorr]

I took some time to dig into the Nextcloud dav app. Here are some notes about the planned implementation. Feedback is very welcome.

Implementation

• Extend classes from \OCA\DAV\CalDAV (CalendarRoot, Calendar, Home, Calendar, CalendarObject, CalDavBackend)

• With Let apps register Sabre plugins or collections (v2) server#6835 register our own sabre collection

• add a collection at /deck with calendar collections at /deck/user/deck-1

• add VTODO entries for every card there

• Showing them in the calendar is part of the caldav client (Thunderbird already has an option for that)

• We should have an additional field for every card to store vtodo properties we don't have mapped to card values (and show them in the ui, like PERCENT-COMPLETE, PRIORITY

Mapping VTODO -> Card

• DUE: duedate
• SUMMARY: title
• DESCRIPTION: text
• CATEGORY: tags
• STATUS: archived/unarchived
• URL: url to the card

Open issues to discuss

calendar-home-set

Calendar collections cannot be added to the principals calendar-home-set. Maybe we need to extend Nextclouds CalendarHome::getChildren so apps can add their own entries to the home collection

Stack representation

Since nested calendar collections are not possible (something like deck-1/stack-1/card-1.ics) are not possible, we still need to figure out how we can represent the current stack in the caldav representation:

• we could just obmit it, users can then access their cards for now but not move them between stacks (that is what i would prefer for now)
• we could create a calendar collection for each stack ( deck-1-stack-1/ deck-1-stack-2/) but that would lead to a huge amount of calendars that would appear in the caldav clients ui
• We could use the category property, but that should imo be used for tags.

[slowhand93]

First of all: thanks for your work Julius! I love Deck.

Regarding stack representation:
I would prefer your second option because I use Deck to organize my days/weeks. So I often move cards between stacks. When I'm understanding you right, this wouldn't be possible if I will use the caldav feature?!

[poVoq]

Hmm... while not perfect, it might be doable to represent stacks via the priority value as usually the stacks are related to some sort of todo, backlog etc. system that is similar to priorities.

[juliusknorr]

@poVoq That could be a solution, either that or maybe we abuse the LOCATION field which is a string value so we could at least show the stacks name.

[laurentiu2]

didn't I moved it once?

maybe showing all calendars as a drop-down list?

[animorphcoop]

Thanks to everyone for continuing the development, we've just made a contribution via Bountysource supporting Deck&Calendar integration!

[juliusknorr]

Hey there,

I'd just like to let you know that due to the ongoing issue with Bountysource we're discussing ways to move to a different platform. As it looks right now, Bountysource might claim some of the money that was contributed by the community. We will try our best to prevent that. Historically we – the Nextcloud GmbH employees – simply put the claimed bounties back to other tickets until one was solved by a community member. So the money was always from the community and for the community. We'll therefore move to a better platform and currently don't post any new bounties until this situation is resolved. The current goal is to move/donate the money to Nextcloud include but details will follow in the forum post.

Hope this makes sense. If you have any questions please ask them on the forum. This comment will be copy-pasted to all open issues with bounties.

[makayabou]

Will wait for it to send a bounty, then. thanks

[rfc2822]

I have just tested CalDAV read access and it works fine with DAVx5!

Just wanted to now that on Android / with the OpenTasks API, task lists can't be set as write-only (yet): dmfs/opentasks#851

So people can edit/modify tasks locally, but the changes can't be synchronized to the server. → Write access over CalDAV would be really nice 😏

[juliusknorr]

Moved out #2399 for the write support so we have an individual ticket to track this.

[q-wertz]

Didn't find this in the discussions and not sure if it is worth an issue.
So far all the tasks of a Deck where one is participant are published as ToDo. Wouldn't it be more straight forward to only see the tasks one is assigned to?
It makes it quite confusing to have now dozen of Tasks one is not assigned to.

[juliusknorr]

Closing this as the first integration part is done and we will track write access in #2399

[devvv4ever]

Having a CalDAV integration is crucial for us, so I was thinking a little bit about the integration... In Oct 2017 you guys were discussing about whether or not categories should be used for stacks. I'd strongly vote for it.

The reason is that you should keep in mind how a client, that isn't aware of a Kanban-style tasks list, would represent these tasks. Just think of the "demo board":

Creating a VTODO per card would create the tasks "Write a press release", "Take nice screenshots", "Write a blog" and "Think of a slogan". This is without any doubt what a user would expect. But also creating a VTODO per stack would also create the tasks "Todo", "In progress" and "Done". What are these tasks supposed to represent? Those tasks can't be assigned to anyone, they can't ever be completed, because that's not what stacks are for, and they will dangle around in every other CalDAV client.

Just a small addition here: why not considering implementing https://tools.ietf.org/html/rfc5545#section-3.6.3 VJOURNAL for such things? VJOURNAL is part of the CalDAV API and it can be used more straightforward as a note or a "simple" task without the need of an end-date or progress. With the RELATED-TO field they could be assigned to an existing VEVENT or VTODO. We hope to get VJOURNAL synchronization into DAVx5 in the future. We want to get that into a supporting app that can display VTODO and VJOURNAL at the same time.

[HLFH]

@devvv4ever Create a feature request?

[PhrozenByte]

@HLFH See #2399 (comment), it's an implementation detail of this partially implemented feature, i.e. no separate feature request.