Deck updates from Reminder App (iOS) not syncing back

anagio · April 4, 2023, 6:10pm

Hi,

Tried to ask on Reddit but no response for 48 hours, so hopefully someone on here might be able to help.

I was so proud to get my deck(s) to show on my IPad Reminder app. Then I realised that any updates or newly created reminder did not sync back to NC Deck.

Despite trying to find anything online, I have drawn a blank. Maybe someone on here has a solution.

All I’m looking for is 2 way sync between a (free) iOS app and NC self hosted Deck.

stefan-niedermann · April 4, 2023, 6:14pm

By 'reminder` you mean the Due date or another feature?

I am the maintainer of the Deck Android app, therefore I can tell you that the Deck server app does not support any thing like a ‘reminder’ - the closest thing would be a due date.

So in case you mean the due date, that is probably a bug in the Deck iOS app, which you should report in their issue tracker (you should he able to find a link in the app store)

In case you are really talking about ‘reminders’: This is a featzre that can only work locally by design at this time - It can not be synchronized.

anagio · April 4, 2023, 7:31pm

Nothing to do with Android, it is NC self hosted syncing with iOS

NC → iOS working

IOS updated tasks in iOS reminder app → NC not updating
IOS created tasks in iOS reminder app → NC getting lost on both sides

stefan-niedermann · April 4, 2023, 7:54pm

Please carefully read my post again (I explained why I mentioned Android while your request is about iOS) and try answering the questions rather than introducing new terms to the discussion without explaining the context (Tasks is a different app and not equal to the Deck app - different words, different meanings ).

anagio · April 4, 2023, 8:09pm

Thanks Stefan,

I somehow ended up seeing my Deck items on the iOS Reminder App, not using the Deck App in iOS.

So being pleased with seeing the Deck entries, I was hoping I could update and re sync them in the opposite direction.

My mistake was using task in my response, it should be record or entry.

stefan-niedermann · April 4, 2023, 8:28pm

Thank you for the clarification.

The Deck server app provides basically two synchronization mechanisms:

A REST API which native Deck clients like Deck iOS (or the Deck Android app) can connect to
The CalDAV protocol, which is usually used by calendar apps and / or task apps (for iOS, Android and other operating systems). This also allows you to few your boards in the Nextcloud Calendar and Tasks apps within a browser

I personally don’t use iOS, but I am pretty sure, that the Reminders App you are talking about uses the second mechanism.

However, the second mechanism is not fully implemented and currently provides only a basic read-only view - with a partially buggy write option. There are several known issues like

github.com/nextcloud/deck

Write access over CalDAV

opened 06:23AM - 08 Oct 20 UTC

juliushaertl

enhancement 1. to develop feature: dav

Split off from https://github.com/nextcloud/deck/issues/15 so we have individual… issues to track: 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`](https://tools.ietf.org/html/rfc5545#section-3.8.1.2) or custom implementation (Nextcloud tagging system) | Currently uses `CATEGORIES`, integration with Nextcloud tags would be better, see https://github.com/nextcloud/tasks/issues/89 | | Assigned users | [`ATTENDEE`](https://tools.ietf.org/html/rfc5545#section-3.8.4.1) or custom implementation | [`ATTENDEE`](https://tools.ietf.org/html/rfc5545#section-3.8.4.1) or custom implementation, see https://github.com/nextcloud/tasks/issues/72 | | Recurring stacks & cards | [`RRULE`](https://tools.ietf.org/html/rfc5545#section-3.8.5.3) | Recurring tasks & subtasks, see https://github.com/nextcloud/tasks/issues/34 | | Attachments | [`ATTACH`](https://tools.ietf.org/html/rfc5545#section-3.8.1.1) or custom implementation | [`ATTACH`](https://tools.ietf.org/html/rfc5545#section-3.8.1.1) or custom implementation, see https://github.com/nextcloud/tasks/issues/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. :heavy_check_mark: Expose deck boards as VCALENDAR, try to map as much data from deck to the VTODO (read only access) 2. :white_check_mark: **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)** 3. :white_check_mark: Deck data could be moved to the DAV backend.

github.com/nextcloud/deck

[CalDAV] PUT on CalDAV collection should return 403 instead of 404

opened 02:37PM - 05 Oct 20 UTC

rfc2822

bug 1. to develop feature: dav

Hi, As long as there's [no write access to Deck's CalDAV collections](https:/…/github.com/nextcloud/deck/issues/15), the server restricts write access as expected. However, it returns 404 instead of 403. **Steps to reproduce:** 1. Upload (PUT) a task (VTODO) to a Deck CalDAV collection. **Actual result:** Currently, it returns 404 Not found when you try to upload a task. **Expected result:** Deck should return 403 Forbidden: > https://tools.ietf.org/html/rfc3744#section-3 > Servers MUST report a 403 "Forbidden" error if access is denied, except in the case where the privilege restricts the ability to know the resource exists, in which case 404 "Not Found" may be returned. Because the client has read access, it knows which resources exist and thus there's no need for 404. The response body should contain: > https://tools.ietf.org/html/rfc3744#section-7.1.1 > If an HTTP method fails due to insufficient privileges, the response body to the "403 Forbidden" error MUST contain the <DAV:error> element, which in turn contains the `<DAV:need-privileges>` element, which contains one or more `<DAV:resource>` elements indicating which resource had insufficient privileges, and what the lacking privileges were: […] With 403 and `<DAV:need-privileges>`, clients can show a meaningful error message. **Tested with:** Nextcloud 20, Deck 1.1.0

and others. I therefore strongly advise to eschew anything else but the native Deck iOS app I linked above (though I don’t know it’s current state, it should for sure work better than any CalDAV mechanism - just my opinion).