No update on activity after federated share has been expired on sharer activity

[grgprarup]

Steps to reproduce

1. Create user Alice on the LOCAL server, and user Brian on the REMOTE server
2. Share a file lorem.txt from user Alice to federated user Brian
3. Accept incoming shares for federated user Brian
4. Let it expire

Expected behaviour

It should be like, You removed the share of 'federated user' for 'lorem\.txt' like in user share or public share

Actual behaviour

No updates on the activities list after the share is expired. Is this the expected behavior?

curl -k -XGET -uAlice:123456 http://localhost/core/index.php/apps/activity/api/v2/activity

{
  "ocs": {
    "meta": {
      "status": "ok",
      "statuscode": 100,
      "message": null
    },
    "data": [
      {
        "activity_id": 1524,
        "type": "remote_share",
        "user": null,
        "affecteduser": "Alice",
        "app": "files_sharing",
        "subject": "remote_share_accepted",
        "subjectparams": [
          {
            "value": "Brian@http://localhost/fed-core",
            "type": "federated_cloud_id"
          },
          {
            "value": "lorem.txt",
            "type": "file"
          }
        ],
        "message": "",
        "messageparams": [],
        "link": "http://localhost/core/files/index.php?dir=%2F&scrollto=%2Florem.txt",
        "object_type": "files",
        "object_id": 2147522177,
        "object_name": "/lorem.txt",
        "subject_prepared": "<federated-cloud-id display-name=\"Brian@…\" user=\"Brian\" server=\"http://localhost/fed-core\">Brian@http://localhost/fed-core</federated-cloud-id> accepted federated share <file link=\"http://localhost/core/index.php/apps/files/?dir=/&scrollto=lorem.txt\" id=\"2147522177\">lorem.txt</file>",
        "message_prepared": "",
        "typeicon": "icon-shared",
        "datetime": "2022-06-28T07:15:06+00:00"
      },
      {
        "activity_id": 1523,
        "type": "file_created",
        "user": "Alice",
        "affecteduser": "Alice",
        "app": "files",
        "subject": "created_self",
        "subjectparams": [
          {
            "value": [
              {
                "value": {
                  "2147522177": "/lorem.txt"
                },
                "type": "file"
              },
            ],
            "type": "collection"
          }
        ],
        "message": "",
        "messageparams": [],
        "link": "http://localhost/core/index.php/apps/files/?dir=/",
        "object_type": "files",
        "object_id": 2147522177,
        "object_name": "/lorem.txt",
        "activity_ids": [
          1523,
        ],
        "files": {
          "2147522177": "/lorem.txt"
        },
        "subject_prepared": "You created <collection><file link=\"http://localhost/core/index.php/apps/files/?dir=/&scrollto=lorem.txt\" id=\"2147522177\">lorem.txt</file></collection>",
        "message_prepared": "",
        "typeicon": "icon-add-color",
        "datetime": "2022-06-28T07:14:08+00:00"
      }
    ]
  }
}

Server configuration

Where did you install ownCloud from: Latest github master

[phil-davis]

After the end of the share expiry date, the share will still exist in the database until:

• someone accesses the share (at that time the LOCAL server should process the incoming access request, realize that the share is past its expiry, remove the share and return a "not found" response) During that processing on the LOCAL server, if the activity app is enabled, it should log the expired-share event.
• the daily cron job runs (some time during the next day) and removes any shares that are now past their expiry. That cron job should log the expired-share event for each share that it removes.

As well as the automated test added in PR #1115 it will be good to do a manual test of the expiry, to double-check that a normal workflow also has this issue. I have set this up locally. I will see what happens tomorrow...