Feature request: support specifying group id separately

[uumas]

Description

If a group has id matching what is configured in oidc groups mapping, but a different display name, it will rename the group to have the same name as the group id. This situation can be achieved using the API or by renaming a group.

Steps to reproduce

1. Create a group "department1"
2. Rename the group to "International Sales Office"
3. Create a mapping rule that adds user to group "department1"
4. Log in using that user

Expected behavior

The user to be added to the group "department1" with display name "International Sales Office".

Actual behavior

The user is added to the group, but its displayname is changed to "department1" too

Environment

• Nextcloud version: 33.0.3
• PHP version: 8.4.21
• user_oidc version: 8.10.1
• oidc_groups_mapping version: 1.1.0

[strobelpierre]

Thanks for the report. I've spent some time tracing this — quick summary of what I think is happening, then a few config questions on your side to confirm before pointing the finger upstream.

Code-path analysis

oidc_groups_mapping only writes a JSON array of group IDs onto the AttributeMappedEvent value — lib/Listener/GroupsMappingListener.php line 56. It doesn't create groups, look up display names, or touch IGroupManager.

user_oidc then reads that value in lib/Service/ProvisioningService.php. When it sees a plain string item (line ~623):

$group = (object)['gid' => $v, 'displayName' => $v];

And later, line ~781:

if (isset($group->displayName)) {
    $newGroup->setDisplayName($group->displayName);
}

So setDisplayName runs on every login with displayName = gid and overwrites whatever the group had before. That matches your symptoms exactly — but I'd like to confirm the path before sending you to file upstream.

What I'd like to check on your install

To rule out a different code path on your side:

1. user_oidc provider config (Settings → Administration → OpenID Connect → your provider):

   • Provider type (Keycloak / Authentik / Authelia / Azure / generic)?
   • Is "Use Azure Graph API to resolve group names" enabled?
   • Is there a group whitelist regex set?
   • Which claim is configured as the group mapping source?

2. oidc_groups_mapping rule that matches department1 — either the output of:

   php occ oidc-groups:list
   

   or a screenshot of the relevant rule from the admin UI.

3. How was department1 renamed to "International Sales Office"? — Admin UI / occ group:rename / API / direct DB write?

With those three pieces I can either confirm the path and write up a clean reproducer for a nextcloud/user_oidc issue, or find a different cause if I'm reading the wrong branch.

Workaround in the meantime

If you want a stopgap while we sort the upstream side: keep gid == displayName so the per-login rename is a no-op. Not ideal, but unblocks you immediately and doesn't require patching anything.

[uumas]

okay, so the items of the array can be either strings or objects. If the item is a string, it will use it as the group id and display name. If it's an object like {gid: "department1", displayName: "International Sales Office"}, it will use those and if it's just {gid: "department1"}, it will assign the group but leave the display name as is.

It seems this app just passes strings to it. There could be an option to specify gid and displayName separately. User_oidc can handle a mix of strings and objects, so additive mode doesn't cause problems if the native groups attribute is in a different format than this plugin uses.

[Benny7623]

Is it possible, that the Nextcloud Version 33 is not supported yet?

[uumas]

I mean sure, but the nextcloud version isn't really relevant here. User_oidc version is same anyway.

[Benny7623]

I tried to use oidc_groups_mapping very detailed/extensively, but with no success to add a user to a specified Group.
I'm using Keycloak with groups and the groups Claim, which seems to work in user_oidc, but not in the oidc_groups_mapping. Do you have a hint how I can debug the Claims I get from Keycloak?
I tried almost every possible Rules that are cnfigurable from the Nextcloud Userinterface in the Browser, except the template, as I don't yet understand how to use it.
I even tried to use nextcloud_groups and nextcloud_reamls instead of groups.
What's the difference between "additive" and "replace" in the User Interface above the rules to be added?

[uumas]

Offtopic. This is a feature request. For help, see https://help.nextcloud.com/

[strobelpierre]

Hi @Benny7623,

uumas is right that this is the wrong thread (this issue is now a feature request about preserving group display names). For general support questions the Nextcloud Help forum is the right place. A few quick pointers since you've already posted here:

NC 33 compatibility: the appinfo/info.xml declares max-version=32, so the appstore won't serve the app on NC 33 by default, but it works in practice — install it via occ app:install --force (uumas is running it on NC 33.0.3 and I tested it on NC 33 locally last week, no functional issues). I'm going to bump that to 33 in the next release.

Debugging Keycloak claims: easiest path is to set Nextcloud loglevel to 0 in config.php and watch data/nextcloud.log during a login. user_oidc logs the full token payload it receives, so you'll see exactly what shape your groups claim has (array of strings, array of objects with name/id, nested under another key, etc.). From there you'll know which claim key to point your rule at.

"additive" vs "replace": these are the two modes the plugin supports for the resulting group set.

• replace: after login, the user's group membership is set strictly to what the rules produce. Groups the user had before but not in the result are removed.
• additive: the rules add groups but never remove. Existing memberships are preserved.

Pick replace if Keycloak is your source of truth; pick additive if you want to mix OIDC-assigned groups with locally-managed Nextcloud groups.

If after enabling debug logs you still don't see your claim being parsed, please open a separate issue with the relevant log excerpt and your rule config — happy to take a look.

[strobelpierre]

Hi @uumas,

Thanks for the detailed analysis and the proposed solution — it lines up with what I traced too. I'm going to implement this.

Design I'm going with: a global toggle in the rule collection (next to the existing additive/replace mode), default off for backward compatibility. When enabled, the listener emits [{"gid": "..."}] objects instead of plain strings, which makes user_oidc skip setDisplayName and preserves whatever display name the group already has.

Concretely:

• One bool field preserveDisplayName at the top of the rule JSON
• Admin UI checkbox alongside the mode selector
• CLI: works through the existing oidc-groups:set JSON arg, no new command needed
• No per-rule option for now — keep it simple, can be added later if a use case comes up

Also planning to bump max-version to NC 33 in the appinfo. I tested v1.1.0 on NC 33 locally last week and you're already running it there with --force — no functional issue reported on either side so far. So 32 and 33 should both ship in v1.2.0.

Does the global-toggle design work for your use case, or do you actually need it per-rule (e.g. some rules preserve display name, others overwrite)? Want to confirm before I start coding.

[uumas]

global toggle is fine