Persist space memberships in share manager#634
Merged
Conversation
Grants on SpaceRoots still require the "spacegrant" and "spacetype" Opaque.
For managing space memberships via the sharemanager we need to loosen the resharing restriction a bit. As adding a new space manager is basically "resharing".
Avoid duplicating code in all managers
Up to now we sent the SpaceShared/SpaceUnshared/SpaceShareUpdated events as part of the Add/Remvove/UpdateGrant calls. With the recent changes to handle Space Membership via the Share manager this resulted in two Events being sent when a Space was shared, one for the ShareCreation and one of the AddGrant. With this change we send the Space related events as part of the Create/Delete/UpdateShare calls. Unfortunately this means we need to add yet another Opaque field to the responses from the ShareProvider to indicate that the thare being accessed was actually targeting a SpaceRoot.
Currently the storage driver is responsible for adding an initial Grant to the SpaceRoot to give the creator of a space the "manager" permssions. With the share manager becoming the primary source for space membership we now to create that initial share as part of the CreateStorageSpace call in the gateway.
The check is done in the shareprovider now not in the space specific code in the gateway.
Some callers (e.g. the graph API) currently only set the OpaqueId of the Grantee, without populating the IDP and Type properties. For User shares we already set those to fallback values. This was missing for Group shares.
This reworks some of the special case handling that the ocs service did for managing space shares. This is mainly for making the acceptance test working in OpenCloud. I don't think any real world client is still using ocs for sharing spaces. Anyway, with this change this should still work.
previously the acceptance tests worked just because of side-effects in
the Handlers for the `/apps/files_sharing/api/v1/shares/{shareid}` route.
Now, if `apps/files_sharing/api/v1/shares/pending` is called without a
{shareId}, we have explicit routes for that.
This check was previously done by the Gateway, when updating the grants on the SpaceRoot.
The permissions check for share removal was moved from the manager/driver to shareprovider we forgot to update the unittest accordingly.
When we can't create the initial "owner" share for a new space, we now delete the created space to not leave any dangling space behind. Adds unit test as well.
Verify that the resource id returned from 'ParseReference' actually looks like a space id.
This removes the code that allowed to by-pass the shareprovider when managing space memberships. Space memberships are now always stored in the usershareprovider.
Move away from lazily initializing the connection to the metastorage and try initialize at service startup. This is ground work for the upcoming migration to import the space memberships into the jsoncs3 share manager.
This is not a service user (i.e. managed by the service-auth authentication), but a special just for the system metadata storage.
When the received share to import has a userid set, we need to update the UserReceiveState even if the Grantee is a group (to correctly import the "accepted" state).
For the upcoming migration of space memberships to the shareprovider the service user needs to be able to read the Grants of all spaceroots.
…pacemember shares The migration state (currently only the version number) is persisted on the metadata storage (migratiion/state.json). Add a first migration "0001_import_spacemembers" to import the spaceroot Grants on the storageprovider as shares into the manager. Issue: opencloud-eu/opencloud#2612
When importing space membership, the userid's from the grants do not have an IDP value set. Do a user/group lookup to get the correct IDP value. Cache results to avoid repeated lookups.
res might be nil when disk.Download returned an error
This add locking around the migration runner to prevent the migrations being executed in parallel when multiple instances of the sharing service are running. The lock has a ttl of 1 minute and is refreshed every 20 seconds. Other instances are trying to acquire the look evert 5 seconds until it was either released or became stale.
This is needed for being able to run the unit tests of the jsoncs3 sharemanager.
While migration are running block any Write call on the share manager.
Allow to cleanly shutdown sharing service while migrations are running.
Member
|
I think we should merge this into main ASAP. We will have to test the performance impact over the course of several weeks. I don't see that happening in a branch. |
aduffeck
approved these changes
May 13, 2026
Member
aduffeck
left a comment
aduffeck
left a comment
There was a problem hiding this comment.
Tested successfully with the rhafer/spacemember-migration opencloud branch. lgtm
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
This merges the current state of the feature/guest-links branch into main. It contains change to how we persist space-memberships. We basically treat them exactly like shares now and persist them in the share manager.
This PR also contains a migration that runs at startup of the share-manager and import all existing space-membership into the share-manager.