I've seen a strange use-case today: someone I know simply can't create and configure Custom Fields effectively (they lack permissions), to the point where instead they are opting to just create dozens of Sub-Tasks per Issue, each one representing a field.
In this configuration, a Sub-Task Summary becomes the Field Name and the Value is the Sub-Tasks' Description.
So instead of a Custom Field with name "my-field" and value entered: "the-value", they will create a Sub-Task in the Task type Issue with a Summary of "my-field" and a Description of "the-value" (and then go and do this for several more fields they can't properly setup Custom Fields for).
I didn't know how to respond because they've achieved their goal of instantly creating "custom" fields and saved themselves from the headache of having their system admin approve and configure actual Custom Fields (which apparently is a very difficult and slow process). Also, from an Automation perspective (why I posted here), this doesn't seem to prevent querying these issues since JQL can search by Sub-Task Summary as well.
But are there any possible repercussions to this work around? I couldn't find any issues related to this other than a very old post that said too many Sub-Tasks could cause performance concerns. Is the performance concern still valid and are there any other concerns with respect to Automation (querying accessing issues)?
Volume of issues is something to think about with performance, but it's not a lot worse than volume of random inconsistent and functionally useless custom fields.
As an admin, I'd rather deal with "a huge pile of probably useless issues" over "a huge pile of definitely useless custom fields". Custom fields have a much larger and wide ranging impact than a single issue.
I would want to question why they think this is a good idea. It is an abuse of sorts, and definitely an indicator that there's a lot of broken process or poor thinking about how stuff gets done and reported on. I would want to ask if their reporting on all of this is of any use to the business (I'd bet on the short answer being "no" as well)
But whatever the root cause of this silliness, letting them create sub-tasks is a vastly superior to letting them cause you massive fielditis.
p.s it's not a "work around", it's "someone not getting it"
@Nic Brough _Adaptavist_ - the reporting was something I was also interested in. If they don't have to search on too many items, then an option is to use checklists instead.
If they used a checklist in a form using ProForma Lite (free up to 3 forms), they get their information captured and avoid avoid the plethora of tasks + avoid custom jira fields.
I've been working with someone on a similar vein (not bypassing custom field protocols) but coping with excessive tasks. We came up with the option of using a task and a check list so they could cut their task list considerably but still have the visual granularity where needed.
But if they need to report on every single field then my option is a no go.
@Nic Brough _Adaptavist_ Thank you, I've since discovered "Schemes" can be used to isolate groups of projects and manage custom fields quite effectively (not disrupting other projects in other schemes). I'm going to suggest this as a mechanism to lower the risk of adding more fields so that they hopefully don't resort to this work around.
Hi all, After many months of work, I am delighted to announce the launch of the Jira Automation Template Library! The Template Library is a new website dedicated to all things Jira au...
Connect with like-minded Atlassian users at free events near you!Find an event
Connect with like-minded Atlassian users at free events near you!
Unfortunately there are no Community Events near you at the moment.Host an event
You're one step closer to meeting fellow Atlassian users at your local event. Learn more about Community Events