I am trying to add a new "tab" to bug item in TFS 2017. Looking at the "tabs" you see things like "Steps to Reproduce", System, etc.
I have found information on changing work item types but nothing about adding a new "tab" across the top where you see Steps to Repro, System, Test Cases, Tasks. The change I want to make may not be possible? Or it is possible I don't know the correct verbiage to use when asking google. The think I want to change may not be a tab control at all it maybe something else different.
Thanks
***************** Updated questions after posting *****************************
After playing around with Process Editor -> WIT -> Open WIT from server -> Bug
as suggested by Andy Li-MSFT I don't see a lot of control on the formatting on the tab. I was planning to add fields in a grid like pattern like a table as shown below. I am able to get the values in the drop down list for field1 and add the fields. However I have a couple follow up questions if you have time.
Setting either the control or column for the control to read-only the column will not render when adding a new bug. I have a little more control if I set AllowedValues and Frozen for the column however the value can still be changed. Is there a better way to set read-only?
There is not much control on the layout. I am OK adding a lot of fields but would like them to be displayed in a table like structure. Is there a way to control the look of the fields on the form?
Is there a way to add the fields in a grid? This would be ideal so I only have one header for each column.
The last-updated-by and last-updated-date. Is it possible to track on a row level who made a change? If not I would be OK just adding a last updated by and last updated date to the new tab. Row level updates would be nice.
<pre>
Field 1 Field 2 (Read-only) Field 3 Last Updated By Last updated Date
Status (completed, empty, N/A) "Some text here which describes something to do" "Optional comments" tfs user name date/time
Status (completed, empty, N/A) "Some text here which describes something to do" "Optional comments" tfs user name date/time
</pre>
You need to modify the WIT definition file (Bug work item type in your scenario).
You can try below ways to do that:
Export the WIT definition file with witadmin commands, add a new tab under <TabGroup> and add a new control for it, then save and import the file. See Import, export, and manage work item types for details.
e.g:
<Tab Label="Tab0501">
<Control FieldName="System.ChangedDate" Type="DateTimeControl" Label="Test0501:" LabelPosition="Left" />
</Tab>
You can also use the TFS Power Tools to export/import WIT definition files or directly modify the files from server:
Visual Studio 2015 : Microsoft Visual Studio Team Foundation Server
2015 Power Tools
Visual Studio 2017 : TFS Process Template Editor
Reference below screenshot to do that.
Another way is writing an extension to Extend the work item form, you can reference my answer in another thread to do that.
I'm using TFS's workitens to DBA's team apply scripts in homologation/production, so, i'm creating a workitem and linking BD's scripts in it. To make sure that nobody will change the script after i created the workitem, the DBAs team is locking the scripts in TFS before aplly. I think there is another tool or method to make it safer and smarter
You can give a try with this workaround by Angela Dugan, In short the solution of Angela works as follows:
Add a field [UserAccessDenied] to a work item but do not show this
on the form In the desired state add a rule [REQUIRED] for a certain
group
Because you can not enter a value, you can never save the work item,
so it is “sort of” read only.
For example, after setting only you in can make a state transition from [Active] to [Resolved]
I am using the vNext build system of TFS 2015.
I currently have the my builds versioning in the traditional format. Major.Minor-rev.RevisionNumber. So, if I have a build for Major 1, Minor 12, the build version would look like 1.12-rev.1 when I start. I would like to know if it is possible to have the build version start at a number other than one, say 55. Such that the build version would look like 1.12-rev.55, and then increment by one as usual after that.
Actually, it is possible to effect this in a vNext build without hacking the database.
There are 2 steps.
First, you will need to implement a powershell build step (as the first step of the build) with the following inline script:
#Set the BuildNumberOffset. (Change this to the difference between the TFS build number,
#and the number that your build needs.)
$BuildNumberOffset = 543
#Don't change
$BuildNumberParts = $($env:BUILD_BUILDNUMBER) -split '\.'
$TFSRevision = [int]$BuildNumberParts[$BuildNumberParts.Length-1]
$BuildNumberParts[$BuildNumberParts.Length-1] = ($TFSRevision + $BuildNumberOffset).ToString()
$BuildNumber = [string]::Join(".", $BuildNumberParts)
Write-Host "##vso[build.updatebuildnumber]$BuildNumber"
Second, on the Label format field of the repository tab set the label format to "$(Build.BuildNumber)" instead of "$(Build.DefinitionName)$(rev:.r)". This is important so that your label will be the same as your updated build number.
There is a way to do this. It isn't pretty, but it works.
Assuming you have a build number format of something like $(Major).$(Minor)-rev$(rev:.r)
To do this queue up a build which will get the number 1.12-rev.1. Then go to the TFS database and into a table called tbl_Build. Find that last build you did and change the value in the BuildNumberRevision column to 54.
The next build that fires off will now be 1.12-rev.55
Unfortunately, it's impossible.
Every build definition has a build number format field where you can use some macros to dictate what the resulting build number should look like. In this format we are using $(Rev:.rr) Its start by one.
What is $(Rev:.rr)?
To ensure that every completed build has a unique name. When a build
is completed, if nothing else in the build number has changed, the Rev
integer value is incremented by one.
Source:MSDN
Moreover, if you want to generating a custom build number without increment.
Here is a blog with detailed procedures:Generate custom build numbers in TFS Build vNext
Couldn't we just manually set this in the format for one build i.e:
$(Major).$(Minor)-rev$(rev:.54)
and then afterwards revert back to:
$(Major).$(Minor)-rev$(rev:.r)
Not tried it, but if it works it'll save hacking around in the database.
You can do this easily, but only if you are using a Git repository in conjunction with a tool called GitVersion
It is a wonderful tool that I always use with my git repos. For your use-case: When you have version 1.2.3 and you want to jump to version 1.2.55, you just add a git tag 'v1.2.55' and it will start the versioning from there. GitVersion is a lot more complicated and does a lot more, but that is one of the features. You don't have to mess with special PowerShell scripts or anything, it instead reads your git repo history and git tags overrides the calculated versioning. There is already a TFS/VSTS/Azure Devops extension called GitVersion that works great from the same developer.
The Answer of #Steve Sims works still with TFS 2017 vNext. Thanks a lot!
I had only to do the first step "to add the script as an inline powershell script in my build." Thanks to #PainElemental
With this "Build number format" in the Options-Tab it works:
$(BuildDefinitionName)_1.2.0$(rev:.r)
I didn't label my sources with the build, so I don't checked:
Second, on the Label format field of the repository tab set the label
format to "$(Build.BuildNumber)" instead of
"$(Build.DefinitionName)$(rev:.r)". This is important so that your
label will be the same as your updated build number.
I think, you can edit the Label Format on the "Advanced" GetSources Options. (usually hidden).
This was also very painful for us, migrating from a existing CI system with it's own build numbering, we needed build numbers to increment from a specific value. Hacking databases wasn't allowed in the organisation, offsets seemed a cludge.
In the end, we used an AutoIt script to start and stop builds and delete the build result using the WebUI and left it running. Not nice, but it did the job.
Needs tweaking for screen resolutions and such, timings also perhaps. Use AutoIt Window Info to find the button locations, make sure browser is fullscreen (not windowed) Run it for a few cycles to ensure it robust before setting the loop larger.
#include <AutoItConstants.au3>
;Increment TFS build count (Chrome browser buttons locations). Start from build result page.
For $i = 1 To 15 Step 1
ConsoleWrite ( "Loop " & $i & " of 5" & #CRLF )
Sleep(200)
MouseClick($MOUSE_CLICK_PRIMARY, 1800, 200, 2)
Sleep(500)
MouseClick($MOUSE_CLICK_PRIMARY, 1150, 881, 2)
Sleep(2000)
MouseClick($MOUSE_CLICK_PRIMARY, 1800, 200, 2)
Sleep(500)
MouseClick($MOUSE_CLICK_PRIMARY, 1055, 165, 2)
Sleep(10000)
Next
TFS/Devops is a really immature CI system, and it's not a patch on what we were running. Unfortunately corporate policy said we move to TFS, as nobody ever got fired for buying Microsoft products (but plenty of people should have got fired for buying them/forcing them where they don't belong).
I'm trying to migrate a large ClearCase stream (it has a large history set too) to TFS 2010 using "TFS Integration Tools".
The tool hangs at TfsMigrationShell.exe Information: 0 : VersionControl: ClearCase history command: 'lshistory -minor -since 01-Jan-0001.00:00:00 -eventid -recurse -fmt "*%n*%o*%m*%e*%d*%Nc*%l##" -pname \IB_FE'
and then it gives the following run time error:
System.OutOfMemoryException: Exception of type 'System.OutOfMemoryException' was thrown.
at System.String.Split(String[] separator, Int32 count, StringSplitOptions options)
at Microsoft.TeamFoundation.Migration.ClearCaseDetailedHistoryAdapter.ClearCaseCommandSpec.ParseHistoryTable(String cmdOutput)
at Microsoft.TeamFoundation.Migration.ClearCaseDetailedHistoryAdapter.ClearCaseServer.GetHistoryRecords(ReadOnlyCollection'1 filters, DateTime since, Boolean writeHistoryRecordsFound)
at Microsoft.TeamFoundation.Migration.ClearCaseDetailedHistoryAdapter.ClearCaseAnalysisProvider.queryHistory(ChangeGroupService changeGroupService)
at Microsoft.TeamFoundation.Migration.ClearCaseDetailedHistoryAdapter.ClearCaseAnalysisProvider.GenerateDeltaTable()
at Microsoft.TeamFoundation.Migration.Toolkit.AnalysisEngine.GenerateDeltaTables(Guid sourceId)
Please advise.
Thanks in advance.
The issue is that:
a cleartool lshistory -minor can be huge for a repo with a large history
it also can be incomplete, since Vob scrubbing is run every week, unless those jobs have been modified to keep them. See "Keep minor event records after scrubbing a VOB database"
Since you cannot modify the tool in order to import only up to a certain data "d1", the "d1" to "d2", and so on until "present day", I would really consider:
importing only a very short history of ClearCase into TFS (the last 5 baselines for instance, if you were using ClearCase UCM)
keeping ClearCase in read-only mode, if you need to go back to older history (for archive).
You have a System.OutOfMemoryException raised, looks like you need more free RAM/Paging for the tool to run.
Close all the running applications you can, make sure the System Paging file is big enough (three times the amount of RAM, for instance).
Then try again.
I try to tune my Team Foundation 2005 work items.
We have 5 iterations paths in the "Bug" work item type.
I would like it to default to a specific value, for example Iterations.Iteration2
I tried to add a DEFAULT rule in the work item type editor but couldn't set the iteration path.
How can I do that?
I'm getting the same error with TFS 2010 when I try to set a default rule for a work item type for a default iteration path.
It seems the rules engine for work items unfortunately doesn't allow this (as explained by this post and others I've seen around).
Create a Work Item Template.
If you're using VS, you'll need the Power Tools. If you're using the web interface, the feature is already built-in.