Create an alarm for any record model, specify when the alarm should generate notifications and which users are to be notified.

For example, we can create the following alarm:

1. Record model? Project Task
2. When must the alarm generate notifications? Two days before the deadline of the task
3. Which user(s) are to be notified? The user responsible for the task

As a result, each project task with a deadline taking place in 2 days will trigger the generation of an alarm notification (a reminder) for the user that is set as responsible within the task. Note that the user can access the task directly from the notification.

All users belonging to the Alarms / Notification User group have access to the Alarm Notifications area, where they can see all their notifications. Users belonging to the Alarms / Manager group can, additionally, see the notifications of other users.

By default, the list view shows only the notifications of the current user that are active and open. However, the filters can be modified to adapt the results to the user's needs.

An alarm notification contains the following information:

• Name: this is the name of the alarm that triggered the generation of this notification.
• Generated for: the user to whom this notification belongs.
• Record: link to the record that triggered the generation of this notification.
• Active from: the date from which the notification is considered active. By default, the date when the notification was generated is set. However, a user can move this date into the future to indicate that the notification is to be handled in the future.
• Notification Message: some information provided by the alarm.
• Notes: text field for the user to note down any information they want.
• State: indicates if the notification is open (to be handled), closed (handled) or cancelled. By default, all notification are generated in the open state. However, a user can change the state at any time.

All users belonging to the Alarms / Alarm User group have access to the Alarms area, where they can manage all their alarms. Users belonging to the Alarms / Manager group can, additionally, manage the alarms of other users.

Additionally, these users have access to a shortcut action named Create Alarm placed in the Action drop-down available in all list views when one or more records are selected and in all form views. Such an action allows the user to create very easily an alarm exclusively for the selected records.

By default, the alarms list view shows only the alarms created by the current user that are draft or done. However, the filters can be modified to adapt the results to the user's needs.

An alarm contains the following information:

• Name: short descriptive name for the alarm. This name is assigned to all notifications generated by this alarm.
• Description: further details to better understand the purpose of the alarm.
• Created by: the user that created the alarm and therefore, the alarm owner.
• Triggered on: the date/time on which this alarm was last triggered. Alarms are normally triggered every day in the early morning by a scheduled action. However, a user can also trigger it manually by means of the Trigger Alarm button. Note that even if the alarm is triggered multiple times in a row, the same notification will not be generated more than once.
• Model: the type of record to be checked in order to decide if a notification must be generated or not.
• Model Domain: python domain used to select only records with certain characteristics. For example, we can configure the alarm to generate notifications only for records in the draft state and whose creator is me by using the following domain: ['&', ('state', '=', 'draft'), ('create_uid', '=', my_uid)]. The following variables and libraries are available:
  • my_uid: variable with my user ID.
  • date: library to manage dates (e.g., date.today())
  • datetime: library to manage date with times (e.g., datetime.now())
  • timedelta: library to manage time deltas (e.g., date.today() + timedelta(days=2))
• Date Field: date(time) field within the specified Model whose check may trigger the generation of a notification. When checking this field, if time information is present, it is simply ignored (e.g., "2017-01-25 09:30:00" is treated as "2017-01-25").
• Number of Days: a negative integer indicates that a notification will be generated this number of days before the date set in Date Field; a positive integer indicates that a notification will be generated this number of days after the date set in Date Field; a zero indicates that a notification will be generated right on the date set in Date Field.
• Notify Only Me: this flag indicates whether I will be the only person to be notified or not. Note that only users belonging to the Alarms / Manager group can actually create alarms that notify other users.
• User Field: the field within the specified Model containing the user(s) to be notified. If Notify Only Me is set, I will be the only person to be notified but I must be also the user specified in this field.
• Explicit Users to Notify: static set of users that must always be notified.
• Notification Message: information that will be provided to the notified user. Here we can provide static information but also dynamic information. To provide dynamic information we must use MAKO templates* (same technique as the one used in email templates). For example, if we have an alarm for project tasks and we want to include in the notification message the name of the project manager, we can use the template ${object.manager_id.name}. To verify that the template is correct and that the notification message looks like desired, we can use the Preview Notification Message button.
• State: indicates if the alarm is draft (not ready to be automatically triggered), done (ready to be automatically triggered) or cancelled. Note that any alarm can be manually triggered by means of the Trigger Alarm button.

* Brief explanation about MAKO templates: all MAKO templates are represented with ${...}. Within the braces we can provide any python code, taking into account that we can only access a limited set of functions and variables. The most important variable we have is object, which represents the record triggering the alarm (in our example, a project task).