Implement OCM to groups in ownCloud core

[michielbdejong]

For now, OCM invites will be sent user-by-user, but we could start prototyping something towards milestone 4, where the OCM call from oc1 to oc2 targets a group@oc2 (or even a group@some-shared-aai) instead of a user@oc2.

[michielbdejong]

This will only work if the sender knows that the receiving server will know what is meant with the group name, i.e. when they share an AAI. Maybe the group name should be namespaced to a specific AAI server.
The sending server should send just one OCM share instead of one per receiving user.
The receiving server should probably have a new remote share type.
How will accepting / removing the share work?

[michielbdejong]

In today's standup we decided to go ahead with this.

[michielbdejong]

@navid-dada let's work on this in pondersource/core#1

[michielbdejong]

See also https://github.com/SURFnet/rd-sram-integration/blob/main/README.md#use-case

[michielbdejong]

Unlike in Nextcloud, in OC-10 the database table schema doesn't have a 'share_type' column:

| oc_share_external | CREATE TABLE `oc_share_external` (
  `id` bigint(20) NOT NULL AUTO_INCREMENT,
  `remote` varchar(512) NOT NULL COMMENT 'Url of the remote owncloud instance',
  `remote_id` varchar(255) NOT NULL DEFAULT '-1',
  `share_token` varchar(64) NOT NULL COMMENT 'Public share token',
  `password` varchar(64) DEFAULT NULL COMMENT 'Optional password for the public share',
  `name` varchar(255) NOT NULL COMMENT 'Original name on the remote server',
  `owner` varchar(64) NOT NULL COMMENT 'User that owns the public share on the remote server',
  `user` varchar(64) NOT NULL COMMENT 'Local user which added the external share',
  `mountpoint` varchar(4000) NOT NULL COMMENT 'Full path where the share is mounted',
  `mountpoint_hash` varchar(32) NOT NULL COMMENT 'md5 hash of the mountpoint',
  `accepted` int(11) NOT NULL DEFAULT 0,
  `lastscan` bigint(20) unsigned DEFAULT NULL,
  PRIMARY KEY (`id`),
  UNIQUE KEY `sh_external_mp` (`user`,`mountpoint_hash`),
  KEY `sh_external_user` (`user`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_bin |

[michielbdejong]

See #28 for latest progress.

[michielbdejong]

Three advantages to implementing it this way:

• it has already been tested for local groups, in production, and people are happy with the way it works, so let's not deviate from that.
• Nextcloud also has the additional share_type column in oc_share_external, so we can avoid deviating from that.
• Having the group id in the incoming OCM share will be useful so we can for instance display it in the UI, and implement group-level behaviour for add/remove/accept/revoke/delete/etc that we maybe didn't even think about yet.

So I would say:
First, use copy-paste to add the behaviour for local shares to to incoming OCM shares.
Then, see if you can use inheritance to improve code reuse.

[michielbdejong]

We talked to Juan from ownCloud, he asked us to store incoming remote group shares in a separate table, put all the functionality in an app, and keep changes to ownCloud core to a minimum.

[michielbdejong]

Places where share_external is mentioned in the owncloud/core codebase and where we probably have to add an additional db query to share_external_group:

• https://github.com/owncloud/core/blob/v10.11.0/apps/files_sharing/lib/Command/CleanupRemoteStorages.php#L175
• https://github.com/owncloud/core/blob/v10.11.0/apps/files_sharing/lib/External/MountProvider.php#L64
• https://github.com/owncloud/core/blob/v10.11.0/apps/files_sharing/lib/External/ScanExternalSharesJob.php#L256
• https://github.com/owncloud/core/blob/v10.11.0/apps/files_sharing/lib/External/ScanExternalSharesJob.php#L269
• https://github.com/owncloud/core/tree/v10.11.0/apps/files_sharing/tests
• https://github.com/owncloud/core/blob/v10.11.0/apps/files_sharing/lib/External/Manager.php but we're overwriting that, right?

Of these, getMountsForUser looks like it's probably what DAV uses to determine which shares to mount into the DAV file tree, right?

[michielbdejong]

getMountsForUser is used in Filesystem.php which is used by DAV probably.

[michielbdejong]

Continuing development in https://github.com/pondersource/core/tree/surf-dev which is a combination of
https://github.com/pondersource/core/tree/accept-ocm-to-groups
and
https://github.com/pondersource/core/tree/ocm-via-sciencemesh

[michielbdejong]

Retrieving the ShareProvider(Factory) code from
https://github.com/pondersource/core/blob/60c23f7de89b213d175d25a1d71c7e7086404b6a/lib/private/Share20/ProviderFactory.php
so we can move it into the ShareProviderFactory of the FederatedGroups app.

[michielbdejong]

With #73 and #48 closed we are getting pretty close to this now!
@navid-dada what is left to do, you think?

[shokri-navid]

So currently these functionalities are available:

• send a sharing request from sender to receiver.
• reciver will notified about new incoming federated shared file.
• receiver can accept the shared file.
• all accepted shared file are listed in main files list in Files Application.

So these functionalities should be tested and implemented if necessary:

• declining incoming share.
• revoke share by the sender
• resharing preshared files.
• what should be the receiver party's reaction to deleting the shared file from the sender party?

[navid-shokri]

this issue will be continued in these issues #74 , #75, #76 , #77

[navid-shokri]

So I will close this Issue. work will be continued with the above-mentioned issues.