Some documentation fixes

[wopfel]

The 1st commit adds a >.

The 2nd commit is about adding the type parameter as a row to the table.

I think the parameter should be mentioned in the table, as it is an essential parameter. I was dealing with scheduling downtimes, so I stumbled upon this.

Having a deeper look into the documentation, I've seen in almost every section the type parameter is not mentioned in the table, but below the table. Please let me know if I should move the type parameter to the table for other sections, too. It would be consistent across the whole document then. (I would create a 3rd commit then.) If the type parameter is mentioned below the table intentionally, then I suggest to drop the 2nd commit and only apply the 1st commit of this PR.

Regards, Bernd

[cla-bot[bot]]

Thank you for your pull request. Before we can look at it, you'll need to sign a Contributor License Agreement (CLA).

Please follow instructions at https://icinga.com/company/contributor-agreement to sign the CLA.

After that, please reply here with a comment and we'll verify.

Contributors that have not signed yet: @wopfel

• If you've already signed a CLA, it's possible we don't have your GitHub username or you're using a different email address. Please contact us if you think this is the case.

• If you signed the CLA as a corporation, your GitHub username may not have been submitted to us. Please reach out to the responsible person in your organization.

[wopfel]

After that, please reply here with a comment and we'll verify.

Contributors that have not signed yet: @wopfel

Signed.

[bobapple]

@cla-bot check

[julianbrost]

I think the parameter should be mentioned in the table, as it is an essential parameter. I was dealing with scheduling downtimes, so I stumbled upon this.

That's not entirely correct. You can also do something like service=foo!bar (query string) or "service": "foo!bar" (JSON body) and this will select that object without explicitly specifying type.

There's room for improvement in the docs for sure (see also #9188), it took me until today to understand how you're supposed to read the documentation: everything in the section https://icinga.com/docs/icinga-2/latest/doc/12-icinga2-api/#filters affects everything in the API even though the simple filters are only used for /v1/objects in the examples and not for /v1/actions, they actually work for both.

Probably the most confusing thing here is that "filter" in "In addition to these parameters a filter must be provided." does not refer to the filter attribute (query string or JSON) but rather means that you have to use any of the filtering methods described in the linked section.

Feel free to either drop your second commit or replace it with something else if my short explanation helped you to understand things better.