Create
cancel
Showing results for 
Search instead for 
Did you mean: 
Sign up Log in
Deleted user
Level
0 / 0 points
Next:
badges earned

Your Points Tracker
Challenges
Leaderboard
  • Global
  • Feed

Badge for your thoughts?

You're enrolled in our new beta rewards program. Join our group to get the inside scoop and share your feedback.

Join group
Recognition
Give the gift of kudos
You have 0 kudos available to give
Who do you want to recognize?
Why do you want to recognize them?
Kudos
Great job appreciating your peers!
Check back soon to give more kudos.

Past Kudos Given
No kudos given
You haven't given any kudos yet. Share the love above and you'll see it here.

It's not the same without you

Join the community to find out what other Atlassian users are discussing, debating and creating.

Atlassian Community Hero Image Collage

Sub-Tasks as Custom Fields? Edited

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

2 answers

1 vote

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.

0 votes
Darryl Lee Community Leader Feb 25, 2021

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

{ducking}

Suggest an answer

Log in or Sign up to answer
TAGS
Community showcase
Published in Jira Automation

Announcing the Jira automation template library!

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

1,009 views 17 26
Read article

Community Events

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

Events near you