Configure a Record Log on a Form
Table of Contents |
In order to have a table that displays specified information from current and previous records, a log table can be used. Creating a log table has historically been restricted to clevr staff for security reasons. A recent software enhancement has improved the process so that any editor can create a log table using only attributes and a custom type.
Creating the Log Table Container
Before adding the log table custom type “Log Template: DataTable” to the form, a container that will become the outer bounds of the log table (this will be referred to as the “log table container”) must first be created. A “Log Template: DataTable” custom type will always position itself at the top left corner of its parent container (being the log table container), as well as match its width.
Creating the log Table
Creating the log table itself is as simple as adding a custom type into the log table container. This custom type can be placed anywhere inside the log table container, as once published it will reposition itself automatically.
1 | Add the custom type “Log Template: DataTable” inside of the log table container.
Once you the form is published, the following empty log table will be visibile. Until elements are specified for the table, the message “No log_column attributes found.” is displayed. |
Adding Elements to the Log Table
The first step to adding the elements you would like to the table is to plan which elements contain the data to properly identify records, along with any element that could potentially be useful to see in aggregate for a person’s records.
Below is a list of example data that can be useful for distinguishing between records in the table:
-
School
-
School Year
-
Grade
-
Teacher
-
Clinician
-
Date of Meeting
The following attributes must be added to each of the fields that are to be shown in the log table.
Attribute | Value |
---|---|
log_column |
This attribute adds the element as a column in the log table. The attribute’s value should be an integer. The columns in the log table will be in order of least to greatest of the values of this attribute. If a non-integer value is entered, the column will still appear in the table, however the column order will be unpredictable. If multiple elements have the same value, then they will be sorted by their ElementId. ex: 1 |
log_column_desc |
This attribute provides the ability to specify the column header in the log table. If the attribute is not provided, then the description attribute will be used in the header. If no log_column_desc or description attribute are present, the column header will be “Unnamed Column {elementId}” ex: Location |
log_column_sort |
This attribute indicates if the log table should be sorted by the values of this column. The two possible values are “asc” for ascending and “desc” for descending. Only one element should be used to sort a log table. Having more than one element will produce unpredictable results. In the following image, the records simply appear in order of creation: In this next image log_column_sort “asc” has been applied to the “Meeting Date” element, with a value of “asc”. |
Example Log Table
The following table will display how multiple example fields are configured, as well as the resulting log table.
1 | |
2 | |
3 | |
4 | |
5 |
Enabling Record Controls in the Log Table
To enable users to delete a record directly from the log table, then the attribute log_showIcons must be applied to the “Log Template: DataTable” custom type with the value of “true”.
Restrictions
-
There can only be a single set of columns defined for a log table. While many log tables can be placed on a form, they will all show the same set of columns.
-
Log tables will not push down elements that appear below them on a form. If a log table contains enough records, it can expand to overlap any elements below. For this reason, we recommend the following placement on a form:
- At the bottom of a tab.
- In a side-by-side configuration with the log table on one side and elements on the other. In this configuration, it would be best to not have any elements below the log table. This layout is best used when a form will have many records that have a limited number of elements.
- In a side-by-side configuration with the log table on one side and elements on the other. In this configuration, it would be best to not have any elements below the log table. This layout is best used when a form will have many records that have a limited number of elements.
- Less ideally, with enough blank space below to provide ample room to expand for the expected number of records. This approach can work on forms that have a predictable number of records, such as yearly assessments where a student should only have a single record for each year of their education.
- A log table can not be repositioned with its parent container, and its width can not be changed from the width of its parent container. For this reason, it is best practice to provide a log table with a dedicated container to control its spatials.
- The log table Header will only use the “description_en-CA” attribute, regardless of which language is selected in a user’s profile. For that reason, if you require multiple language support in a log table, it is best to specify a log_column_desc attribute with both languages included.