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!

[tbsbdr]

needs clarification what the expected behaviour is

[tiran133]

To make it easy to understand and to not have to deal with a custom role. Ignore the custom role part.
It's not the issue here.
Also, I'm not even sure if this is the right place to discuss this.
I was just tired of waiting and tried to fix it myself opening this PR but then realising it is an underlying problem which has nothing to do with the custom role here.

---

Unfortunately that is not that easy to describe the expected behaviour. As there is one fundamental question to answer first.

As already multiple times described in here and here opencloud-eu/opencloud#1799
there is an inconsistency between the UI and the API.

I'm talking about a user (User role) which has the Can Manage permission in any space.

This user is allowed to disable the space. Any user with Can Manage is allowed to do this.
This user however cannot enable or delete the space via the UI.
After disabling the space and refreshing the page the two menu items are missing.

The refresh is key here without a refresh the user can enable/delete the space

After the refresh the user is still able to do this actions enable/delete via API.

You can try it on https://demo.opencloud.eu
Just login as Alan.

Two Option.

Option 1
The can manage permission allows disable/enable/delete This is what currently is reflected in the API.

Expectation:
The UI should show enable/delete options after a page refresh.

Option 2
The can manage permission should not allow disable/enable/delete of a space
And these actions are reserved for Space admin and admin according to the docs see above.

Expectation:
Fix the API to not allow these actions and also remove the disable menu item from the UI.


To voice a preference here. Option 1 is very much preferred here. As this would allow the user to self-manage the spaces.
At least this is what our use case requires.

---

Clarification on this PR!

As stated above this would fix the menu Items with our custom role. It would allow the user with that role to perform these actions, however, this would be a workaround and not a proper fix as also stated above.

The fix would be to have consistent behaviour with the Can Manage permission regardless which role the user has.