Sub-Tasks as Custom Fields?

[uidev]

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)?

https://community.atlassian.com/t5/Jira-questions/What-s-the-maximum-number-of-subtask-s-per-issue/qaq-p/413470

[Nic Brough -Adaptavist-]

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"

[Kate Caldecott]

@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.

[uidev]

@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.

[Darryl Lee]

I'm wondering if enabling the Labels field would be better or worse.

{ducking}