I have a custom field called "Detailed Status" in the issue page. After an issue is verified by testers, they will change the value of this field to "Ready for Deployment". After we deploy the latest code to the server, this should be changed to "Verified after Deployment".
At the moment, after every deployment there will be at least 10-15 issues which will require a developer to manually go to each issue and change the value of the custom field to "Verified After Deployment"
Is there a way I could automate this?
I went through the documentation - I found out the option to do a Bulk Edit but my project architect wouldn't hear of any manual intervention at all.
Event listeners wouldn't serve the purpose would they, since deployment is not a Jira event but an external process. Could this be done using a script ? By directly doing an update on the JIRA tables or so ?
Sorry for sounding very vague and ignorant, since I am quite new to JIRA customization. Any pointers would be appreciated. Thanks.
There is a REST API that can be used by a script to update the custom field in the issues.
Start with http://jira-python.readthedocs.org/en/latest/
or
https://developer.atlassian.com/display/JIRADEV/JIRA+REST+API+Example+-+Edit+issues#JIRARESTAPIExample-Editissues-Examplesofupdatinganissueusingfields.
Sounds like your QA takes action during the Dev process (on Dev/Test/Stage environment(s)) to verify the issue has been resolved, and again after the deployment to a Production environment. If this is true, you could modify your workflow to allow for status & transitions to automatically set the field via a Post Function.
If QA hits 'Pass', it sends the issue forward in the workflow where that action updates the field "Detailed Status", and if they hit 'Fail/Reopen' it sends it back to Dev along with the corresponding status you want on that custom field. This would meet the mandate of no manual intervention.
There are several free plugins that can accomplish this, and streamline your workflow so that it mirrors your development practices.
Related
I am running Azure DevOps 2019 RC1 with an Inheritance Collection and a new Agile project.
I have a requirement that when a user creates a work item (task/issue), they must automatically be added as a follower of this work item. How can I achieve this? I have look in the rules for the work item under process customisation but it doesn't appear to be possible this way.
We are using the tickets to track issues. Whoever discovers the issue raises the ticket. The basic requirement is that anyone who raises a ticket should be automatically notified of its progress, even though they are not responsible for the development or testing.
Currently the work around is telling the user that when they create an issue they must click the Follow button, but it is easy for them to forget and then lose their updates. It seems like a very simple customisation so maybe I'm missing the obvious.
Thanks
I think you can't auto follow things currently, but you can add notification setting that will send automatically emails when work item is updated. To do this, go to Project Settings > Notifications page and create new subscription. Select "Work/A work item is changed" and put "Members of ... team by role" in Deliver to selection. Set roles to "Created by" and untick the "Skip initiator".
Your problem would be addressed precisely with the feature requested in the official Azure DevOps' feedback platform here:
479189 - Automatically follow work items I interact with
(That page also mentions workarounds, including per-team one answered here, and a per-person alternative. See this comment. The shortcoming of both is that they don't allow to you to unsubscribe for selected tickets.)
We had a few cases when:
Someone changes a task group (or build/release/whatever).
Makes some mistake.
Then publishes/saves it.
But doesn't notify anyone that such changes were made.
Some hours later some dependent build breaks because of those changes.
And we have to spend even more time trying to find what and when has changed as it is not often that simple to find out with external task groups.
What we want to have:
Ideally - some approval process for such changes. Kind of like code review, but for task groups/builds.
If not - then at least some way to receive notifications about changes in task groups and etc. we are interested in?
I found neither, and, honestly, doubt that such features are present in the TFS version we use (TFS 2018.2), but perhaps I've missed something.
There isn't any workflow security or approval process for the groups. You could suggest that kind of feature on the developercommunity. Restrict access to edit Task Groups to only those who understand how to bump the Task Group version. That way at least you will keep backward compatibility across your builds unless that explicitly upgrade to that version.
There aren't any built in notifications, but you could create an automated process to send email notifications using PowerShell using the existing API.
Get the Id for the task group using the taskgroups list api
Use the revisions api to get the history _apis/distributedtask/taskgroups/{taskgroupid}/revisions
Send an update for anything that edited today
I'm trying to have my company transition to JIRA from email for bug tracking purposes, and I can't figure out one thing: why JIRA (and BitBucket's Issues, which is sort of a limited version of JIRA) don't have a "Ready for retest" status.
I imagine the flow works like this:
Bug is reported
Bug is handled by developer
Developer marks bug as ready for retest
Tester tests, marks "Resolved" or "Closed" if all is OK, otherwise back to "Open".
Apparently I misunderstand something or other people don't work in the same way. What's the correct workflow status for the testers to retest the bug?
You, or your jira administrator, can create your own status in Jira. Look in Jira adminstration/ issues/ issue attributes and there you can add a status.
Then you still need to add that status to your project workflow, but that is another story.
Here is a link to help with all of it: https://confluence.atlassian.com/jirakb/define-new-status-or-steps-in-jira-workflow-718835875.html
Some organizations use the "Resolved" state to mean what you do by "ready for retest", then move the bug to "Closed" when the retest is successful. This would let you use the default workflow without adding states.
I've been looking for a way to have a user acknowledge a
ticket after it has been assigned to them. I don't know if
this is a built in feature or if there is a plugin that
will create a state/button for a user to accept a ticket
after it has been put in there queue. I would expect to
see something like this from the ticket window around
workflow or start progress but no amounts of digging
through configuration settings has turned anything
relevant up.
Does anyone know about this added functionality in JIRA?
Much thanks.
I did this by a custom workflow step. After an issue arrived to an assignee (with status New) he/she should move it to another step (with status Open). Until he/she does it, the issue is considered as not noticed/reached the assignee. Also I have had a report showing issues with New status for more than a predefined period of time.
I'm not aware of a ready-made plugin which performs similar task (perhaps, I should dig into my posts on Atlassian answers to discover some clues for other solutions).
As #Stan says above, a custom workflow is the way to implement this. The workflow functionality in JIRA is very flexible and as a result has a bit of a learning curve, but Atlassian's documentation is pretty good. Post back here if you need help.
I'm getting into SDK documentation, but this site has so many eyes and great answers I figure I'd throw this one out there to get some leads.
In project Server 2007, you can manage whether or not you get "task Alert" emails whenever a new task is assigned to you or existing tasks are modified. You can change this manually and individually via the web application under your personal settings.
As the project manager, say, I cannot toggle that for the entire team or manage it from my side. So if a resource or stakeholder who is assigned to a task(s) does not want email every time the plan is updated, I cannot handle that for them. I would have to walk them through the Project Web Access application to set it themselves manually.
So, has anyone crossed this bridge, and if so how did you toggle that flag for Task Alerts either through the SDK classes or via the PSI webservices? Before I slog through the docs, if I could get some "take a look ats..." that'd be great...Thanks!
You can change it in the SQL Tables. Here's a posting on it at the project server experts page.
www.projectserverexperts.com/ProjectServerFAQKnowledgeBase/SetDefaultEmailSubscriptions.aspx