I'm trying to update a HP QC Defect via REST API using PUT VERB. However, it will tell me it can't update the defect because of a "Missing required field".
I would understand if the field was actually required, but the thing it that it is not. I can go into QC, update that same defect with the value I am trying to update it with in script, and it works just fine.
If the Status field is set to deferred then "User-03" which is labelled "Deferred Reason" is a mandatory field and you can't save the defect without a deferred reason when status is deferred.
In this case, status is set to "Closed", so this required field does not apply in this work flow state. However, HP REST API 11 will still make me provide a value for every single "potential" required field regardless of the current workflow state.
This is a very bad design. Is there a way around this? I don't want to put dummy data in these fields just to satisfy an issue with HP's API.
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<QCRestException><Id>qccore.required-field-missing</Id>
<Title>Missing required field: user-03 for entity defect</Title>
<ExceptionProperties/></QCRestException>
HP's rest api is bypassing the workflow/vbs configured for all these purpose. It is highly depended upon the customization metadata which we have per project.
To overcome what you should do is, go to customization -> Project entities -> entity -> custom fileds -> user-03. Mark it non required field from customization. In the workflow script still you can set it mandatory for specific conditions so that it works with same behavior from the user's point of view and hopefully rest will also allow you to update without specifying this field.
Thanks,
Gaurav
Related
I'm trying to build an integration for a client between Big Commerce and their ERP system. As part of this, I need to update existing custom fields against products in Big Commerce.
The API reference (https://developer.bigcommerce.com/api-reference/store-management/catalog/product-custom-fields/updatecustomfield) states that this is possible. I have built the integration code to use the exact method described in the API reference but it keeps returning a 422 error which says:
The custom field with the name: xxxxxxxxx & value: yyyyyy already exists.
I don't understand why it would give this error; I know it exists, that's why I'm updating it. If it didn't exist, I would be using the Create Custom Field method instead.
Anyone ever come across this issue before or know why this may be occurring?
Thanks in advance.
I've found the API to be fairly robust, and use the custom_field API a LOT.
Have you done a quick check, via the API to get ALL the custom_fields for the product you are trying to update the custom_field for, and make sure you are updating by the correct custom_field ID? (so, not trying to change a different custom_field, which will then cause this error to be raised?)
We are using a hosted AzureDevops (ADO) instance to track requirements, bugs, and manual test runs. I know how to create notifications, and i know how to create new fields in ADO.
My question is: is it possible to create notifications for fields such as "Outcome" which is the result of a manual test case the values of which are active, blocked, or failed.
The goal is to create a notification when: assignedTo=#me AND outcome CHANGES (although, I'd accept most combinations.
From the document Default and supported notifications, We can see it is impossible to create a notification from the test case results on the change of the outcome. For test case results is not a work item, the results changed but the test work item is not changed.
Though it cannot be created in a standard way, you can create a custom field (named OutCome) by creating an inherited process. And change your current process to this inherited process
Then create a custom notification to send you an email on the change of the field outcome. You have to manually update the outcome field of the test case from Boards.
You can also go to Developer community to submit suggest a feature request. Hopely Microsoft development team will consider this feature and adding the notification for Test case results.
Accordint to this blog one can hide the business process flows. I'm trying to follow it but there's no flows defined for my opportunity (according to the list).
I'd like to "delete" the flow for Opportunity entity (or at least affect it somehow to display different steps/different number of steps). The reason is that we'll be migrating from an older version and they've got a picklist with percentages of the deal being done. Not sure how to map it onto the Opportunity in 2013 and even if, I'm not sure the client'd like it.
Is it at all possible to remove business process flow from Opportunity in CRM 2013?
When I do follow the guide and fool around with all flows, I get to remove the one for Opportunity but then I'm shown the error message as in the image below. So I'm assuming that it's not the correct approach. Or did the blogger referred to in the first paragraph cheat and took his screenshot after closing the warning? :)
The blogger in the blog is using the earlier version of Dynamics CRM than yours. Newer versions of Dynamics CRM will show the above warning.
Beside one way in the blog, there are a couple of way to show/hide Business Process Flow:
use Javascript to set the display attribute of process bar element:
function hideBusinessProcessFlow()
{
document.getElementById('header_process_d').style.display = "none";
}
function showBusinessProcessFlow()
{
document.getElementById('header_process_d').style.display = "block";
}
Reference: https://community.dynamics.com/crm/b/misscrm360exploration/archive/2014/07/24/show-and-hide-business-process-flow-in-crm-2011-2013.aspx
Please note that this is unsupported customization.
Update processid and stageid fields of the record. Use update these fields with Javascript or writing a plugin/workflow to do this.
Have a look at this solution: http://code.msdn.microsoft.com/Change-Dynamics-CRM-2013-a6beb85e
In your case, you just need to update processid and stageid fields to null, then the annoying warning will disappear.
Good luck!
Are you looking at the complete list of Processes under Customisations? If you're looking at an unmanaged solution it won't appear unless it's been added to that solution. It's in there OOB and called Opportunity Sales Process, I just deactivated it on a clean org. No need to delete it, just deactivate it or edit as required.
There are two things that can be done for any business process flow in MS CRM:
Deactivate BPF
Delete BPF
In order to remove Business Process Flow (BPF) from existing records, it is not enough to just deactivate BPF. Even when we deactivate BPF, records that are associated with it will still show BPF with warning message that it is deactivated.
It is true, if you delete BPF from Processes in MS Dynamics CRM, they will be removed (not showed) from the records that were associated with that BPF. However, what if you do not want to delete default BPFs, like those related to sales process on system entities (Leads, Opportunities and Accounts)? What if you want to hide these default system BPF from default system entity (i.e. Opportunity)?
In this case you need to write plugin/workflow activity to remove association of the entity record from BPF.
See my GitHub example how to do this
This MS CRM community post is also useful:
Remove business Process Flow from Account
Does anyone know if it's possible to define rules or trigger on rally?
For example, field X is required only if field Y is defined and so on?
Also, is there a way to create a field that acts like a plan Estimate field? I want to define custom QA estimate field and want it be updated once the child QA estimate has been changed (that happens automatically in plan Estimate field but I looking to have this functionality in my custom field.)
Custom rules and workflows aren't currently possible in Rally, although it's a popular feature request. I'd recommend signing into Rally Ideas, and adding your and your teammates' votes and comments to the following Idea:
Add definable workflow enforcement into work fields to enforce agile process
Which will enhance the visibility of this feature request with Rally's product owners and usability teams.
I need to set up different permission on an object based on its workflow state. For instance, 'manager group' can edit the object only if state=draft but 'super manager group' can edit it also if state=validated.
It seems that's not possible using ir.model.access and I'm evaluating if it could be done using ir.rule. It seems not...
Is there a official way to get this or do I need to implement this feature (maybe by adding a condition into ir.model.access machinery).
This is not possible by default with ir.model.access, because this permission model is designed to act like simple Unix permission on CRUD operations, and it is statically defined, per-model and per-group.
You may be able to implement something like this using ir.rule, as it implements dynamic per-record access control based on field values. By having a set of rules defined only on the write and unlink operations and based on the state field, you will be able to prevent some groups from modifying records in certain states. By using the technique of an always-true rule [(1,'=',1)] you can then relax a non-global rule for users who have a "super-access" group. See also this answer.
This option will have important caveats however:
Be careful not to make those rules apply for read, as it will make the records completely disappear, and generally wreak havoc in your processes
The interface will not become read-only when the rule is in effect, and if you want to make the fields and buttons read-only you will have to find a way to specify this via attrs in a manner that depends on the user's groups. See also this Launchpad question.
the Save button in the UI will not be disabled
The standard error reporting in case of ir.rule restriction is not very clear, so it will certainly confuse users (note: it's being improved for 7.0)
As you see, using ir.rule filters for this purpose is far from a perfect solution, and you will first need to find appropriate solutions for the above issues.
Ultimately, you might have an easier task of implementing your own logic for this, plugging a new mechanism in the ORM primitive API methods: fields_view_get (for making fields dynamically read-only based on the user groups) and the CRUD methods (for actually restricting the operations)
There is another way instead of hacking web-client.
You can always have 2 views for the same Object .
For manager group.
For super manager group.
In manager group you can use attrs = {'readonly': [('state', '!=', 'draft')]}
or any condition as you needed.
And in the same way in super manager group, you can put his condition for fields.
I have this feature working on a production environment, using just Record Rules: in Project Issues, "basic users" can create and cancel issues, but can't open or close them.
Despite the GUI limitations mentioned by #odony, it works perfectly.
These are the Record Rules used::
There is a special case that needs attention: changing from a read-write State to a read-only State:
In the action's method, if the the State is changed after other write operations, the user will be able to change the State; but if there are some write operations after the State update, the user will not be able to change State.
In my example, the Project Issue method to Open an issue is case_open(). It first changes State and then does additional changes, like settting Open Date, User and Message history. Because of this, basic users can't Open issues. If you want them to be able to do so, case_open() must be overridden so that it changes State after all other write operations are done.
I got a similar requirement...
My requirement was to make a char field(say "test_123") readonly in the sale.order if the user comes under the group "sale user" otherwise editable for the group "Sale Manager".
That is, if the sale order is in draft state then anyone can edit, but it the sale order is confirmed then this field "test_123" is only editable for "Sale Manger"
What I did is I added a functional field (is_group_manager) which returns True if the user comes under the group "sale manager" and the state is not "draft" otherwise false.
Then in the xml view I added the field "test_123" with attribute attrs="{'readonly':[('is_group_manager','=',0)]}"
for example
<field name="is_group_manager" invisible="1"/>
<field name="test_123" attrs="{'readonly':[('is_group_manager','=',0)]}"/>
This will work only in openerp v6.0. Maybe this will be helpful for you. :)