The value in value_raw is always a string.
However the implementation is bizarre.
You can do things like this (as you indicated already).
value_raw = 'True'
value_raw = '42'
But the handling of a dict is really bizarre, you do not process it as json at all, in fact, if you try that you get a whole bunch of errors.
These two functions below worked for me, but ymmv.
import ast
def value_raw_to_dict(value_raw: str) -> dict:
return ast.literal_eval(raw)
def dict_to_value_raw(value: dict) -> str:
return value.__str__()
If you need strings in the value, for example agent in a host_check_command rule.
Then you must set it like this:
value_raw = "'agent'"
While you can set numbers like shown above, there is one more peculiarity that i have found which is absolute bonkers.
This is if the number is to indicate the index value of a dropdown box.
If there is a dropdown involved, you must follow the same rule as for strings, so to select the first item from a dropdown box you must do:
value_raw = "'0'"
Otherwise it will return with an error that sends you on a wild goose chase.
These are things that i found out arbitrarily. (Check mk version 2.1.0p44 and some earlier versions, so ymmv if you have a different version).
I have not tested this, but perhaps if the value raw needs to be empty, you can get away by setting its value to None in Python?
Btw, i’m using requests as the basis for the API calls as per the examples in REDOC, which for the most part seem to work.
I found that the REST API itself is inconsistent in places.
According to the chapter ‘JSON envelope attributes for objects’ in the Redoc documentation, in the example of the envelope it shows that the unique identifier is: ‘instanceId’.
However i have found that throughout various CRUD API calls it can be one of these keys: ‘id’, ‘ident’, ‘title’, ‘name’, ‘description’, ‘alias’
These are all used in one call or another, ‘instanceId’ on the other hand is not used anywhere as far as i can find.
Like you i also hope that in 2.4 they will revisit the API, and make a 2.0 version that is consistent across the board, and does handle value_raw and many other things in a consistent and more logical way that is also in-line with terminology that is used in the user interface.
I learned a lot about the API by writing an API client in Python for it, but i’m sure i haven’t found all the strange things yet.