fix: align space action permissions with backend abilities

[tiran133]

Description

Space actions (canBeDeleted, canRename, canEditDescription, canRestore)
now honour the abilities reported by the backend when user has "create-all" permission.

According to
https://github.com/opencloud-eu/reva/blob/main/pkg/storage/utils/decomposedfs/spaces.go#L1115-L1116
The User should be able to disable/restore and delete its managed spaces.

Backend Permission for create-all frontend permission.

{
        "id": "79e13b30-3e22-11eb-bc51-0b9f0bad9a58",
        "name": "Drives.Create",
        "displayName": "Create Space",
        "description": "This permission allows creating new spaces.",
        "permissionValue": {
          "operation": "OPERATION_READWRITE",
          "constraint": "CONSTRAINT_ALL"
        },
        "resource": {
          "type": "TYPE_SYSTEM"
        }
      },

Although it won't fix the underlaying issue that the owner of a space (User role) should be able to disable/delete/restore via the frontend. Currently, only disable is possible. Restoring or deleting a space as manager of that space with the User role is still not possible.

The comment in the functions.ts suggest problem with the permission model
https://github.com/opencloud-eu/web/blob/main/packages/web-client/src/helpers/space/functions.ts#L244

At least this honour Drives.Create with CONSTRAINT_ALL

Related Issue

• Fixes
  Disabling and deleting Spaces with API when UI for disabling and deleting space is not shown in context menu opencloud#1799

How Has This Been Tested?

• test environment: local dev setup (pnpm vite against a local OpenCloud backend via docker-compose up -d)
• test case 1: unit tests in packages/web-client/tests/unit/helpers/space/functions.spec.ts updated/added to assert action-specific permission handling for canBeDeleted, canRename, canEditDescription, and canRestore (verified with pnpm test:unit --run packages/web-client/tests/unit/helpers/space/functions.spec.ts)
• test case 2: manual check in the UI for a disabled space — restore/delete/rename/edit-description actions only appear when the backend grants the corresponding ability
• test case 3: pnpm check:all passes (types, lint, format, unit tests)

Types of changes

• Bugfix
• Enhancement (a change that doesn't break existing code or deployments)
• Breaking change (a modification that affects current functionality)
• Technical debt (addressing code that needs refactoring or improvements)
• Tests (adding or improving tests)
• Documentation (updates or additions to documentation)
• Maintenance (like dependency updates or tooling adjustments)

[JammingBen]

Restoring or deleting a space as manager of that space with the User role is still not possible.

I'm not 100% sure, but if I remember correctly (and according to the docs) it shouldn't be. Disabling, restoring & deleting spaces is for administrators and space admins, not space managers. In that case this would be an API issue, since it currently allows all these operations for managers on their assigned spaces. There is no such thing as an "owner" of a project space, I believe that's why we went with that decision. I might be wrong though... @tbsbdr @micbar do you remember?

Anyway, you stated that this PR is not tackling this issue, so to be honest, I'm having a hard time understanding what it actually solves for you. Is it related to the custom role you mentioned in opencloud-eu/opencloud#1799?

[tiran133]

When I was writing owner I meant manager, a space member with can manage permission.
I'm aware there are no ownerships of a space.

About what the docs say it is a bit wired since currently you are allowed to disable any space are a member of with permission can manage regardless of User role.
Either via API or UI if that's not intended as the docs say it's a serious issue.
I confirmed this on the demo site. I disabled "Webinars and Talks" as Alana

I then can even delete/enable it straight after. But as soon as I refresh the page I am now unable to enable/delete it again via UI still be able to enable/delete via API.

Yes, it would fix an issue we have with our custom role. Where we took the User Role and added the Drives.Create Permission and called it spaceoperator
This way we can create users which are allowed to create spaces but don't see the admin menu to manage all space.
Just their “own” they get added as can manage to that created space.

That's what the original issue was about.

But yes in essence the issue where you should or shouldn't (I guess this question has to be answered first) be able to disable/enable/delete as a member with can manage permission still persists and has nothing to do with our custom role.
When we opened the other issue in Nov. last year I did not dig into this as deep.
Now I can see it is a general problem with the can manage permission.

We also could add Drives.ReadWriteEnabled to the custom role, but this is a more powerful role which allows to disable/enable/delete for all spaces even though the User doesn't have the can manage permission. More like an admin permission.


I can see why you hesitant to address the issue like this when it comes to permissions since this would probably just solve our needs nothing else in general and probably is just a workaround.

But the original issue is over 7 month old and wasn't addressed properly.

Let's use this opportunity to address this now?

I think it first it needs to be answered
Should or shouldn't a can manage member be allowed to disable/enable/delete

Based on that it is either a serious issue with the permission model or just a UI issue.

And it should not lay there for 7 months.

Anyway I hope we can find some solution here and I am happy to help where I can.

[JammingBen]

I think it first it needs to be answered
Should or shouldn't a can manage member be allowed to disable/enable/delete

Yes I agree. I'll check in with the team to get an answer to that, then we can decide how to move forward with this. Sorry for the long wait!