New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[WIP] Make Tasks a DAV client, close #280 #291

Merged
merged 58 commits into from May 16, 2016

Conversation

Projects
None yet
9 participants
@raimund-schluessler
Member

raimund-schluessler commented Feb 13, 2016

We want to get rid of the calendar dependency and use the CalDAV server build-in in oC core 9.x.

In order to hopefully make the development easier the same DAV library as in core and calendar will be used. No more server side CalDAV stuff in the app itself.

Todos:

_Calendars_

  • Get calendars
  • Create calendar
  • Delete calendar
  • Rename calendar

_Tasks_

  • Get tasks
  • Create task (subtask)
  • Fix creating tasks in the collection views
  • Toggle subtasks visibility
  • Delete task
  • Toggle task state
  • Rename task
  • Set task priority
  • Set start date
  • Set end date
  • Set progress
  • Edit categories
  • Edit note
  • Change calendar
  • Respect write privileges for drag-n-drop
  • Creating subtasks in "All" view does not work
  • Only load uncomplete tasks, load completed tasks on demand
  • Load completed subtasks when opening parent task
  • Respect timezone setting for start, due and reminder
  • Enable copying tasks
  • Set reminder (with notification support)
  • Implement comments

_Various_

  • Check compliance ./occ app:check-code tasks
  • Add makefile for appstore packaging
  • Add an issue template

_Search_

  • Implement search provider

@raimund-schluessler raimund-schluessler changed the title from [WIP] Make Tasks a DAV client, closes #280 to [WIP] Make Tasks a DAV client, close #280 Feb 13, 2016

@raimund-schluessler

This comment has been minimized.

Member

raimund-schluessler commented Feb 13, 2016

@georgehrke @raghunayyar I would like to use your implementation of the client side calendar service and maybe other files from the calendar-rework if its ok with you.

@georgehrke

This comment has been minimized.

georgehrke commented Feb 13, 2016

I would like to use your implementation of the client side calendar service and maybe other files from the calendar-rework if its ok with you.

Sure, it's free software, go ahead :)

@raimund-schluessler

This comment has been minimized.

Member

raimund-schluessler commented Feb 13, 2016

Can someone tell me if it is possible to also get the id of a calendar? If yes, how has the request body to look like?

I tried something like this

<?xml version="1.0"?>
<d:propfind  xmlns:d="DAV:" xmlns:c="urn:ietf:params:xml:ns:caldav" xmlns:aapl="http://apple.com/ns/ical/" xmlns:oc="http://owncloud.org/ns" xmlns:cs="http://calendarserver.org/ns/">
  <d:prop>
    <d:displayname />
    <d:id />
    <c:id />
    <aapl:id />
    <c:calendar-description />
    <c:calendar-timezone />
    <aapl:calendar-order />
    <aapl:calendar-color />
    <c:supported-calendar-component-set />
    <oc:calendar-enabled />
    <d:acl />
    <d:owner />
    <oc:invite />
  </d:prop>
</d:propfind>

but this does not return an id. @DeepDiver1975 @georgehrke maybe?

@georgehrke

This comment has been minimized.

georgehrke commented Feb 13, 2016

<d:href>/remote.php/dav/calendars/admin/personal/</d:href> is unique. I don't think you can get the database id. It wouldn't be of any use anyway, because you always need the url.

@raimund-schluessler

This comment has been minimized.

Member

raimund-schluessler commented Feb 14, 2016

It wouldn't be of any use anyway, because you always need the url.

Yes, that's true. But I need something to show in the address bar when a user opens a calendar, so the page history works correctly. The database ID would have been the easiest solution.

@georgehrke

This comment has been minimized.

georgehrke commented Feb 14, 2016

The display name is supposed to be unique. Although I'm not sure this if this is enforced at the moment.

@raimund-schluessler

This comment has been minimized.

Member

raimund-schluessler commented Feb 14, 2016

The displayname is currently not enforced to be unique and it won't be for different users.

For the moment I will just count upwards, but this might result in a usability problem when a user bookmarks the link to a certain calendar. I will have to think of a better solution later on.

@DeepDiver1975

This comment has been minimized.

Member

DeepDiver1975 commented Feb 15, 2016

The displayname is indeed not unique. But the Uri is.

@raimund-schluessler

This comment has been minimized.

Member

raimund-schluessler commented Feb 15, 2016

The Uri also seems to only be unique for one user. But when User1 shares a calendar with the (for him) unique Uri 'test' with User2 which also has a calendar with this Uri, User2 has two calendars with the same Uri. Hence, only the principaluri is really unique, or am I wrong?

@DeepDiver1975

This comment has been minimized.

Member

DeepDiver1975 commented Feb 15, 2016

The shared Uri will be test_shared_by_user1

@raimund-schluessler

This comment has been minimized.

Member

raimund-schluessler commented Feb 15, 2016

The shared Uri will be test_shared_by_user1

Ah, alright, thank you.
Can I query the Uri directly, or do I have to extract it from the url?
The request

<?xml version="1.0"?>
<d:propfind  xmlns:d="DAV:" xmlns:c="urn:ietf:params:xml:ns:caldav" xmlns:aapl="http://apple.com/ns/ical/" xmlns:oc="http://owncloud.org/ns" xmlns:cs="http://calendarserver.org/ns/">
  <d:prop>
    <d:displayname />
    <d:uri />
    <c:uri />
    <aapl:uri />
    <oc:uri />
    <c:calendar-description />
    <c:calendar-timezone />
    <aapl:calendar-order />
    <aapl:calendar-color />
    <c:supported-calendar-component-set />
    <oc:calendar-enabled />
    <d:acl />
    <d:owner />
    <oc:invite />
  </d:prop>
</d:propfind>

does not return any uri, but gives

...
  <d:propstat>
   <d:prop>
    <d:uri/>
    <cal:uri/>
    <x1:uri xmlns:x1="http://apple.com/ns/ical/"/>
    <oc:uri/>
   </d:prop>
   <d:status>HTTP/1.1 404 Not Found</d:status>
  </d:propstat>
...

instead.

@DeepDiver1975

This comment has been minimized.

Member

DeepDiver1975 commented Feb 15, 2016

Can I query the Uri directly, or do I have to extract it from the url?

you have to extract it

@raghunayyar

This comment has been minimized.

Member

raghunayyar commented Mar 19, 2016

\o/

@raimund-schluessler

This comment has been minimized.

Member

raimund-schluessler commented Apr 23, 2016

With 8808e77 we only load pending tasks. But this also means completed tasks are not loaded at all at the moment.

@DeepDiver1975 Is there a possibility to load the five newest completed tasks per list? And maybe also a query to get the total number of completed tasks at the server?

@DeepDiver1975

This comment has been minimized.

Member

DeepDiver1975 commented Apr 24, 2016

CalDAV and carddav queries have no understanding of aggregation functions - we have been looking for this for Contacts already.
But getting the five newest should be possible this the calendar query

@raimund-schluessler

This comment has been minimized.

Member

raimund-schluessler commented Apr 26, 2016

Hm, can someone give me a hint on how to limit and order the result set? My naive try to limit the result set to five didn't succeed and I don't seem to be able to figure it out by myself:

<c:calendar-query xmlns:c="urn:ietf:params:xml:ns:caldav" xmlns:d="DAV:" xmlns:a="http://apple.com/ns/ical/" xmlns:o="http://owncloud.org/ns">
   <d:prop>
      <d:getetag/>
      <c:calendar-data/>
   </d:prop>
   <d:limit>
      <d:nresults>5</d:nresults>
   </d:limit>
   <c:filter>
      <c:comp-filter name="VCALENDAR">
         <c:comp-filter name="VTODO">
            <c:prop-filter name="COMPLETED">
               <c:is-not-defined/>
            </c:prop-filter>
         </c:comp-filter>
      </c:comp-filter>
   </c:filter>
</c:calendar-query>

@Henni @georgehrke @DeepDiver1975

@georgehrke

This comment has been minimized.

georgehrke commented Apr 26, 2016

I don't think that CalDAV reports support limit and offset.
One way to do this is in two requests.
First one: send your request without <c:calendar-data/>
Second request: Take the hrefs from request one and send a multiget to the server

@raimund-schluessler

This comment has been minimized.

Member

raimund-schluessler commented Apr 26, 2016

I thought this was possible because of this: https://tools.ietf.org/html/rfc5323#section-5.17 Did I misunderstand it?

@georgehrke

This comment has been minimized.

georgehrke commented Apr 26, 2016

The webdav search extension has nothing to do with CalDAV and CardDAV reports.

@DeepDiver1975

This comment has been minimized.

Member

DeepDiver1975 commented Apr 27, 2016

I don't think that CalDAV reports support limit and offset.

indeed - only carddav query supports that ... my bad - sorry

@raimund-schluessler raimund-schluessler merged commit ff877e3 into master May 16, 2016

2 checks passed

Scrutinizer 33 new issues, 3 updated code elements
Details
continuous-integration/travis-ci/pr The Travis CI build passed
Details
@raimund-schluessler

This comment has been minimized.

Member

raimund-schluessler commented May 16, 2016

Merging this. Remaining problems are tracked in separate issues:

Timezone for start, due and reminder: #312
Copying tasks: #313
Setting reminder: #314
Implement comment feature: #315
Search: #311

@janvonde

This comment has been minimized.

janvonde commented May 16, 2016

will you release the app soon and add the features afterwards, or will you just continue to develop in the master branch and release the app when everything is done?

@raimund-schluessler

This comment has been minimized.

Member

raimund-schluessler commented May 16, 2016

As it was requested by several users, I will release a version to the appstore soon and indicate the yet missing features. So it is possible to install via the appstore again and everybody can decide whether or not he is willing to update.

@janvonde

This comment has been minimized.

janvonde commented May 16, 2016

awesome! 👍

@nickvergessen

This comment has been minimized.

Contributor

nickvergessen commented May 18, 2016

Thanks a lot @raimund-schluessler

@Gomez

This comment has been minimized.

Member

Gomez commented May 24, 2016

Great work @raimund-schluessler. 🍻 at ownCloudConf!

@nickvergessen nickvergessen deleted the DAVclient branch May 25, 2016

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment