New alert rules
You can now set mission alerts to include humidity, light and impacts in addition to temperature. While not really something flashy, it allows more detailed reporting and monitoring of what has happened. If you need this sort of data, this addition is pure gold to you. If not, it might come in handy if your needs change.
Obviously the alert capabilities are tied to what the loggers included in the mission can measure. With a mission full of Logmore Three QR tags, you could set a full variety of alerts, while setting a shock alert for a mission without a single Logmore Three would not benefit from the alert in any way.
You can now mark mission alerts as checked. When you marked an alert checked, it is moved by the system to the "checked" tab of the list and won't show up as a notification on the scan page. A single click is enough to check the alert.
If something needs to be said about a specific alert (e.g. "Don't mind this, it was a mistake on my part, I left the logger on a table in room temperature") it can be done using the commenting system of missions. Click on the Add comment -button on a specific alert and the UI automatically prefills the needed hashtag to the comment.
When a comment has been posted, it can be clicked if it contains an alert hashtag. The UI then scrolls down to the specific alert on the list and highlights it for a couple of seconds. This way it's easy to see what the details of the alert in question are. The number of comments on an alert is also indicated in the table.
What if the alert required following actions? You can also make a comment on the alerts to specify what has happened and why, and what was done to fix any possible issue. The comment function also includes the user's name, allowing you to recognize who marked the alert as checked.
The advanced setting for a logger now includes the option to make that specific logger's data public. By toggling the option on, the data collected by that logger can be accessed when the QR code is scanned even without logging in to a user account that has access to the logger otherwise. The logger's data can also be shared by sharing the logger page's URL address.
You might want to use the public setting to allow your customers access the data on the specific logger you've used in a shipment to them, or to skip the login requirement for your own employees who might not need their own accounts and user access. Everything depends on your own specific use case.
However, you shouldn't make your loggers public without consideration. As with all data, it's always good to keep security in mind. With public access the logger's will be public. It is highly unlikely that someone figures out the logger page's URL without them scanning the logger or you giving them the address, but the theoretical possibility exists nonetheless. Only make loggers public if you know the data is ok to be available to anyone.
Like loggers, whole missions can now be made public. The same rules apply to public missions as public loggers: if someone has the direct URL of the mission's page, they can read the data available on that page.
When creating a new mission you can set the mission to be automatically public if all the loggers included are already public. If they aren't, you can set the mission public after creating it by accessing the "edit mission" settings from the mission's page. It's also worth noting that if you use the quick mission creation option, the mission will automatically be public if all of its loggers are.
As with public loggers, missions should only be made public if it is beneficial to the use case in order to maximize security. Keep security a priority and keep your mission data private unless your company benefits from customers, employees or other stakeholders having free access to it!