class Jamf::MEMBER_CLASS
This class represents a Computer
in the JSS
.
Adding Computers to the JSS
¶ ↑
At the moment, this class cannot be used to add new Computers to the JSS
. Please use other methods (like the Recon App or QuickAdd package)
Editing values¶ ↑
Any data that arrives in the JSS
via an “inventory update” (a.k.a. ‘recon’) cannot be modified through this class, or the API.
Data that can be modified are:
-
Management
Account
(seeset_management_to
) -
barcodes 1 and 2
-
udid
-
serial_number
Note: Even tho the webUI doesn’t allow editing theserial_number
, the API does, and it can be useful for dealing with duplicates that arise when a logic-board swap causes a new computer record. to be created. -
location data via the
Locatable
module -
purchasing data via the
Purchasable
module -
Extension Attribute values via the
Extendable
module Note: as with other ‘recon’ generated values, Ext. Attrs. populated by scripts cannot be modified via the API. (the change would be overwritten the next time the machine did a recon)
After making any changes, you must call update
to send those changes to the server.
MDM
Commands¶ ↑
See the {Jamf::MDM} mixin module for Class and Instance methods for sending MDM
commands to computers.
To send MDM
commands without fetching Computer
instances, use the class methods, which can take multiple computer identifiers at once.
NOTE: the poorly named ‘UnmanageDevice’ mdm command is implemented as {#remove_mdm_profile} (which is its name in the webUI) as well as {#unmanage_device}. Calling that method will NOT fully unmanage a computer from the JSS’s point of view, it will just remove the mdm management profile from the machine and all configuration profiles that were installed via the JSS
. Those profiles may be re-installed automatically later if the computer is still in scope for them
To properly unmanage a computer, use the {#make_unmanaged} Instance method which removes the mdm profile, but also makes the machine unmanged by the JSS
, setting the management acct to nil, and requring re-enrollment.
Management History & Logs¶ ↑
Computer
Management History and logs can now be retrieved both from a Computer
instance, and directly via class methods without fetching an instance. This is handled by the mixed-in {Jamf::ManagementHistory} module, Q.V. for details.
Appication Usage History¶ ↑
Computer
Instances now have access to their Application Usage history via the {#application_usage} method. Call the method with a start-date value (either a String
or a Time
object) and an optional end-date value. If you omite the end-date, the start-date is used and you’ll see usage for just that day.
See {#application_usage} for details about the data returned.
NOTE: your JSS
must be gathering Appication Usage data in order for any data to be returned, and the usage history will only go back as far as your setting for flushing of Application Usage Logs.
Management Data¶ ↑
The computers ‘manamgement data’, as presented on the ‘Management’ tab of the computer’s detail page in the JSS
web UI, is available from the {#management_data} method. That method may return a large dataset, unless a subset is requested.
Subsets of management data have their own methods, which are faster and only retrieve the subset requested. See {#smart_groups}, {#static_groups}, {#policies}, {#configuration_profiles}, {#ebooks}, {#app_store_apps}, {#restricted_software}, and {#patch_titles}
The subset methods can take an ‘only:’ parameter, which is a symbol specifying the value you care to see. For example {#smart_groups} returns an array of hashes, one for each smart_group the computer is in. Those hashes have two keys, :name, and :id. However if you only want an array of names, you can call ‘smart_groups only: :name`
When any of the manamgement data methods are used the first time, the data is read from the API and cached internally, the cache is then used for all future calls. To re-read the data from the API and re-cache it, provide ‘refresh: true` to any of the manamgement data methods.
Other Methods¶ ↑
-
{#set_management_to} change the management acct and passwd for this computer, aliased to
make_managed
-
requires calling
update
to push changes to the server
-
-
{#make_unmanaged} an shortcut method for {#set_management_to}(nil)
-
requires calling
update
to push changes to the server
-
-
{#apps} a shortcut to {#software} [:applications]
-
{#licensed_sw} a shortcut to {#software} [:licensed_software]
-
{#computer_groups} a shortcut to {#groups_accounts} [:computer_group_memberships]
-
{#local_accounts} a shortcut to {#groups_accounts} [:local_accounts]
-
{#drives} a shortcut to {#hardware} [:storage]
-
{#printers} a shortcut to {#hardware} [:mapped_printers]
@see APIObject
@see Locatable
@see Purchasable
@see Matchable
@see FileUpload
This class represents a Mobile Device stored in the JSS
.
Adding devices to the JSS
¶ ↑
When creating new MobileDevices in the JSS
with this class (using {Jamf::MobileDevice.make}) you must specify a udid, and serial_number
before calling ‘create` or `save`. You can provide these values with the `.make` call, or afterward using setters.
Management History & Logs¶ ↑
MobileDevice
Management History and logs can now be retrieved both from a MobileDevice
instance, and directly via class methods without fetching an instance. This is handled by the mixed-in {Jamf::ManagementHistory} module, Q.V. for details.
MDM
Commands¶ ↑
See the {Jamf::MDM} mixin module for Class and Instance methods for sending MDM
commands to mobiledevices.
To send MDM
commands without fetching mobiledevice instances, use the class methods, which can take multiple identifiers at once.
NOTE: If the {#name=} method is used to change the name of a supervized device, the DeviceName MDM
command will be sent to the device when the changes are sent to the server via {#save} or {#update}
@see Jamf::APIObject
Constants
- APPLICATION_USAGE_DATE_FMT
The date format for retrieving usage data
- APPLICATION_USAGE_KEY
The top-level hash key of the raw app usage data
- APPLICATION_USAGE_RSRC
The API resource for app usage
- BOOT_FLAG
Boot partitions are noted with the string “(Boot Partition)” at the end
- CHECKIN_KEY
The top-level hash key for the checkin settings
- CHECKIN_RSRC
The API Resource for the computer checkin settings
- COMPUTER_APPLICATIONS_RSRC
- EXT_ATTRIB_CLASS
This is the class for relevant Extension Attributes
- HW_PREFIX_IPAD
- HW_PREFIX_IPHONE
- HW_PREFIX_TV
- INV_COLLECTION_KEY
The top-level hash key for the inventory collection settings
- INV_COLLECTION_RSRC
The API Resource for the computer inventory collection settings
- JPAPI_INVENTORY_DETAIL_RSRC
The resource for getting all inventory data for a computer at once
- JPAPI_INVENTORY_RSRC
The base resource for computer data in the JPAPI
- LIST_RSRC
The (temporary?) list-resource
- MDM_COMMAND_TARGET
- MGMT_DATA_KEY
The top-level hash key of the computer_management data
- MGMT_DATA_RSRC
The API resource for computer_management data
- MGMT_DATA_SUBSETS
Thes are both the subset names in the resrouce URLS (when converted to strings) and the second-level hash key of the returned subset data.
- NON_UNIQUE_NAMES
- OBJECT_HISTORY_OBJECT_TYPE
the object type for this object in the object history table. See {APIObject#add_object_history_entry}
- OTHER_LOOKUP_KEYS
these keys, as well as :id and :name, can be used to look up objects of this class in the
JSS
- RSRC_BASE
The base for REST resources of this class
- RSRC_LIST_KEY
the hash key used for the JSON list output of all objects in the
JSS
- RSRC_OBJECT_KEY
The hash key used for the JSON object output. It’s also used in various error messages
- SEARCH_CLASS
An
AdvancedComputerSearch
in theJSS
@see
Jamf::AdvancedSearch
@see
Jamf::APIObject
- SITE_SUBSET
Where is the
Site
data in the API JSON?- UPLOAD_TYPES
file uploads can send attachments to the
JSS
using :computers as the sub-resource.
Attributes
@return [Array<Hash>]
The computers associated with this user
Each Hash
has then :id and :name for one computer
@return [String] The user’s email address
@return [String] The user’s full name
@return [String] The name of the user’s LDAP server
@return [Array<Hash>]
The mobile devices associated with this user
Each Hash
has then :id and :name for one device
@note This data is currently broken - the JSON output of the API only returns one mobile device, and it isn’t formatted in a standard way.
@return [Array<Hash>]
The peripherals associated with this user
Each Hash
has then :id and :name for one peripheral
@return [String] The user’s phone number
@return [String] The user’s position / job title
@return [Integer] the total number of vpp codes assigned to this user
@return [Array<Hash>]
The user-based vpp assignments associated with this user
Each Hash
has then :id and :name for one assignment
Public Class Methods
See Jamf::APIObject#initialize
Private Class Methods
Public Instance Methods
Private Instance Methods
Add this user to a site
@param site the name of the site
@return [void]
# File lib/jamf/api/classic/api_objects/user.rb 232 def add_site (site) 233 return nil if @sites.map{|s| s[:name]}.include? site 234 raise Jamf::InvalidDataError, "No site in the JSS named #{site}" unless Jamf::Site.all_names(cnx: @cnx).include? site 235 @sites << {:name => site} 236 @need_to_update = true 237 end
# File lib/jamf/api/classic/api_objects/user.rb 200 def email= (new_val) 201 @email = new_val 202 @need_to_update = true 203 end
# File lib/jamf/api/classic/api_objects/user.rb 194 def full_name= (new_val) 195 @full_name = new_val 196 @need_to_update = true 197 end
# File lib/jamf/api/classic/api_objects/user.rb 218 def ldap_server= (new_val) 219 raise Jamf::InvalidDataError, "No LDAP server in the JSS named #{new_val}" unless Jamf::LdapServer.all_names(cnx: @cnx).include? new_val 220 @ldap_server = new_val 221 @ldap_server_id = Jamf::LdapServer.valid_id @ldap_server 222 @need_to_update = true 223 end
# File lib/jamf/api/classic/api_objects/user.rb 206 def phone_number= (new_val) 207 @phone_number = new_val 208 @need_to_update = true 209 end
# File lib/jamf/api/classic/api_objects/user.rb 212 def position= (new_val) 213 @position = new_val 214 @need_to_update = true 215 end
Remove this user from a site
@param site the name of the site
@return [void]
# File lib/jamf/api/classic/api_objects/user.rb 246 def remove_site (site) 247 return nil unless @sites.map{|s| s[:name]}.include? site 248 @sites.reject!{|s| s[:name] == site} 249 @need_to_update = true 250 end
Private Instance Methods
Workaround for the recurring Jamf
Classic API Bug where JSON is missing data that should come in an array of hashes, but only comes as a hash with a single hash inside, with data for only the last item in the XML array.
When needed, we fetch and parse the XML, which has the desired data. Use any truthy parameter to re-fetch the XML data, otherwise the data last fetched is used.
In this case, the user group data is fetched as XML and returned as an Array
of Hashes, one per group the user is a member of. Each hash containing three Symbol keys:
id: Integer, the group id name: String, the group name is_smart: Boolean, is it a smart group or a static group?
@param refresh Re-fetch the group data from the API
@return [Array<Hash>] The groups the user is a member of.
# File lib/jamf/api/classic/api_objects/user.rb 273 def user_groups(refresh = false) 274 @grp_array = nil if refresh 275 return @grp_array if @grp_array 276 277 @grp_array = [] 278 raw_xml = @cnx.c_get "/users/id/#{@id}", :xml 279 xmlroot = REXML::Document.new(raw_xml).root 280 xml_grps = xmlroot.elements['user_groups'] 281 282 xml_grps.each do |xml_grp| 283 next if xml_grp.name == 'size' 284 285 gid = xml_grp.elements['id'].text.to_i 286 gname = xml_grp.elements['name'].text 287 smart = xml_grp.elements['is_smart'].text == 'true' 288 @grp_array << { id: gid, name: gname, is_smart: smart } 289 end # groups.each 290 291 @grp_array 292 end