RFC-6 - Change in workflow properties - Group Name -> GroupId

RFCs are a way for Atlassian to share what we’re working on with our valued developer community. Please respect our community guidelines: keep it welcoming and safe by commenting on the idea not the people (especially the author); keep it tidy by keeping on topic; empower the community by keeping comments constructive. Thanks!

All usages of group name in Jira platform workflows are migrating to the respective group id.

  • Publish: 14 Apr 2023
  • Discuss: 28 Apr 2023
  • Resolve: 12 May 2023

Problem

The reasons behind this are:

  • Change group names without breaking workflow rules.
  • A step towards unblocking import of multiple sites into one.

We will deal with all the structured data within the instance like performing online translations. The APIs will remain the same and the experiences will be affected as little as possible. However, we won’t translate the workflow properties, which admins must review and translate.

The properties that will be affected will be the ones with this shape:

jira.permission[.subtasks].{permission}.group.[.suffix]

For example:

  • jira.permission.subtasks.attachdeleteown.group
  • jira.permission.attachdeleteown.group[2]

See Jira Cloud admin docs on using workflow properties.

Once we issue the deprecation notice, admins and vendors will need to perform these translations themselves to make permissions work. If they aren’t changed, these permissions will always evaluate as false.

Given our development guidelines, we don’t have a safe way to roll out a translation between GroupName → GroupId that can be rolled back. Since it’s a workflow property that can be any key and value, we can’t guarantee that updates will not overwrite these.

For instance, a Marketplace app could set a property for a previously translated permission, breaking the workflow’s intention. Given the deprecation notice, this error could take months to discover, making debugging hard.

Even if we create a new parameter with the translated entry, vendors and admins would still have to do the implementation and migration work. We wouldn’t be reducing the amount of work that admins and vendors will need to do.

Proposed solution

For the length of the deprecation notice, we will be supporting — for these permissions — to have groupName or groupId. Once the deprecation notice is over, we will no longer support groupNames in permissions with this shape.

jira.permission[.subtasks].{permission}.group.[.suffix]

Actions

Admins and vendors will be required to update the content of properties in workflows with this shape:

jira.permission[.subtasks].{permission}.group.[.suffix]

to use groupId instead or groupName.

Vendors and admins can also delete these properties or update their process in order to use Conditions or Validators available - if that suits their business processes.

1 Like

This may be a stupid question, but will product admins be able to reference the group IDs to configure the properties?

Hi AaronMorris1, thanks for your question.
The visibility on the groupIds will require site admin or organization admin permissions, as they do today - Create and update groups | Atlassian Support
If you are a product administrator without site/organization admin permissions, you would require of your site/organization admin’s assistance to change these permission values, as you would require it in order to see the group names currently.
Luis.

1 Like

Solved in favour of the proposed solution.