Event Templates
Event Templates are introduced to be able to display more detailed information
about a specific event. This template is included in the status details and on
the event details page.
Creating a template
To create a template for an event you need to know what the event type and
optionally the alert type is. For detail on this, please refer to
event and alert type reference documentation.
File structure
To start using custom event templates create a directory called templates in
NAV’s etc-directory, and inside that directory you create the alertmsg
directory. And finally inside this directory you can add event templates using
the following structure:
base.html
<event-type>
..base.html
..<alert-type>.html
<event-type>
..base.html
..<alert-type>.html
For a boxDown template it would look like this:
templates
..alertmsg
..boxState
..boxDown.html
Common template for all events
To create a template common for all events, create the base.html and add html
there.
Common template for an event-type
To create a template common for for instance boxState-events, create the
directory boxState and the file base.html inside the directory and add html
there.
Single template for an alert-type
To create a template for all boxDown-events, you create the directory boxState
because that is the event-type of boxDown and then you create the file
boxDown.html and add html there.
Template context
The template has all the variables from the API as well as the alert-object
available. See /api/1/alert and the class AlertHistory in the file
python/nav/models/event.py for more details.
nav.models.event.AlertHistory
-
class
nav.models.event.
AlertHistory
(*args, **kwargs)
From NAV Wiki: The alert history. Simular to the alert queue with one
important distinction; alert history stores stateful events as one row,
with the start and end time of the event.
- Parameters
id (AutoField) – Id
source (ForeignKey to Subsystem
) – Source
device (ForeignKey to Device
) – Device
netbox (ForeignKey to Netbox
) – Netbox
subid (VarcharField) – Subid
start_time (DateTimeField) – Start time
end_time (DateTimeInfinityField) – End time
event_type (ForeignKey to EventType
) – Event type
alert_type (ForeignKey to AlertType
) – Alert type
value (IntegerField) – Value
severity (IntegerField) – Severity
-
exception
DoesNotExist
-
exception
MultipleObjectsReturned
-
acknowledge
(account, comment)
Acknowledges this alert using a given account and comment.
Any pre-existing acknowledgement will be overwritten.
-
acknowledgement
Model field: alert, accesses the Acknowledgement
model.
-
alert_type
Model field: alert type, accesses the AlertType
model.
-
alert_type_id
Model field: alert type
-
alertqueue_set
Model field: history, accesses the M2M AlertQueue
model.
-
device
Model field: device, accesses the Device
model.
-
device_id
Model field: device
-
end_time
Model field: end time
-
event_type
Model field: event type, accesses the EventType
model.
-
event_type_id
Model field: event type
-
get_downtime
()
Returns the difference between start_time and end_time, the current
downtime if the alert is still open, and None if the alert is
stateless.
-
get_next_by_start_time
(*, field=<django.db.models.fields.DateTimeField: start_time>, is_next=True, **kwargs)
Autogenerated: Finds next instance based on start_time
.
-
get_previous_by_start_time
(*, field=<django.db.models.fields.DateTimeField: start_time>, is_next=False, **kwargs)
Autogenerated: Finds previous instance based on start_time
.
-
id
Model field: id
-
is_acknowledged
()
Returns an Acknowledgement instance if this alert has been
acknowledged, otherwise None.
-
is_open
()
Returns true if stateful and open.
-
is_stateful
()
Returns true if the alert is stateful.
-
messages
Model field: alert history, accesses the M2M AlertHistoryMessage
model.
-
netbox
Model field: netbox, accesses the Netbox
model.
-
netbox_id
Model field: netbox
-
objects
= <django.db.models.manager.ManagerFromAlertHistoryQuerySet object>
-
save
(*args, **kwargs)
Save the current instance. Override this in a subclass if you want to
control the saving process.
The ‘force_insert’ and ‘force_update’ parameters can be used to insist
that the “save” must be an SQL insert or update (or equivalent for
non-SQL backends), respectively. Normally, they should not be set.
-
severity
Model field: severity
-
source
Model field: source, accesses the Subsystem
model.
-
source_id
Model field: source
-
start_time
Model field: start time
-
subid
Model field: subid
-
value
Model field: value
-
variables
Model field: alert history, accesses the M2M AlertHistoryVariable
model.
-
varmap
Descriptor for simplified dict-like access to the AlertHistory
stateful variable map.
NOTE: Updating the dictionary will not save it, the attribute must be
assigned a dict value for a db update to take place.