With our TFS 2015 source control we require developers to check-in changes against work items.
However, we've had a couple of instances where a developer has checked in against one work item within our development branch, but then when merging to our QA branch they've checked in the merged changes to a different work item. An example of this is where a bug has been created underneath a PBI, the changes in dev have been checked in against a task under the bug, but then merged to QA against the PBI itself. This causes us issues with traceability.
I've seen that it's possible to add a check-in policy of "Work Item Query Policy". I'm just wondering if there is a way to write a query that will determine if the work item of a check-in after a merge matches the work item of the source changesets? I'm not necessarily after the exact query (though it would be lovely if someone could provide one :) ), really I'm just wondering whether it's possible or not to have a query to do this - i.e. is the information available to queries in TFS?
You can't do this with the existing policies, you'd need to build a custom policy.
So, technically this is possible. You can access the VersionControlServer object through the PendingChanges object:
this.PendingCheckin.PendingChanges.Workspace.VersionControlServer
You can use that to query the history of the branch in question and grab the work items associated to the check-ins in that branch.
You can check the associated workitems to the current workitem:
this.PendingCheckin.WorkItems
You could probably even provide the option to auto-correct by adding the correct work items to the checkin upon validation.
One of my policies provides an example on using the VersionControlServer from a policy.
Related
We are migrating sets of WorkItems from an On-Prem Server (latest AzureDevops build 2022) to a new Azure DevOps org and team in the cloud. For the migrator we haven't done any User mapping or anything to map the Assigned To field.
Most work items come over with the Assigned To field showing the appropriate name.. however some work items end up showing as Assigned To as ME -- the person executing the migration. NONE of the actual work items we are migrating are assigned to me in the source system.
I've run a couple of Dry run work item migrations and it consistently seems to pick on the same work items (meaning if I ran it now, source work item 1234 is assigned to me, and if I re-run it later, that same work item would be assigned to me again).
The assigned to person in the Source for these work items, doesn't seem to matter, as other work items assigned to those people, do get properly assigned to
I guess I'm trying to understand what cases would be causing this behavior, I don't immediately see anything common or odd about the items in question.
After (or before) we convert from TFS 2012.2 to TFS 2015.3 (which we have done just fine in a test run) we would like to revert our team project to the standard TFS 2015 Agile process template, and no longer use the customized agile process that we had modified from TFS 2012. We are quite willing to delete all of our work items and start over, but need to keep the team project history and change sets. Anyone know how to do this? Answers to prior questions on this did not address this situation. Thanks.
There is no easy way to do it. Basically the steps require you to use a lot of witadmin commands. Start by deleting any work item types that were added and don't exist in the default template.
Then push the standard work item definition for each work item type.
Then push the categories
Then push the process configuration
Then delete any fields that are no longer used
That should bring you back to the standard template.
An alternative you could try is to use the WitMorph project. You can write a set of rules to migrate your data back into working order.
GOAL:
-To allow the manager to only view the all projects in qlikview, and not edit anything.
-Team members can only see data from projects they are in
CONDITIONS:
-Joe(Team member) can only see data from his projects only.
-Bob(Manager) can see data from all projects in the team, however he cannot edit or make changes to them.
In this scenario, there is only 1 manager, an admin, and many team members.
So I guess the process would be:
Check who the user is (Not sure what to use here. Username/password? Ideally it would be the company email, but don't know if this is possible)
Once it knows who the user is, checks if said person can access the document
If they do have access, it decides what can be accessed. (if manager, can only view all projects, if team member, can only view certain projects)
Display the dashboard.
Right now, the QVW file gets data from a database using OLEDB connection.
Sorry I've only been introduced to Qlikview about a week ago and I've been tasked to get this done so any help would be great.
Thanks.
You can find a lot about QV section access around.
Think your scenario is possible to be achieved using section access. Please read https://community.qlik.com/docs/DOC-1853 for more detailed explanation of section access methods.
Warning: Always have copy of the document without section access!
Just to be sure you are not locked out of the document because if this happens there is no way to open the document
I am creating a clone of Default Merge Window, to add a feature.
I already have a Merge candidates in a grid from command below:
MergeCandidate[] candidates = tfs.GetMergeCandidates(edtSelectedSource.Text, cbxTargetBranchs.Text);
Now, the user selected 1 or more candidates and I need to merge them.
But the TFS API VersionControl.Merge requires source path and target path.
At first, my question, I need to iterate each candidate and merge each file of its changesets, one by one ?
Second, how could I obtains the target path from a changeset ?
First off, I've done a fair amount of programming with the TFS API, but merging is something that I would never blindly trust to automation. Merge conflicts are best dealt with by human beings. Yes, it's painful and can be automated in many cases, but in many others - things can go terribly wrong. I would think twice and then twice again before doing this on Production branches.
Here's some tips that should help:
You need to create a temp Workspace. The Workspace is the sandbox where everything happens. The Workspace can have files and thus, file locations associated with it. Workspace items have rich metadata.
Have a look at the Workspace and WorkspaceInfo classes.
Then have a look at the workspace client:
http://msdn.microsoft.com/en-us/library/microsoft.teamfoundation.versioncontrol.client.item.aspx
As long as the changesets are continuous, you can do it in a single merge call. If they are not continuous, you need to submit n merges for each continuous block. Let's say they select changesets 10, 15 and 20 and these are continuous (i.e. there are no additional candidates between that range) then you would submit a merge with a versionFrom of 10 and versionTo of 20.
As far as paths go, you want to use the ones that you passed into QueryMergeCandidates and you'll want to specify the full recursion type as well.
We're migrating from Bugzilla to Redmine and there's one feature of bugzilla which I'm unsure how to replicate in Redmine.
Is there any way to list all the bugs / features of a specific priority across all projects?
We used to use this mechanism to identify what bugs / features to assign next to developers. If listing all urgent bugs doesn't work in Redmine, perhaps there's a different way of working which could be used instead?
This is easy:
Go to https://your.redmine.domain/issues?set_filter=1 : This should clear any current filter criteria and display all open issues across all projects the currently logged user has access to.
Select your filter - in this case, add a filter for Priority, and hit apply
You may save this filter by clicking on Save: This will allow you to access to this filter quickly without configuring it every time. You may also choose grouping criteria as well as the columns to display.