In/Out Board Blog

OfficeStatus offers Windows desktop, web, and mobile web end user interface options. Regardless of which of these you choose, OfficeStatus can show dates and times in a locale-specific manner.

If you’re using OfficeStatus Windows Client, this happens automatically as long as each end user’s operating system is configured with the correct region and language settings. All versions of Windows allow the end user to specify their preferred date and time formats, and OfficeStatus Windows Client will honor those.

As for the web (and mobile web) interface, OfficeStatus will automatically adapt date/time displays based upon browser configuration. If no browser configuration language settings are available, the server locale will be used.

For example, let’s say I’m using Google’s Chrome web browser. If I navigate to Settings and click the Show advanced settings link, I can then click the Language and input settings button to reveal the following window:

Using the configuration above, the OfficeStatus web interface will display dates and times in U.S. English. However, if I’m from Latvia, Europe this may not be what I want. The solution is to click the Add button in the Languages window shown above and add  the Latvian language to Chrome. Next, I drag and drop Latvian so that it appears at the top of my supported language list:

Now I can click the Done button in Chrome’s settings window and access the OfficeStatus web interface again. This time, I will see date and time values formatted specifically for the Latvian locale. Other browsers (besides Chrome) have similar settings.

If you don’t want to configure each user’s browser, another option is to force the OfficeStatus web interface to use a specific culture configuration. This can be done by modifying the web.config file that resides in the webroot folder below your OfficeStatus Server installation path (for example, “c:\program files\officestatus server\webroot\web.config”).

The web.config file is plain text, so you can edit it with any text editor (we recommend making a backup before editing it just to be safe). Start by finding the following entry:

<globalization culture="auto" uiCulture="auto" enableClientBasedCulture="true" />

If I wanted to force OfficeStatus Server to display dates and times better suited to the Latvian locale, I would change this value as follows:

<globalization culture="lv-LV" />

After making the above change, I save the web.config file and log back into the OfficeStatus web interface (note that all users will be logged out when you save a change to web.config). Again, I’ll see dates and times displayed as expected for the Latvian locale. This will be true for all users, regardless of browser settings.

For a full list of culture codes supported by the “culture” globalization setting above, please click here.

So, as you can see OfficeStatus offers a lot of flexibility in terms of locale support. If you need assistance with any of the above, please don’t hesitate to contact contact us.

OfficeStatus 5 supports the updating of user statuses via email. This feature allows users to send quick status updates to OfficeStatus from any device that supports the ability to send email messages.

To enable and configure this capability, navigate to Administration >> Status >> Email Status Updates.

How it Works

Email Status Updates work through the use of standard email protocols. Users will send status update messages to a dedicated OfficeStatus email account (via SMTP) using their preferred mail client, and OfficeStatus Server picks them up and processes them using the IMAP protocol.

When OfficeStatus Server collects status update emails via IMAP, it attempts to match the “from” address of each message to an OfficeStatus user account. If a match is found and the email subject line can be parsed correctly, the user’s status is changed accordingly. If a matching user is found but the email message subject cannot be parsed, OfficeStatus will send the user an error notification email.

Requirements and Preparations

Preparing to use OfficeStatus Email Status Updates feature involves the following steps:

1. Create a dedicated email account for use by OfficeStatus for the purpose of supporting Email Status Updates. You can create this email account on your corporate mail server, on GMail, etc. Ensure that IMAP support is enabled for the account.

2. Ensure that each OfficeStatus user has an email address assigned to their account profile. These email addresses will be used to match inbound status update email messages, so please double-check them for correctness.

3. Configure the OfficeStatus Email Status Updates feature (details below).

4. Test the feature by sending a correctly formatted email (details below) to the email account you created in step 1.

Configuration

The following Email Status Update configuration fields are available.

• Enable Status Updates via Email – By default, this feature is disabled, so you’ll first need to enable it here.
• IMAP Server Address – The fully qualified host name or IP address of your IMAP server (i.e. imap.gmail.com).
• Use SSL – When enabled, connections to the above IMAP server address will be made securely (using SSL/TLS). Many modern mail servers (including GMail) require the use of secure IMAP connections.
• Username – Enter the username of the email account to which status update email messages will be sent. In many cases, this username will be the same as the account’s email address. As noted above, this account must be used exclusively by OfficeStatus in support of the Email Status Updates feature.
• Password – The password associated with the above IMAP account.
• Move Processed Messages To – When specified, processed status update email messages will be moved into this IMAP folder after being processed (successfully or otherwise). Use of this field is not required, but is strongly recommended.

Once you’ve configured the above fields, use the Test Connection button to ensure proper connectivity to your IMAP account.

Important: When collecting email messages via IMAP, OfficeStatus Server will only process unseen messages in the account’s inbox. However, as an added safeguard we strongly recommend the use of the “Move Processed Messages To” option to limit inbox growth. For example, a common strategy is to move processed messages directly to the Trash (i.e. [IMAP]/Trash) folder.

Composing and Formatting Status Update Emails

In order to be processed correctly by OfficeStatus, status update emails must follow a simple set of formatting rules.

Firstly, the email must be sent to the dedicated OfficeStatus Email Status Updates email account created in Step 1 of the “Requirements and Preparations” section above.

Secondly, the email message’s subject line must include the user’s desired target status, and may also optionally include a due back and status comment information. The email subject format is as follows:

[Status Name] [Due Back Date/Time] [Status Comments]

Of the above, only the Status Name is required – the due back and comment information is optional. Now let’s look at each of these parts more closely.

• Status Name – This must precisely match either the full name of an existing status, or it’s alias.
• Due Back Date/Time – This value can either be relative (i.e. “1 day”) or absolute (i.e. “2pm”). Relative times can be specified as X min/minute/minutes/m, X hr/hour/hours/h, or X day/days/d.
• Status Comments – Any data that can’t be parsed as a status or due back date/time will be used as a status comment.

OfficeStatus uses a very flexible parser to extract due back date/time information. For example, all of the following accomplish the same result:

Ex 1: “Out 30m”
Ex 2: “Out 30 min”
Ex 3: “Out 30minutes”
Ex 4: “O 30m”

Note that in example 4 above, it is that “O” is specified as the alias for the “Out” status. You can specify aliases for statuses via the Status Editor.

Here are another set of examples, all of which indicate that the user will return tomorrow at 9am with a comment of “call my cell”:

Ex 1: “Out 1d 9am call my cell”
Ex 2: “O 1 day 9:00 call my cell”
Ex 3: “Out 8/16/2014 9:00am call my cell”

Note that if even if the user composed a due back date/time that was somehow invalid, the portions of the subject line that could not be interpreted would simply become part of the user’s current status comment.

If the due back/date time refers to a date/time that occurs in the past (ex: a user sends “Out 9am” at 3pm in the afternoon), the due back date will automatically be shifted to the following day.

Important: OfficeStatus will parse only the subject line of inbound status updates. Other message parts (such as the message body) will be ignored.

With the release of OfficeStatus v4.5 comes a new ability to constrain users to the departments of which they are currently a member.

The switch that toggles this feature on/off is part of the administrative user editor. Engaging it will ensure that the user will only see their own department(s). Users that are members of other departments will be invisible.

This feature extends beyond the in/out status board, affecting user messaging, status watches, etc. It can be beneficial in cases where your organization would prefer a higher degree of departmental isolation, limiting and simplifying interaction between users within the OfficeStatus interfaces.

Also, a related change – by default, users can no longer modify their own departmental membership as they could in releases prior to v4.5. If your organization wishes one or more users to have this ability, it can be allowed at the user level.

With the recent release of OfficeStatus v4.5 comes a powerful new in/out board feature – user status locks.

Locking a user’s status prevents it from being changed by external forces such as calendar sync, presence detection features (e.g. “status events”), status scheduling etc. When a user’s status is locked, it can only be unlocked via direct user interaction.

So how is this feature useful? Well, it’s actually designed to assist with a number of specific scenarios, but one common one is when an employee unexpectedly calls in sick. That OfficeStatus user may very well have an active status schedule, or may be actively syncing their status with their Outlook/Exchange calendar. In such cases, the user’s status will be automatically updated during sync operations, which is probably not what you want if the user is out sick.

Status locks resolve this problem by allowing qualified users (admin, receptionist, or manager role members) to temporarily prevent status changes for such users. As mentioned above, only a user-initiated status change will effectively unlock it.

It’s also possible to use screen monitoring software if you have staff that are working remotely so you can use that to see exactly what staff are doing.

OfficeStatus v4.5 also provides a site-wide switch (off by default) that can prevent “normal users” (those that aren’t part of the admin, receptionist, or manager roles) from locking their own statuses.

Finally, status locks can also be observed in user status reports (an additional column has been added for this purpose).