Important Notice: On February 29th, this community was put into read-only mode. All existing posts will remain but customers are unable to add new posts or comment on existing. Please feel to join our Community Discord for any questions and discussions.

Packages in autodeployment still shows in the "updates tab" in package library

I don't think it is very intuitive that packages that are set to auto deployment, still shows on the updates lists, even if they are downloaded and deployed automatically.

This makes the updates list longer then it has to be. 

 

Example. Notepad++ is set to auto deploy. Current version is 6.8, it is already downloaded by "Auto deployment" BUT...

- It still shows on the updates lists. 
- It is not available as normal downloaded package (stored on repository).

 

Problem with this is that :

-It is actually downloaded to the repository, available to auto deploy, but not visible as a "normal package"
- It clutters the updates lists with a package that is actually handled by the deployment.

 

It would make more sense, since the package is already downloaded, that it was available as normaly downloaded package from the repository, AND that it was removed from the updates list... 

 

currently I need to cross reference the auto deployment list with the update lists when selecting what packages that i need to download and either manually deploy or set an auto deploy setting.

 

Another suggestion would be an option to HIDE packages that are part of an auto deployment.

Or am I missing something?




autodeploy_updates.png
0

Comments

1 comment
Date Votes
  • Hi Espen,

    The package library existed before Auto Deployment but when the feature was introduced, the packages had to be separate so that they weren't able to be edited.  If we kept everything in the same list and you edited the name of the package and added some additional nested steps or a message followed by a logoff step, when the new package was released and downloaded it would overwrite all of those changes leaving you to do the work all over again and reset the schedules, etc.

    Another use case where you would want these types of packages separate is if you would like to give yourself a buffer to test packages before unleashing them.  A great example of this is Java.  Some customers will set up Java to Auto Deploy but will change the Approval Policy to a custom time or manually so that they can import the new package and test the impact it will have on their environment and staff before approving the Auto Deployment schedule.

    Until the Auto Deployment/Package Library is redesigned by the developers during an overhaul the Auto Deploy and standard downloads will remain separate.

    Jason

    0