Good morning,
I'm sorry to bother you,
In Azure DevOps 2019 / TFS, as it is possible to autocomplete a work item when validating a pull request.
I would like to know if it would also be possible to add a field to the pull request that would modify the corresponding fields in the linked work items.
In our workflow, a field would have to be filled in during this step (from "Active" to "Resolved") of the pull request and I don't know how to do it.
Thank you in advance for your feedback!
There is no such function in pull request by default. But a similar user voice is under review, you can vote it and add your comment:
https://developercommunity.visualstudio.com/idea/365704/customize-work-item-state-after-pr-is-closed.html
Related
I have used a few code review programs. I am now using pull requests in Bitbucket. I am expecting a certain process:
Create review (ie pull request)
Comments are added by reviewers. ( am used to a graded system where someone can mark the change as a bug which needs to be fixed before being merged)
The review is sent back to the originator who fixes any problems that are marked
(!!)The originator pushes their changes to their branch and then the code review is done again by all reviewers who then approve or reject the new changes.
With all things being good, the review is approved and then merged.
What I am wondering about are steps 3 and 4. There seems no grading to the comments and there seems to be no way for the originator to see quickly the comments (in some condensed format). Also, how do new changes update a pull request? Is this just missing from the Bitbucket system or is there a way to achieve this?
"there seems to be no way for the originator to see quickly the comments (in some condensed format)". Open a pull request, and look over on the right hand side. I see 3 tabs: Details / Files / Activity. Under "Activity", I can filter to "All Comments".
"how do new changes update a pull request?" When creating a pull request, you are requesting approval from your colleagues to pull code from some source branch to some target branch. So, when the source branch is updated with changes, the pull request should automatically reflect that. In other words, you shouldn't have to take any extra action.
"There seems no grading to the comments" A reviewer can check a box that says "merge not allowed until the 'issue fixed' box is checked." The repo admin has some latitude to set how strict the PR / merge policies will be, including whether approval is needed from anyone or from specific individuals.
So I understand that once I open a pull request, I automatically get a code review for the code that's about to be merged, that's great! But is there a a way to create a Code review without creating a Pull Request? For example, let's say I am working on a feature and I would like to do a code review with peers, but I don't want to do a Pull Request as the feature is still Work In Progress.
I understand that I can use the "compare" feature in BitBucket to see the code diff, but I needed the "Codereview" kind of feature explicitly so that I can:
Share the code review link with my peers so that they can see it
They can comment and open "tasks" on the code
and all of it while not creating a Pull Request. Is that possible?
Question is already asked here.
The usual process is to start code review based on a pull-request (this is how I understand the usage in BitBucket).
It is acceptable to create the pull-request and mark it as in progress and you can always add more commits on the PR later.
This is explained in the official doc:
But, the pull request is more than just a notification—it’s a dedicated forum for discussing the proposed feature. If there are any problems with the changes, teammates can post feedback in the pull request and even tweak the feature by pushing follow-up commits. All of this activity is tracked directly inside of the pull request.
Your peers must be aware that you don't need immediate approval but just comments until you finish the feature (PR ready to be merged)
I've allowed my Stakeholders to create Work Items but I would like to restrict them to only be able to create bugs and NOTHING else. Currently they can create ANY Work Item type including Epics... I'm thinking there has to be a way to stop this but I can't seem to find it.
There is no setting for this. And there is already a similar feature request submitted on VSTS User Voice: Hide Work Item Types (WITs) based on permission/security group.
In TFS, how do I request more information from the owner of a work item and have my request appear in the work item history?
So for example a user submits a bug, then I would like to use TFS to request more information and I would like my request to be within or attached to the bug. Then would like the user to update the bug in a way that I can see the progression.
Similarly is there a way to notify the user that I have updated the bug (without explicitly sending them a manual email)?
So I would like this to be outside the context of a daily standup meeting and a more automated process.
You could add a new state or reason, with a piece of workflow that assigns the work item back to the creator automatically and have a email alert on assigned to changes to [me]. However I normally just manually assign it to someone and ask for more details in the history.
Can anyone show me a quick example of posting a checkin with javascript using FB.api('/me/checkins', 'post', etc?? Mine doesn't seem to work. Also does anyone know if this will take a date variable?
The me/checkins appears to be a read-only table (there's no permission to request to do a add). Per the documentation, you can add/remove comments on an existing check-in as well as add/remove a user's like of that check-in.
From the https://developers.facebook.com/docs/reference/api/permissions/
user_checkins : Provides read access to the authorized user's
check-ins or a friend's check-ins that the user can see.
Edit
My mistake, I missed seeing the publish_checkins permission in the list there...disregard.
Did you happen to try posting a checkin via the Graph API Explorer tool? Did it work?