attach() function in actionExecutor for nagios/nagiosxi fails due to permissions error

Issue Summary

Customer reported issue on CentOS 7, with NagiosXI - seems like the issue is present in both DEB and RPM packages and for Nagios and NagiosXI.

attach() function seems to fail due to a permission error in writing the .zip file - not totally clear where it's actually writing it to, but it seems like that's problem - no filepath is specified. 

This is similarly reported in Github:  https://github.com/opsgenie/oec-scripts/issues/72

Steps to Reproduce

Install the Nagios plugin and set up OEC - create an event in Nagios to trigger an alert in OG, and you should see the error.

Expected Results

This function runs as intended and adds an attachment back the parent alert

Actual Results

Function fails and no attachment is added.  Here's the error:

DEBUG[2022-10-24T14:18:36.399951518Z] Current Worker: 4, Idle Worker: 3, Queue Size: 0, Queue load: 0
DEBUG[2022-10-24T14:18:42.25166557Z] Action[Create] execution of message[87f1c816-61c8-433c-920f-caf5148
00dc9] with entityId[ae26d995-542a-461c-8eb0-6e5578edfe50-1666621106293] failed: exit status 1 Stderr: Tracebac
k (most recent call last):
  File "/home/opsgenie/oec/scripts/actionExecutor.py", line 414, in <module>
    main()
  File "/home/opsgenie/oec/scripts/actionExecutor.py", line 363, in main
    attach("service")
  File "/home/opsgenie/oec/scripts/actionExecutor.py", line 270, in attach
    zip_file = zipfile.ZipFile(file_name, 'w')
  File "/usr/lib64/python3.6/zipfile.py", line 1113, in __init__
    self.fp = io.open(file, filemode)
PermissionError: [Errno 13] Permission denied: 'details_2022_10_24_14_10_1666621122.zip'
DEBUG[2022-10-24T14:18:42.251742856Z] Job[87f1c816-61c8-433c-920f-caf514800dc9] has been processed by wo
rker[0b07779e-186c-4537-a3e7-b03c930a1055]

Workaround

As a note, prepending a path of /home/opsgenie/ to the filename set in the function seems to fix the issue (though the full filepath is given as the name of the attachment in OG, see screenshot). The only issue of this workaround is that there's no clean up of these created zip files.