Allow changing matching criteria

[cconard96]

Allow GLPI administrators to change how devices are matched between Jamf and GLPI. Currently the device UUID is used, with the name used as a fallback. At least, there should be an option to change this to serial number.

Whatever options are allowed, that information must be provided in the list API call to Jamf to avoid making an additional call per every device.

The following identifying fields are currently available from the Classic API /mobiledevices endpoint:

• ID
• Name / Device Name
• UDID (UUID)
• Serial Number
• Phone Number
• WiFi MAC Address

[rani2001]

Hello,

I'm sorry if my question seems stupid but how can we change the way we match devices between GLPI et Jamf ?

Thanks

[cconard96]

You can't. I'm not looking to evolve this plugin much at the moment as I work full time on GLPI itself and I don't work for a business that uses Jamf anymore (hence the mass closure of the issues i created for potential new features).

However, it shouldn't be that big of an issue. The only matching/merging that would need done is when:

• you created a computer/phone in GLPI manually and then want to link it with a Jamf device.
• This plugin previously created an asset but you completely deleted the device in Jamf somehow, re-added it, and now want to link it with the previously created GLPI asset.

The regular sync works directly with the ID the device has in Jamf.

Merging works with the UUID/UDID fields in GLPI and Jamf primarily. If no device in GLPI has the same UUID as the Jamf device, it falls back to matching on the name.

However, merging isn't an automated process and the initial match only affects the GLPI asset chosen by default in the UI. You always have the opportunity to manually choose which GLPI device you want it to link with.

Do you have a specific use case where custom matching criteria (criteria for the default selection) is required? Like I said, merging should be an extremely rare need outside of the initial setup when you previously manually created the assets in GLPI.

[cconard96]

You can't. I'm not looking to evolve this plugin much at the moment as I work full time on GLPI itself and I don't work for a business that uses Jamf anymore.

However, it shouldn't be that big of an issue. The only matching/merging that would need done is when:

• you created a computer/phone in GLPI manually and then want to link it with a Jamf device.
• This plugin previously created an asset but you completely deleted the device in Jamf somehow, re-added it, and now want to link it with the previously created GLPI asset.

The regular sync works directly with the ID the device has in Jamf.

Merging works with the UUID/UDID fields in GLPI and Jamf primarily. If no device in GLPI has the same UUID as the Jamf device, it falls back to matching on the name.

However, merging isn't an automated process and the initial match only affects the GLPI asset chosen by default in the UI. You always have the opportunity to manually choose which GLPI device you want it to link with.

Do you have a specific use case where custom matching criteria (criteria for the default selection) is required? Like I said, merging should be an extremely rare need outside of the initial setup when you previously manually created the assets in GLPI.

[rani2001]

Thank you for the explanations.

Actually it's during the first merge. Since I have more than 2000 computers in Jamf, I have to manually link them one by one with the corresponding GLPI device.

For mobiles, the match is found automatically, not for computers.

It doesn't matter, I'll do it manually.

Thanks for your help

[cconard96]

You may be able to use the Data Injection GLPI plugin to ease the initial merge by exporting a csv of your devices from Jamf including the serial number, udid, etc and then using the data injection plugin to mass update your assets to fill in the missing data required for the Jamf plugin to do the initial match suggestions.

[rani2001]

I think I know why I'm having this problem. The discovered computers have this message at the UDID column: "Not collected during discovery"

Is it possible to restart a discovery again?

[cconard96]

You can use the "Clear pending imports" button in the "Import devices" page to make the plugin forget everything it discovered but didn't import yet and then click "Discover now" to run another discovery immediately. However, when it says "Not collected during discovery" it isn't a temporary issue caused by a bug. The API call the plugin makes to Jamf for discovery is a basic one that returns all devices but only the Jamf ID and name for computers. The same type of API call to get all mobile devices, for some reason, is far more useful and returns data like the UDID. So, for computer imports, it should still work with name matching. If not, then there is indeed a bug.

Currently, I am trying to switch everything in this plugin from using the older "Classic" API to the "Pro" API, although I'm told by Jamf it isn't a replacement and it is still missing essential functionality.

[cconard96]

The next release (3.1.0) will utilize the Pro API for the discovery of Computers (done in #128) and therefore will know the UUID/UDID of them during discovery. I don't have an ETA for the release. There are some other improvements I want to work on before the release, plus I want there to be a beta test period for it.

[rani2001]

Thank you very much for your help and the time spent on this plugin. I will happily test the beta version when it comes out.

[cconard96]

An alpha release has been created: https://github.com/cconard96/jamf/releases/tag/v3.1.0-alpha1

You should notice a "Join Discussion" button under the release. You can use that to create a GitHub discussion to converse about the release. I'd like to try using GitHub discussions rather than issues for non-stable releases.

[rani2001]

Thank you very much for your work. I'm going to test this...

[cconard96]

Thank you very much for your work. I'm going to test this...

Hello, Were you able to test the 3.1.0 alpha release?