[GH-ISSUE #1486] Feature Request: Provide a sane path for life cycle of community scripts

kerem commented

2026-03-14 05:46:43 +03:00

Owner

Originally created by @NiceGuyIT on GitHub (Apr 16, 2023).
Original GitHub issue: https://github.com/amidaware/tacticalrmm/issues/1486

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?

Originally created by @NiceGuyIT on GitHub (Apr 16, 2023). Original GitHub issue: https://github.com/amidaware/tacticalrmm/issues/1486 **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?

kerem added the

enhancement

label

2026-03-14 05:46:43 +03:00

kerem commented

2026-03-14 05:46:54 +03:00

Author

Owner

@silversword411 commented on GitHub (Apr 16, 2023):

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

@silversword411 commented on GitHub (Apr 16, 2023): 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

kerem commented

2026-03-14 05:46:59 +03:00

Author

Owner

@NiceGuyIT commented on GitHub (Apr 17, 2023):

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

Script checks are updated with the script content and script name.
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.

@NiceGuyIT commented on GitHub (Apr 17, 2023): 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.

kerem commented

2026-03-14 05:47:04 +03:00

Author

Owner

@silversword411 commented on GitHub (Apr 18, 2023):

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

@silversword411 commented on GitHub (Apr 18, 2023): There's definitely some room for improvements to the system, let's discuss!

kerem commented

2026-03-14 05:47:09 +03:00

Author

Owner

@NiceGuyIT commented on GitHub (Apr 18, 2023):

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 commented on GitHub (Apr 18, 2023): 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. ![image](https://user-images.githubusercontent.com/7763429/232883014-00fc2670-65e4-4c0e-93b2-edf8436520e1.png) Automation Manager >Checks was updated. ![image](https://user-images.githubusercontent.com/7763429/232883174-52898c01-cdef-470e-878b-9f873c7185bf.png) 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. ![image](https://user-images.githubusercontent.com/7763429/232883447-1692c9ef-4c98-4824-8c29-740bff3b1629.png) Agent > Checks was updated. ![image](https://user-images.githubusercontent.com/7763429/232883775-83e0291a-aed1-44c7-a5ae-780de8c72b88.png) 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.

kerem commented

2026-03-14 05:47:14 +03:00

Author

Owner

@NiceGuyIT commented on GitHub (Apr 18, 2023):

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.

@NiceGuyIT commented on GitHub (Apr 18, 2023): 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.

kerem commented

2026-03-14 05:47:20 +03:00

Author

Owner

@silversword411 commented on GitHub (Apr 18, 2023):

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 commented on GitHub (Apr 18, 2023): 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.

kerem commented

2026-03-14 05:47:25 +03:00

Author

Owner

@silversword411 commented on GitHub (Aug 30, 2023):

@silversword411 commented on GitHub (Aug 30, 2023): Related: https://github.com/amidaware/tacticalrmm/issues/1489

kerem commented

2026-03-14 05:47:30 +03:00

Author

Owner

@silversword411 commented on GitHub (Aug 30, 2023):

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:

Update the name: field in the .json to start with zzDEPRECATED
Update the filename: field in the .json to start with zzDEPRECATED_
Update the description: field in the .json. Include notes/URLs as appropriate.
Update the category: field to DEPRECATED
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.

@silversword411 commented on GitHub (Aug 30, 2023): 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.

kerem commented

2026-03-14 05:47:35 +03:00

Author

Owner

@dinger1986 commented on GitHub (Aug 30, 2023):

Sounds perfect to me

@dinger1986 commented on GitHub (Aug 30, 2023): Sounds perfect to me

kerem commented

2026-03-14 05:47:40 +03:00

Author

Owner

@NiceGuyIT commented on GitHub (Jul 20, 2025):

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.

To expand on this, adding a standard header to the files may help. If the file is coming from another system, like another git repo, having (duplicating) the fields in a header at the top of the script will help make the scripting system play nice with other systems.

Adding a version to the JSON or header will help, even if the version is a commit hash. Exporting the scripts will retain the version and help with the overall life cycle of the script.

As Tactical matures, versioning the community-scripts repo to match a tacticalrmm version makes sense. The community scripts are not versioned and the Tactical update process uses git pull to update the scripts from main before importing.

@NiceGuyIT commented on GitHub (Jul 20, 2025): > 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. To expand on this, adding a standard header to the files may help. If the file is coming from another system, like [another git repo][1], having (duplicating) the fields in a header at the top of the script will help make the scripting system play nice with other systems. Adding a version to the JSON or header will help, even if the version is a commit hash. Exporting the scripts will retain the version and help with the overall life cycle of the script. As Tactical matures, versioning the [community-scripts][2] repo to match a [tacticalrmm][3] version makes sense. The community scripts are not versioned and the Tactical update process uses [git pull][4] to update the scripts from main before importing. [1]: https://github.com/amidaware/tacticalrmm/issues/1206 [2]: https://github.com/amidaware/community-scripts [3]: https://github.com/amidaware/tacticalrmm [4]: https://github.com/amidaware/tacticalrmm/blob/cb1fe96b4bf71b753eba490e0b2c0edc2581d603/update.sh#L398

Rows
Columns

[GH-ISSUE #1486] Feature Request: Provide a sane path for life cycle of community scripts #2874