[Check_mk (english)] 1.5.0p5: Custom notification: missing parameters

Hi list,
I’ve encountered a problem with a notification script which I use. This script works in version 1.2.8p20, but it shows an error in 1.5.0p5.
I get an error on some variables, they fail with KeyError: ‘PARAMETER_xxxxxxxx’.

2018-10-08 14:13:05 * notifying via , parameters: field6, field5key,
field1key , errorid, processid, field2key, field4key, checkmaintenance, field2, field3, field1, field2content, field1content, field4, field5, field4content, field3content, concerningprocess, field5content, field6content, checkaffectedmonitoringstate,
field6key, field3key, bulk: no

I’ve got this in /local/share/check_mk/web/plugins/wato/notifications.py (just the part related to this field):

        ( "field1key",

ListChoice(

title = _(“Field 1 is key field”),

choices = [

( “yes”, _(“Yes”) ),

],

default_value = “yes”,

)

),

I did a ‘print context’ and there is no PARAMETER_FIELD1KEY in context (it just doesn’t exist) so this explains the error.
What I did find in context, was ‘PARAMETER_FIELD5KEYS’: u’’, ‘PARAMETER_FIELD1KEY_1’: u’yes’.
Note the extra ‘S’ at FIELD5KEY and the extra ‘_1’ after FIELD1KEY.

Is this a bug / did I screw up my notifications.py / other?
Can anyone put me on the right track?

Met vriendelijke groeten / Kind regards / Mit freundlichen Grüßen,

Arno Wijnhoven

This looks like a bug to me. The variable names are wrong in os.environ.items.
I suppose Check_MK puts them there using the notification script.

Currently I’m printing the environment variables to notify.log.

The issue only seems to happen with the CheckBox (ListChoice) option.
Even more strange, some parameters exist multiple times (both have wrong names though).

2018-10-09 08:59:17 Output: NOTIFY_PARAMETER_FIELD1KEYS yes
2018-10-09 08:59:17 Output: NOTIFY_PARAMETER_FIELD1KEY_1 yes

···

Should be ‘NOTIFY_PARAMETER_FIELD1KEY’ (you can see in my last mail how I defined this parameter).

Can anyone confirm this is a bug or am I looking in the wrong place?
I’m phasing out the ‘ListChoice’ option for now. I’ll change it to a DropdownChoice with yes/no, my guess is this will solve my issue.

Still, this shouldn’t be necessary.

Arno Wijnhoven

From: checkmk-en [mailto:checkmk-en-bounces@lists.mathias-kettner.de]
On Behalf Of Arno Wijnhoven
Sent: maandag 8 oktober 2018 14:32
To: checkmk-en@lists.mathias-kettner.de
Subject: [Check_mk (english)] 1.5.0p5: Custom notification: missing parameters

Hi list,
I’ve encountered a problem with a notification script which I use. This script works in version 1.2.8p20, but it shows an error in 1.5.0p5.
I get an error on some variables, they fail with KeyError: ‘PARAMETER_xxxxxxxx’.

2018-10-08 14:13:05 * notifying via , parameters: field6, field5key,
field1key , errorid, processid, field2key, field4key, checkmaintenance, field2, field3, field1, field2content, field1content, field4, field5, field4content, field3content, concerningprocess, field5content, field6content, checkaffectedmonitoringstate,
field6key, field3key, bulk: no

I’ve got this in /local/share/check_mk/web/plugins/wato/notifications.py (just the part related to this field):

        ( "field1key",

ListChoice(

title = _(“Field 1 is key field”),

choices = [

( “yes”, _(“Yes”) ),

],

default_value = “yes”,

)

),

I did a ‘print context’ and there is no PARAMETER_FIELD1KEY in context (it just doesn’t exist) so this explains the error.
What I did find in context, was ‘PARAMETER_FIELD5KEYS’: u’’, ‘PARAMETER_FIELD1KEY_1’: u’yes’.
Note the extra ‘S’ at FIELD5KEY and the extra ‘_1’ after FIELD1KEY.

Is this a bug / did I screw up my notifications.py / other?
Can anyone put me on the right track?

Met vriendelijke groeten / Kind regards / Mit freundlichen Grüßen,

Arno Wijnhoven

Changing all ListChoices to DropdownChoices in ‘notifications.py’ works for me, no more errors.
Obviously I need to adjust all notification rules, but since I only need to set ‘yes’ or ‘no’ values, this isn’t much work.

···

Arno Wijnhoven

From: Arno Wijnhoven
Sent: dinsdag 9 oktober 2018 09:33
To: Arno Wijnhoven arnow@vsnsystemen.nl; checkmk-en@lists.mathias-kettner.de
Subject: RE: 1.5.0p5: Custom notification: missing parameters

This looks like a bug to me. The variable names are wrong in os.environ.items.
I suppose Check_MK puts them there using the notification script.

Currently I’m printing the environment variables to notify.log.

The issue only seems to happen with the CheckBox (ListChoice) option.
Even more strange, some parameters exist multiple times (both have wrong names though).

2018-10-09 08:59:17 Output: NOTIFY_PARAMETER_FIELD1KEYS yes
2018-10-09 08:59:17 Output: NOTIFY_PARAMETER_FIELD1KEY_1 yes

Should be ‘NOTIFY_PARAMETER_FIELD1KEY’ (you can see in my last mail how I defined this parameter).

Can anyone confirm this is a bug or am I looking in the wrong place?
I’m phasing out the ‘ListChoice’ option for now. I’ll change it to a DropdownChoice with yes/no, my guess is this will solve my issue.

Still, this shouldn’t be necessary.

Arno Wijnhoven

From: checkmk-en [mailto:checkmk-en-bounces@lists.mathias-kettner.de]
On Behalf Of Arno Wijnhoven
Sent: maandag 8 oktober 2018 14:32
To: checkmk-en@lists.mathias-kettner.de
Subject: [Check_mk (english)] 1.5.0p5: Custom notification: missing parameters

Hi list,
I’ve encountered a problem with a notification script which I use. This script works in version 1.2.8p20, but it shows an error in 1.5.0p5.
I get an error on some variables, they fail with KeyError: ‘PARAMETER_xxxxxxxx’.

2018-10-08 14:13:05 * notifying via , parameters: field6, field5key,
field1key , errorid, processid, field2key, field4key, checkmaintenance, field2, field3, field1, field2content, field1content, field4, field5, field4content, field3content, concerningprocess, field5content, field6content, checkaffectedmonitoringstate,
field6key, field3key, bulk: no

I’ve got this in /local/share/check_mk/web/plugins/wato/notifications.py (just the part related to this field):

        ( "field1key",

ListChoice(

title = _(“Field 1 is key field”),

choices = [

( “yes”, _(“Yes”) ),

],

default_value = “yes”,

)

),

I did a ‘print context’ and there is no PARAMETER_FIELD1KEY in context (it just doesn’t exist) so this explains the error.
What I did find in context, was ‘PARAMETER_FIELD5KEYS’: u’’, ‘PARAMETER_FIELD1KEY_1’: u’yes’.
Note the extra ‘S’ at FIELD5KEY and the extra ‘_1’ after FIELD1KEY.

Is this a bug / did I screw up my notifications.py / other?
Can anyone put me on the right track?

Met vriendelijke groeten / Kind regards / Mit freundlichen Grüßen,

Arno Wijnhoven