[GH-ISSUE #1992] Feature Request - Add dynamic variables for Scripts #3192

New issue

Closed

opened 2026-03-14 06:49:30 +03:00 by kerem · 6 comments

kerem commented 2026-03-14 06:49:30 +03:00

Owner

Copy link

Originally created by @InfraCharm on GitHub (Aug 31, 2024).
Original GitHub issue: https://github.com/amidaware/tacticalrmm/issues/1992

Is your feature request related to a problem? Please describe.
No. This is something I'd like to see so we can drop another piece of software we use in our stack.

Describe the solution you'd like
When setting up scripts, allow admins to set script argument or environment variable fields to be filled in when the script is ran from the RMM.

This feature would add more configurable options to script functionality in the RMM. An example is if you wanted to do a "Ping" script on Linux, you would add the "target" variable under dynamic variables and select if it's a script argument or environment variable. You would then right click the client and select "Run Script" and select the script as normal - but another screen shows up before the script runs asking you to fill in the "target" variable before the script is sent to the client for execution. This is best for configurations where things may change or you need to enter a license key - etc;

The variables should be able to be re-ordered or atleast configured to be in a specific order for script arguments.

Describe alternatives you've considered
We currently use script-server (https://github.com/bugy/script-server/) for similar functionality - would be cool if it was built into the panel and we can stop running extra software!

Additional context
Feel free to ask questions!

Originally created by @InfraCharm on GitHub (Aug 31, 2024). Original GitHub issue: https://github.com/amidaware/tacticalrmm/issues/1992 **Is your feature request related to a problem? Please describe.** No. This is something I'd like to see so we can drop another piece of software we use in our stack. **Describe the solution you'd like** When setting up scripts, allow admins to set script argument or environment variable fields to be filled in when the script is ran from the RMM. This feature would add more configurable options to script functionality in the RMM. An example is if you wanted to do a "Ping" script on Linux, you would add the "target" variable under dynamic variables and select if it's a script argument or environment variable. You would then right click the client and select "Run Script" and select the script as normal - but another screen shows up before the script runs asking you to fill in the "target" variable before the script is sent to the client for execution. This is best for configurations where things may change or you need to enter a license key - etc; The variables should be able to be re-ordered or atleast configured to be in a specific order for script arguments. **Describe alternatives you've considered** We currently use script-server (https://github.com/bugy/script-server/) for similar functionality - would be cool if it was built into the panel and we can stop running extra software! **Additional context** Feel free to ask questions!

kerem closed this issue 2026-03-14 06:49:35 +03:00

kerem commented 2026-03-14 06:49:41 +03:00

Author

Owner

Copy link

@ZzBombardierzZ commented on GitHub (Aug 31, 2024):

If I'm understanding correctly, I don't see the point or need of what you're asking for. Just use the "Run script" menu as it is and you can fill out the env variables or the script variables before you click run.

Alternatively, if you mean a dynamic/unique variable that goes to each agent (like agent 1 gets IP 8.8.8.8 but agent 2 should get 1.1.1.1), then use agent custom variables and then feed the {{agent.foobar}} into the script variable or env variable field.

If you need help making this work, Discord is very helpful. Please let me know if I'm way off here and misunderstood something.

<!-- gh-comment-id:2322946683 --> @ZzBombardierzZ commented on GitHub (Aug 31, 2024): If I'm understanding correctly, I don't see the point or need of what you're asking for. Just use the "Run script" menu as it is and you can fill out the env variables or the script variables before you click run. Alternatively, if you mean a dynamic/unique variable that goes to each agent (like agent 1 gets IP 8.8.8.8 but agent 2 should get 1.1.1.1), then use agent custom variables and then feed the {{agent.foobar}} into the script variable or env variable field. If you need help making this work, Discord is very helpful. Please let me know if I'm way off here and misunderstood something.

kerem commented 2026-03-14 06:49:46 +03:00

Author

Owner

Copy link

@wh1te909 commented on GitHub (Aug 31, 2024):

this feature already exists, you can pass data to script via arguments or env vars. documentation here with video examples: https://docs.tacticalrmm.com/functions/scripting/

<!-- gh-comment-id:2323048369 --> @wh1te909 commented on GitHub (Aug 31, 2024): this feature already exists, you can pass data to script via arguments or env vars. documentation here with video examples: https://docs.tacticalrmm.com/functions/scripting/

kerem commented 2026-03-14 06:49:51 +03:00

Author

Owner

Copy link

@InfraCharm commented on GitHub (Aug 31, 2024):

If I'm understanding correctly, I don't see the point or need of what you're asking for. Just use the "Run script" menu as it is and you can fill out the env variables or the script variables before you click run.

Alternatively, if you mean a dynamic/unique variable that goes to each agent (like agent 1 gets IP 8.8.8.8 but agent 2 should get 1.1.1.1), then use agent custom variables and then feed the {{agent.foobar}} into the script variable or env variable field.

If you need help making this work, Discord is very helpful. Please let me know if I'm way off here and misunderstood something.

I think I might be lost here @ZzBombardierzZ. I'm trying to streamline the script process for my employees. Not all employees will know which script arguments go where and what the value should pertain to.

This would create custom fields in the script process essentially, prompting the person running the script to fill them out. This means there is less room for error.

Some scripts we run need 5-10 different arguments, keeping track of those with the way the RMM is a pain.

Quick Mockup:

<!-- gh-comment-id:2323049290 --> @InfraCharm commented on GitHub (Aug 31, 2024): > If I'm understanding correctly, I don't see the point or need of what you're asking for. Just use the "Run script" menu as it is and you can fill out the env variables or the script variables before you click run. > > Alternatively, if you mean a dynamic/unique variable that goes to each agent (like agent 1 gets IP 8.8.8.8 but agent 2 should get 1.1.1.1), then use agent custom variables and then feed the {{agent.foobar}} into the script variable or env variable field. > > If you need help making this work, Discord is very helpful. Please let me know if I'm way off here and misunderstood something. I think I might be lost here @ZzBombardierzZ. I'm trying to streamline the script process for my employees. Not all employees will know which script arguments go where and what the value should pertain to. This would create custom fields in the script process essentially, prompting the person running the script to fill them out. This means there is less room for error. Some scripts we run need 5-10 different arguments, keeping track of those with the way the RMM is a pain. Quick Mockup: 

kerem commented 2026-03-14 06:49:56 +03:00

Author

Owner

Copy link

@InfraCharm commented on GitHub (Aug 31, 2024):

this feature already exists, you can pass data to script via arguments or env vars. documentation here with video examples: https://docs.tacticalrmm.com/functions/scripting/

Please review my last comment.

<!-- gh-comment-id:2323060645 --> @InfraCharm commented on GitHub (Aug 31, 2024): > this feature already exists, you can pass data to script via arguments or env vars. documentation here with video examples: https://docs.tacticalrmm.com/functions/scripting/ Please review my last comment.

kerem commented 2026-03-14 06:50:01 +03:00

Author

Owner

Copy link

@ZzBombardierzZ commented on GitHub (Sep 1, 2024):

If I'm understanding correctly, I don't see the point or need of what you're asking for. Just use the "Run script" menu as it is and you can fill out the env variables or the script variables before you click run.

Alternatively, if you mean a dynamic/unique variable that goes to each agent (like agent 1 gets IP 8.8.8.8 but agent 2 should get 1.1.1.1), then use agent custom variables and then feed the {{agent.foobar}} into the script variable or env variable field.

If you need help making this work, Discord is very helpful. Please let me know if I'm way off here and misunderstood something.

I think I might be lost here @ZzBombardierzZ. I'm trying to streamline the script process for my employees. Not all employees will know which script arguments go where and what the value should pertain to.

This would create custom fields in the script process essentially, prompting the person running the script to fill them out. This means there is less room for error.

Some scripts we run need 5-10 different arguments, keeping track of those with the way the RMM is a pain.

Quick Mockup:

I agree that something to pop-up after clicking run script or after you choose the script to help you fill out "required" variables would make running scripts much easier for a general employee, with emphasis on "required". Not sure how it would look to implement such a thing, but it could display the required input variables into a list as you're showing.

However, I still don't see how that is a dynamic variable or what you mean exactly with that.

What I imagine you're trying to do with "dynamic variables" -and correct me if I'm still misunderstanding- is to have it use a specific value for each agent you try to run it on. If that is the intended goal, then using agent variables that are prefilled or with a default value that you can modify for any special cases may be easier for you.

Again, I may be totally misunderstanding, so if you can be more specific on what your end goal is that may help to see if there's a way to get to your goal without necessarily adding the variable menu example in the image.

<!-- gh-comment-id:2323092028 --> @ZzBombardierzZ commented on GitHub (Sep 1, 2024): > > If I'm understanding correctly, I don't see the point or need of what you're asking for. Just use the "Run script" menu as it is and you can fill out the env variables or the script variables before you click run. > > > > > > Alternatively, if you mean a dynamic/unique variable that goes to each agent (like agent 1 gets IP 8.8.8.8 but agent 2 should get 1.1.1.1), then use agent custom variables and then feed the {{agent.foobar}} into the script variable or env variable field. > > > > > > If you need help making this work, Discord is very helpful. Please let me know if I'm way off here and misunderstood something. > > > > I think I might be lost here @ZzBombardierzZ. I'm trying to streamline the script process for my employees. Not all employees will know which script arguments go where and what the value should pertain to. > > > > This would create custom fields in the script process essentially, prompting the person running the script to fill them out. This means there is less room for error. > > > > Some scripts we run need 5-10 different arguments, keeping track of those with the way the RMM is a pain. > > > > Quick Mockup: > >  > > > > I agree that something to pop-up after clicking run script or after you choose the script to help you fill out "required" variables would make running scripts much easier for a general employee, with emphasis on "required". Not sure how it would look to implement such a thing, but it could display the required input variables into a list as you're showing. However, I still don't see how that is a dynamic variable or what you mean exactly with that. What I imagine you're trying to do with "dynamic variables" -and correct me if I'm still misunderstanding- is to have it use a specific value for each agent you try to run it on. If that is the intended goal, then using agent variables that are prefilled or with a default value that you can modify for any special cases may be easier for you. Again, I may be totally misunderstanding, so if you can be more specific on what your end goal is that may help to see if there's a way to get to your goal without necessarily adding the variable menu example in the image.

kerem commented 2026-03-14 06:50:06 +03:00

Author

Owner

Copy link

@InfraCharm commented on GitHub (Sep 1, 2024):

If I'm understanding correctly, I don't see the point or need of what you're asking for. Just use the "Run script" menu as it is and you can fill out the env variables or the script variables before you click run.

Alternatively, if you mean a dynamic/unique variable that goes to each agent (like agent 1 gets IP 8.8.8.8 but agent 2 should get 1.1.1.1), then use agent custom variables and then feed the {{agent.foobar}} into the script variable or env variable field.

If you need help making this work, Discord is very helpful. Please let me know if I'm way off here and misunderstood something.

I think I might be lost here @ZzBombardierzZ. I'm trying to streamline the script process for my employees. Not all employees will know which script arguments go where and what the value should pertain to.
This would create custom fields in the script process essentially, prompting the person running the script to fill them out. This means there is less room for error.
Some scripts we run need 5-10 different arguments, keeping track of those with the way the RMM is a pain.
Quick Mockup:

I agree that something to pop-up after clicking run script or after you choose the script to help you fill out "required" variables would make running scripts much easier for a general employee, with emphasis on "required". Not sure how it would look to implement such a thing, but it could display the required input variables into a list as you're showing.

However, I still don't see how that is a dynamic variable or what you mean exactly with that.

What I imagine you're trying to do with "dynamic variables" -and correct me if I'm still misunderstanding- is to have it use a specific value for each agent you try to run it on. If that is the intended goal, then using agent variables that are prefilled or with a default value that you can modify for any special cases may be easier for you.

Again, I may be totally misunderstanding, so if you can be more specific on what your end goal is that may help to see if there's a way to get to your goal without necessarily adding the variable menu example in the image.

I'm simply looking for a way to make custom fields for script arguments and environment variables, These would go in as the input for a script, not to be confused with custom fields when a script is finished running.

These aren't specific for each client, site, or agent - they are "dynamic" on runtime. This prompt in my photo would come up when actually preparing to run the script and get data for the script arguments in that example.

We already have a solution that works for this, as stated in a previous comment - I just wanted to see if we can get the same functionality in TRMM so we can drop more software from our stack.

@ZzBombardierzZ

<!-- gh-comment-id:2323101834 --> @InfraCharm commented on GitHub (Sep 1, 2024): > > > If I'm understanding correctly, I don't see the point or need of what you're asking for. Just use the "Run script" menu as it is and you can fill out the env variables or the script variables before you click run. > > > > > > > > > > > > > > Alternatively, if you mean a dynamic/unique variable that goes to each agent (like agent 1 gets IP 8.8.8.8 but agent 2 should get 1.1.1.1), then use agent custom variables and then feed the {{agent.foobar}} into the script variable or env variable field. > > > > > > > > > > > > > > If you need help making this work, Discord is very helpful. Please let me know if I'm way off here and misunderstood something. > > > > > > I think I might be lost here @ZzBombardierzZ. I'm trying to streamline the script process for my employees. Not all employees will know which script arguments go where and what the value should pertain to. > > This would create custom fields in the script process essentially, prompting the person running the script to fill them out. This means there is less room for error. > > Some scripts we run need 5-10 different arguments, keeping track of those with the way the RMM is a pain. > > Quick Mockup: > >  > > I agree that something to pop-up after clicking run script or after you choose the script to help you fill out "required" variables would make running scripts much easier for a general employee, with emphasis on "required". Not sure how it would look to implement such a thing, but it could display the required input variables into a list as you're showing. > > However, I still don't see how that is a dynamic variable or what you mean exactly with that. > > What I imagine you're trying to do with "dynamic variables" -and correct me if I'm still misunderstanding- is to have it use a specific value for each agent you try to run it on. If that is the intended goal, then using agent variables that are prefilled or with a default value that you can modify for any special cases may be easier for you. > > Again, I may be totally misunderstanding, so if you can be more specific on what your end goal is that may help to see if there's a way to get to your goal without necessarily adding the variable menu example in the image. I'm simply looking for a way to make custom fields for script arguments and environment variables, These would go in as the input for a script, not to be confused with custom fields when a script is finished running. These aren't specific for each client, site, or agent - they are "dynamic" on runtime. This prompt in my photo would come up when actually preparing to run the script and get data for the script arguments in that example. We already have a solution that works for this, as stated in a previous comment - I just wanted to see if we can get the same functionality in TRMM so we can drop more software from our stack. @ZzBombardierzZ

Sign in to join this conversation.

No Branch/Tag specified

Branches Tags

develop

master

1.0.0

v1.4.0

v1.3.1

v1.3.0

v1.2.0

v1.1.0

v1.0.0

v0.20.1

v0.20.0

v0.19.4

v0.19.3

v0.19.2

v0.19.1

v0.19.0

v0.18.2

v0.18.1

v0.18.0

v0.17.5

v0.17.4

v0.17.3

v0.17.2

v0.17.1

v0.17.0

v0.16.5

v0.16.4

v0.16.3

v0.16.2

v0.16.1

v0.16.0

v0.15.12

v0.15.11

v0.15.10

v0.15.9

v0.15.8

v0.15.7

v0.15.6

v0.15.5

v0.15.4

v0.15.3

v0.15.2

v0.15.1

v0.15.0

v0.14.8

v0.14.7

v0.14.6

v0.14.5

v0.14.4

v0.14.3

v0.14.2

v0.14.1

v0.14.0

v0.13.4

v0.13.3

v0.13.2

v0.13.1

v0.13.0

v0.12.4

v0.12.3

v0.12.2

v0.12.1

v0.12.0

v0.11.3

v0.11.2

v0.11.1

v0.11.0

v0.10.5

v0.10.4

v0.10.3

v0.10.2

v0.10.1

v0.10.0

v0.9.2

v0.9.1

v0.9.0

v0.8.5

v0.8.4

v0.8.3

v0.8.2

v0.8.1

v0.8.0

v0.7.2

v0.7.1

v0.7.0

v0.6.15

v0.6.14

v0.6.13

v0.6.12

v0.6.11

v0.6.10

v0.6.9

v0.6.8

v0.6.7

v0.6.6

v0.6.5

v0.6.4

v0.6.3

v0.6.2

v0.6.1

v0.6.0

v0.5.3

v0.5.2

v0.5.1

v0.5.0

v0.4.32

v0.4.31

v0.4.30

v0.4.29

v0.4.28

v0.4.27

v0.4.26

v0.4.25

v0.4.24

v0.4.23

v0.4.22

v0.4.21

v0.4.20

v0.4.19

v0.4.18

v0.4.17

v0.4.16

v0.4.15

v0.4.14

v0.4.13

v0.4.12

v0.4.11

v0.4.10

v0.4.9

v0.4.8

v0.4.7

v0.4.6

v0.4.5

v0.4.4

v0.4.3

v0.4.2

v0.4.1

v0.4.0

v0.3.3

v0.3.2

v0.3.1

v0.3.0

v0.2.23

v0.2.22

v0.2.21

v0.2.20

v0.2.19

v0.2.18

v0.2.17

v0.2.16

v0.2.15

v0.2.14

v0.2.13

v0.2.12

v0.2.11

v0.2.10

v0.2.9

v0.2.8

v0.2.7

v0.2.6

v0.2.5

v0.2.4

v0.2.3

v0.2.2

v0.2.1

v0.2.0

v0.1.8

v0.1.7

v0.1.6

v0.1.5

v0.1.4

v0.1.3

v0.1.2

v0.1.1

v0.1.0

Labels

Clear labels   

In Process

  

bug

  

bug

  

dev-triage

  

documentation

  

duplicate

  

enhancement

  

fixed

  

good first issue

  

help wanted

  

integration

  

invalid

  

pull-request

Mirrored from GitHub Pull Request

  

question

  

requires agent update

  

security

  

ui tweak

  

wontfix

No labels

In Process

bug

bug

dev-triage

documentation

duplicate

enhancement

fixed

good first issue

help wanted

integration

invalid

pull-request

question

requires agent update

security

ui tweak

wontfix

Milestone

Clear milestone

No items

No milestone

Projects

Clear projects

No items

No project

Assignees

Clear assignees

No assignees

1 participant

Notifications

Subscribe

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference

starred/tacticalrmm#3192

No description provided.