Is there a way to only update an extension attribute's value if it hasn't been populated yet? If the field is already populated, I want JAMF to leave it alone. Something along the lines of:
if ""; then
do this command
echo the result
not sure if there's a field or variable associated with it... in MUT, I know it would be EA_4 or whatever the ID is, but not sure if JAMF uses the same term.
The EA, by design, will always return a result to Jamf Pro. If your script returns
echo <result>some result</result>, then "some result" will be the value of the EA. If you don't explicitly return a result, the EA effectively returns
<result></result> (an empty value).
To control the action, I make a policy to run the script (heavy lifting) and then output the results to a text file, then have the EA just check the text file for results (light task). With the policy, I can control it with once per computer or if file exists inside the script. I think there is a feature request out there to make EAs more powerful, like running some and not others or running them more often than along with recon.
You could pull the EA from the API in your script, check if it is empty, and then either create/return the value or just return the existing value.
I guess the question is what are you trying to accomplish by having an EA that never changes? How is the EA get set initially? And what are you using the EA for in Jamf?
just fell foul of this and it's a pain. Trying to rework a LAPS script so it doesn't need API calls I used the write value to file then read file method, then delete the file for security. works ok until the EA runs again and outputs a blank value overwriting the password value! So it's API or leave file behind...
I did find and upvote this
@nikgio If I understood it, you do not want to use an API call and run the script directly from the EA and only setup a password if there is none. Basically set once and forget.
One option is to write an empty local file like .lapsSetupDone when you run the script.
So every time the EA script runs if that file exists/is found just exit the script otherwise set the password and set the "marker".
We do use a hidden file in our provisioning once it is done. We put it in /var/db/ like the .AppleSetupDone
And if there is a need to re-issue a new password just create a policy to delete that file.
Would strongly suggest to use explicit data sets with everything you do. Blank values can be treated as
NULL or a blank string, and depending on how you are leveraging that data, it can mean two very different things. You can also find that in some scenarios blank values end up being used when they should not. As a general rule all my EAs will return
false if I don't find the value I am looking for, that way I can use that data upstream and know exactly what it means and not have to code around either
NULL or blank strings. Plus it mitigates being bitten by a blank value. I have seen this bite me before so just passing this along.
What @tlarkin says is even more important for anything in date format. An empty date matches EVERYTHING, so I use a date outside the 'reasonable' range (eg 9.9.1999) as a default value in case an event has not yet happened on a device. That way I don't get bogus result with 'before' or 'after' tests.