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!
Related
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.
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
What is the "Follow-up" button in the Gerrit Review is doing? And when should it be used?
I am using Gerrit 2.13.8.
I saw this feature mentioned here and also played around with it a bit as I was curious myself.
...allows us to create a Follow-Up change. The Follow-Up changes are
changes that are based on existing changes. This gives you an
opportunity to create a chain of related changes.
The "follow-up" feature allows you to create change-sets very quickly.
The parent commit of these change-sets will be the change-set that they were created from (the change-set where the "follow-up" button was used).
This feature could be useful for when you are wrapping up a change but a few additional bugs or tweaks were found that you don't want to include in the current change-set.
You can create change-sets for those follow-up items rather than having to create the change-sets manually.
The text that is typed into the popup box after you click the follow-up button becomes the commit message for the new change-set.
We are trying to impose couple of rules on our project , can you tell us if it is possible to do? and if yes where should I start on this?
One of the example rule is
Deliverable can’t be closed with non-closed children.
This means that even in resolved state a child item would block closing the deliverable.
This should apply to parent child link types only
This would only apply to deliverable parent and any type of valid child
There are two ways you can do this.
Server-side:
You can add a plugin to tfs, that changes workitems. A good example would be TFSAggregator. It won't have the solution for your specific problem, but I can show you how to change work items on the server side. Shouldn't be a big problem to add your case.
The problem with this solution is, that it only changes a workitem after it has been saved. So user will still be able to close the child, but the server will re-open it.
Client-side:
The second solution would be a custom control, which can be implemented in the WITD of your work item. It can be just an invisible control, that adds some validation. You can find some examples here.
The downside of this solution? You have to install the custom control on every single client that uses Visual Studio and you may have to develop a specific version for web-access.
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.