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've seen this questioned asked before here
and have applied the suggested solution but am still coming up with
Tag not defined for this message
I'm sending this message :
toapp : 8=FIX.4.4|9=151|35=V|34=2|49=Test|52=20180731-14:35:54.947|56=UAT-Test|55=EUR/USD|63=SP|115=Username|167=FOR|207=XCEL|262=1|263=1|264=0|265=0|461=SPOT|10=074|
and getting this back
toadmin : 8=FIX.4.4|9=134|35=3|34=3|49=Test|52=20180731-14:35:54.982|56=UAT-Test|45=2|58=Tag not defined for this message type|371=264|372=W|373=2|10=090|
The entry in the data dictionary for marketdatarequest is :
<message name="MarketDataRequest" msgtype="V" msgcat="app">
<field name="MDReqID" required="Y"/>
<field name="SubscriptionRequestType" required="Y"/>
<field name="MarketDepth" required="Y"/>
<field name="Symbol" required="Y"/>
<field name="SecurityType" required="Y"/>
<field name="MDUpdateType" required="Y"/>
<field name="CFICode" required="Y"/>
<field name="SettlType" required="Y"/>
<field name="OnBehalfOfCompID" required="N"/>
<field name="SecurityExchange" required="Y"/>
</message>
...
<field number="264" name="MarketDepth" type="INT"/>
All the other FIX implementations I've come across also have NoMDEntryTypes and NoRelatedSym groups which this does not which is strange but this is what the spec requires.
Also am I correct in saying that if I send an toapp message and get the toadmin message back with no fromapp/fromadmin message, does that mean quickfix intercepted the message as incorrectly formed and never sent it?
The rejection is not for your market data request. I can tell this from tag 372=W in the rejection:
FIX 4.4 : RefMsgType <372> field
The MsgType <35> (35) of the FIX message being referenced.
Source
MsgType W refers to a market data snapshot.
From the information you've given, I can infer that you send a MarketDataRequest (35=V) which presumably works successfully. The server you're connecting to replies with a snapshot (35=W) and your FIX engine then automatically responds to them with a rejection, because their snapshot includes tag 264 which are you not expecting.
Let's assume there is such part in quickfix's data dictionary
<message name="Name" msgtype="type">
<field name="field1" required="Y"/>
<field name="field2" required="Y"/>
<field name="field3" required="N"/>
<group name="group1" required="Y">
<field name="field4" required="Y"/>
</group>
<group name="group2" required="Y">
<field name="field5" required="Y"/>
<field name="field6" required="N"/>
</group>
</message>
While sending request, I need to construct message correctly - set field5 in group2, field4 in group1, and field1 outside of any group. Is there a way in quickfix library to know, for example, if field4 is in a group or not? And in which group?
If not, how is it possible to use quickfix library, if you are depending on data dictionary client will use? I should force clients to configure data dictionary as I configured it?
I should force clients to configure data dictionary as I configured it?
Yes. A server ("acceptor") and its clients ("initiators") should all be using the same DataDictionary.
If you are providing a server, you should provide documentation that defines exactly what messages/fields you support, and how use use those messages and fields. If you don't provide a QuickFIX data dictionary file, you should provide sufficient information so that client firms can create one.
Is there a way in quickfix library to know, for example, if field4 is in a group or not? And in which group?
I think you are asking this question because you don't really know what you're doing yet. :)
I think there might be DD methods for this, but I can't really remember because they're not something people usually need. I don't think this is the right approach for whatever your problem is.
Is there any way to create test instance with parameter using the REST API on QC 11 ?
I have a test in my test plan with some parameters, or just one for the exercise :
I want to create using the rest API :
A test set in my test lab
A test instance in this test set
A test run of my test (the one in the plan) in this test instance
And be able to set the value of my parameters
I have manage to do the first 3 points. But I can not find how to set the parameter value for my instance. If I create the tests manually it is asked during the add of the test in the instance. And I can find the parameters in the Execution Settings in the Test Instance detail :
I have search in the documentation, but didn't find anything about how to set/use theses parameters. I have made GET on every objects, but didn't find them. I also try some urls like :
/test-instances/25378/test-parameters
/test-instances/25378/execution-settings
/test-instances/25378/exec-settings
But they always return 404.
Is there any way to set these parameters values ?
I had same troubles and here is my solution.
You can query your test parameters as:
/tests/{id}/test-parameters
And your test instance parameters, which are effectively actual values for those in your test instance, with:
/test-instances/{id}/step-parameters
For parameter values created via UI it returns like this:
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<Entities TotalResults="1">
<Entity Type="step-parameter">
<ChildrenCount>
<Value>0</Value>
</ChildrenCount>
<Fields>
<Field Name="origin-test">
<Value>-1</Value>
</Field>
<Field Name="vc-user-name">
<Value></Value>
</Field>
<Field Name="id">
<Value>21</Value>
</Field>
<Field Name="parent-id">
<Value>46</Value>
</Field>
<Field Name="used-by-owner-type">
<Value>test-instance</Value>
</Field>
<Field Name="actual-value">
<Value><html><body>
<div align="left">
<font face="Arial"><span style="font-size:8pt">AAA</span></font>
</div>
</body></html></Value>
</Field>
<Field Name="key">
<Value></Value>
</Field>
<Field Name="used-by-owner-id">
<Value>34</Value>
</Field>
</Fields>
<RelatedEntities/>
</Entity>
</Entities>
Where used-by-owner-id is id of the test-instance and parent-id is id of test parameter of the test.
Actual value for this case is AAA wrapped up with html tags.
You can create step parameters like this using normal POST to url:
/step-parameters
Note: Don't use same nested url for creation as you use for retrieval. You'll not be able to create parameters with such a combination of parameters you need.
API documentation really sucks, but you can get ideas how to retrieve or create things you need by requesting entity schema with
/customization/entities
In OpenERP XML fields are used to load module data.
The <record> tag is used for this.
When reinstalling the module, the records are rewritten with the current data in the XML file.
But is there a way to change just one of the record fields without rewriting all the others?
For instance, in addons/project_issue/project_issue_view.xml we have this action definition:
<record id="project_issue_categ_action" model="ir.actions.act_window">
<field name="name">Issue Categories</field>
<field name="res_model">crm.case.categ</field>
<field name="view_type">form</field>
<field name="view_id" ref="crm.crm_case_categ_tree-view"/>
<field name="domain">[('object_id.model', '=', 'project.issue')]</field>
<field name="context" eval="{'object_id': ref('model_project_issue')}"/>
</record>
Is it possible to change just the name field in an XML file of a custom module?
I already tried :
<record id="project_issue.project_issue_categ_action" model="ir.actions.act_window">
<field name="name">Issue Categorization</field>
</record>
and
<update id="project_issue.project_issue_categ_action" model="ir.actions.act_window">
<field name="name">Issue Categorization</field>
</update>
<record id="project_issue.project_issue_categ_action" model="ir.actions.act_window">
<field name="name">Issue Categorization</field>
</record>
Your given code will change the name but won't affect menu name. You can see your given action name in form and tree view.
To change menu name, you have to override menu only not action.
For example:
<record id="project_issue.menu_project_issue_category_act" model="ir.ui.menu">
<field name="name">Issue Categorization</field>
</record>
You can even refer Apply groups on already created menus