Deletion of calendar event reported as being made by another user

[doc75]

I am not sure that the issue is coming from the activity app, but after some search I have not understood how this activity app is retrieving the information. i am ready to continue the investigation is anyone has some hints.

Steps to reproduce

1. Create an event in a calendar
2. Delete the event (event is moved to trash bin)
3. Wait for 1 month for the event to be deleted

Here is what I can see in the oc_activity table for all the cases where this issue is reproduced:

240290  1637427023  30  calendar_event  user1 user1 dav object_add_event_self {"actor":"user1","calendar":{"id":65,"uri":"personal","name":"Personal"},"o    bject":{"id":"8c45c334-76c6-47a1-96b3-b867288570a0","name":"Event Name","classified":false,"link":{"object_uri":"8c45c334-76c6-47a1-96b3-b867288570a0.ics    ","calendar_uri":"personal","owner":"user1"}}}    []      calendar  65
259418  1646416850  30  calendar_event  user1 user1 dav object_move_to_trash_event_self {"actor":"user1","calendar":{"id":65,"uri":"personal","name":"Per    sonal"},"object":{"id":"8c45c334-76c6-47a1-96b3-b867288570a0","name":"Event Name","classified":false,"link":{"object_uri":"8c45c334-76c6-47a1-96b3-b86728    8570a0.ics","calendar_uri":"personal","owner":"user1"}}}    []      calendar  65
263032  1649021407  30  calendar_event  user2 user1 dav object_delete_event {"actor":"user2","calendar":{"id":65,"uri":"personal","name":"Personal"},"obj    ect":{"id":"8c45c334-76c6-47a1-96b3-b867288570a0","name":"Event Name","classified":false}}   []      calendar  65

This issue is only happening after my upgrade to Nextcloud 23.0.3 which also lead to the upgrade of the calendar app version from version 3.2.0 to version 3.2.2. I performed a diff between those 2 calendar versions and I cannot see what could cause this change of behavior (but I am not a specialist).

Any hint on how to debug this further would be highly appreciated.

Expected behaviour

notification should not be sent as the event has been removed by current user

Actual behaviour

Notification is received the day (or the day after) execution of step 3 saying that another user has deleted one of your event.

Server configuration

Operating system: Official docker image (php-fpm alpine)

Web server: NGINX

Database: PostgreSQL

PHP version: 8.0.17

Nextcloud version: 23.0.3

Where did you install Nextcloud from: Official docker image (php-fpm alpine)

Signing status:

No errors have been found.

List of activated apps:

Enabled:
  - accessibility: 1.9.0
  - activity: 2.15.0
  - admin_audit: 1.13.0
  - bookmarks: 10.2.1
  - bruteforcesettings: 2.3.0
  - calendar: 3.2.2
  - circles: 23.1.0
  - cloud_federation_api: 1.6.0
  - comments: 1.13.0
  - contacts: 4.1.0
  - contactsinteraction: 1.4.0
  - cospend: 1.4.6
  - dashboard: 7.3.0
  - dav: 1.21.0
  - deck: 1.6.1
  - drawio: 1.0.2
  - encryption: 2.11.0
  - federatedfilesharing: 1.13.0
  - federation: 1.13.0
  - files: 1.18.0
  - files_external: 1.15.0
  - files_markdown: 2.3.5
  - files_mindmap: 0.0.26
  - files_pdfviewer: 2.4.0
  - files_rightclick: 1.2.0
  - files_sharing: 1.15.0
  - files_trashbin: 1.13.0
  - files_versions: 1.16.0
  - files_videoplayer: 1.12.0
  - firstrunwizard: 2.12.0
  - gpxpod: 4.3.0
  - impersonate: 1.10.0
  - keeweb: 0.6.8
  - logreader: 2.8.0
  - lookup_server_connector: 1.11.0
  - mail: 1.11.7
  - maps: 0.1.10
  - nextcloud_announcements: 1.12.0
  - notes: 4.3.1
  - notifications: 2.11.1
  - oauth2: 1.11.0
  - onlyoffice: 7.3.2
  - password_policy: 1.13.0
  - photos: 1.5.0
  - privacy: 1.7.0
  - provisioning_api: 1.13.0
  - quota_warning: 1.13.1
  - recommendations: 1.2.0
  - serverinfo: 1.13.0
  - settings: 1.5.0
  - sharebymail: 1.13.0
  - spreed: 13.0.4
  - support: 1.6.0
  - survey_client: 1.11.0
  - systemtags: 1.13.0
  - text: 3.4.1
  - theming: 1.14.0
  - twofactor_backupcodes: 1.12.0
  - twofactor_totp: 6.2.0
  - updatenotification: 1.13.0
  - user_status: 1.3.1
  - viewer: 1.7.0
  - weather_status: 1.3.0
  - workflowengine: 2.5.0
Disabled:
  - end_to_end_encryption: 1.8.1
  - user_ldap

Nextcloud configuration:

{
    "system": {
        "memcache.local": "\\OC\\Memcache\\APCu",
        "apps_paths": [
            {
                "path": "\/var\/www\/html\/apps",
                "url": "\/apps",
                "writable": false
            },
            {
                "path": "\/var\/www\/html\/custom_apps",
                "url": "\/custom_apps",
                "writable": true
            }
        ],
        "passwordsalt": "***REMOVED SENSITIVE VALUE***",
        "secret": "***REMOVED SENSITIVE VALUE***",
        "trusted_domains": [
            "localhost",
            "cloud.virlet.org",
            "cloud.mesdatas.org"
        ],
        "datadirectory": "***REMOVED SENSITIVE VALUE***",
        "dbtype": "pgsql",
        "version": "23.0.3.2",
        "overwrite.cli.url": "https:\/\/cloud.virlet.org",
        "dbname": "***REMOVED SENSITIVE VALUE***",
        "dbhost": "***REMOVED SENSITIVE VALUE***",
        "dbport": "",
        "dbtableprefix": "oc_",
        "dbuser": "***REMOVED SENSITIVE VALUE***",
        "dbpassword": "***REMOVED SENSITIVE VALUE***",
        "installed": true,
        "instanceid": "***REMOVED SENSITIVE VALUE***",
        "overwriteprotocol": "https",
        "mail_smtpmode": "smtp",
        "mail_smtpsecure": "tls",
        "mail_sendmailmode": "smtp",
        "mail_from_address": "***REMOVED SENSITIVE VALUE***",
        "mail_domain": "***REMOVED SENSITIVE VALUE***",
        "mail_smtpauthtype": "LOGIN",
        "mail_smtpauth": 1,
        "mail_smtphost": "***REMOVED SENSITIVE VALUE***",
        "mail_smtpport": "587",
        "mail_smtpname": "***REMOVED SENSITIVE VALUE***",
        "mail_smtppassword": "***REMOVED SENSITIVE VALUE***",
        "maintenance": false,
        "default_language": "fr",
        "default_locale": "fr_FR",
        "skeletondirectory": "",
        "default_gocale": "",
        "updater.release.channel": "stable",
        "loglevel": 2,
        "data-fingerprint": "660893591097d782ba485ffec0c1254b",
        "trusted_proxies": "***REMOVED SENSITIVE VALUE***",
        "theme": "",
        "memcache.distributed": "\\OC\\Memcache\\Redis",
        "memcache.locking": "\\OC\\Memcache\\Redis",
        "redis": {
            "host": "***REMOVED SENSITIVE VALUE***",
            "port": 6379
        },
        "encryption.legacy_format_support": false,
        "encryption.key_storage_migrated": false,
        "default_phone_region": "FR"
    }
}

Are you using an external user-backend, if yes which one: None

Client configuration

Browser: Firefox

Operating system: Linux

Logs

Nextcloud log (data/nextcloud.log)

Nothing relevant found in the log

Browser log

Not relevant as the issue does not involve the browser

[okow]

I also see this kind of obviously wrong Activity-Logs.

On my system a user allegedly has deleted calendar-entries he acctually has no access to.
As in "[Bug]: Wrong user name in log for system events nextcloud/server#31861" described the user is the alphabetically first in the user-list.

[Nextcloud Hub II] (23.0.3) (updated a few days ago, did not notice the behaviour prior to the update)
Activity 2.15.0

[doc75]

On my side also the wrong user is the first in alphabetical order.

[ChristophWurst]

I have also seen this on an installation recently

• User A has a calendar shared with user B
• User B deletes an event
• The event goes into user A's trash bin (Allow access to shared caldav trash bin items server#27372)
• After 30d the event gets deleted in the background -> the backend assumes to calendar owner to be the actor

[ChristophWurst]

\OCA\DAV\CalDAV\Activity\Backend::triggerCalendarActivity does

$currentUser = $owner;

if there is no user in context. that is the case with cron.

[ChristophWurst]

For calendar events we currently have two activities: one when the event is moved to the bin, another when it expired inside the bin. Both say the event was deleted by a user. What if we just only emit an activity for the first case? Expiring the trash should be silent.

[okow]

As a user i've never noticed the second deletion event and i agree it's of little or no use.

But to clarify my first post about the wrong user being reported:
It is not a user the calendar event was shared with and who may have/had the right to delete it.
In my case it was another, uninvolved person who just is the first one in alphabetical order on the userlist.

BTW: on my system this exact person changed recently from 'Bisch*** ' to 'A_Zo***' since i added the latter.
I also just checked for wrong activities which happend before the creation of this new 'first' user.
Those activities still state 'Bisch***' as actor only new entries show 'A_Zom***'.
So the bug seems to happen at creation-time of the activity-entry, not at display time.

[kaiyou]

According to my latest comment there, I am now fairly certain this is the same issue as nextcloud/server#31861 and it sounds like it is more general than activity, so I would tend to consider this one a duplicate.

[tcitworld]

What if we just only emit an activity for the first case? Expiring the trash should be silent.

This is already done, there's no activity produced when the calendar object has the deletedAt information.
https://github.com/nextcloud/server/blob/9de0e77ee016c00973720b79069e9c931090390c/apps/dav/lib/Listener/ActivityUpdaterListener.php#L222-L226

[vierbergenlars]

This is already done, there's no activity produced when the calendar object has the deletedAt information.

Unfortunately, I just found out that the calendar object never has the deletedAt information.

The CalendarObjectDeletedEvent is dispatched here: https://github.com/nextcloud/server/blob/0bceaee444c61a613c636e8bd3579c19764f0c66/apps/dav/lib/CalDAV/CalDavBackend.php#L1479

A couple of lines, before the calendar data is fetched with getCalendarObject(): https://github.com/nextcloud/server/blob/0bceaee444c61a613c636e8bd3579c19764f0c66/apps/dav/lib/CalDAV/CalDavBackend.php#L1462,
which does not include the deleted-at property at all: https://github.com/nextcloud/server/blob/0bceaee444c61a613c636e8bd3579c19764f0c66/apps/dav/lib/CalDAV/CalDavBackend.php#L1462

So, in effect, activities are produced for calendar objects that are purged from the trashcan.

[tcitworld]

Thanks a lot! I had the idea to check that but forgot to!
Working on a fix.

[tcitworld]

If you're seeing this, beware that you need both nextcloud/server#32471 and nextcloud/server#30438 (or their appropriate backports for your Nextcloud version) to have it fixed.