[1.0.5] Not possible to provide parameter values for scripts that are to be uploaded

[grahampugh]

There appears to be no means of providing a parameter value for a script that is included in a policy.
The <parameters></parameters> section of a Script Template provides the opportunity to alter the display name of each parameter, but there's no means of inputting a value to the parameters.

If a Policy Template is edited, so that the parameter value can be included, this adds another script entry to the policy in addition to the one added due to the presence of a Script Template. This would result in the script running twice, once without the parameter value and once with.

It should be possible to provide both parameter display names to scripts and parameter values to script entries of policies.

[grahampugh]

I also cannot separate the script creation into a separate Processor. For some weird reason, the script is still added twice. Example:

<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
    <key>Description</key>
    <string>Downloads the latest version of 'Adobe Acrobat Reader DC' and makes a pkg of it then uploads it to the JSS.</string>
    <key>Identifier</key>
    <string>ch.id.jss.AdobeAcrobatReaderDCUpdates</string>
    <key>ParentRecipe</key>
    <string>com.github.novaksam.pkg.AdobeAcrobatReaderDCUpdates</string>
    <key>Input</key>
    <dict>
        <key>NAME</key>
        <string>Adobe Acrobat Reader DC</string>
        <key>PROD_NAME</key>
        <string>%NAME%</string>
        <key>LANGUAGE</key>
        <string>ML</string>
        <key>POLICY_LANGUAGE</key>
        <string/>
        <key>CATEGORY</key>
        <string>Productivity</string>
        <key>POLICY_CATEGORY</key>
        <string>Untested</string>
        <key>GROUP_NAME</key>
        <string>%PROD_NAME% test users</string>
        <key>GROUP_TEMPLATE</key>
        <string>SmartGroupTemplate-test-users.xml</string>
        <key>EXCLUSION_GROUP_NAME</key>
        <string>%PROD_NAME% test version installed</string>
        <key>EXCLUSION_GROUP_TEMPLATE</key>
        <string>SmartGroupTemplate-test-installed.xml</string>
        <key>EXTENSION_ATTRIBUTE</key>
        <string/>
        <key>POLICY_TEMPLATE</key>
        <string>PolicyTemplate.xml</string>
        <key>SELF_SERVICE_DESCRIPTION</key>
        <string>Views, prints, and comments on PDF documents, and connects to Adobe Document Cloud. Will install the most recent full installer if no version of Adobe Acrobat Reader DC already exists on the computer.</string>
        <key>SELF_SERVICE_ICON</key>
        <string>%NAME%.png</string>
    </dict>
    <key>MinimumVersion</key>
    <string>0.4.0</string>
    <key>Process</key>
    <array>
        <dict>
            <key>Processor</key>
            <string>StopProcessingIf</string>
            <key>Comment</key>
            <string>Checks if the file already exists in the cache</string>
            <key>Arguments</key>
            <dict>
                <key>predicate</key>
                <!-- Depending on the processor in the parent recipe, either download_changed (returned by URLDownloader)
                or new_package_request (returned by PkgCreator and AppPkgCreator) will be used to the left of the ==. -->
                <string>download_changed == False</string>
            </dict>
        </dict>
        <dict>
            <key>Processor</key>
            <string>JSSImporter</string>
            <key>Arguments</key>
            <dict>
                <key>prod_name</key>
                <string>%NAME%</string>
                <key>scripts</key>
                <array>
                    <dict>
                        <key>name</key>
                        <string>trigger_dependencies-preinstall.sh</string>
                        <key>template_path</key>
                        <string>%NAME%-ScriptTemplate.xml</string>
                    </dict>
                </array>
            </dict>
        </dict>
        <dict>
            <key>Processor</key>
            <string>JSSImporter</string>
            <key>Arguments</key>
            <dict>
                <key>category</key>
                <string>%CATEGORY%</string>
                <key>groups</key>
                <array>
                    <dict>
                        <key>name</key>
                        <string>%GROUP_NAME%</string>
                        <key>smart</key>
                        <true/>
                        <key>template_path</key>
                        <string>%GROUP_TEMPLATE%</string>
                    </dict>
                </array>
                <key>exclusion_groups</key>
                <array>
                    <dict>
                        <key>name</key>
                        <string>%EXCLUSION_GROUP_NAME%</string>
                        <key>smart</key>
                        <true/>
                        <key>template_path</key>
                        <string>%EXCLUSION_GROUP_TEMPLATE%</string>
                    </dict>
                </array>
                <key>policy_category</key>
                <string>%POLICY_CATEGORY%</string>
                <key>policy_template</key>
                <string>%POLICY_TEMPLATE%</string>
                <key>prod_name</key>
                <string>%NAME%</string>
                <key>self_service_description</key>
                <string>%SELF_SERVICE_DESCRIPTION%</string>
                <key>self_service_icon</key>
                <string>%SELF_SERVICE_ICON%</string>
            </dict>
        </dict>
    </array>
</dict>
</plist>

PolicyTemplate.xml:

<?xml version="1.0" encoding="UTF-8"?>
<policy>
	<general>
        <name>%PROD_NAME%%POLICY_LANGUAGE%%POLICY_LICENSE% v%version%</name>
		<enabled>true</enabled>
		<frequency>Ongoing</frequency>
		<category>
			<name>%POLICY_CATEGORY%</name>
		</category>
	</general>
    <scope>
		<!--Scope added by JSSImporter-->
	</scope>
	<package_configuration>
		<!--Package added by JSSImporter-->
	</package_configuration>
	<scripts>
        <size>1</size>
        <script>
            <name>trigger_dependencies-preinstall.sh</name>
            <priority>Before</priority>
            <parameter4>Adobe_Acrobat_Reader_DC-install</parameter4>
        </script>
	</scripts>
	<self_service>
		<use_for_self_service>true</use_for_self_service>
		<install_button_text>Install</install_button_text>
		<self_service_description>%SELF_SERVICE_DESCRIPTION%</self_service_description>
	</self_service>
	<maintenance>
		<recon>true</recon>
	</maintenance>
</policy>

ScriptTemplate.xml:

<?xml version="1.0" encoding="UTF-8"?>
<script>
    <name>trigger_dependencies-preinstall.sh</name>
    <category>Productivity</category>
    <filename>trigger_dependencies-preinstall.sh</filename>
    <info />
    <notes />
    <priority>Before</priority>
    <parameters>
        <parameter4>Trigger name</parameter4>
   </parameters>
    <os_requirements />
</script>

This makes the trigger_dependencies-preinstall.sh appear twice in the uploaded policy. I cannot find a way to avoid this.

[sheagcraig]

There's a lot of implicit behavior that happens when you run a JSSImporter processor in an AutoPkg recipe. You have two JSSImporters back to back, but there's nothing clearing the AutoPkg env in-between, so both processors are going to use the same values from the Input section, minus the differences explicitly set in the processor items. Is it possible that something is happening here?

That's probably why it's doing it twice?

About the parameters, I don't recall what the rules are exactly, but you should be able to put whatever you want into the AutoPkg env with Input values, and then JSSImporter will make them available as replacements in the template. I.e. your recipe has an input for <key>SCRIPT_PARAM</key><string>Trigger name</string> and your script template would need to have a parameters section with the value of one parameter being %SCRIPT_PARAM%.

[grahampugh]

Revisiting this issue as it's still a problem.

It doesn't appear to be possible to add a script AND have the parameter4 value filled in in the policy.

Given this script template:

        <script>
            <name>Prism 7-postinstall.sh</name>
            <category>Science &amp; Math</category>
            <filename>Prism 7-postinstall.sh</filename>
            <parameter4>%license_key%</parameter4>
            <priority>After</priority>
        </script>

If you put this in the PolicyTemplate.xml, parameter4 is filled in as it should be, but the policy will fail to run if the script is not already present in the JSS.

If you put the same XML in a ScriptTemplate.xml, parameter4 is ignored (and you can't pass a variable into it).

You can add the following in the ScriptTemplate.xml, but this creates a label for the script itself, not for the policy:

    <parameters>
               <parameter4>Some Value</parameter4>
          </parameters>

If you add a ScriptTemplate.xml AND have the script stuff in the PolicyTemplate.xml, the script is uploaded, but it is added twice to the policy, once without the parameter4 and once with.

So, how does one upload a script AND provide parameter values (not labels) in the same JSS run?

[sheagcraig]

@grahampugh and I discussed this on Slack today. The fundamental issue here is that the scripts and child tags in a policy template are appended to by any AutoPkg scripts objects. Specifically, the policy is created with the policy template, which may include a scripts tag. Then, when JSSImporter sees there are scripts in the AutoPkg environment variables, it checks to see if there is already a scripts tag, creating it if there isn't, and then adds in an entry for each of the scripts provided in the AutoPkg scripts array.

Currently, there are no AutoPkg variables handled specially by the code regarding parameters. It does copy the priority from the script object to the policy's reference to it. However, it does not add anything to the policy except the name and id (the python-jss method add_object_to_path does this) and then the priority (special case).

My proposal is to create two new keys that can be part of the JSSImporter's scripts/script dict: policy and script. Anything contained in the dicts under those keys would be copied to the resulting policy or script item for the script in question, beating the templated values.

So the final process would look roughly like this:

1. Handle scripts
   1. Does this script already exist? If so, grab it.
   2. Read the template, perform text substitution from the AutoPkg env.
   3. Add/override any recipe/scripts/script/script key/value pairs into the script object XML.
   4. If the script object already exists, copy the ID value from the retrieved XML to the working copy.
   5. Save.
2. Handle policies
   1. Does this policy already exist? If so, grab it.
   2. Read the template, perform text substitution from the AutoPkg env.
   3. Do other stuff (package, extension attribute, scope, etc)
   4. For each script in the recipe/scripts section:
      1. Add a reference to that script's name, ID.
      2. Copy the priority (in case one hasn't been provided in the next step, since this seems to be a required value (maybe test whether it is?))
      3. Add/override any recipe/scripts/script/policy key/value pairs into the policy's scripts section.
   5. If the policy object already exists, copy the ID value from the retrieved XML to the working copy.
   6. Save.

This really leaves the script template as unnecessary, so if we can determine that removing it causes a minimum of grief, we could potentially remove script templates after a suitable deprecation period.

[grahampugh]

@sheagcraig I’m going to work on this proposal shortly. One thing that occurs to me though - why are scripts and script-based EAs still treated differently? I understand the legacy reason that scripts were formerly uploaded as files, but now there is really no difference.

It looks like it shouldn’t be difficult to unify the handling of both types of script, so that EA scripts could be separate from their template. It would need to still work for EA templates with an embedded script object as before, but there could be advantages for allowing that for script objects too, for instance so that text substitution in the body of the script could be carried out.

I see that a script template could be unnecessary given your suggestion above, however, which would change the above idea. EAs will always need a template since that information is not part of a policy template.

Thoughts?

[grahampugh]

I have implemented this facility into my JamfUploader processors, so am unlikely to spend any time on making it work in JSSImporter.