as per the documentation, 3 parameters are passed to the script. that includes message subject & body, where you can use various variables (or just hardcode strings).
does that help with your usecase ?

https://www.zabbix.com/documentation/2.2/manual/config/notifications/media/script

Thanks for your reply richlv. Yes I'm aware of the three default parameters passed to the alert script.
Unfortunately this does not offer us the flexibility to include additional arguments (in our case for an incident record; assignment group, incident priority, service, hostname, CI#, etc).

As you state, we can hard code this into the body of the alert and have our script strip them out, but we will have a large number of users who should not have to ensure the syntactical integrity of their alert message bodies.

With what I consider a small change, we could then define a script as 'my_script.pl --priority 3 --assignee Wintel' and prevent these extra variables being required in the message body. This way they are managed and provisioned to end users by the Zabbix app team here.

As a workaround, we are currently creating 'wrapper' scripts which require only the three default arguments but call our incident script with the additional required parameters. Pretty messy!

Specifications at https://www.zabbix.org/wiki/Docs/specs/ZBXNEXT-2163

(1) [S] Database patch created in development branch svn://svn.zabbix.com/branches/dev/ZBXNEXT-2163 r55410, r55412
RESOLVED

<dimir> The spec says

A database patch must be added to set exec_params field to {ALERT.SENDTO}\n{ALERT.SUBJECT}\n{ALERT.MESSAGE}\n for the existing Script media types.

however this part seems to be missing.

REOPENED

wiper RESOLVED in r55662

<dimir> Please review my changes in r55671.

wiper Thanks, CLOSED

(2) [S] Server side support for alert macros and custom parameters for script media type.
RESOLVED in r55414

<dimir> Compilation errors:

[...]
discoverer.c:263:35: note: in expansion of macro ‘MACRO_TYPE_COMMON’
         &item.snmpv3_contextname, MACRO_TYPE_COMMON, NULL, 0);
                                   ^
../../../include/zbxserver.h:53:5: note: expected ‘char **’ but argument is of type ‘int’
 int substitute_simple_macros(zbx_uint64_t *actionid, const DB_EVENT *event, DB_EVENT *r_event, zbx_uint64_t *userid,
     ^
discoverer.c:263:54: warning: passing argument 11 of ‘substitute_simple_macros’ makes integer from pointer without a cast
         &item.snmpv3_contextname, MACRO_TYPE_COMMON, NULL, 0);
                                                      ^
In file included from discoverer.c:27:0:
../../../include/zbxserver.h:53:5: note: expected ‘int’ but argument is of type ‘void *’
 int substitute_simple_macros(zbx_uint64_t *actionid, const DB_EVENT *event, DB_EVENT *r_event, zbx_uint64_t *userid,
     ^
discoverer.c:262:7: error: too few arguments to function ‘substitute_simple_macros’
       substitute_simple_macros(NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL,
       ^
In file included from discoverer.c:27:0:
../../../include/zbxserver.h:53:5: note: declared here
 int substitute_simple_macros(zbx_uint64_t *actionid, const DB_EVENT *event, DB_EVENT *r_event, zbx_uint64_t *userid,
     ^
make[3]: *** [discoverer.o] Error 1 
make[2]: *** [install-recursive] Error 1
make[1]: *** [install-recursive] Error 1
make: *** [install-recursive] Error 1

REOPENED

wiper RESOLVED in r55638

<dimir> Looks good. Please review my small change in r55650.

wiper Thanks, CLOSED

(3) [F] Custom parameter support for Script media type in frontend.

iivs RESOLVED in svn://svn.zabbix.com/branches/dev/ZBXNEXT-2163 r55715, r55724, r55732

oleg.egorov CLOSED

ZBXNEXT-2047 appears related to me. Couldn't you make a new kind of macro that holds them all and pass that as an argument?

(4) Removed translation strings:

• Wrong fields for media type.
• Incorrect media type port "%1$s" provided.
• Password required for media type.

Added translation strings:

• Script parameters
• Media type is missing parameters: %1$s
• Incorrect value "%1$s" in field "%2$s" for media type "%3$s".
• Field "%1$s" is required for media type "%2$s".
• Field "%1$s" is missing a value for media type "%2$s".
• Duplicate "description" value "%1$s" for media type.
• No "%1$s" given for media type.
• Empty media type ID.
• Incorrect media type ID.
• Script parameters "%1$s" are missing the last new line feed for media type "%2$s".
• Password required for media type "%1$s".

oleg.egorov CLOSED

<richlv> looks like there was one more translation string change :

• removed "Password required for media type."
• added "Password required for media type \"%1$s\"."
  was this intended ?
  REOPENED

iivs Sorry, forgot to mention this change. RESOLVED

<richlv> thanks, CLOSED

I really like the new specification defined here, but I'm concerned it doesn't actually address the issue I've described. The root issue is that if I want to pass arguments to my script, completely unrelated to zabbix (maybe a verbose switch or a log file path, e.g. `script.pl -v --log=/some/log [recipient] [subject] [body]`), then the action will fail with "file not found".

Can I use the new spec to solve this problem by simply pass a command argument as a new "script parameter"?? E.g.:

param 1: -v
param 2: --log=/some/log
param 3: {$ALERT.SENDTO}
...

yes, passing such extra parameters is explicitly supported. but please do test the development branch and provide feedback here or on irc

Thanks richlv, unfortunately I can't access SVN behind the firewall at work to test, but I'll take a look ASAP.

(5) [F] Description validation issue:
mediatype.update

[
    {
        "mediatypeid": "1",
        "description": "SMS"
    },
    {
        "mediatypeid": "2"
    }
]

SQL statement execution has failed \"UPDATE media_type SET  description='SMS' WHERE mediatypeid='1'\".

Other issue for mediatype.create

[
    {
        "description": "E-mail2",
        "type": 0,
        "smtp_server": "[email protected]",
        "smtp_helo": "company.com",
        "smtp_email": "[email protected]"
    },
    {
        "description": "E-mail2",
        "type": 0,
        "smtp_server": "[email protected]",
        "smtp_helo": "company.com",
        "smtp_email": "[email protected]"
    }
]

SQL statement execution has failed \"INSERT INTO media_type (description,type,smtp_server,smtp_helo,smtp_email,mediatypeid) VALUES ('E-mail2','0','[email protected]','company.com','[email protected]','6')\".

iivs RESOLVED in r55900

oleg.egorov In DB
mediatypeid = 3 and description = SMS
mediatypeid = 9 and description = Email

mediatype.update
[
    {
        "mediatypeid": "3",
        "description": "SMS2"
    },
    {
        "mediatypeid": "9",
        "description": "SMS2"
    }
]

Result:

SQL statement execution has failed \"UPDATE media_type SET  description='SMS2' WHERE mediatypeid='9'\".

iivs RESOLVED in r55920

oleg.egorov CLOSED

(6) [F] Update with empty script parameters

Undefined index: exec_params [zabbix.php:21 → require_once() → ZBase->run() → ZBase->processRequest() → CController->run() → CControllerMediatypeUpdate->doAction() → CController->getInput() in include\classes\mvc\CController.php:197]
implode(): Invalid arguments passed [zabbix.php:21 → require_once() → ZBase->run() → ZBase->processRequest() → CController->run() → CControllerMediatypeUpdate->doAction() → implode() in app\controllers\CControllerMediatypeUpdate.php:100]
Field "exec_path" is missing a value for media type "E-mail".

iivs RESOLVED in r55903

oleg.egorov CLOSED

(7) [F] Based on documentation: https://www.zabbix.org/wiki/Docs/specs/ZBXNEXT-2163

...The last parameter must also have newline character at the end.

Now missed newline after last parameter.

Discussed addition changes:

• Interface. As default "Script parameters" is empty(zero rows);
• Explode by "\n", but use count - 1 to display parameters.

iivs Added newline to the last parameter RESOLVED in r55903
But this should be discussed, if actually newline is needed. Newline is just a separator between parameters and we can use implode() and explode(). Now we always have to remove last newline. Since API does not validate string, either API should validate last newline or server should remove this restriction.

iivs Discussed with sasha and wiper and decided to add exec_params validation in API to check the last new line feed. RESOLVED in r55927

oleg.egorov CLOSED

(8) [F] Please review my minor coding style improvement r55875

iivs Thanks. Similar minor coding style fix provided in r55893. Trunk conflicts resolved in r55894. Please, review.

oleg.egorov CLOSED

Will this be released in v2.x or only in v3?

3.0 only.

Server side successfully tested.

Frontend side successfully tested.

Implemented in pre-3.0.0alpha3 (trunk) r55951

(9) Documentation

API documentation updated:
https://www.zabbix.com/documentation/3.0/manual/api/changes_2.4_-_3.0
https://www.zabbix.com/documentation/3.0/manual/api/reference/mediatype/object

martins-v Reviewed, with a small word order change.

Also updated:

• https://www.zabbix.com/documentation/3.0/manual/config/notifications/media/script
• https://www.zabbix.com/documentation/3.0/manual/appendix/macros/supported_by_location
• https://www.zabbix.com/documentation/3.0/manual/introduction/whatsnew300#custom_parameter_support_for_alert_scripts

Please review.

iivs Thanks! Looks good to me.
CLOSED

wiper Agreed

"Add command-line parameters to the script.
{ALERT.SENDTO}, {ALERT.SUBJECT} and {ALERT.MESSAGE} macros are supported in script parameters.
Customizing script parameters is supported since Zabbix 3.0."

I have a request, why not enable the trigger macros to expand here as well? As now this adds some flexiblity. But having the possibilty to pass
{TRIGGER.STATUS}
{TRIGGER.DESCRITPION}
etc would be REAL nice.

Today we send the messages a json, and the script parses that json to extract the needed values. However
one of the things we are trying to achive is to make it quick to update the text sent to our oncall.
This is done by using the trigger description field, But if anyone inserts any character that trips up the json parsing the alertscript fails.

So being able to put every needed part in as a seperate parameter would be nice.

for the record, other macro/variable support tracked in ZBXNEXT-3185

this made creating alertscript notably more complicated - ZBXNEXT-3243 asks to supply a few params by default

Related bug: ZBX-12693.