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.
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.
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, you are misunderstanding it still.
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.
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)
Hey Community mates! Claire here from the Software Product Marketing team. We all know software development changes rapidly, and it's often tough to keep up. But from our research, we've found the h...
Connect with like-minded Atlassian users at free events near you!Find a group
Connect with like-minded Atlassian users at free events near you!
Unfortunately there are no AUG chapters near you at the moment.Start an AUG
You're one step closer to meeting fellow Atlassian users at your local meet up. Learn more about AUGs