I use a Kanban board with a Scrum development project. I've seen that Jira can automatically ask the user whether or not to close the primary item; when the last of its sub-tasks are closed. But this isn't happening with my Kanban board.
What triggers Jira explicitly to ask the user whether to close the main item? Does this need to be configured?
In the end, I fixed this by installing an add-on, Adaptavist ScriptRunner for JIRA.
This allows you to create a post function that updates the main item when the status of a sub-task changes.
I wanted to only close the main item when all sub-tasks were closed, not whenever one sub-task is closed. To make that work, I added a condition so the main item can only be closed when all sub-tasks are closed. I could create this condition even without ScriptRunner.
I didn't have to write a script or do any other programming. It was pretty issue once I installed ScriptRunner.
This can be done in the post function. Just create a small script that checks if all of the subtasks are closed, which can then push the parent task in the necessary transition or else you can throw an event when the sub tasks are closed and use the Auto Tranisiotn Listener in JIRA Toolkit to do the transition.
Related
We moved to using Git and PRs... then we moved to Azure DevOps from on-premise TFS.
Our developers still have a number of old, irrelevant code reviews in their Assigned to me section.
I tried following the directions here
How can you cancel a Code Review Request? but using that method I was unable to set the Closed Status field. The edits would not save.
That's when I stumbled across a UI feature to simply Edit the items in the query.
Then we can set the State to Closed and the Closed Status to Abandoned.
Then click Save Items in the query menu, refresh the query, and they're all gone now.
Apologies if this has already been asked and answered.
I want to only allow a TFS user to change the state of a PBI/Bug when all tasks have been set to Done or Removed.
Is this possible?
By default we cannot achieve that.
However you can have a try with the extension TFS Aggregator which is a plugin that is designed to handle this scenario.
There is a thread just has the same requirements submitted on GitHub with the discussion on using the TFS Aggregator to achieve that, you can refer to it for details : Update the state of a PBI (or any parent) to "Done" when all children get moved to "Done" or "Removed"
Related user voice here : Automatic State Transition based on linked Work Item State
I'm using TFS 2017 update 1 on premises with still old form layout. Since in my custom workitem type I have more than one Description TAB (e.g. Trigger tab, Pre-conditions tab etc.), I'd like to dynamically change the label of TABS when some tetx is written inside (e.g. adding a * as suffix to the label) in order to give TFS users the possibility to immediately know which TAB effectively contains informations without the need to open them all.
This question seems more related to the useage of a software/extension--tfs-aggregator.
Have noticed you also asked the same question in GitHub and already got a reply.
No this is not possible with the tfs Aggregator.
https://github.com/tfsaggregator/tfsaggregator/issues/237
Your requirement is also could not be achieved in TFS with workitem customization for now.
Besides, questions about general computing software are off-topic for Stack Overflow unless they directly involve tools used primarily for programming. Your could ask the question directly under the extension in marketplace or from GitHub.
I want to make a sub-task read-only when its parent is Closed. The sub-task does not have a typical workflow associated with it - just a single step that says "Not Applicable".
My thinking was that I'd extend the Closed action (whatever that is) and set the jira.issue.editable property to false. Is this possible, and if so, with what parts of the API??
Many thanks!
One easy way to do so would be to attack a post function to the close transition of the parent issue that will move the sub-task to a locked transition.
To create the post function you can use Script Runner or Jira Scripting Suite. To add a locked transition for the subtask, add a new state to it's workflow and on the workflow screen make it read only, see this answer for more details.
If you want to restore the sub-task status once an issue was re-opened, on the post-script that leads to close state of the parent issue, save to a subtask custom field it's current state before making the transition to locked. Then attach a post function to the parent issue re-open transition that will move the subtask back to it's original state, according to what's saved in the custom field.
The answer turned out to be even simpler than I thought. I extended SimpleWorkflowAction which gets invoked when an issue is moved to closed. At that time, I set the Status of any children to closed. Voila, problem solved.
And yes, I asked on Atlassian as well!
I am using Jira for organizing user stories for my project on Agile approach. When I tried to close a user story it shows the status as ' Resolved', rather than 'Closed'.
Can someone help me how to change the user story status to closed?
Please post your suggestions and help.
Its a bit hard to answer such a vague question - so if you can ellaborate a bit on the customization you have done in your JIRA instance, it can help.
Some pointers:
JIRA is using workflows to manage the flow an issue can use.
The default workflow that comes with an installation of JIRA is called "jira" and looks like this: https://confluence.atlassian.com/display/JIRA/Configuring+Workflow
Depending on the customization of your JIRA installation, you can either change the workflow to go from Open to Closed when you use the "Resolve" operation.
If you are not the JIRA administrator, different workflow transitions can have various properties and conditions and validators set on them, for example checking for permissions. So if you are a user that does not have permissions to do a certain transition - you can see if you can change it via the permissions administation panel, or again - in the workflow validations.