nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

Best practice for custom fields unique to a project

Mick Szucs

A question for the Atlassian admins here.

Our instance has a number of projects sharing a common set of screen schemes.

The owner of one project is requesting an additional field that should appear only on issues in their project.

It seems like there are two options available to achieve this:

1 - move the project to it's own set of screen schemes and add the unique custom field.

2 - configure the custom field with context settings that make it available only in the target project, and add it to all the relevant screen schemes.

Which approach is recommended?

Accepted answers

Scott Schellhardt_kfhy1i

Hi Mick,

Personally I would do option 1. In my case, I will typically have a discussion with the user about what problem the addition of a custom field is trying to solve for them, then I would see if there was a field already living in the instance that would provide the same or similar function, if there wasnt, I would create the field and do option 1. Typically, I would use the context option if multiple projects have the same field but require different value.

Hope this helps !

Laurie Sciutti

@Mick Szucs ~ I would go with option 2. Limiting the availability of a custom field to only the projects that will actually use it is preferred - custom fields with global contexts have a significant impact on system performance. Ref: https://confluence.atlassian.com/adminjiraserver0912/configuring-custom-field-contexts-1346047394.html

This also eliminates the need to manage additional schemes. Definitely more efficient.

All comments

Scott Schellhardt_kfhy1i

Mick Szucs

It does, thanks!

Laurie Sciutti

This also eliminates the need to manage additional schemes. Definitely more efficient.

Mick Szucs

Thanks for the suggestion.

The note regarding the performance impact of custom fields with global contexts appears in the Jira Server documentation.

I can't find any comparable warning for the Jira Cloud documentation (though it stands to reason that there would at least be client-side impact.)

I am attracted to this approach for ease of implementation. The other approach is more work, but produces a "more deterministic" outcome - it's easier to see the exceptions on a per-project basis when they're captured as screen schemes.

Laurie Sciutti

@Mick Szucs ~ true, however....as your system grows it becomes much more difficult to manage multiple screen schemes. Also, here is the documentation link for Cloud: https://support.atlassian.com/jira-cloud-administration/docs/configure-custom-field-context/

Welcome!

It looks like you're new here. Sign in or register to get started.

Quick Links

Find more posts tagged with

cloud

jira-service-management-cloud

jira-service-management