Credential Reporting - Enhance Credentials table with creation and lastScan time
In order to have effective credential reporting, column information for creation and lastscan time was necessary to be recorded in the credential table. Without those, this required information was lost as soon as Event Logs were purged. With this information, we are able to look up the event in the event table (if it has not yet been purged). The creation and lastscan timestamps are now stored and available for Credential reporting.
Comloss (on\off) messages were processed incorrectly
Excessive CPU Usage
A correlation was found between the very high load and conditions in the system. The service that uses CPU usage the most when the system is not reachable through the web user interface started to heavily consume CPU usage when there were clients connected via the Web Socket. FIXED
It was determined what was causing this situation and a solution was implemented to more efficiently support Web Sockets on busy systems. Efficiency was increased, allowing for better management of a large number of doors.
In People Reports, the deleted Partition\Card\Group items should be removed from the added filters
When creating a People report, a “Loading…” status was displayed instead of the list of Partitions, Cards, or Groups and the item to be deleted was not removed from this list. FIXED
The list of Partitions, Cards, and Groups is now displayed and the deleted item is removed from this list. The filter does not contain the deleted item.
Better input validation on Touch and Token columns in the imported CSV file
When a CSV file was imported, the person was added successfully; however, on the details page, there were no added mobile credentials. FIXED
Handling of groups inaccessible to the user in reports
Manager\Report users were unable to update the report in which the Groups filter included not-accessible Groups. A “Loading…” status was displayed instead of the list of Groups. The list of Groups should be displayed at the added group filter in the Filter section. It is necessary that some of the selected Groups are associated with the Partition that is different from the Partition related to the user having a Manager\Reporter role.
Perform complete logging of Person modification information when importing a CSV file.
It was suggested that when persons are added to the system from a CSV file that the information should be added to the audit log. All modifications (creating persons, adding a person to a group, credential modifications, etc.) should be added to the audit log. This information is now added to the audit log when persons are imported from a CSV file.
Users with a Manager role are prevented from importing a CSV file in which a Partition column exists
If a user with a Manager role imports a CSV file with content in the Partition column, an error message is received since a Manager user does not have permissions to Partitions. The Partition column is excluded from the downloadable CSV template for users having a Manager role.
New System Events were created relating to power management
The following system events have been added based on power management.
- Loss of DC power
- Overcurrent events
The following events are available in the System Events trigger list. They also appear in an Events report. New event triggers are present on the Add/Edit System Event page.
- On Input Power Loss
- On Input Power Recovery
- On Overcurrent Detected
- On Overcurrent Cleared
- On Low Power Mode On
- On Low Power Mode Off
- On Battery Connect
- On Battery Disconnect
New event names are present on the Add/Edit Events Report page.
- Overcurrent Detected
- Overcurrent Cleared
- Input Power On
- Input Power Off
- Low Power Mode On
- Low Power Mode Off
- Battery Connected
- Battery Disconnected
Results of the Events Report with the included filter events described above contain the following messages:
- Input power loss has been detected for the controller on the connection
- Input power has been restored for the controller on the connection
- Overcurrent has been detected for the controller on the connection
- Overcurrent has been cleared for the controller on the connection
- Low power mode has been enabled for the controller on the connection
- Low power mode has been disabled for the controller on the connection
- A battery has been connected to the controller on the connection
- A battery has been disconnected from the controller on the connection
|Event Name||Event Report Message*|
|Overcurrent Detected||Overcurrent has been detected for the controller on the connection|
|Overcurrent Cleared||Overcurrent has been cleared for the controller on the connection|
|Input Power On||Input power has been restored for the controller on the connection|
|Input Power Off||Input power loss has been detected for the controller on the connection|
|Low Power Mode On||Low power mode has been enabled for the controller on the connection|
|Low Power Mode Off||Low power mode has been disabled for the controller on the connection|
|Battery Connected||A battery has been connected to the controller on the connection|
|Battery Disconnected||A battery has been disconnected from the controller on the connection|
*These messages are also presented on the Live Events page. They are also seen in emails if there are System Events that send emails on any of the above events.
New Aperio hub shows up gray in Door States
When a Status Request message from an Aperio Hub was missed, all devices associated with this hub were marked as comm loss. However, when a Status Request message is received again, the status for the devices are not changed. A synchronization command is sent for all devices when receiving a Status Request message after missing the previous message. FIXED
Duplicate comm loss messages removed in logs
Comm loss messages were being processed incorrectly (duplicated) because of an incorrect parameter name. FIXED
Eliminate spurious REX/DPS events when establishing a connection to the controller
An issue was found that whenever the status on a board is queried, the responses come through as new events. New messages were not being registered if the state of the specified option had not been changed. FIXED
Support for card number values in multi-swipe Audit Logs and Events
Multi-swipe logs now include a card number value when the following conditions are executed:
- The read credential is a card type (not touch or token);
- The read card is associated with a person who has an allowed rule. If the person has a denied rule, multi-swipe does not work. (Each scan is registered as a separate action with denied status.)
If a person has two cards, and they are scanned one after another, multi-swipe works and is logged where the multi-swipe log includes the card number of the last card scanned.
If a System Event is created which should send an email on the multi-swipe allow Action, the received email will include the card number.
Fix processing of card numbers with no facility code and very low card numbers
Previously, card numbers with no facility code and very low card numbers were not working well with the typical 26-bit reader. FIXED