I have a requirement to copy an existing dashboard dashboard in an org(source org) to a different org(target org) under a different ado instance by any means possible. Dashboard can have widgets and widgets can be linked to
pipeline
Query - A query can be referencing to a user, team, project, custom values of a standard field, custom fields
some other things that i have not encountered so far
So far my steps are as follows
get dashboard details using get dashboard rest api
identify widgets in dashboard details api response
get any pipeline if there is no pipeline create a dummy one and use its details for a widget that is using pipeline
identify distinct queries present in all widgets
create its equivalent query in target org and save its id
replace queryid in widget settings to its equivalent created queryid in targetorg
create dashboard in target org
I am facing issue in step 5
There are lot of moving variables in a query. Query might be referencing to things that does not exist in target org like a particular user, team, custom values of a standard field, custom fields. In order to create a query successfully i need to know possible values of a field in target org. While creating a new query from ui it shows possible values for a field in dropdown so i am wondering is there any rest api that gives possible values of a field and if no such field exist in target org then it should throw error.
Looking forward to suggestions for a simpler or alternative approach to replicate a dashboard across different ado instance and/or better approach for step 5
If you are looking for a rest api the query the fields in your target process of the organization, you could refer to this doc. Field-list.
GET https://dev.azure.com/{organization}/_apis/work/processes/{processId}/workItemTypes/{witRefName}/fields?api-version=6.0-preview.2
After that, you could create the fields in your target process, you could refer to this rest api. Fields-Create
POST https://dev.azure.com/{organization}/_apis/work/processdefinitions/{processId}/fields?api-version=4.1-preview.1
Or could you share more details of your requirement, like screenshots and widget definition or dashboards configuration for update.
I would like to to automatically add data to multiple fields when creating new work item in Azure Devops boards
For example: when a user create new bug - the planned version field will be set automatically to lastest version available
You can try to use the work item rule feature to do this.
For example:
Conditions
When A work item is create ...
Actions
Then Set the value of ... {Field Name} to {Value}
This feature is available in all the customize processes (Inheritance process). For more details, you can reference the document "Add a rule to a work item type".
Can I add an unique custom field inside a work item.
So when a new work item is added, a validation error occurs if a previously added work item already contain a that value.
I've tried inside the "Rule" section of work item customization, but without success
There is no built-in rule to enforce uniqueness. The only field that is guaranteed to be unique is the work item ID.
It is possible to create a custom control that uses the REST API to query whether the contents of a field are unique and have it enforce that uniqueness. But that has a few caveats. The rule will only be enforced in the UI, other experiences (like bulk changes, excel etc) won't triggr this validation. Direct manipulation through he REST API won't either. And I would expect concurrency problems when you venture in this direction.
I have this question and trying to get suggestions ,i am working on a a project where the business admins go to UI and sets some rules ..For example lets say JIRA has a feature like if this jiraticket belongs to (Some arbitrary board "XYZ" ) board and type of the jira is "Task" then Label should be added ..
This kind of rules the admin of JIRA through the admin screens sets this rules(How he sets it keep it a side for now )...Now when the user creates a JIRA under the board and sets type with our Lable then based on the rule it should throw an error saying the label should be set ..
There are two parts to implement this feature
1)While admin sets this through the screen we need to create the rule and store it some where..
2)While user creates the jira run the rules which has been stored and say it is valid or not
I am looking for any framework in java it can be done easily for 1) which creates the rule where some framework can understans it and can run the riles with 2) point.
Does some one has any suggestions on this ..?
Thanks,
Swati
Sorry if this is sort of confusing because I'm not sure how to word this. I am trying to create a workflow that runs off of Account's in Microsoft CRM 2011. One part of this workflow requires me to retrieve a field contained in the Business Unit of the User in the Account's "Created By" field. However, the workflow will only allow me to access the Business Unit itself, but not any of its fields.
I'm wondering if there is a simple trick or work-around that will allow me access to this data.
Thanks!
For reference, the Account has a User, who has a Business Unit, and the Business Unit has a field I need to access. CRM, however, doesn't want to let me get more than 2 levels deep when accessing fields.
Clunky but do-able if you accept a bit of denormalisation (temporarily or otherwise). I'll assume for the sake of example you want to get at the "cost centre" field from the BU.
Add a field on User entity to temporarily hold the value from the BU (so make it same type and length, text(100) in this case), optionally put it on the form.
Create a child workflow for the User entity to update the user with the "cost centre" value from their BU. Make it only available to run as a child, not onDemand or anything else. Activate
In your Account workflow, add a step to call the child workflow against the relevant user (eg Created By in your case).
Add a step to wait until the new cost centre field on the user record contains data.
Now do whatever you need to with the value from the user record, such as update the Account, or do some branched logic.
Whatever you do, once you have used the value, clear the field on the user record, or do this as the last step of the workflow.
Now, since Users don't change BU very often, you might actually just go ahead and keep that value on the User record permanently, and instead of a child workflow, simply run this on create of a new user, or on change of BU, and store the value permanently on the User record. Yes, it is 'denormalised' and not purest SQL design, but then you don't need a child workflow, you don't need a wait state and you don't have to clear the value at the end, or worry about what happens when two Accounts need to run their workflow at the same time. I include the more general approach above as this might apply to other records which do change their parent quite often.
Just an additional thought - you can access the "owning business unit" of the Account, but this will be the BU of the Owning User, rather than the Created By, but is your business process such that this would normally be the same person? (eg users only have Create priviledge to "user owned" depth, so can only create records they own).
If so, then you could get at the BU directly from the Account, and then any fields on it too (in a condition or to update the Account)
Alternative which is less ideal but a similar approach - add a relationship from Account to BU (eg "created BU"). Now you can update the Account with this by referring to the Created By User's BU, then in the next step, reference this value from the Account. This is again denormalised, and less preferable since number of Accounts is far greater than number of users, so the level of duplicate information is much higher.
You can't get deeper with the standard steps of a workflow.
The solution is to create a custom workflow activity, you can start from this article:
http://msdn.microsoft.com/en-us/library/gg328515.aspx