Feature Request: Provide a sane path for life cycle of community scripts

[NiceGuyIT]

Is your feature request related to a problem? Please describe. As a user, if I start using a community script, what happens if that script is later renamed, deprecated or has a breaking change?

As a developer, how do I communicate to people using the script that a script is deprecated, has a breaking change, or possibly renamed/removed?

Describe the solution you'd like I would like a clear path for the life cycle of community scripts, and have this documented in the documentation. Here are some ideas to improve visibility of the life cycle.

• If a community script has a drastic change, continue using the existing version until acknowledged by the admin.
• Add a flag to the scripts screen showing a script is deprecated.
• Add a flag to the scripts screen showing a script has a breaking change.
• Add a flag to the scripts screen showing a script has been renamed or removed.
• Notify the admin what scripts need attention. This could be done with a "needs attention" filter.
• Add the above to the script's definition (metadata?) for the developer to indicate these changes. This implies a system for adding metadata about scripts.

Describe alternatives you've considered N/A

Additional context Related to issue #1206 which stores custom scripts in a separate repo. This feature request is specifically about community scripts.

The current path needs documentation. I believe changes are applied automatically, but I don't know about renaming or deleting scripts. Are those removed from the user's dashboard?

[silversword411]

The path has been existing scripts aren't approved unless I make sure someone doesn't break something (why there's 1-2 unaccepted PRs ATM)

I think there's something in the contributing docs that mentions that fact

[NiceGuyIT]

I'm cleaning up some policies and if a custom script is modified after being added to a policy:

1. Script checks are updated with the script content and script name.
2. Script tasks are updated only with the content. The script name is not updated. (Is this a bug?)

This makes it very difficult to see which (task) script is creating the output. A small workaround might be to output the script name, last modified and version number in a header for all scripts. I'm talking custom scripts because you can't modify community scripts.

[silversword411]

There's definitely some room for improvements to the system, let's discuss!

[NiceGuyIT]

I created a script called 🔥🔥🔥🔥🔥🔥Test - File Rename. This was manually added to the community scripts and then imported. I can see it in the script manager. Then I added the script to a policy as both a script check and task. Finally, I renamed the script to 🧊🧊🧊🧊🧊🧊Test - File Rename and imported it again. Let's see which systems are updated with the new name.

Script manager was updated, obviously.

Automation Manager >Checks was updated.

Automation Manager > Tasks was not updated. Note: You need to edit the task to see which scripts are attached since multiple scripts can be attached to a single task.

Agent > Checks was updated.

Agent > Tasks does not show the script name.

TL/DR: Bug confirmed: Renaming the script does not rename the script in the task. All other place are renamed. I'll open an issue for this.

While writing this, I added the necessary information to the community_scripts.json which includes a UUID. I realize now if the UUID does not change, the name can be anything and is separate from the filename on disk. From a systems perspective, anything that is upstream is automatically applied when updating.

[NiceGuyIT]

Deleting the script from the community script library appears to remove it from all sources. The script is removed from the task and the task remains because it can have multiple scripts. How is the user notified if the script is no longer attached to the task? The current system silently deletes the script from their task.

[silversword411]

I had a feeling that's what would happen, why I did that huge update a while ago pre-policy rework, and have been very careful on script updates ever since.

We should definitely have some safeguards in place though.

[silversword411]

Related: https://github.com/amidaware/tacticalrmm/issues/1489

[silversword411]

How about starting with naming and keyword conventions:

If a script has become deprecated or invalid for some reason for now we can't just delete the community script. Best practices would be to:

1. Update the name: field in the .json to start with zzDEPRECATED
2. Update the filename: field in the .json to start with zzDEPRECATED_
3. Update the description: field in the .json. Include notes/URLs as appropriate.
4. Update the category: field to DEPRECATED
5. Rename the script file name in /scripts/ to match json filename:

Once we have a fixed workflow on how script files are deleted from the community script library that are in use in peoples TRMM servers we can work on making them go away permanently.

[dinger1986]

Sounds perfect to me