How to add columns to ExternalLink on the "Links" page on Azure DevOps Workitem ?
Answered : Not Possible see answer below
Pull Request is not like Code Review Request, it's not a work item
type, we cannot see it from the exported process template. So, I don't
think we can customize the columns like the common work item types. –
Andy Li-MSFT
after going through the following links
link1
link2
and trying the workaround discussed here
I have failed to add more columns to links of the type externallink
i have added the following code as described:
<Page Label="Links" LayoutMode="FirstColumnWide">
<Section>
<Group Label="links">
<Control Type="LinksControl" Name="links">
<LinksControlOptions>
<LinkFilters>
<ExternalLinkFilter Type="Build" />
<ExternalLinkFilter Type="Integrated in build" />
<ExternalLinkFilter Type="Pull Request" />
<ExternalLinkFilter Type="Branch" />
<ExternalLinkFilter Type="Fixed in Commit" />
<ExternalLinkFilter Type="Fixed in Changeset" />
<ExternalLinkFilter Type="Source Code File" />
<ExternalLinkFilter Type="Found in build" />
<ExternalLinkFilter Type="GitHub Pull Request" />
<ExternalLinkFilter Type="GitHub Commit" />
</LinkFilters>
<Columns>
<Column Name="System.State" />
<Column Name="System.ChangedDate" />
<Column Name="System.PullRequest.IsFork" />
</Columns>
</LinksControlOptions>
</Control>
</Group>
</Section>
</Page>
But the results still show only the original columns.
The problem is that the field/column you added (<Column Name="System.PullRequest.IsFork" />) is not a valid work item filed/column. The workaround is only available for work item types due to the columns depend on work item fields.
You need to add a valid work item field/column here. We can get all the available work item fields by calling the Get Work Item REST API with parameter $expand=Fields added in the URL from a specific work item.
GET https://{instance}/{collection}/{project}/_apis/wit/workitems/{id}?$expand=Fields&api-version=4.1
For example, the following screenshots shows all the available fields for my Task work item. (It depends on how you defined the fields, if you defined a custom field, you can also see it from the response body.):
After that, we can add the columns (System.CreatedBy and Microsoft.VSTS.Common.Priority for example in this sample)
Then check the behavior in a Task work item:
Please note that, Pull Requests is not a work item type. We cannot get valid work item fields by calling the Pull Requests REST API. In this case, I don't think we can customize the columns like the common work item types.
is there a possibility to add the field "Microsoft.VSTS.Scheduling.RemainingWork" on backlog level? I would like to have a field with remaining work in the backlog, so that the work can be entered there directly without creating a work item.
example image
Azure DevOps Server version: Version Dev17.M153.3
I added following lines in Bug.xml:
<FIELD name="Verbleibende Arbeit" refname="Microsoft.VSTS.Scheduling.RemainingWork" type="Double" reportable="measure" formula="sum" />
<Group Label="Details">
<Control Label="Verbleibende Arbeit" Type="FieldControl" FieldName="Microsoft.VSTS.Scheduling.RemainingWork" />
<Control Label="Aufwand" Type="FieldControl" FieldName="Microsoft.VSTS.Scheduling.Effort" />
<Control Label="Schweregrad" Type="FieldControl" FieldName="Microsoft.VSTS.Common.Severity" />
</Group>
On the backlog, you can specify columns and the quick add panel configuration. Check this:
Set default columns
Customize the quick add panel
Use witadmin to import and export process configuration.
I'm running Azure DevOps Server 2019 and I added a Boolean field to my User Story work item. The description for Boolean fields says "Boolean: Adds a True/False or Yes/No field.". It defaults to displaying a True/False toggle. I can't find how to change it to display a Yes/No toggle instead.
Sorry for confusion. The value "Yes/No" is actually not supported for a Boolean field type by default. An a workaround, you can use String type instead of Boolean type, which render a dropdown box for Yes/No:
<FieldDefinition name="MyField" refname="My.Field" type="String">
<ALLOWEDVALUES expanditems="true">
<LISTITEM value="Yes" />
<LISTITEM value="No" />
</ALLOWEDVALUES>
</FieldDefinition>
When you create a work item such as Bug in Azure devops, the values that you would see in the drop down of say Reason field would depend on the value you select for State field. For e.g. see these screenshots (Template Agile, no customizations)
Then if you change the state, the allowed values change as shown
To make matters more confusing, these are just few of the values that are returned by the documented REST API
The given API returns
"defaultValue": null,
"allowedValues": [
"Verified",
"Not fixed",
"Test Failed",
"As Designed",
"Cannot Reproduce",
"Copied to Backlog",
"Deferred",
"Duplicate",
"Fixed and verified",
"Obsolete",
"Fixed",
"Investigation Complete",
"Approved",
"Investigate",
"Resolved in error",
"Reactivated",
"Regression",
"Build Failure",
"New"
],
"helpText": "The reason why the bug is in the current state",
"alwaysRequired": false,
"dependentFields": [
{
"referenceName": "System.State",
"name": "State",
"url": "https://dev.azure.com/nikhil/_apis/wit/fields/System.State"
},
{
"referenceName": "Microsoft.VSTS.Common.ResolvedReason",
"name": "Resolved Reason",
"url": "https://dev.azure.com/nikhil/_apis/wit/fields/Microsoft.VSTS.Common.ResolvedReason"
}
],
"referenceName": "System.Reason",
"name": "Reason",
"url": "https://dev.azure.com/{project}/{templateid}/_apis/wit/fields/System.Reason"
},
I am trying to figure out the right API or set of APIs that help demystify when to show what in the combo boxes, when to mark them read-only and when to let the user edit them.
The Resolved Reason Field is further interesting. For most parts it seems to simply copy the value from the Reason field, however the Rules API (see below) does not indicate this behaviour. It looks like what the Rules API returns does not match the behaviour that this field exhibits.
There is a concept of Rules mentioned in the REST API here - https://learn.microsoft.com/en-us/rest/api/azure/devops/processes/rules/get?view=azure-devops-rest-5.1#processrule
However this does not seem to give rules which specifically control "allowedValues" for fields based on value of another field as I explained above.
Question:
Is there an API that can give a comprehensive set of rules for fields on a work item types including their allowedValues? For e.g. the Reason or Resolved Reason field depending on the choice of State field as shown above?
Is there an API that can give a comprehensive set of rules for fields
on a work item types including their allowedValues? For e.g. the
Reason or Resolved Reason field depending on the choice of State field
as shown above?
First of all, I need to say, no, there is no such REST API to get the Reason value which depending on the State filed chosen. Since these are all not be documented, the best way for us to verify it is using the Fiddler trace(Fiddler can record all internet data between web application and internet).
[As example, here I will use Bug work item to show that.]
First, clear all the records in Fiddler => open the Bug work item in Azure Devops => press F12 in Fiddler to start record the data.
Change the work item state in Azure Devops(Note: just change, do not save it. "Save" belong to another operation). Then go Fiddler to see its internet records:
You will see that there only 2 event API, and these API are only used to post the action sign but not operate it. See the request body of first POST Event API:
You can see that it just used to post a sign about the State field has changed. That's why I say that there's no API to get the Reason value which depending on the State filed chosen, because our develop team did not use the script with API to achieve that.
Now, you should be very confusing that who is this action message to be sent to? Since the Reason field value listed is not controlled by the api, then who is in control?
The answer is XML process template.
In Azure Devops, the WIT are all controlled by XML template. You can find all rules such as the Reason field value listed depend on the State field changed, copy the value from the Reason field and etc.
I have uploaded the Bug.xml of process template into my github, you can refer to that code to analysis it: Agile-process/Bug.xml .
For the Reason field value listed depend on the State field
changed.
<FIELD name="Resolved Reason" refname="Microsoft.VSTS.Common.ResolvedReason" type="String" reportable="dimension">
<ALLOWEDVALUES>
<LISTITEM value="As Designed" />
<LISTITEM value="Cannot Reproduce" />
<LISTITEM value="Deferred" />
<LISTITEM value="Duplicate" />
<LISTITEM value="Fixed" />
<LISTITEM value="Fixed and verified" />
<LISTITEM value="Obsolete" />
<LISTITEM value="Copied to Backlog" />
</ALLOWEDVALUES>
<HELPTEXT>The reason why the bug was resolved</HELPTEXT>
</FIELD>
These are the xml code which control the Resolved Reason listed. I believe that you have got its logic. The message of event API we got from fiddler are get by the relevant WIT *.xml. Then the corresponding operation will be trigger and acted.
For copy the value from the Reason field.
<TRANSITION from="New" to="Resolved">
<ACTIONS>
<ACTION value="Microsoft.VSTS.Actions.Checkin" />
</ACTIONS>
<REASONS>
<DEFAULTREASON value="Fixed">
<FIELDS>
<FIELD refname="Microsoft.VSTS.Common.ResolvedReason">
<COPY from="value" value="Fixed" />
<ALLOWEDVALUES>
<LISTITEM value="Fixed" />
</ALLOWEDVALUES>
</FIELD>
</FIELDS>
</DEFAULTREASON>
<REASON value="Deferred">
<FIELDS>
<FIELD refname="Microsoft.VSTS.Common.ResolvedReason">
<COPY from="value" value="Deferred" />
<ALLOWEDVALUES>
<LISTITEM value="Deferred" />
</ALLOWEDVALUES>
</FIELD>
</FIELDS>
</REASON>
<REASON value="Duplicate">
<FIELDS>
<FIELD refname="Microsoft.VSTS.Common.ResolvedReason">
<COPY from="value" value="Duplicate" />
<ALLOWEDVALUES>
<LISTITEM value="Duplicate" />
</ALLOWEDVALUES>
</FIELD>
</FIELDS>
</REASON>
<REASON value="As Designed">
<FIELDS>
<FIELD refname="Microsoft.VSTS.Common.ResolvedReason">
<COPY from="value" value="As Designed" />
<ALLOWEDVALUES>
<LISTITEM value="As Designed" />
</ALLOWEDVALUES>
</FIELD>
</FIELDS>
</REASON>
<REASON value="Cannot Reproduce">
<FIELDS>
<FIELD refname="Microsoft.VSTS.Common.ResolvedReason">
<COPY from="value" value="Cannot Reproduce" />
<ALLOWEDVALUES>
<LISTITEM value="Cannot Reproduce" />
</ALLOWEDVALUES>
</FIELD>
</FIELDS>
</REASON>
<REASON value="Obsolete">
<FIELDS>
<FIELD refname="Microsoft.VSTS.Common.ResolvedReason">
<COPY from="value" value="Obsolete" />
<ALLOWEDVALUES>
<LISTITEM value="Obsolete" />
</ALLOWEDVALUES>
</FIELD>
</FIELDS>
</REASON>
<REASON value="Copied to Backlog">
<FIELDS>
<FIELD refname="Microsoft.VSTS.Common.ResolvedReason">
<COPY from="value" value="Copied to Backlog" />
<ALLOWEDVALUES>
<LISTITEM value="Copied to Backlog" />
</ALLOWEDVALUES>
</FIELD>
</FIELDS>
</REASON>
</REASONS>
<FIELDS>
<FIELD refname="System.AssignedTo">
<COPY from="field" field="System.CreatedBy" />
</FIELD>
<FIELD refname="Microsoft.VSTS.Common.ActivatedDate">
<SERVERDEFAULT from="clock" />
</FIELD>
<FIELD refname="Microsoft.VSTS.Common.ActivatedBy">
<COPY from="currentuser" />
<VALIDUSER />
<REQUIRED />
</FIELD>
<FIELD refname="Microsoft.VSTS.Common.ResolvedBy">
<COPY from="currentuser" />
<VALIDUSER />
<REQUIRED />
</FIELD>
<FIELD refname="Microsoft.VSTS.Common.ResolvedDate">
<SERVERDEFAULT from="clock" />
</FIELD>
</FIELDS>
</TRANSITION>
This just a short section which about the copy value from the Reason field from the xml file of Bug work item.
In fact, you can find all process rules from these XML file which could not get with API(Note: I just mean the default process rule). If you want, I can share the completed XML files of process in my github.
Hope this could help you more clearly:-)
Is there an API that can give a comprehensive set of rules for fields
on a work item types including the allowedValues of say Reason field
depending on the choice of State field?
For this issue , you can use Rules - List api to get it .
GET https://dev.azure.com/{organization}/_apis/work/processes/{processId}/workItemTypes/{witRefName}/rules?api-version=5.1-preview.2
I test with postman , the figure below is the result returned by my test.
By searching for keywords, we can get the rules of allowed values for Reason field depending on the choice of State field.
The processId parameter required in the api can be obtained through this rest api.
Hope this helps.
I have a custom stored procedure with in parameters that return fields of different tables how I can map this custom stored to an entity? I only want to use like a read only values for a report I don't want to save or something like that I try to add the extra fields to the most similar entity but when I execute the method in code the extra fields are null
Solution 1: Using a view
A view allows to aggregate data from different entities.
<Article>
<Id />
<Name />
<Lines typeName="LineCollection" />
<cf:method name="LoadArticlesByCommand" body="load(string commandName) from ArticleByCommand where CommandName = #commandName" />
<cf:view name="ArticleByCommand" autoLightweight="true">
<ArticleName expression="Name"/>
<ArticleQty expression="Lines.Quantity" />
<CommandName expression="Lines.Command.Name" />
</cf:view>
</Article>
<Command>
<Id />
<Name />
<Lines typeName="LineCollection" />
</Command>
<Line setType="List">
<Article typeName="Article" key="true" />
<Command typeName="Command" key="true" />
<Quantity typeName="int" />
</Line>
http://blog.codefluententities.com/2014/04/22/views-auto-lightweight-and-the-modeler/
https://www.softfluent.com/documentation/Views_PersistentViews.html
Solution 2: Using a lightweight entity
Instead of creating a view, you can can create a lightweight entity that contains only the properties used by the stored procedure.
<cf:entity name="Person" lightweight="true">
<cf:property name="FirstName" typeName="string" />
<cf:property name="lastName" typeName="string" />
<cf:method name="ComputeBalance"
body="load () raw"
rawBody="SELECT 'John' AS FirstName, 'Doe' AS LastName" />
</cf:entity>
Solution 3: Custom mapping
For more specific values or types, a custom method can be provided to map the database values to .NET types. This custom method will be called with a DataReader as parameter, meaning that a developer could do whatever he wants.
<cf:entity name="Sample">
<cf:method name="LoadPair" body="raw" rawBody="SELECT 1234,5678"
returnTypeName="CodeFluent.Runtime.Utilities.Pair<System.Int32,System.Int32>"
cfom:methodName="On{0}" />
<cf:snippet>
private static CodeFluent.Runtime.Utilities.Pair<int,int> OnLoadPair(System.Data.IDataReader reader)
{
return new Pair<int, int>(reader.GetInt32(0), reader.GetInt32(1));
}
</cf:snippet>
</cf:entity>
You can also use OnAfterReadRecord or OnBeforeReadRecord rules
If it is not essential that you map the results of the custom stored procedure to an entity than another option is to use the built in support for DataSets.
http://blog.codefluententities.com/2011/06/22/dataset-support-in-codefluent-entities/
<cf:method name="LoadAllCities" body="raw" returnTypeName="System.Data.DataSet">
SELECT $Address::City$ FROM $Address$
</cf:method>
.
DataSet ds = Address.LoadAllCities();
foreach (DataTable table in ds.Tables)
{
foreach (DataRow row in table.Rows)
{
Console.WriteLine("City: " + row[0]);
}
}
Upon re-reading you're question I am providing another answer.
In response to the part where you said "I try to add the extra fields to the most similar entity but when I execute the method in code the extra fields are null". The following steps should be able to solve that problem.
Execute one of the automatically created stored procedure in SQL Management Studio.
Execute the stored procedure you manually created.
Verify that the fieldnames returned by both stored procedures match.
I think the above will solve your immediate problem but I still don't like the solution. The reason is that you said you picked the most similar entity. I think that is going to cause problems in the future especially if the stored procedure is not being mapped to all of the entities properties.
I would recommend either lightweight entity, view or DataSet.