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

He Who Shall Not Be Named July 19, 2016

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.

 

 

1 answer

0 votes
Nic Brough -Adaptavist-
Community Leader
Community Leader
Community Leaders are connectors, ambassadors, and mentors. On the online community, they serve as thought leaders, product experts, and moderators.
July 19, 2016

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.

 

He Who Shall Not Be Named July 20, 2016

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-
Community Leader
Community Leader
Community Leaders are connectors, ambassadors, and mentors. On the online community, they serve as thought leaders, product experts, and moderators.
July 20, 2016

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.

He Who Shall Not Be Named July 20, 2016

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.

 

Nic Brough -Adaptavist-
Community Leader
Community Leader
Community Leaders are connectors, ambassadors, and mentors. On the online community, they serve as thought leaders, product experts, and moderators.
July 20, 2016

It does not work.

Using your example, you create the three fields for X and then reuse two of them for Y with different "mapped" names.

I want to search for issues where I'm the Supervisor.  A search on Supervisor is going to return issues where I'm also a Partner.  Because they're the same field.  The only way to make it work is to define them as different fields, which is what JIRA already does.

Now, for some other types of field (select lists), you can define a context which gives you the option of different lists of options for each context.  Which solves that problem (but it's not implemented well in JIRA because you can't really do it for several projects and issue types)

He Who Shall Not Be Named July 20, 2016

Hi Nic,

Like I said, projects are independent.

But then again, wouldn't this JQL work?

(project = Y and UserPicker1 = name) and (project = X and UserPicker1 = name)

 

Nic Brough -Adaptavist-
Community Leader
Community Leader
Community Leaders are connectors, ambassadors, and mentors. On the online community, they serve as thought leaders, product experts, and moderators.
July 20, 2016

It will work, but it requires the user to completely understand the mapping, and it's useless for cross-project reporting, because there's only one user field there, so you can't logically split the data.

 

He Who Shall Not Be Named July 21, 2016

Thanks for your input Nic.

 

 

Suggest an answer

Log in or Sign up to answer