This file documents changes to Argus that are relevant for operations and end-users.
Mostly changes to the alpha frontend that will not be detailed here.
Support for multple API tokens per user has been added, via django-rest-knox. For that reason, the old API endpoints for dealing with token authentication has been deprecated, and new endpoints have been added to v2 of the API.
We've copied the linting rules from argus-htmx, so anything that have not been merged yet might have to be updated to keep the linters happy.
All v1 API endpoints for dealing with phone numbers have been deprecated. Please see the v2 endpoints dealing with destinations instead.
This version marks the inclusion of our new, alpha web frontend. It does not do everything the existing standalone frontend does yet, hence alpha. See docs for how to test.
The big but hidden new feature this time is a new database table to hold user preferences, in a namespaced fashion. Different apps can have different sets of preferences with the same names but different values.
There is as of yet nothing that uses the preferences. The machinery needs to be in place for the new frontend.
See the docs and remember to migrate.
Bugfix release, logout via the React SPA frontend should now work again.
It is now possible to delete "dormant" users, defined as: users that have never created an event or incident. Such users may be autocreated when testing new login methods.
This release is mainly to wrangle dependencies to the in-progress new frontend.
There's a new library argus.htmx that exists to make it easier to develop the
new frontend. The new frontend cannot be run simultaneously with the REACT SPA
frontend as some settings conflict.
See the new docs in docs/reference/htmx-frontend.rst for details.
All the hard coded support for the REACT SPA frontend has been split out into a library.
In the process, the following renames were done:
ARGUS_COOKIE_DOMAIN->ARGUS_SPA_COOKIE_DOMAIN(environment variable)COOKIE_DOMAIN->SPA_COOKIE_DOMAIN(setting)ARGUS_TOKEN_COOKIE_NAME->ARGUS_SPA_TOKEN_COOKIE_NAME(hidden setting)
How to deploy argus-server with support for this frontend has also changed, see the new documentation section "REACT Frontend". In short, it is necessary to change which settings-file to base the deployment on.
You might have to rebuild docker images: ours uses a newer Python (3.10) and PostgreSQL (14) than they used to.
Any setting can now be changed via the (EXTRA|OVERRIDING)_APPS-machinery.
This is the first version of Argus to be able to run on Django 5.1.
Support for Python 3.8 has been dropped.
The most visible changes are in the documentation.
The function get_psa_authentication_names() has been remooved, it was not in
use by us.
How to customize filtering has changed, it is no longer necessary to override
FilterSerializer and validate_jsonfilter.
There's a backwards incompatible change to prepare for the next Django LTS
(5.2): The setting STATICFILES_STORAGE has been replaced with STORAGES. If
STATICFILES_STORAGE has been changed from the provided default in
a deployment, it will have to be updated. See STORAGES["staticfiles"] in for
instance argus.site.settings.base.
Changing ticket urls in bulk now sends out change events, behaving like other bulk changes. This means there will be an overall increase in events if bulk changing tickets is common.
The "description" field on Incident is now editable via API.
This moved around a lot of code in order to allow swapping out the filtering system. The Filter-model is still used but the bits that uses the contents of Filter.filter is independent of the model.
Optimization of API Incident PUT/PATCH.
Tiny bugfix-release, nothing to see here.
Remember to migrate!
Backwards-incompatible change: Because it is now possible to filter on multiple event types instead of just one, both API V1 and API V2 has changed its schema for Filter.filter.
- The key
"event_type"is gone from V1. It never should have been there in the first place since it's new functionality. - The key
"event_type"has been replaced with a new key"event_types"in V2. Where"event_type"was a single string,"event_types"is a list of strings.
Luckily, the frontend at https://github.com/Uninett/argus-frontend never added support for this feature.
Behavior does not change as the key not being set (or set to None/empty list) will ignore the key when sending notifications.
Existing instances of "event_type" in the database is automatically changed
to "event_types" iff "event_type" was not falsey. Reversing the migration
will set "event_type" to the first string in "event_types" hence might lose
data: don't reverse the migration in production!
There's a new API endpoint allowing the deletion of an existing incident and
its events. The new setting INDELIBLE_INCIDENTS controls this, the backwards
compatible setting is True. Toggle to False to allow deletion. The plan
forward is to limit deletion according to some rule we haven't decided on:
- limit it to "new" incidents, for an unfinished definition of "new"
- have an (optional) flag on incident controllable by the source
- so.. many.. ideas, hence, running code now, hard decisions later.
Smaller change: the data in Incident.metadata can now be replaced with HTTP
PATCH/PUT, in line with ticket_url, details_url and level.
This release marks the start of The Great HTMx Experiment and a cooperation with Geant.
Incidents have a gotten a new field so remember to run migrations.
There's a new "How To"-section in the docs, we expect it to grow rapidly.
There's lots of quality of life improvements in the admin.
There's a new way to add additional django apps to your own instance of argus-server. Currently this is only via two new environment variables, see the settings-documentation.
The official docker image has been changed so if you use it in production have a peak first.
The stresstest command is now a lot more useful: it is handy for even more
lazily creating a lot of fake incidents in the database where you don't care
about he contents. Just remember to turn off sending of notifications first!
You can turn it of or on for specific profiles with a new cli command:
toggle_profile_activation. It is now also easier to toggle, activate and
deactivate profiles in the admin. Have a look.
django-debug-toolbar has been added as a dev dependency but it is not in use
in the included dev settings yet.
This release finishes the process started in 1.14.3. Make sure to run the migrations in 1.14.3 before you run the migrations included here!
Furthermore, Django 3.2 is no longer supported so upgrade, upgrade!
This release changes the database in order to get rid of a dead dependency, make sure to run migrations:
$ python manage.py migrateThis version can run on Django 5.0 if necessary. Install the dependencies in
requirements-django50.txt if so.
This version can run on Django 4.2. In production, ensure that the list of
entries in CSRF_TRUSTED_ORIGINS are absolute urls, all starting with
https://.
The CHANGELOG is now maintained by towncrier.
The frozen requirements-files have been updated with new versions, please
upgrade which versions are used in production accordingly with
pip install -r requirements-djangoVERSION.txt where VERSION is either 32for
Django 3.2 or 42 for Django 4.2.
- Restructured documentation about integrations
Due to a change in the signature of NotificationPlugin.send(), 3rd party
plugins will need to mark better which versions of argus-server they work with
in their dependencies-list. The old-style plugins work on 1.9-1.13.
- Add the "installed" field to the media serializer. This is so that the frontend can detect media used that is no longer installed on the backend.
- Ensure the right notifications go to the right destinations when sending many of each.
- Change the signature of the notification-plugin
send-method to avoid passing in the database - Send one email per email-address so as to not leak who else gets that email.
Works with argus-frontend 1.11 and newer.
- Add inline destinations to user edit page in admin
- Add management command for listing filters
- Add management command for bulk acting on incidents matching a given filter
- Raise validation error on posting incident with tags without tag key
-
Drop support for Python 3.7
-
Remove all remaining uses of
Filter.filter_string, replace with Filter.filter, in preparation of removing the actualfilter_stringfield from the database.The API v1 still accepts
filter_stringbut it is optional. It will prefer the data infilter. v2 ignores the presence or absence offilter_stringentirely.
- Ensure that the start event is created after the incident has its tags so that notification filters with tags trigger correctly.
- Change what is logged on notification sending in order to ease solving problems in production. Prior to this, we couldn't know whether there is a problem with matching an event to filters, or whether the problem is actually storing all incoming events. Turn on debug-logging to get it all.
- When sending a notification in production a typo lead to an exception that prevented sending the notification but was otherwise hidden from the end user.
- Fixed acking-bug that only occured if notifications were turned on
- Add docs for how to write a notification plugin
- Add a new command "stresstest", for stress-testing the API
- Migration! Add a field "installed" to the Media-model
- Support running on Django 4.2
- Documented how to use email to send notifications to Slack
- Make the auth-method endpoint also show username/password
- Allow updating of a timeslot with an empty time recurrence list, which results in all time recurrences to be removed from the timeslot
- Optimize and refactor bulk api operations
- Start the process of getting rid of
Filter.filter_stringby ensuring the info infilter_stringis also inFilter.filter
- CORS-headers do not want explicit port numbers if the ports are the default
for their type, that is: 80 for http or 443 for https. This lead to CORS not
working if there was an explicit port in the
ARGUS_FRONTEND_URLsetting, which used to generate a CORS entry for the frontend. Such port numbers are now stripped when generating the CORS header.
With this version, the API for bulk changes of incidents and sending of notifications to new and interesting destinations via destination plugins has been frozen, and should be ready for use, completing what was started in 1.10.
- Also include frontend-url to incident in incident-serializer
- Show installed plugins in the metadata view
- Fix API for adding events in bulk, with tests
- Fix API for bulk acking, with tests
- Renamed the ticket creation endpoint via plugin from
/ticket/to/automatic-ticket/
- Send serialized incidents to the ticket-plugin, not database objects (This makes plugins much easier to test.)
- Added support for testing on Python 3.11 and Django 4.0, 4.1
- Plugin system for ticket system integrations, documented in the new "Ticket system settings" sections.
- Add a production-oriented Dockerfile and use Github to build and store images
- New API endpoint to create a new ticket in an external ticket system
- Add docs about notification plugins
- Added the possibility to filter notifications by event-type
- Added a management command that will create incidents if a source token is close to expiring
- Added an endpoint to create events for incidents in bulk
- Added an endpoint to set ticket_url of incidents in bulk
- Added the possibility to filter notifications by event-type
- Flatten the json structure for posting acknowledgements.
- Added an endpoint to acknowledge incidents in bulk
- Added an endpoint to get a refreshed auth token.
- Add a filter to find incidents with a duration longer than a given amount of minutes.
- Added tests for previously untested incident endpoints
- Fix typo that prevented SMS messages from being sent.
- A notification profile can now have a name.
- Added endpoint that returns True if another user has a destination with the same medium and settings as the destination with the given primary key
- One timeslot can now be used by multiple notification profiles.
This update includes changes to the database model, requiring a migration of the database.
- Documentation for our own management commands (CLI-scripts)
Running migrate will complete the changes that started with 1.6.0.
- New API endpoint
/incidents/all-events/for listing all events. - Users can now have multiple emails and phone numbers
This update includes changes to the database model, requiring a migration of the database.
Which notification plugins are in use are now decided by the new setting
MEDIA_PLUGINS. There are no default contents of this setting, to make it
possible to turn off notifications.
In order to support the included email and sms-plugins, add the following to your tailored settings-file:
MEDIA_PLUGINS = [
"argus.notificationprofile.media.email.EmailNotification",
"argus.notificationprofile.media.sms_as_email.SMSNotification",
]
- Acking an incident when notifications were turned on was broken, this is a workaround.
- New query parameter
searchfor the incident endpoint. This allows searching for incidents that contain given keywords. The result is a list of incidents where each given keyword exists in the incident description and/or in any event descriptions that belongs to the incident. - External authentication supported via REMOTE_USER environment variable.
- All mentions of Uninett has been replaced with Sikt. This is because Uninett was a merged into Sikt – Norwegian Agency for Shared Services in Education and Research on January 1st 2022.
This update includes changes to the database model, requiring a migration of the database.
Note that the migration that allows the text-search is quite heavy and may time out if you have very many incidents. If this happens, make an issue of it (including how many incidents and how long it took before timing out) and we'll make a patch-release with a documented work around for you.
In order to run tox successfully on Python 3.10, make sure tox was installed with Python 3.10 or testing might fail with:
KeyError: scripts
- New API endpoint
/login-endpoints/for listing all login endpoints. - New query parameter
countfor the incident endpoint to be used along with a filter. This will make the endpoint return a count of how many incident matches the given filter along with the filter itself. This is useful for debugging. - The
levelattribute for incidents can now be updated via the incident endpoint.
- The initial event for stateless incidents will now be labeled as "Stateless" instead of "Incident start". Stateful incidents are still labeled "Incident start".
This update includes changes to the database model, requiring a migration of the database.
- NotificationProfileViewV1 should no longer appear in API v2.