Group- and User Names don't work after Update to 7.10

We use Group names that have ‘-’ Characters, like ‘executive-board-member’.

After moving to the Docker image 7.10 (community and enterprise) we get the following messages:

Group has an invalid id: 'executive-board-member' is not a valid resource identifier.

Is this a bug or is there a migration path for 7.9 to 7.10?

1 Like

Hi @pme123,

with Camunda BPM 7.10 we introduced a Whitelist Pattern for User, Group and Tenant IDs. This pattern is enabled by default which means that your defined group name is not valid anymore. You can either change group names to comply the pattern or define your own Whitelist Pattern. For more information, please see the migration guide.

Cheers,
Tassilo

1 Like

We have run into this problem updating from 7.8 to 7.11. As with the original OP we have some characters which are now disallowed in our group IDs.

Is there a reason why Camunda has restricted these id fields? If it’s solving a bug or going to cause problems in the future, I’d like to take the pain now, but if not I will leave as-is.

Hi @Ettery,

it’s for security reason: https://docs.camunda.org/security/notices/#notice-3.

But you can change the default whitelist: https://docs.camunda.org/manual/7.11/user-guide/process-engine/identity-service/#custom-whitelist-for-user-group-and-tenant-ids

Hope this helps, Ingo

1 Like

This change pushes us towards less readable group ids - which is a good thing, my Camunda groups are coming from another system and I’d like to use that system’s numeric IDs as Camunda group IDs. However, I see that you are displaying Group IDs on the Tasklist UI, which is then meaningless to the user (see attached screen shot).

Do you have plans to fix the UI? The point of having a Name field is usually that that is what’s displayed for the user, allowing the ID to be system-defined.

image

Hi @Ettery,

interesting finding. It works as expected in the invoice example included in the download distribution. Here, the group displays are “Accounting, Sales”, which are the group names.

Running the example with developer console of the browser, I saw that the response frm the engine contains both, ID and name of the groups:

{
  "group": [
    {
      "_links": {
        "self": {
          "href": "\/group\/accounting"
        }
      },
      "_embedded": null,
      "id": "accounting",
      "name": "Accounting",
      "type": "WORKFLOW"
    },
    {
      "_links": {
        "self": {
          "href": "\/group\/sales"
        }
      },
      "_embedded": null,
      "id": "sales",
      "name": "Sales",
      "type": "WORKFLOW"
    }
  ]
}

Maybe you can influence the return of your identity service providing the groupname? For LDAP it looks like this example:

    <property name="groupSearchBase" value="" />
    <property name="groupSearchFilter" value="(objectclass=groupOfNames)" />
    <property name="groupIdAttribute" value="ou" />
    <property name="groupNameAttribute" value="cn" />
    <property name="groupMemberAttribute" value="member" />

Hope this helps, Ingo

Thanks for looking into this Ingo, let me dig into what is going on on our side.