All contacts show *Last modified seconds ago*

[ChristophWurst]

Describe the bug

Last modified date, if known, should work reliably

Steps to reproduce

1. Open the contacts app
2. Open any contact (can be your own, recently contacted or system address book)
3. Scroll to the bottom

Expected behavior

Real last modified date

Actual behavior

Contact version

5.3

Operating system

No response

PHP engine version

None

Web server

None

Database

None

Additional info

No response

[meichthys]

I'm not seeing this in v 5.3.0-rc.2

Could it be a caching issue?

[meichthys]

Maybe it's limited to recently contacted contacts?

[ChristophWurst]

I still see it with 27 RC2. It happens with my own contacts, recently contacted and system contacts

[meichthys]

Ok, for reference I'm on 26.0.1 RC1
I only have 1 recent contact but that does seem to have the issue, Other contacts are fine.

[ChristophWurst]

I tested again and this only happens with system contacts. A contact in a real address book shows Last edited 5 months ago

[ChristophWurst]

My impression is that we don't have a last modification date for every contact.

If we don't have the data we should hide the text

[ChristophWurst]

nextcloud/server#38544 for a related feature request. The SAB contacts do not have a REV at the moment.

[JohannesGGE]

I found where the magic happens:

contacts/src/services/checks/invalidREV.js

Lines 55 to 69 in 6f79fbc

	fix: contact => {
	try {
	// removing old invalid data
	contact.vCard.removeProperty('rev')
	// creatiing new value
	const rev = new VCardTime(null, null, 'date-time')
	rev.fromUnixTime(Date.now() / 1000)
	contact.vCard.addPropertyWithValue('rev', rev)
	return true
	} catch (error) {
	return false
	}
	},

The fix is called because the fallowing returns true in some cases:

contacts/src/services/checks/invalidREV.js

Lines 31 to 53 in 6f79fbc

	run: contact => {
	try {
	const hasRev = contact.vCard.hasProperty('rev')
	const rev = hasRev && contact.vCard.getFirstProperty('rev')
	const revValue = rev && rev.getFirstValue()
	if (revValue) {
	const version = contact.version
	const type = revValue.icalclass
	if (version === '3.0' && type === 'vcardtime') {
	return false
	}
	if (version === '4.0' && type === 'icaltime') {
	return false
	}
	}
	} catch (error) {
	return true
	}
	return true
	},

One of these cases are the vCard created by the contacts app:

BEGIN:VCARD
VERSION:4.0
PRODID:-//Nextcloud Contacts v5.3.0-beta2
UID:6aa9cf0f-e92e-4e5a-9c13-799ca265f9fd
FN:Contact
ADR;TYPE=HOME:;;;;;;
EMAIL;TYPE=HOME:
TEL;TYPE=HOME,VOICE:
REV;VALUE=DATE-AND-OR-TIME:20230531T135555Z
END:VCARD

REV;VALUE=DATE-AND-OR-TIME:20230531T135555Z seems to be a valid format for v4.0 of vCards but invalid for v3.0 as far as I understand it and as written in this issue #1352 . I don't understand why version === '3.0' && type === 'vcardtime' return true (valid but actually invalid) here, and 4.0 return false (invalid but it is actually valid)

Ical.js says revValue.icalclass === 'vcardtime' for REV;VALUE=DATE-AND-OR-TIME:20230531T135555Z
and revValue.icalclass === 'icaltime' for REV:20230531T135555Z. Can't relate why.

---

So the actual problem is that the contacts app now writes vCard v4.0 and the fix wants to repair the valid REV.
To fix the issue, I would just add the case version === '4.0' && type === 'vcardtime' where the validation returns valid. But as stated I don't really get the implementation here.

[ChristophWurst]

Does it also try to repair read-only system accounts?

I have to dig into details of vcard v3 and v4 too. @st3iny might know a few things too.