You're on your way to the next level! Join the Kudos program to earn points and save your progress.
Level 1: Seed
25 / 150 points
Next: Root
1 badge earned
Challenges come and go, but your rewards stay with you. Do more to earn more!
What goes around comes around! Share the love by gifting kudos to your peers.
Keep earning points to reach the top of the leaderboard. It resets every quarter so you always have a chance!
Join now to unlock these features and more
The Atlassian Community can help you and your team get more value out of Atlassian products and practices.
Hello everyone
We use JIRA as a database for our production of books, which means that each book is an issue.
Each book is a unique issue and has a reporter/assignee from our office, who handle the primary work on the book. There are multiple tasks to each issue/book, e.g. cover production, which is handled by freelancers who work in JIRA from home. They have a hard time keeping an overview of their work, since we can't assign them to our titles.
At the moment, we have disabled sub-tasks, but I thought they might be useful for this. But each sub-task receive a new issue-key(which opens up a whole bucket of problems with our existing setup). Is it possible to have sub-tasks not have an issue key?
Is there a better way to have multiple assignees? I read the link below a couple of times, but none of the solutions seems like what I'm looking for, except the sub-task one, which in turn is troublesome, due to the nature of multiple issue keys.
https://confluence.atlassian.com/jira062/how-do-i-assign-issues-to-multiple-users-588581419.html
Thanks for any help and sorry if I've been unclear in any way,
Nikolaj
Subtasks MUST have an issue key. In most respects, they're the same as regular issues. They can have their own workflow and screens, and can be converted to regular issues.
I've never encountered problems with subtasks. What are the problems caused by subtasks having an issue key in your system? Regardless of your current issue with the freelancers, it sounds like anything that prevents you from using sometasks mut be crippling to say the least. Tell us about your issues, maybe we can help.
Hi Nicolas
Thanks for the swift reply!
I see, and I admit it makes sense.
Without going too in-depth, we track a lot of statistics by issue-key and have a lot of issues in our system (20.000). And if we had to add a couple of sub-task per issue, we would lose the overview we have now I'm afraid.
I feel a bit stupid for asking, because when I looked around a bit more, I found out, that I can add a custom field, where I can add a user. This will actually solve our problems, without adding subtasks, since I can just add a "Freelancer"-field to every issue, and add whoever is working on it.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
The custom field could be a workable solution. You lose some functionalities by not using the Assignee field, some JQL functions for instance (like "assignee = currentUser"). That could be an annoyance, but I can't think of anything truly bad that can't be worked around.
Notifications however can be set up to notify the value of a User custom field, so that would be ok.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
I think it suits our needs for now
Would you know if it possible to set up a Issue security in a way, so a user can only see the issues they are assigned to in this custom field?
Thanks for all the help!
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Issue security looks at the standard Assignee field. You'd have to modify code to have it look at another field.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Hello,
We are similarly trying to avoid creating so many sub-tasks for our issues and we are investigating this plugin:
https://marketplace.atlassian.com/plugins/com.idalko.jira.plugins.igrid/server/overview
I haven't mastered it yet but it's worth checking out.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Sub-tasks are issues so they must get a number. It is the primary key in the database. No, you can't have multiple assignees, which really means it really isn't assigned to and the responsibility of anyone and will get overlooked (real life experience).
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Hi Joe
I see your point, thanks for answering so fast
I managed to find another solution meanwhile, sorry to bother all of you!
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Hi Nikolaj,
One possible option would be to use one of the plugins that gives you checklists within your issues.
Here is one we wrote for example: https://marketplace.atlassian.com/plugins/com.topshelfsolution.simpletasklists/server/overview
Instead of subtasks, each JIRA issue can have an arbitrary amount of "todo" items within it. These are tracked independently, and don't have standard JIRA issue keys. Additionally, each user gets a personal "inbox" of sorts, showing all the tasks the user was mentioned in.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Can the list of To Do items be added automatically for each type of issue?
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.