Allow disabling group prefix

[hrenard]

Expected behaviour

We should be able to disable group prefix.
I think it's a regression because this was the default behavior in v5.

Actual behaviour

It's not possible to set an empty value from the CLI.
And in the UI, the difference between empty or default isn't clear either.

Server configuration

PHP version:
8.2

Nextcloud version: (see Nextcloud admin page)
28.0.9

App version:
6.2.0

[blizzz]

The behaviour is different yes, but existing groups are not affected.

[rthaler]

But it breaks systems using group names without a prefix. The lack of an option to disable the prefix or set it to empty is causing issues. This flexibility is needed to maintain compatibility with setups that don’t use group prefixes. In my case, new users automatically provisioned via SAML end up in new groups like SAML_groupname and therefore lose access to existing shared resources.

[blizzz]

But it breaks systems using group names without a prefix. The lack of an option to disable the prefix or set it to empty is causing issues. This flexibility is needed to maintain compatibility with setups that don’t use group prefixes. In my case, new users automatically provisioned via SAML end up in new groups like SAML_groupname and therefore lose access to existing shared resources.

These are local groups with users from mixed backends?

[rthaler]

In my case, there is no mix of different backends. All users and groups are exclusively provisioned via Keycloak, so these are local groups created by Keycloak. However, the proposed change would require me to adjust all existing groups and group assignments, which would create significant complications. Additionally, folders and shares are created by another system, meaning adjustments would also need to be made there, further complicating the process. That’s why it would be very helpful to have the option to disable the prefix or set it to empty, to ensure compatibility with the existing setups.

[blizzz]

@rthaler

In my case, new users automatically provisioned via SAML end up in new groups like SAML_groupname and therefore lose access to existing shared resources.

Users are still sorted into existing groups that do not have a prefix. And when migrating groups from local to SAML backend, the ID will persist without the backend. Both scenarios are covered with automated tests.

Additionally, folders and shares are created by another system, meaning adjustments would also need to be made there, further complicating the process.

Now when it comes to newly created groups and the IDs are just assumed, then I see how you can run into it.