RFC-103: Jira Field Configuration Overhaul: Admin Experience and API Changes

General Request for Comments (RFC)
, , ,
32

Hi Leanne,

Thanks for asking. First of all our app does not need the customFieldConfigScheme mapping, I was just curios because of the impacts of the RFC and the CHANGE-3019. What we really miss is the contextId mapping.

Our app provides delegated administration features so that normal users can work on custom field contexts and edit/delete/update options.

Therefore we actually do not care on which screens the custom field appears in, since we provide the user a direct list of fields+contexts. When the user clicks on the field he sees the field contexts which he has permissions for. And then he can click on the context he wants to edit and work on the options.

To achieve this we implemented our own app permissions. We can grant to users or groups to work on the entire field (global field permission) or to work only on single contexts (context permissions).

We basically store for example to grant user bob with userId=155 to field with fieldId=10064 and context X with contextId=12108 that has projectY with id=10008 and projectZ with id=10009

contextPermission => { fieldId=10064, contextId=12108, userId=155 }

When it comes to cloud migrations we can successfully map :green_square: these things:

  • userIds/userKeys
  • groupNames
  • fieldIds

But we cannot map :red_square: (because the mapping is missing)

  • contextIds

—-

I am currently working on a workaround where I use projects to map 1:1 with contexts and handle the global context differently.

:open_book: /rest/api/3/field/customfield_10064/context/projectmapping

{
  "maxResults": 100,
  "startAt": 0,
  "total": 84,
  "isLast": true,
  "values": [
    { "contextId": "10198", "isGlobalContext": true },
    { "contextId": "10476", "projectId": "10072" },
    ...
    { "contextId": "10553", "projectId": "10149" },
🩵  { "contextId": "12108", "projectId": "10008" },
🩵  { "contextId": "12108", "projectId": "10009" },
    { "contextId": "12109", "projectId": "10002" }
  ]
}

The workaround currently maps the server projectId to a cloud projectId. Per custom field I then have to get the projectmapping and match the contexts by projectId. Which is a lot of work and could be error prone. I need special handling for global context and maybe some workItem based contexts.

:fairy: My wish is simply to get a direct 1:1 server custom field contextId to cloud custom field contextId mapping. Or is the jira/classic:customFieldConfigScheme mapping really the contextId mapping already? And will it map to the cloud contextId even after the CHANGE-3019 changes?
Please clarify thanks.

that would be awesome :slight_smile: