AX1139

Updating alert notification status using Save Type 4

Using Save Type 4, you can update alert notification status (read or not read) by using save-to-database within a spreadsheet. This is intended to be used in cases where alert notifications are being viewed using a custom solution, rather than by using the built-in Notifications task pane.

Save Type 4 depends on the placement of save-to-database tags within the sheet. There are three components:

  • The primary SaveStructure2DB tag, which defines the locations of the save-to-database control row and control column, and specifies the desired operation.
  • Column tags in the save-to-database control row, to specify the columns which hold the notification properties.
  • Row tags in the save-to-database control column, to flag rows to be saved.
Save-to-database tag summary
Tag Type Tag Syntax

Primary tag

[SaveStructure2DB; Axiom.Notifications; CustomSaveTag=Name]

Row tags

[Save]

Column tags

NotificationID

IsRead

NOTE: Save Type 4 must be enabled for the sheet on the file's Control Sheet in order for the save process to occur. For more information, see Using Save Type 4.

Placing the primary save-to-database tag in the sheet

To define the save-to-database process, place the following tag in any cell in the sheet, within the first 500 rows:

[SaveStructure2DB;Axiom.Notifications]

The row containing this tag becomes the control row for the process, and the column containing this tag becomes the control column for the process.

You can also optionally use the custom save tag parameter. For example:

[SaveStructure2DB;Axiom.Notifications;CustomSaveTag=MarkRead]

NOTES:  

  • The primary SaveStructure2DB tag must be located in the first 500 rows of the sheet.

  • The SaveStructure2DB tag can be placed within a formula, as long as the starting bracket and identifying tag are present as a whole within the formula. For more information, see Using formulas with Axiom feature tags.

Defining the alert notification properties in the control row

Within the control row for the save-to-database process, specify the columns that define the alert notification properties. These properties can be placed in any column.

Column Tag Description

NotificationID

The database ID of the alert notification. This is different than the AlertID, which is defined in the alert properties.

IsRead

The read status of the alert notification, either True or False.

The column tags can be placed to either the right or the left of the SaveStructure2DB tag. Both columns are required. Only the IsRead status can be changed; the NotificationID is to identify the notification to modify.

The control row must be dedicated to containing only valid column names for the Save Type 4 operation to the target table. Any invalid entries in the control row will cause an error when saving.

NOTE: These are the only columns of the Axiom.Notifications table that are supported for use with Save Type 4. Any other columns listed in the save-to-database row will be ignored by the save process.

Flagging the rows to be saved

Within the control column for the save-to-database process, mark each row that you want to be saved with a [Save] tag. This is the only valid action for the table save.

If you have defined a custom save tag in the SaveStructure2DB tag, then you must mark the rows with that tag instead of the default tag. For example, if your primary tag is [SaveStructure2DB; Axiom.Notifications; CustomSaveTag=MarkRead] then you would place the tag [MarkRead] in the rows that you wanted to be saved.

Only rows that are marked with a valid tag are processed; all other rows are ignored, even if there is content in the property columns. If a row contains a valid tag but no content exists in the property columns, a save error will occur.

NOTE: The row tag can be placed within a formula if desired.

Populating the table properties in the spreadsheet

In the property columns, enter the alert notification properties for each notification that you want to update. It is assumed that this will be done by using an Axiom query or GetData functions to the Axiom.Notifications table to return the relevant properties.

For example, imagine that you want to query in the current alert notifications for a user, and then display those notifications in an Axiom form. The user can then check a box to show they have read the notification. The read notifications are then hidden in subsequent refreshes and the next time the file is opened. You would:

  • Create an Axiom query to the Axiom.Notifications table to bring in the notifications for the current user. This filtering happens automatically when the table is queried; you don't need to define a data filter to restrict the results to the current user.
  • Configure Save Type 4 to save back the current IsRead status for the notifications, and set up the form to support saving to the database.
  • Configure a formatted grid to display the results of the query. The formatted grid could also contain a check box that would toggle the IsRead value from False to True.
  • Omit notifications that have been read by either filtering the Axiom query (IsRead=False), or by configuring the [Row] tags for the formatted grid to be dynamic based on the IsRead status.

The Axiom form user can select the check box in the grid to indicate that they have read a notification. The grid could be set to auto-submit and save on submit to immediately update once a user has made this selection, or you could trigger the update and save using a Button component.