I´m using the python jira package to create and update issues in our self hosted Jira. Sometimes it happens, that issues are created without filling in all information. Because of that, customfields are empty after the creation.
Later, people want to update some fields that were empty before, because now they have new information.
This is not working, I get the error:
"errorMessages":[],"errors":{"customfield_100233":"Field 'customfield_100233' cannot be set. It is not on the appropriate screen, or unknown."}}
I guess this happens because the field is hidden and therefor can´t be updated, because it currently has an empty value.
Has somebody an idea, how to solve this?
I found the solution.
Jira Dropdown Fields can´t be updated to None via a value, you have to set the id to -1.
Related
Does anyone know if there is a list of what the custom fields equate to when calling jira via an api to bring the results back?
Not sure a way through restapi, but a workaround.
I had similar issue, so I exported JQL result with All fields which gave field names like custom_field012(SomeFieldName) then I had created a reference table with Custom_field and corresponding field name
I found this link worked and brought up a list of all custom fields.
https://MY-JIRA-URL/jira/rest/api/2/field
You also need to have your Jira open in the same browser.
Currently creating an automation using zapier which should change the lead owner in salesforce when the event takes place. It successfully reaches salesforce but does not actually change the "lead owner" but it is instead reflected in the lead history section. There is no clear salesforce workflow or rule in place which should prevent this automation from occurring.
When the automation executes as you can see above, the lead owner successfully changes in the lead history but it does not actually change the lead owner of the actual lead so we are manually having to go back and change this.
Has anybody else faced similar issues when working with the salesforce API when changing the lead owner and if so what was the solution?
Check Lead assignment rules. It's separate area in Setup, different from workflows, flows, process builder and triggers.
You probably have an active rule that runs on update, not only on insert. Your API call works OK, changes the OwnerId field but then the assignment rule overwrites that. That's why you see it as 2 entries in history.
You can also confirm what's going on byenabling debug logging on the integration user and check if it captures anything.
Optionally you could also suppress the assignment rule during the update. This is... questionable. I mean talk with your SF admin first, if you suppress the rule then you moved bit of logic out of salesforce. 2 months later nobody will remember why something doesn't fire, it's cleaner to just modify the rule to skip these records.
If Zapier uses SF REST API there's a HTTP header it should send, Sforce-Auto-Assign: FALSE. If it uses SOAP API - similar thing will have to be set in the SOAP message's header, check the WSDL for exact syntax?
We solved this, just broke down the issue and resolved by doing the following (This was beyond the standard salesforce scope of support as we use custom prefill URL's for anybody wondering):
Create a new hidden field called something such as 'tmp_owner'
Assign the new lead owner ID to a new text field called 'tmp_owner' which is hidden on
the lead field to other salesforce org users
Added a salesforce workflow rule when this 'tmp_owner' is populated replace the 'lead owner' field with the data.
How can one set the allowed values for a Rally attribute (e.g. "Package") using Rally's web services API (2.0)?
I know how to retrieve the allowed values, and the WSAPI documentation says one should be able to POST new ones, or PUT to existing ones to rename them. But in actuality, POSTing new ones returns an error saying that POST isn't supported, and PUTting to existing ones isn't possible because they don't have _refs to PUT to.
Clearly there must be some way to do this — after all, the GUI can do it — but I haven't managed to figure it out. Anyone have the answer?
Ah, the package field... 'Twas a simpler time when this field was created. Unfortunately it is implemented differently than almost all other dropdowns in Rally and as such is not able to be updated via WSAPI as you have found. Other field allowed values (including custom fields) have _refs and operate as you expect above.
Let's say I have a plugin Foo in osclass. In that plugin we register a hook for when an item is posted. According to the osclass hooks documentation the only hook that is run when an item is posted is posted_item.
But as far as I can tell from looking at the code this is run after the initial item data has already been validated and stored in the database. What if a validation of some plugin specific code fails and I would like to show the user an error message and present him with the form again to give him/her the chance to alter this information? Much like if you try to submit a new item but don't fill in one of the base information like description for instance.
I can't seem to find a way to do this. Only workaround I find to avoid the item being posted despite containing invalid plugin specific data, without editing the main osclass code, is to delete the posted item again in the posted_item hook callback function of my plugin. This feels extremely cumbersome and also requires every other plugin to check that the item still exists to make sure they don't save data connected to an item that is now deleted.
What I would like, and wonder if I have missed, is a hook that is run when an item is posted but before it's written to the database and have the ability to generate "errors" that would cause the item to not be posted and the user redirected back to the form with the "error" displayed just like for the basic item information.
Anyone have a solution I have missed? This feels like a very important part of plugins and without it posted items could become very fragmented.
A user on the osclass forums (teseo) told me about the undocumented hook pre_item_add that can be used.
<?php
function cust_my_plugin($aItem) {
osc_add_flash_error_message('My plugin has a complaint.');
$pItem = new CWebItem();
$pItem->redirectTo( osc_item_post_url() );
}
osc_add_hook('pre_item_add', 'cust_my_plugin');
?>
He also sais
The only bad news is that you can't merge your plugin validation
process with that of the core script, so if the ad had an error
related to your plugin and other errors, it would be rejected twice,
one by your plugin, the second by the core script. I couldn't see any
workaround for this little issue.
Hi I'm am trying to get the list of issues from a JIRA server using the SOAP API provided by JIRA.
I'm trying to filter the issues based on a custom field (and latter I will want to set that custom field).
If I get the list of issue it returns the custom fields for those issues along with them (I get customfieldId, key, values for each custom field) and I can get the custom field with getCustomFields methods provided by the API (to look for the ID of the field with a given name).
The issue I have is that if I login with an account that is not an admin (using the API) I can't call the getCustomFields method (it throws an exception saying I have to be an admin to do that).
My question is: Is there any other way to know which is the ID of the custom field I desire that can be done using a normal user account?
Also if you know how to set a custom field for an issue, it would also be very helpful :) (I would also like to be able to do it with a regular user account).
You have to be an admin to get a list of custom fields. Any 'normal' account can act on the custom fields via the API provided the user knows the customfield ID.
You can set the value of a custom field too, even with a 'normal' account. Again, the user needs the appropriate permissions to do this. Example provided here.
More here and here.
You can also use getFieldsForEdit(token, issueKey), which will return RemoteField[] for all fields available for edit on that issue (even if it has not yet been defined on the issue). It does not require admin permissions, but because it has the word "Edit" in the method, it does require that you have permission to edit the issue (which means, e.g., if the issue is status=Closed, it will raise an exception unless you allow editing closed issues. Unfortunately, I have yet to find a way to retrieve the RemoteField[] list (in order to map id to name), so getCustomFields() and getFieldsForEdit() appear to be the only options.
Have you tried getting a list of issues from the project, picking one, zeroing out the data, and using that as a template? That might work.
SOAP is being deprecated in favor of the REST API, which also has a better method to get this information