I use Zabbix API method trigger.get to retrieve a list of available triggers. I try to exclude some triggers from the result list by passing their ids into params:
"excludeSearch": "true",
"search": {"triggerid": "37328"}
It doesn't seem to exclude the trigger with the given id. In the manual I read:
search Works only for string and text fields.
I am not sure if it applies to triggerid which is
triggerids string/array
Anyway, is there any other way to get exclusion by triggerid working?
PS. I tried other names for that parameter, i.e. triggerid, triggerids, and experimented with passing value arrays, objects etc.
I'm not aware of a way to exclude triggers by ID in trigger.get. The confusion regarding string/not is understandable - the API documentation you quote that says "string/array" is looking at this from the API perspective, while the "Works only for string and text fields" part talks about the database field types. The trigger ID is a numeric field in the DB, thus it cannot be searched - and filtering for it cannot be reversed either.
Related
I am doing an HTTP GET request to /maximo/oslc/os/mxsr and using the oslc.select query string parameter to choose:
*,doclinks{*},worklog{*},rel.commlog{*},rel.woactivity{*,rel.woactivity{*}}
This lets me get related data, including related worklogs, but the worklog does not include the 'description_longdescription' field.
The only way I seem to be able to get that field is if I do a separate HTTP GET to query a worklog id directly through /maxrest/rest/mbo/worklog . Then it provides the description_longdescription field.
I understand this field is stored separately through the linked longdescription table, but I was hoping to get the data through the "next gen" oslc api with one http get request.
I've tried putting in 'worklog{*,description_longdescription}', as I read somewhere that longdescription is a "non-persistent" field and must be explicitly named for inclusion, but it had no effect.
I figured out that for the /maximo/oslc/os/mxsr object in the API, I needed to reference the related MODIFYWORKLOG object through the rel.modifyworklog syntax in the oslc.select query string:
oslc.select=*,doclinks{*},rel.modifyworklog{*,description_longdescription},rel.commlog{*},rel.woactivity{*,rel.woactivity{*}}
I also had to explicitly name the non-persistent field description_longdescription for it to be included.
Ref. for the "rel." syntax: https://developer.ibm.com/static/site-id/155/maximodev/restguide/Maximo_Nextgen_REST_API.html#_querying_maximo_asset_management_by_using_the_rest_api
I'm trying to filter my users list by comparing two parameters
query="EmployeeData.EmployeeID=externalId"
EmployeeData.EmployeeID is a custom schema that is populated, with a cron job, with the same value as externalId.
Of course I let the cron do the field copy only if necessary, this is the reason I'm trying to filtering the users list.
In the way i wrote seems that the query trying to looking for a value "externalId" into the EmployeeData.EmployeeID ignoring that "externalId" is a even a field
any suggestion?
The way your code is written, the query sent to Google's servers is as you correctly guessed the following:
EmployeeData.EmployeeID=externalId where your actual externalId is not sent but rather the string "externalId".
To replace this string for the actual value of your variable, you can use what is called "string concatenation" 1. To do it, you just need to modify your code as shown below:
query="EmployeeData.EmployeeID=" + externalId;
This way, the query will be sent as you need to Google's servers.
Hey there and thanks in advance.
I'm exporting the API of an application onto my spreadsheet, which works fine. Due to how the API was programmed however, some of the columns now contain the TypeID (an integer representing the "name") and not the actual name. I know what TypeID represents what Name, so what I'm looking for is a way to substitute all entries of said column with the actual name.
I have already begun to make a humongus switch case in the script editor that just checks every cell in that column and based of the contents substitues the right name, but as you can probably imagine that would take a while.
Just wondering if there is a "cleaner" and more effective way.
I'd recommend making a JSON object to represent your switch case and call that
i.e :
var jsonMap = {"TYPEID":"NAME"};
Then call :
jsonMap[fieldValue]
To return the correct value for that field
You could have the script trigger on row modification and have it translate that way.
Alternatively I'd recommend mapping the field before it is exported into sheets using the language you're exporting in and have the data enter the sheet correctly
So I have done some hunting around online, and have been able to figure out how to use the enum tag in a swagger doc to specify a list of possible values for a field. However, in my current API what I need instead is to have a list of potential fields, each of which has a string value.
To be more precise, I have a POST request that sends JSON in the request body. As part of this request users need to send a single ID field. However, we accept multiple types of ID fields. So the request would look something like this:
{name:"name", product:"product", [FirstIdType, SecondIdType, ThirdIdType]:"ID Value"}
So I need to have the user submit a JSON that has a name, product, and one of FirstIdType, SecondIdType, or ThirdIdType. Technically it is required to have exactly one of those three ID types in the request, but I don't really mind if that isn't possible in the swagger doc. Noting it in the description for the field is fine.
The other constraint is that I can't really change the design at this point. The app has already been built using this design and changing it is out of my hands. Which means that I can't just make an array of ID Types and then choose one of them.
Here is the relevant bit from my swagger doc. The area that needs changed is the ID field. Any thoughts or directions on how to get that to go forward would be really appreciated.
definitions:
request_post:
description: (post) request schema
properties:
name:
type: string
product:
type: string
Id:
type: string
Instead of defining what optional fields can come on the path, you can label the fields that are required and make the rest variable by default.
http://swagger.io/specification/#parameterObject
required boolean Determines whether this parameter is mandatory. If
the parameter is in "path", this property is required and its value
MUST be true. Otherwise, the property MAY be included and its default
value is false.
I send over proper json formatted code, according to v2 api docs:
lists/subscribe.json
"GROUPINGS":[{"id":removed_id,"name":"grouping_name","groups":["group_name"]}]
I get back information about a member... It does not say they are interested in that group name..
lists/member-info.json
"GROUPINGS":[{"id":removed_id,"name":"grouping_name","form_field":"hidden","groups":
[{"name":"group_name","interested":false},{"name":"other_group_name","interested":false},
{"name":"other_group_name2","interested":false},{"name":"other_group_name3","interested":false}]}]
I do not understand how I can get these users to show up as "subscribed" to a group within my grouping. I have been trying for nearly 5 hours now. I have tried:
making sure the groups: value is an [] array.
trying out making that value a string (which surprisingly did not throw errors)
capitalizing "GROUPINGS" when sending it in merge_vars
not capitalizing "groupings" when sending in merge_vars
using the lists/update-member.json method to update these groups
using the name of my interest group instead of grouping in the grouping array.
using the option replace_interests on both true and false
In conclusion,
I had to email mailchimp a support ticket. Without changing my code at all - it works this morning. Interestingly enough, mailchimp was experiencing many issues yesterday with servers being down and alleged email hackings.
To be clear about which version of my code worked - following the API exactly for v2.
It was an error on mailchimp's end.
{
"id":"MY LIST ID",
"email":{
"email":"THE EMAIL TO SUBSCRIBE"
},
"merge_vars":{
"GROUPINGS":[
{
"id":THE GROUPING ID,
"groups":[
"THE NAME OF MY GROUP"
]
}
]
},
"double_optin":false,
"replace_interests":true,
"apikey":"MY API KEY"
}
Also, in case you are curious, replace_interests is true when the groups you send are supposed to replace existing groups the subscriber is interested in. False indicates that the groups you pass should be added to the interest groups.
If you are updating a member (method: lists/update-member), it may be best to set replace_interests to false just to make sure it does not overwrite your existing interest groups (possibly with blank groups). The default value for it is true, so this could be another place prone to error.