When we are doing the customization of a work item type in VSTS. Do we also have the ability to track the history of the customization itself?
For example, we are trying to find out when the start date field was added to our customized Bug work item type.
A field was not there in a previous Increment but we noticed it recently. Just want to find out if there is a date captured somewhere that tells us when it was added or who may have added it?
Unfortunately we cannot get the information from VSTS for now. No date or history included from the retrieved process information via REST API.
However there's already a user voice submitted here to suggest the feature to add Activity Log to VSTS to track user accesses, you can go and vote it up or submit a new one to suggest the feature again to achieve that is future release.
For now as a workaround we suggest that you can ask the team members to add corresponding comments in description area after completing the customization for the process... Thus you can track the history of the customization...
Related
I'm looking to migrate a project from one org to another in Azure DevOps. We've ended up with two or three orgs, and this project that I'm looking to move has all sorts of weird and wonderful work items created and custom fields added. What I'm looking to do is move the project and then see if I can persuade the powers that be that certain things can be dropped but I have an immediate need to move as-is so that reporting and other work isn't impacted.
I have tried to get this to work with the migration tools (and tried to follow the videos) but have hit a dead-end. I think there are two issues potentially. One being the ReflectedWorkItemId. It says that it's not found in User Stories but I'm not sure how to resolve this? Do I go into user stories and add a field called 'ReflectedWorkItemId' and populate it with the work item number and/or add the same field in the destination org process?
It also mentions in the info that it can't find one of the Work Item Types - Processes. There are a few other custom work item types that have been created too but I assume it's given up on the first one. Do I have to create all of the work item types and the custom fields for each work item type in the destination org? Or am I getting the wrong end of the stick with this?
To provide sync as well as migration it is important that the tools knows which items have already been migrated. This is the purpose of the ReflectedWorkItemId field.
The field is not required in either case, however... if you don't have
the field then the system cant be re-run as it will re-copy all
completed work items. If you add the field to the target then it will
only copy those items it cant find. If you add the field to the source
(yes it needs to be the same refname), and set UpdateSoureReflectedId
to true then you can also filter the source, using a query and limit
what you load.
The former prevents duplicates, and the latter allows you to filter
the data load...
This is mentioned in this document. Here is a similar issue you can refer to.
TF201077 that usually happens when the target Project does not have a work item of that name. You can refer to this issue on github for help.
I want to pin a chart to the Azure DevOps Services dashboard that shows how many bugs in the current sprint have a linked test case or not.
I have been able to put up a query for the same but it appears that such queries can't be charted out. Is there an alternate way?
Here's the error that I get while creating a chart out of my query
Additionally, I would also like to know if there is a way to ensure that when I Resolve/Close a bug workitem in AzDo services, I can check if there is at least one associated test case work item with the bug. I have explored Bug rules but can't find out a clean way to get the link types associated with the work item. How can I achieve this?
Thanks
I have been able to put up a query for the same but it appears that
such queries can't be charted out. Is there an alternate way?
As for the error you got, it's one open issue here in our feedback forum, the product team is considering about it. But there might be some time before the feature comes true. You can track the issue to get notifications if there's any update. Sorry for the inconvenience.
Is there an alternate way?
If you just need a widget to display the results of the query, you can consider using Query Results widget, if supports tree or direct links. But if you do want the pie chart for WITs, I afraid it's not supported for now when using tree or direct links. You can check the related extensions here.
I have explored Bug rules but can't find out a clean way to get the
link types associated with the work item. How can I achieve this?
As I know we don't have such option in Azure Devops Boards.
If we close/delete one workItem, it won't display a prompt or what that tells us the related workItems are still active.
But I think that would be a great idea, so I suggest you can post one feature request here to share your idea to product team. Then we can share the feature request link here and people who interested in that would vote for you! Hope all above make some help :)
I have a User Story against which there is an impediment faced in current sprint. Due to this impediment, we are not able to complete the US in this sprint. However we cannot also close it or mark it resolved. Since its open without any action, its also interfering with the burndown charts.
Can I get an advice on how we can handle impediments in Azure DevOps and thereby set that work has been halted/suspended on a particular user story? I was reading the related article here: https://learn.microsoft.com/en-us/azure/devops/boards/backlogs/manage-issues-impediments?view=azure-devops.
Thanks and Regards,
Satheesh Vijayan
As stated in the documentation:
You use issues or impediments to track items that may block work from
getting done. In general, you link these items to user stories or
other work items using a Related link type.
So as a workaround ,you can try customizing impediments tracking ,through this you can customize the item state,add a special state to impediment item . For details, see Customize an inheritance process.
Organization Settings -> Process -> Inheritance process -> Impediment ->State -> New state
Note: only inheritance process can be customized.
I'm working on a project that's got a great JIRA setup and awesome buy-in of everyone for the agile development process. The issue I'm having is that tickets stack up in code review. I'd like to be able to see who code reviewed what, much like I can see who has closed out which tickets.
I know that metrics are there to be used for good and not evil, so I want to do this to ensure that people spending time code reviewing are properly credited instead of that time not being recognized at all.
Currently, everyone who does code review assigns themselves to the ticket (which is unassigned upon being placed into the "Ready for Review" workflow state), so at some point there is a record of them working on it. Is this a good way to track the reviewers and is there a way to get aggregate information this after the fact? If not, is there a better way of representing this information in JIRA?
Thanks!
A simple solution would be to add a custom field called 'Code Reviewer' of type select a user. You would be able to search on that and report on it.
You could workflow it so that when the issue is transitioned out of your 'Code Review' status a window pops up containing only the "Code Reviewer' custom field to be completed.
What you need to do:
Create a new custom field - this is done in the 'Issues' configuration menu. Ensure your custom field uses the 'select a user' type.
https://confluence.atlassian.com/display/JIRA/Adding+a+Custom+Field
Create a new Screen - this is also done in the 'Issues configuration menu. On your new screen you need to make sure that the only field that is visible is your new custom field.
https://confluence.atlassian.com/display/JIRA/Defining+a+Screen
Edit your workflow. Find the transition from out of 'Code Review' and associate it with your custom screen.
https://confluence.atlassian.com/display/JIRA/Configuring+Workflow
The result will be that when a user transitions out of 'Code Review' they will have the custom screen pop-up. They can then select the name of the person who did the code review and this will be populated in the custom field.
We are using the Tuleap 7.0 for Project management. We have a new requirement that we need to show the contact number of current logged in user when a artifact is submitted either in a separate field or in the same field (submitted by). Is it possible to show or what type of code change has to be done, to retrieve the current logged in user information when artifact is created. Kindly do needful.
That's not easy. There are two main steps: one surrounding the user; the other surrounding the artifact.
First you would need to edit PFUser.class.php to add the property to the user object. You would also probably need to create a forgeupgrade script (database upgrade) so that you could save and modify the property. Obviously the UI and scripts that manage the CRUD of a user would also need changing.
Next, you would need to create a new type of class that extends TrackerformElementField, make that type available for use in the Tracker Field administration and set its value to the user's contact number.
Unfortunately, any of these modifications, if not done carefully, can have important side-effects. If you want to write your code and have it reviewed by the community, you can go through gerrit.tuleap.net and read the developer guide