User-defined variables are not replaced when Global Variables are used

[lincoln123lin]

Describe the bug
User-defined variables are not populated when global variables are used in the ability execution inside an operation.

To Reproduce
Steps to reproduce the behavior:

1. Create a new operation
2. Launch any ability with global variables #{origin_link_id} and #{server} and some user-defined variables. Give values to all the user-defined abilities and leave the global variables empty
3. Observe the output command

Expected behavior
The command has an obfuscated and a plaintext version of the commands, with the command in obfuscated having the origin_link_id but the plaintext does not. The user-defined abilities are not defined in both cases.

Screenshots

Desktop (please complete the following information):

• OS: Windows (Caldera server running on Ubuntu)
• Browser: Firefox
• Version: 5.0.0

Additional context
In my screenshot, I am running my own custom ability. But the best default ability that fits this bug scenario is "Service Creation". The only user-defined ability is #{remote.host.fqdn} so recommended to modify it to add additional variables to make the reproduction realistic.

[github-actions]

Looks like your first issue -- we aim to respond to issues as quickly as possible. In the meantime, check out our documentation here: http://caldera.readthedocs.io/

[d3vco]

This issue is related to another issue (or inconvenience, maybe?) - if values aren't supplied for all fact templates in an ability, then none of the values are substituted in. Depending on when/how the global facts are inserted, both of these issues could have the same solution.

I suggest that the default behavior should be: any provided values should be substituted for the relevant fact template, regardless if values have been provided for all fact templates.

To Reproduce Related Issue:

1. In a new operation, open "Add Potential Link".
2. Select the "Fingerprint network services" ability.
3. Modify the command by removing -p #{remote.host.port} (final command should read nmap -sV #{remote.host.ip}).
4. Type in a value for remote.host.ip. Leave remote.host.port blank / don't select a value.
5. Add potential link.
6. Note that the IP value you entered does not get substituted into the command. The executed command will be nmap -sV #{remote.host.ip} and the link will fail.

[lincoln123lin]

Right now, the only way to work with this 'inconvenience' is to supply all the related global variables with a value when executing the ability in an operation. E.g. for the variable #{server} you will give a value of "http://<server address>:8888" instead of leaving it blank.

However, if we are to use the #{origin_link_id} for lateral movement, the link id is generated on-the-fly, and we won't know the link_id beforehand. So we won't be able to supply a value for it.

P.S. realise the issue is lying on the frontend of the operations page. Sending a POST request to Caldera via curl/request does not have any such issues.

[elegantmoose]

Yikes, yea this an annoying 'inconvenience'. Looking at PR on magma repo from @d3vco now.

[elegantmoose]

merged @d3vco's fix.

Reopen if still having problems.