nextcloud/tasks

Due date not saved directly after task creation

doitux opened this issue · 27 comments

Steps to reproduce

  1. Add a task
  2. Select the new task and select a due date
  3. Reload the page in the browser

Expected behaviour

The due date should stay as before

Actual behaviour

The recent added due date is deleted

Server configuration detail

Operating system: FreeBSD 10.3-RELEASE-p17 hostBSD 10.3-RELEASE-p17 #6: Mon Mar 13 00:47:05 CET 2017 root@mywebsite.de:/usr/obj/usr/src/sys/DMRKERNEL amd64

Webserver: Apache/2.4.25 (FreeBSD) OpenSSL/1.0.2k mod_fcgid/2.3.9 (cgi-fcgi)

Database: mysql 5.6.35

PHP version: 7.0.16
Modules loaded: Core, date, libxml, pcre, Reflection, SPL, hash, session, cgi-fcgi, standard, apcu, calendar, ctype, curl, dom, fileinfo, filter, ftp, gd, gettext, mysqlnd, iconv, intl, imagick, imap, json, mbstring, mcrypt, mysqli, openssl, PDO, posix, SimpleXML, sqlite3, tokenizer, xml, xmlwriter, zip, zlib, pdo_mysql, pdo_sqlite, Phar, soap, xmlreader, xsl, ionCube Loader, Zend OPcache

Nextcloud version: 13.0.2 - 13.0.2.1

Signing status

Array

List of activated apps
Enabled:
 - calendar: 1.6.1
 - contacts: 2.1.3
 - dav: 1.4.6
 - federatedfilesharing: 1.3.1
 - federation: 1.3.0
 - files: 1.8.0
 - files_sharing: 1.5.0
 - files_texteditor: 2.5.1
 - files_trashbin: 1.3.0
 - files_versions: 1.6.0
 - firstrunwizard: 2.2.1
 - issuetemplate: 0.3.0
 - lookup_server_connector: 1.1.0
 - news: 12.0.1
 - nextcloud_announcements: 1.2.0
 - notifications: 2.1.2
 - oauth2: 1.1.0
 - password_policy: 1.3.0
 - provisioning_api: 1.3.0
 - serverinfo: 1.3.0
 - survey_client: 1.1.0
 - systemtags: 1.3.0
 - tasks: 0.9.6
 - twofactor_backupcodes: 1.2.3
 - updatenotification: 1.3.0
 - workflowengine: 1.3.0
Disabled:
 - activity
 - admin_audit
 - comments
 - encryption
 - files_external
 - files_pdfviewer
 - files_videoplayer
 - gallery
 - logreader
 - sharebymail
 - theming
 - user_external
 - user_ldap

Configuration (config/config.php)
{
    "instanceid": "***REMOVED SENSITIVE VALUE***",
    "passwordsalt": "***REMOVED SENSITIVE VALUE***",
    "secret": "***REMOVED SENSITIVE VALUE***",
    "trusted_domains": [
        "mycloud.mywebsite.de"
    ],
    "datadirectory": "***REMOVED SENSITIVE VALUE***",
    "overwrite.cli.url": "https:\/\/mycloud.mywebsite.de",
    "dbtype": "mysql",
    "version": "13.0.2.1",
    "dbname": "***REMOVED SENSITIVE VALUE***",
    "dbhost": "***REMOVED SENSITIVE VALUE***",
    "dbport": "",
    "dbtableprefix": "oc_",
    "dbuser": "***REMOVED SENSITIVE VALUE***",
    "dbpassword": "***REMOVED SENSITIVE VALUE***",
    "installed": true,
    "maintenance": false,
    "mysql.utf8mb4": true,
    "loglevel": 0,
    "memcache.local": "\\OC\\Memcache\\APCu",
    "updater.secret": "***REMOVED SENSITIVE VALUE***",
    "theme": ""
}

Please report this in the https://github.com/nextcloud/server repository. This app is just a client and is not involved in the update process.

Please reopen this issue because i realized this also happens when just do a reload of the page in the browser directly after selecting a due date!

The tasks are currently not immediately synced to the server. Does this also happen if you wait for some seconds?

Sorry, I didn't remember this correctly. They should be directly saved if you put a due- or start-date. Do you see a request to the server when you put a date?

I've tested waiting for 20 minutes. But it does not help. After reloading the page the due date is deleted. How can i check if there is a request?

You need to open the Web-Console. For Firefox the shortcut is Ctrl+Shift+K. For Chrome you have to press Ctrl+Shift+I and then click on console.

When you then set a due date, you should see a request to the server. e.g.
firefoxrequest

When you click on this request, you should see what date was send.

Yes i can see a PUT request directly after selecting the due date:

core.js?v=94b45501:5729 PUT https://mycloud.mysite.de/remote.php/dav/calendars/doitux/aufgaben/Nextcloud-8tqdt2xi9t2kjeagra0rpq.ics 412 ()
request @ core.js?v=94b45501:5729
update @ merged.js?v=94b45501:1978
e.doUpdate @ merged.js?v=94b45501:1978
e.setDue @ merged.js?v=94b45501:1978
_$scope.setdueday @ merged.js?v=94b45501:1977
onSelect @ merged.js?v=94b45501:1977
_selectDate @ core.js?v=94b45501:13
_selectDay @ core.js?v=94b45501:13
selectDay @ core.js?v=94b45501:13
dispatch @ core.js?v=94b45501:3
r.handle @ core.js?v=94b45501:3

But anyway after reloading the page the due date is deleted. Can you reproduce this issue?

Can you reproduce this issue?

No, the dates are saved correclty for me.

Could you please check the request and look if the due date is given:

VERSION:2.0
PRODID:-//Nextcloud Tasks v0.9.6
BEGIN:VTODO
CREATED:20180227T103432
DTSTAMP:20180429T225107
LAST-MODIFIED:20180429T225107
UID:gc6akb6ojdd
SUMMARY:Tasktitle
PRIORITY:0
PERCENT-COMPLETE:0
X-OC-HIDESUBTASKS:0
DUE:20180429T230000
END:VTODO
END:VCALENDAR

There should be a line starting with DUE e.g. DUE:20180429T230000 as in the above given task.
Also, are other changes to the task saved?

I've selected the due date of new task to 2018-05-17 and i found this data in the request:

BEGIN:VCALENDAR
VERSION:2.0
PRODID:-//Nextcloud Tasks v0.9.6
BEGIN:VTODO
CREATED:20180430T082557
DTSTAMP:20180430T082724
LAST-MODIFIED:20180430T082724
UID:2np3fmmksnp
SUMMARY:rssdf
PRIORITY:0
PERCENT-COMPLETE:0
X-OC-HIDESUBTASKS:0
DUE:20180517T090000
END:VTODO
END:VCALENDAR

The data looks fine. I suspect a bit, that the server is behaving bad. Could you check the response of the server, please?

Or could it be possible, that another client is manipulating the data?

<d:error xmlns:d="DAV:" xmlns:s="http://sabredav.org/ns">
<s:exception>Sabre\DAV\Exception\PreconditionFailed</s:exception>
<s:message>An If-Match header was specified, but none of the specified the ETags matched.</s:message>
<s:header>If-Match</s:header>
</d:error>

Is that the wanted info?

Yes, the server reported an error, although I don't know what could cause this. I think it is not the Tasks app causing it, but this is not sure. Maybe @georgehrke knows what could be wrong?

I've played around and maybe found a useful information:
When i add the task and do a page reload BEFORE i select a due date than the due date stays correctly also after another page reload.

Definitely interesting, but doesn't really explain the problem. Due dates are saved correctly for me after creating a task and setting the date without any page reload.

@armaccloud Could you please have a look at the request which the app send when you create a due date directly after the creation of the task and check whether it also fails with the error reported above (#167 (comment))

@raimund-schluessler
Yes, in what logs, where do I have to look?

You have to open the browser console and set a due date ad described in #167 (comment)

The following errors occur when setting the due date (precondition failed)

image

The following information in params

BEGIN:VCALENDAR
VERSION:2.0
PRODID:-//Nextcloud Tasks v0.9.6
BEGIN:VTODO
CREATED:20180511T123206
DTSTAMP:20180511T123220
LAST-MODIFIED:20180511T123220
UID:4fndi3vi529
SUMMARY:Test
PRIORITY:0
PERCENT-COMPLETE:0
X-OC-HIDESUBTASKS:0
DUE:20180529T130000
END:VTODO
END:VCALENDAR

The following response

<?xml version="1.0" encoding="utf-8"?>
<d:error xmlns:d="DAV:" xmlns:s="http://sabredav.org/ns">
  <s:exception>Sabre\DAV\Exception\PreconditionFailed</s:exception>
  <s:message>An If-Match header was specified, but none of the specified the ETags matched.</s:message>
  <s:header>If-Match</s:header>
</d:error>

Yes, this is the same problem. Unfortunately I still have no idea what causes this. Could you please check if this happens also for other changes to the task, like setting the importance or the percent finished?

Ok, I have done another test

  1. Created a new task, filled in all fields (start date (all day), due date (all day), priority, percentage completed, category, free field)
  2. Clicked on Files App, then reopened Tasks app

Result
All fields are empty, except for the title

Retried this test just by refreshing the Tasks app page after creating a task, which has the same result
If I populate the same fields again on the existing task, it does save the details. So it's on the initial creation of the task that something goes wrong.

Retried this test just by refreshing the Tasks app page after creating a task, which has the same result
If I populate the same fields again on the existing task, it does save the details. So it's on the initial creation of the task that something goes wrong.

Ok, when you create a task, you should see three requests, as in this screenshot.
task_creation

A PUT request, a GET request and a REPORT request. They should all finish with a 2xx status code as above.

Also, could you check if the same happen when you create an entry in the calendar and immediately try to change it? The calendar app uses the same procedure of creating an entry.

Initial task creation (only title)
image

Updating that task
image

Initial Calendar Event creation
image

Calendar Event Update (free text addition)
image

@raimund-schluessler
Is this all the info you need? Let me know if any more troubleshooting is necessary.

Well, sadly I am out of ideas what could cause this.

This is most likely a web server misconfiguration. I ran into it, too, and debugged it. I've got Apache2 and have following pieces in my configuration:

        …
        RequestHeader  edit "If-None-Match" "^\"(.*)-gzip\"$" "\"$1\""
        Header  edit "ETag" "^\"(.*[^g][^z][^i][^p])\"$" "\"$1-gzip\""
        …

Essentially, this strips off the "-gzip" suffix, which would be breaking caching. This is done when sending out the ETag header and when receiving the If-None-Match header. The tasks app is sending the "If-Match" header however which must fit to the Etag of the corresponding task. After adding it to the configuration, it works as expected:

        …
        RequestHeader  edit "If-None-Match" "^\"(.*)-gzip\"$" "\"$1\""
        RequestHeader  edit "If-Match" "^\"(.*)-gzip\"$" "\"$1\""
        Header  edit "ETag" "^\"(.*[^g][^z][^i][^p])\"$" "\"$1-gzip\""
        …

It is in Apache2 in my case, but the header modification can be done in any server.

Thanks a lot @blizzz, very interesting. But I still wonder, why this is not happening for the Calendar app. The two apps seem to behave differently here. I guess this could be tackled with the move to the https://github.com/nextcloud/cdav-library in the vue branch without server reconfiguration as well.

But I still wonder, why this is not happening for the Calendar app.

Implementation details I guess.

without server reconfiguration as well.

If the server is configured as above, If-Match should be included to work properly. Independent from this case, there might be other apps or services that could suffer the same way. This whole thing is a hack anyhow, probably not needed with future Apache 2.6.

Should be fixed in master now with the vue rewrite. Please reopen, if this still persists.