Safely test sending of notifications — Argus 0 documentation (2024)

Testing filters, profiles, timeslots regardless of destination type¶

When doing a test of everything except details of the destination type, usethe standard email medium(argus.notificationprofile.media.email.EmailNotification) as the soledestination type. Adapt or create a profile accordingly.

Redirect email to console¶

Do not actually send those notification emails, catch them locally.

There are two ways of doing this:

1. Changing the EMAIL_BACKEND setting todjango.core.mail.backends.console.EmailBackend. Sending an email willthen turn up in some terminal window somewhere.

2. Sending to an email server you control, the easiest is to send it to oneset up for the test. Set EMAIL_HOST to localhost, EMAIL_PORT to1025, and run a dummy mailserver:

   See Also

   2023 Conference – NeurIPS Blog

   $ python -m smtpd -n -c DebuggingServer localhost:1025

Sent notifications will then be dumped to the console where the dummy serverruns.

The former method works less well with docker since it can be tricky to findthe correct container that has the dump of the email, plus there’s usually somuch going on in the console of the container that finding the message might betricky. With the latter method the email is dumped in the window theDebuggingServer is running in, which allows a little more control.

One of the two methods above is probably what you want for yourdevelopment-setup regardless.

Testing something that fails in production¶

Copy the profiles to your debugging-setup. You can just reuse yourdevelopment-setup for this: move the dev-database out of the way (for instancewith the ALTER DATABASE .. RENAME statement), dump the production database,then import the dump into your dev-database.

Deactivate profiles you are not testing¶

Deactivating profiles prevents spam, makes the test go faster since there isless to test, and makes it easier to find the result in the console since lesswill be printed. (Don’t do this in production regardless.)

Find the ids of the profiles you want to test first. Let’s assume you’ll betesting profiles “1” and “22”.

There are several methods:

1. Deactivate all others in the admin.

2. If you have access to the database, deactivate via python manage.py dbshell:

   argus=> UPDATE argus_notificationprofile_notificationprofile SET active = false WHERE id NOT IN (1, 22);

3. You can deactivate via the python shell as well, launch with pythonmanage.py shell:

   > from argus.notificationprofile.models import NotificationProfile> NotificationProfile.objects.exclude(id__in=(1, 22)).update(active=False)

With option 1 you need an authenticated user in the system that has bothis_staff and is_superuser set to True. For all the others you needdatabase access.

Testing specific destination types¶

If the plugin has a dummy version that just dumps to the console, see iftesting with that dummy is sufficient. Otherwise you need to find a testdestination (in order to not spam the production destination). For instancewith the MS teams-plugin set it up to spam a test-channel or yourself.

If the live test works but pushing to the production destination does not, it’sprobably a permissions-problem.

Making test incidents to trigger the notification system¶

While it is possible to sit in the python shell and create everything by handfor 100% control, most of the time it is sufficient to use one of the belowmethods:

1. In the admin, go to the Incidents model in the “ARGUS_INCIDENT” section.There’s a button “FAKE INCIDENT” just left of the “ADD INCIDENT”-button.

2. From the command line use the create_fake_incident command with pythonmanage.py.

We do not recommend making an incident directly in the database, because theevent that triggers the notification is made by Python.