This is the official 1.0.2 release, exactly the same as the former 1.0.2b8.
- @grahampugh added a feature that prevents policies from being overwritten if there is no new package to upload, called
STOP_IF_NO_JSS_UPLOAD. It is enabled by default. To override this behaviour and force the processor to continue and overwrite policies etc., run your autopkg recipe with the
- @grahampugh added a
do_updatefeature to prevent overwriting a computer group if it already exists on the server, while continuing to create the group if it is not there.
- @nstrauss added a
skip_scopefeature to allow the upload of a policy without changing any existing scope.
- @nstrauss added a
skip_scriptsfeature to allow the upload of a policy without changing any existing script objects in the script.
- @grahampugh added a new
wait_for_iddefinition, which provides a common method to check for feedback on the upload of each API object, in an attempt to reduce the chance of cloud clusters returning conflicting information about whether an object has been successfully uploaded or not.
- Verbosity is increased with respect to reporting object IDs.
- References to JSS are changed to "Jamf Pro Server"... except in the name
JSSImporterof course! I think we're stuck with that one.
- Fixed a bug that prevented Types
SMBfrom being accepted (was introduced in 1.0.2b5).
- Fixed a bug that was introduced in 1.0.2b5 which prevented certain packages from uploading (relevant to #162).
- Changed the order of the code which waits for the creation of a package id, and added a wait for the creation of a category id, to fix problems with package objects not yet existing when uploading a package.
- Updated the embedded python-jss, which fixes a
urllibproblem when running in python2 (#151)
- @grahampugh contributed (#135) which prevents uploaded scripts from having certain special characters incorrectly escaped, namely
JCDSmode does not currently work and will cause a recipe to fail if configured. JCDS users should use the
- Efforts continue to be made to reduce intermittent failures of upload of packages to Jamf Cloud Distribution Points and CDPs, icons or other objects, but they may still occur. We believe this is due to the clustering involved with Jamf Cloud Distribution Points. See (#81), (#119), (#145) etc. Ultimately, we need Jamf to provide proper endpoints for package uploads and managing icons. Please bug your Jamf support and sales consultants as often as possible!
- The above efforts to improve package upload reliability may conversely cause problems on setups with multiple DPs of different types. Scenarios involving Cloud plus Local DPs are not yet tested, and there probably needs to be a more intelligent method of treating each DP as a separate package upload process than currently exists.