Contacts: invalid value in deathdate cannot be repaired

Created on 24 Apr 2019  路  6Comments  路  Source: nextcloud/contacts

Steps to reproduce

  1. deathdate is stored in a vcf-file as DEATHDATE;VALUE=DATE:20190421
  2. when editing the contact in eM Client, e.g. adding a given name, the value will bes destroyed to DEATHDATE;VALUE=time:000000 ( I know this is up to em Client)
  3. back in nextcloud and editing in contacts-app the field deathdate still exists, but shown as "invalid date". Right! (EDIT: not calendar-app but contacts-app)
  4. to repair this, it is no more possible to select a date, but you must delete and recreate a new deathdate.

Expected behaviour

invalide date can be repaired by selecting a date by calendar selector

Actual behaviour

repairing is not possible

Server configuration detail

Operating system: Linux info 3.0 #1337 SMP Tue Jan 01 00:00:00 CEST 2000 all GNU/Linux Linux info 3.0 #1337 SMP Tue Jan 01 00:00:00 CEST 2000 all GNU/Linux Linux info 3.0 #1337 SMP Tue Jan 01 00:00:00 CEST 2000 all GNU/Linux Linux info 3.0 #1337 SMP Tue Jan 01 00:00:00 CEST 2000 all GNU/Linux

Webserver: Apache (cgi-fcgi)

Database: mysql 5.5.60

PHP version:

7.1.27
Modules loaded: Core, date, libxml, openssl, pcre, sqlite3, zlib, bcmath, bz2, calendar, ctype, curl, dba, dom, hash, fileinfo, filter, ftp, gd, gettext, SPL, iconv, session, intl, json, mbstring, mcrypt, standard, PDO, mysqlnd, pdo_sqlite, Phar, posix, Reflection, imap, shmop, SimpleXML, soap, pdo_mysql, exif, tidy, tokenizer, wddx, xml, xmlreader, xmlwriter, xsl, zip, mysqli, cgi-fcgi

Nextcloud version: 15.0.7 - 15.0.7.0

Updated from an older Nextcloud/ownCloud or fresh install: updated from owncloud 10.0.3

Where did you install Nextcloud from: ?

Signing status

Array
(
)

List of activated apps

Enabled:
 - accessibility: 1.1.0
 - activity: 2.8.2
 - admin_audit: 1.5.0
 - bruteforcesettings: 1.3.0
 - calendar: 1.6.5
 - cloud_federation_api: 0.1.0
 - contacts: 3.1.0
 - dav: 1.8.1
 - deck: 0.6.0
 - drawio: 0.9.2
 - encryption: 2.3.0
 - federatedfilesharing: 1.5.0
 - federation: 1.5.0
 - files: 1.10.0
 - files_external: 1.6.0
 - files_pdfviewer: 1.4.0
 - files_sharing: 1.7.0
 - files_texteditor: 2.7.0
 - files_trashbin: 1.5.0
 - files_versions: 1.8.0
 - files_videoplayer: 1.4.0
 - gallery: 18.2.0
 - issuetemplate: 0.5.0
 - logreader: 2.0.0
 - lookup_server_connector: 1.3.0
 - metadata: 0.9.0
 - notes: 2.6.0
 - oauth2: 1.3.0
 - password_policy: 1.5.0
 - provisioning_api: 1.5.0
 - richdocuments: 3.2.4
 - serverinfo: 1.5.0
 - sharebymail: 1.5.0
 - support: 1.0.0
 - survey_client: 1.3.0
 - theming: 1.6.0
 - twofactor_backupcodes: 1.4.1
 - updatenotification: 1.5.0
 - user_saml: 2.1.1
 - workflowengine: 1.5.0
Disabled:
 - announcementcenter
 - caniupdate
 - comments
 - files_accesscontrol
 - files_antivirus
 - files_automatedtagging
 - files_retention
 - firstrunwizard
 - groupfolders
 - impersonate
 - mail
 - nextcloud_announcements
 - notifications
 - onlyoffice
 - radio
 - sharepoint
 - systemtags
 - user_ldap

Configuration (config/config.php)

{
    "instanceid": "***REMOVED SENSITIVE VALUE***",
    "passwordsalt": "***REMOVED SENSITIVE VALUE***",
    "secret": "***REMOVED SENSITIVE VALUE***",
    "trusted_domains": ***REMOVED SENSITIVE VALUE***"
    "datadirectory": "***REMOVED SENSITIVE VALUE***",
    "overwrite.cli.url": "https:\/\/***REMOVED SENSITIVE VALUE***".de\/ownCloud",
    "dbtype": "mysql",
    "version": "15.0.7.0",
    "dbname": "***REMOVED SENSITIVE VALUE***",
    "dbhost": "***REMOVED SENSITIVE VALUE***",
    "dbtableprefix": "oc_",
    "dbuser": "***REMOVED SENSITIVE VALUE***",
    "dbpassword": "***REMOVED SENSITIVE VALUE***",
    "debug": false,
    "filelocking.enabled": true,
    "installed": true,
    "logtimezone": "UTC",
    "loglevel": 4,
    "maintenance": false,
    "mail_from_address": "***REMOVED SENSITIVE VALUE***",
    "mail_smtpmode": "smtp",
    "mail_domain": "***REMOVED SENSITIVE VALUE***",
    "mail_smtphost": "***REMOVED SENSITIVE VALUE***",
    "mail_smtpport": "25",
    "mail_smtpauthtype": "LOGIN",
    "mail_smtpauth": 1,
    "mail_smtpname": "***REMOVED SENSITIVE VALUE***",
    "mail_smtppassword": "***REMOVED SENSITIVE VALUE***",
    "mail_smtptimeout": 15,
    "theme": ""
}

Are you using external storage, if yes which one: local/smb/sftp/...

Are you using encryption:

Are you using an external user-backend, if yes which one: LDAP/ActiveDirectory/Webdav/...

Client configuration

Browser: Firefox 0.0

Operating system: Windows 10

Logs

Web server error log

Insert your web server log here 

Nextcloud log

Insert your Nextcloud log here

Browser log

Insert your browser log here, this could for example include:

a) The javascript console log
b) The network log
c) ...


Want to back this issue? Post a bounty on it! We accept bounties via Bountysource.

0. Needs triage bug

All 6 comments

Hey, thanks for your issue

  • when editing the contact in eM Client, e.g. adding a given name, the value will bes destroyed to DEATHDATE;VALUE=time:000000 ( I know this is up to em Client)

If EM is removing the data, we cannot repair anything indeed.
This is an issue that should be opened into the em software ?
https://forum.emclient.com/emclient/topics/vcard-birthday-format-not-valid seems related. I don't know much about the em client, but destroying values is absolutely not the way to go. :/

ANy reasons you use this software over nextcloud's contacts app?

Hi skjnldsv,
I know, repairing is impossible for you, because you don't have the date. But I know the date. And when I want to repair it, e.g. by entering the date in contacts-app, it is not possible. The calendar-selector does not reset the wrong VALUE=time to the correct VALUE=date. When it would do so, it would be possible for me to enter the correct deathdate. This was my idea.

Regarding eM Client I agree with you :-). It is an issue that should be sloved by them.

I changed from thunderbird/Lighting to eM Client because of the native CalDAV and CardDav implementation. Several CardDAV servers or accounts were not supported.

Reopened.
Sorry, I didn't want to close.

The calendar-selector does not reset the wrong VALUE=time to the correct VALUE=date. When it would do so, it would be possible for me to enter the correct deathdate. This was my idea.

You mean, when entering the new fixed date manually, it does not work?
SOrry, I'm not sure I understand properly :see_no_evil:

Yes, you are right. Field description is "Todestag" (Deathdate) and in the field is written "invalid date". By clicking the calender symbol I see the date 1899-11-30. I can enter todays date 2019-04-24 and after clicking OK I see "Apr 24," but expecting "Apr 24, 2019". Clicking again at the calendar symbol the date is 1900-04-24. Exporting a vcf file there is written DEATHDATE;X-APPLE-OMIT-YEAR=1604;VALUE=DATE:1604-04-24. This is new for me, I can't see any logical system. As I remember it should not been saved but that may be related to case #1071.

Regardless of who created the wrong data, what should you do if you receive the wrong data (error handling)?
First, try to repair (you don't know the correct dates, so this is impossible).
Second, inform the user of the wrong data (you are doing this) and let them decide whether to delete, correct or leave it unchanged.
If I (the user) know the correct date, I may want to correct it. But that is not possible. It just looks like it is possible.

Was this page helpful?
0 / 5 - 0 ratings

Related issues

silverhook picture silverhook  路  5Comments

Dennis1993 picture Dennis1993  路  5Comments

michaelletzgus picture michaelletzgus  路  5Comments

despens picture despens  路  3Comments

caugner picture caugner  路  3Comments