RFC-53: Changes to when a parent field can be edited

RFCs are a way for Atlassian to share what we’re working on with our valued partner community.

It’s a document for building shared understanding of a topic. It expresses a technical solution, but can also communicate how it should be built or even document standards. The most important aspect of an RFC is that a written specification facilitates feedback and drives consensus. It is not a tool for approving or committing to ideas, but more so a collaborative practice to shape an idea and to find serious flaws early.

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!

  • Publish: 20 May 2024
  • Discuss: 3 June 2024
  • Resolve: 17 June 2024

Problem

For issues in a company managed project, Jira administrators are able to configure screens for the three issue operation: create issue, view issue and edit issue.

For most fields, if a field is not configured on a screen for the edit issue operation, users are unable to edit the field for the issue.

The parent field does not follow this rule, the parent field is editable regardless of screen configuration.

A bug report has been created by customers to change the parent field to be consistent with other fields. See https://jira.atlassian.com/browse/JSWCLOUD-26400.

Proposed Solution

In order to resolve the bug, the following experiences will be changed when the parent field is not on the screen configured for the edit issue operation:

  • The issue view - the parent will be visible but not editable
  • The edit issue metadata REST API - will not return the parent field in the response

Impact on new and existing projects

There are many Jira users with existing company manage projects where the parent field is not on the screen configured for the edit issue operation.

In order to avoid changes in the parent field behaviour for these projects, the parent field will be added to the screen configured for the edit operation for existing company managed projects.

The parent field will also be added to the screen configured for the edit issue operation for new projects to ensure that the parent is editable on project setup.

Issue View

Editing the parent in the breadcrumb in issue view

When the parent field is not on the screen configured for the edit issue operation, a tool tip will appear in the breadcrumb to let users know they cannot edit the parent.

Editing the parent in the parent field in issue view

When the parent field is on the screen configured for the view issue operation but not on the screen configured for the edit issue operation, the parent field will visible but not editable.

Edit issue metadata REST API

The edit issue metadata REST API will not return the parent field in the response if it is not configured on the screen for the edit issue operation.

An example response for before

{
    "fields": {
        "parent": {
            "required": false,
            "schema": {
                "type": "issuelink",
                "system": "parent"
            },
            "name": "Parent",
            "key": "parent",
            "hasDefaultValue": false,
            "operations": [
                "set"
            ]
        },
        "environment": {
            "required": false,
            "schema": {
                "type": "string",
                "system": "environment"
            },
            "name": "Environment",
            "key": "environment",
            "operations": [
                "set"
            ]
        },
        "comment": {
            "required": false,
            "schema": {
                "type": "comments-page",
                "system": "comment"
            },
            "name": "Comment",
            "key": "comment",
            "operations": [
                "add",
                "edit",
                "remove"
            ]
        },
        "assignee": {
            "required": false,
            "schema": {
                "type": "user",
                "system": "assignee"
            },
            "name": "Assignee",
            "key": "assignee",
            "autoCompleteUrl": "https://example.atlassian.net/rest/api/3/user/assignable/search?issueKey=TES-2&query=",
            "operations": [
                "set"
            ]
        }
    }
}

An example response for after

{
    "fields": {
        "environment": {
            "required": false,
            "schema": {
                "type": "string",
                "system": "environment"
            },
            "name": "Environment",
            "key": "environment",
            "operations": [
                "set"
            ]
        },
        "comment": {
            "required": false,
            "schema": {
                "type": "comments-page",
                "system": "comment"
            },
            "name": "Comment",
            "key": "comment",
            "operations": [
                "add",
                "edit",
                "remove"
            ]
        },
        "assignee": {
            "required": false,
            "schema": {
                "type": "user",
                "system": "assignee"
            },
            "name": "Assignee",
            "key": "assignee",
            "autoCompleteUrl": "https://example.atlassian.net/rest/api/3/user/assignable/search?issueKey=TES-2&query=",
            "operations": [
                "set"
            ]
        }
    }
}

Edit Issue API

There will be no changes to the behaviour of the edit issue REST API. An api user will be able to edit the parent value of an issue regardless of their screen configuration as long as they have the correct permissions.

Asks

While we would appreciate any reactions you have to this RFC, we’re especially interested in learning the impact this will have on you and the amount of deprecation notice you would require to adjust to the change in behaviour.

2 Likes

Thanks, this is an important bug to be fixed.

Since the RFC is primarily talking about the issue view: Will this configuration also respected in the edit issue API, and all other UIs where a parent change may be possible (e.g. in the backlog drag and drop experience)?

Hi @hannes-finesoftware
At the moment we are not planning on making changes to the edit issue API.

Since the parent field is a highly used feature, we had concerns about the impact of these changes.
In order to reduce the risk, we decided to restrict the changes to issue view and the edit issue metadata REST API.
We plan to monitor the rollout and then gauge the desire from customers to change the edit issue API.

1 Like

The bug is a problem for sure, and needs to be addressed. IMO, the proposed workaround is … ok … if well documented. But I seem to recall that there are other system fields (Team?) that may have a similar problem of being editable when not on the Edit screen. It would be worth checking whether any other fields have a very similar problem as https://jira.atlassian.com/browse/JSWCLOUD-26400

Hello!
Thank you for creating this RFC. Will these same changes be reflected in the create field metadata endpoint? Currently the parent field is still included in the create metadata for an issue even if it’s removed from the relevant create screen, even though the create Jira issue modal hides it, meaning it’s hard to make our third party app consistent with Jira functionality.
Thanks!

1 Like

Hi @MattDoar

What kind of documentation would you like us to provide?
We are planning on publishing some documentation on the developer community about these changes, is there other documentation you would like to see?

Also, thank you for raising the point about other fields. We have been focusing on the parent field specifically for this change but I’ve started some discussions about how we wish to deal with the other fields.

Kind regards
Anne

Hi @SophieRogers

We explored looking at the create field metadata endpoint, I agree it’s a confusing experience.

At the moment, we are planning on only making changes to the edit issue metadata REST API to minimise the risk of these changes.
We suspect changing the create field metadata endpoint would have a large impact.

Kind regards
Anne

1 Like

I’m thinking of the documentation about system fields. Somewhere there is text for example that says you can only stop the Priority field appearing by using a field configuration, not a screen. For DC at least. Somewhere like that to explain when you can and cannot edit the Parent field. Otherwise every Jira admin will have to reverse engineeer this behavior themselves, not the best experience.

Hi @matt

Sorry for the delayed response.

I’ve had a discussion with a couple teams regarding your comment about other fields having the same problem.
It seems we have tried to address this problem in the past but have hit problems when we rolled out the fix.
When the behaviour for a field was changed to respect the edit screen, there were many customers who relied on the broken behaviour of being able to edit the field without having the field on the edit issue operation screen and were negatively impacted.

We’re trying to avoid this happening with the changes to the parent field by adding the parent field to existing screens and new screens. However, it may be harder to justify making these types of changes to a customer’s configuration for other less used fields.

I’d suggest if this is a concern to you, to raise a bug so that we can gauge the impact / interest of fixing this issue.

Regarding documentation, thanks for raising this. I’ll speak to our content designers on how to make the behaviour clear in our documentation.

Kind regards
Anne

Hi everyone, thanks for sharing your thoughts here. I wanted to let you know that we have now published the above as an official deprecation, with an adjusted period of 3 months given the relatively minor impact of this change. See below for a link to the official notice, with reference code CHANGE-1641.

1 Like