As you can probably guess, a room booking system needs to be able to send email notifications. These may include, for instance, booking confirmation emails sent to customers.
MIDAS is no exception, and an extensive range of email settings and options are available in the software. Administrative users may configure these via MIDAS Admin Options → Manage MIDAS → Email.
One of the available email settings allows you to have email notifications sent from your MIDAS system to be sent from a particular email address.
Typically, for automated emails that you don’t require a response to, you may specify a “no-reply” style address.
However, what if you want to provide a way for your customers to contact you should they have any queries?
Well, you could use a real email address instead of a no-reply “black hole” inbox which isn’t monitored.
Or, from MIDAS v4.29 onwards, you could instead specify a “Reply To” email address. This can be different from the address that emails from your MIDAS system are sent from.
Specifying an alternate “reply to” email address
In the above example screenshot, all email sent from the MIDAS system will be sent as though it originated from the address “[email protected]”.
However, if a recipient of an email from this MIDAS system hits “Reply”, they’ll be composing a message that will be sent to “[email protected]” (instead of “[email protected]”.
This new setting adds a standard “Reply-To” header to all outgoing email from your MIDAS system.
More information on the various email configuration options and settings in MIDAS may be found in the documentation.
Notifications each have their own expiration time, after which they are automatically removed from a user’s Notification Center. Users could also manually remove a notification at any time.
For MIDAS v4.29 we’re also giving users the option to mark notifications as having been “read”.
Read notifications will still be present in the user’s Notification Center until they expire or are manually removed. However, unread notifications will be highlighted, whereas read notifications won’t be.
Also, if the user has opted to be shown their notifications each time they log in, this popup will now only show them their unread notifications. So the new “mark as read” option will help keep clutter to a minimum. It will only show notifications the user hasn’t yet seen and acknowledged on the notification pop-up after login.
Users will of course still be able to see all their notifications – both read and unread – via the Notification Center icon.
New options to restrict users to “self” booking or requesting
For MIDAS v4.29, we’re expanding the range of options available to administrators when it comes to assigning user permissions.
MIDAS already includes an extensive range of permissions which can be assigned on a per-user basis. One of these permissions is the “Can Make Bookings” permission. This setting controls whether a given user account can make bookings, or just booking “requests”, or neither.
Following customer feedback, we’re adding a couple of additional options to this particular user permission.
Now administrators can restrict user accounts to only be able to book/request for themselves.
Prior to this, a user with permissions to make bookings/requests could select a client on their Add Bookings screen that the booking or request was to be for.
Now, if the “Can Make Bookings” permission is set to “Yes (For self only)”, the user will only be able to make bookings for themselves. They will not be able to make bookings for any arbitrary client in the system.
Similarly, the “Requests Only (For self only)” option works the same, but only allows the user to make booking requests for themselves.
Every MIDAS booking system includes a “Recent Activity” log feature. This allows administrators to audit all activity taking place in their scheduling system.
The log records logins/outs, failed login attempts, bookings and clients added, modified, or removed, emails sent, database backups, and more.
The Recent Activity log can be quickly accessed by administrators from a dedicated toolbar icon.
Data from the log is shown on screen in chronological order (newest entries first), and is split into 4 columns:
Date / Time – The date and time that the event occurred
Originating IP – The IP address that the event originated from
User – The user account that initiated the event
Action – The event itself
The Recent Activity log may also be exported directly to Excel.
We’ve made a number of improvements to the performance of the Recent Activity log for MIDAS v4.28.
These include…
Log entries now load in blocks
Log entries are now loaded in blocks, with a “Show More” button available to append the next entries
For each and every action which occurs in a MIDAS system, an entry is made in the recent activity log.
Entries in the log are typically kept for a period of 30 days before automatically being removed. This retention period can be change to keep logs for longer or shorter periods.
For very active MIDAS systems (or those with a long log retention period), the Recent Activity Log can become very large.
To display a lengthy log in its entirety could slow down the viewer’s browser, and in some extreme cases make it appear that their browser has frozen/hung.
To address this, from v4.28 the Recent Activity log no longer displays all its entries at once.
If the log contains a high number of entries, only the newest entries will be shown, along with a “Show More” button at the bottom of the screen. Clicking the “Show More” button will load and append the next set of log entries to entries currently shown on screen.
The “Show More” button will continue to show as long as there are more entries in the log which aren’t currently being shown on screen.
The number of log entries shown on screen is derived from the “Maximum search results to display per page” setting. This setting usually controls the number of search results returned per page via the built in “Search” feature. However, the number of Recent Log Entries shown in each “block” is twice this setting. So if “Maximum search results to display per page” is set to the default of “50”, then 100 Recent Activity log entries will be shown at once.
Failed login attempts are now collated
Failed login attempts are now collated into single entries on screen
One of the benefits of the Recent Activity Log is that it records all failed login attempts to your MIDAS system.
This may happen, for instance, if a user enters their password incorrectly.
Similarly, if may also happen if someone tries to login to a non-existent account.
In today’s world, hackers use automated tools to try to “brute force” their way into systems. They do this by sending automated login requests using different email/password combinations. Often dozens, if not hundreds, of automated requests could be made every second.
As MIDAS logs failed and invalid login attempts, automated tools could soon flood the Recent Activity log with failed login entries.
To combat this, we’ve made a change in v4.28. Now instead of displaying every single failed login attempt, multiple failed login attempts from the same IP address will show as a single entry. This entry will indicate the total number of failed attempts, the time of the first attempt, and the time of the most recent failed attempt.
Faster rendering and displaying of the log
In addition to loading log entries in blocks, for v4.28, we’ve also streamlined the actual HTML code used to display log entries on screen.
This has more than halved the number of “nodes” (elements) that your browser has to process and render in order to display the recent activity log.
The result is that the Recent Activity Log now loads far quicker than it did before!
