class Jamf::JpBuilding
A building in the Jamf
Pro API
Alas we can’t migrate Jamf::Building
to use the JPAPI - it must stay in the classic API because of how it interacts Scopes in scopable objects over there.
The parent class is the OAPI object representing a single member of the collection, i.e. the ‘GET_OBJECT’ similar to the POST_OBJECT
defined in the class below.
Constants
- ALT_IDENTIFIERS
Identifiers not marked in the superclass’s OAPI_PROPERTIES constant which usually only identifies ‘:id’
- FILTER_KEYS
Must define this when extending
Filterable
- GET_PATH
- LIST_PATH
The path for GETting the list of all objects in the collection, possibly filtered, sorted, and/or paged REQUIRED for all collection resources
GET_PATH
, POST_PATH, PUT_PATH, PATCH_PATH, and DELETE_PATH are automatically assumed from theLIST_PATH
if they follow the standards:-
GET_PATH
= “#{LIST_PATH}/id”-
fetch an object from the collection
-
-
POST_PATH =
LIST_PATH
-
create a new object in the collection
-
-
PUT_PATH = “#{LIST_PATH}/id”
-
update an object passing all its values back. Most objects use this or PATCH but not both
-
-
PATCH_PATH = “#{LIST_PATH}/id”
-
update an object passing some of its values back Most objects use this or PUT but not both
-
-
DELETE_PATH = “#{LIST_PATH}/id”
-
delete an object from the collection
-
If those paths differ from the standards, the constants must be defined here
-
- POST_OBJECT
The OAPI object class we send with a POST request to make a new member of the collection in
Jamf
. This is usually the same as the parent class.- PUT_OBJECT
The OAPI object class we send with a PUT request to change an object in
Jamf
by specifying all its values. Most updates happen this way, and this is usually the same as the parent class- SEARCH_RESULT_OBJECT
The OAPI object class we get back from a ‘list’ query to get the whole collection, or a subset of it. It contains a :results key which is an array of data for objects of the parent class.