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; } } }

Service Desk uses custom field way much better - update JIRA Screen customization as well!

MyCompanyPublicName

Applied for a trial version of ServiceDesk and I was impressed by its ability to use custom fields but with different display names!

This is an absolute must have for JIRA Core as well! Any plans to implement this soon?

Reason? Our instance (cluster) is HUGE and having 50 custom fields when 1 UserPicker custom field is actually just needed (e.g. Approver, Manager, Partner, Key Person, Lead Developer, etc...) will significantly help performance.

We currently have over a thousand and the reason it's stopped growing for the past year is we have to say NO to our users which totally sucks for them.

We have a brilliant team who made a self-service way to create Confluence Forms which does the same thing, but not all teams want to use thing (and with good reason!). JIRA really needs this ability.

Accepted answers

All comments

Nic Brough -Adaptavist-

I don't think you'll ever see that happen.

The reason you've got loads of different fields with different names is that they are for different things. Lumping Manager, Partner, Lead developer and so-on into one field is nonsense, as you then have no way to search for the different roles in the field. How do I search by "lead developer = nic", when I'm lead on issue X and partner on issue Y - any search is going to pull back both records because they're now the same field.

Your problem is structure and/or procedure in your organisation, and the software can't help you with that.

MyCompanyPublicName

That is simply remedied by having a mapping.

project X has UserPicker1 = Lead Developer

project Y has UserPicker1 = Partner

Each project is independent so there's no harm for us. Your concern is very much real of course in some cases.

But look at the benefits. I guess it depends on where we are coming from and priorities. Having a growing group company with currently ~50k users and ~3k projects will only mean more custom fields. Of course structure and procedure can help but that's such a huge scale/endeavor to do.

Nic Brough -Adaptavist-

I think you've misunderstood the problem.

When I search for "UserPicker1 = Nic", I'm going to get all the data where I'm Lead Developer or Partner. There is no way to search for "Partner = Nic". Your design does not work.

MyCompanyPublicName

Nic, you are misunderstanding it still.

Let's say:

Project X will require 3 UserPickers because you have Lead Developer, Partner and Approver fields.
Project Y requires 2 UserPickers because it needs Supervisor and Tester fields.

In normal scenarios, 5 UserPickers custom fields are created.

In my proposal, only 3 UserPickers would need to be created because you just re-use it and map it accordingly.

I believe in your train of thought UserPicker1 was used as Lead developer AND Partner for Project X.

I hope you get my point now.

Welcome!

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

Quick Links

Find more posts tagged with

custom-field

screen

display-name