Keep order of tasks (iCloud)

[yahrens]

Add an option to set the ordering, e.g. sort alphabetically or simply taking the order from iCloud (if possible).

[untitaker]

Does iCloud let you explicitly order the tasks?

[dmfs]

Apple clients let you reorder tasks. But I didn't check yet how they store the task order. I guess it's an X- property in the VTODO.

Am 2. Dezember 2014 21:42:59 MEZ, schrieb Markus Unterwaditzer notifications@github.com:

Does iCloud let you explicitly order the tasks?

---

Reply to this email directly or view it on GitHub: https://github.com/dmfs/tasks/issues/118#issuecomment-65300807

Diese Nachricht wurde von meinem Android-Mobiltelefon mit K-9 Mail gesendet.

[dmfs]

Just learned about RFC 3648. Maybe that's how they do it.

[untitaker]

I have an iCloud account. Shall I test?

[dmfs]

Oh yes, that would be great. We won't have time to take of this until next year.

[untitaker]

To my surprise Apple actually does expose this information via their iCalendar files. Each VTODO item has a X-APPLE-SORT-ORDER property with an integer value. Sorting by this value ascendingly will give you the desired order.

Example VTODOs, when reordering the tasks as two, one, three: https://gist.github.com/untitaker/6fd67c2d75a4eea78573

[untitaker]

Also note that this property used to be missing for me when creating tasks through the iCloud webinterface, which doesn't allow tasks reordering.

[dmfs]

@untitaker interesting, thanks for sharing!

[dmfs]

I wonder if the sort order is interpreted as a string or as an integer.

i.e. like "999" > "1000" or like 999 < 1000

[untitaker]

@dmfs Could it be that iCloud recently started to require a special form of auth other than HTTP? Your client sends a request to setup.icloud.com (afaict) and gets a mobileme-token, while my client tries normal HTTP auth, but gets empty collections back.

[dmfs]

The empty collections must have a different reason, otherwise you would get an Authentication error. Basic Authentication should work well. Have you tried with an app-specific password (after enabling two-step authentication)?

[untitaker]

I'm not sure how app-specific passwords would work if I didn't even register my app anywhere. I'm just using the "normal" DAV-APIs at caldav.icloud.com and contacts.icloud.com, which used to work fine with sending the user's creds through HTTP auth.

[dmfs]

You don't need to register your app for this. After you've enabled two-step authentication you can create random passwords that you can use to log in via regular Basic authentication. However, you can revoke those passwords at any time without changing your primary password. That's it. It's not OAuth2 ... Anyway if you didn't enable two-step authentication, BASIC authentication should still work with your regular password. We don't do any magic here either.

[untitaker]

Can confirm that app-specific passwords don't change the behavior.

[untitaker]

Your client sends a POST-request to setup.icloud.com. From what I can see this is an iCloud-specific API.

I replaced my calendar-query requests with sync-collection requests that don't carry a sync token, now I get an 500-error back.

[untitaker]

I found the reason my calendar-query-requests didn't work. The following would return an empty collection:

<C:filter><C:comp-filter name="VCALENDAR"/></C:filter>

This works instead:

<C:comp-filter name="VCALENDAR">
    <C:comp-filter name="VTODO">

    </C:comp-filter>
</C:comp-filter>

[untitaker]

The task items are sorted numerically: 999 < 1000

[dmfs]

The setup POST request is just to use a different authentication mechanism, that appeared to be more robust than BASIC authentication in the past. However, it has been superseded by app-specific passwords.

I guess they didn't care about filtering by VCALENDAR only, because all items in a Calendar collection must be enclosed in a VCALENDAR object.

numerical sorting ... hmm. Thanks for testing that!

[untitaker]

I guess they didn't care about filtering by VCALENDAR only, because all items in a Calendar collection must be enclosed in a VCALENDAR object.

The reason I do this is because it's easier to reuse the XML template for calendar-query requests than do a PROPFIND. I didn't find any other way to get all kinds of items via calendar-query.

[dmfs]

The reason I do this is because it's easier to reuse the XML template for calendar-query requests than do a PROPFIND.

Is it? I'd say a PROPFIND is the easiest way to get everything in a collection. It's basically like a calendar-query just without the filter. And PROPFIND is well supported by all servers.

[untitaker]

"Easier" as in "less code". I already use PROPFIND for CardDAV, but didn't really care about sharing code there. I've changed it now, and it doesn't seem to take that much more code.

[dmfs]

A that makes sense.