As always, you get the release from this zip file.
(NOTE: You should always use the zip file, and not do a Git pull from the repository. The reason for this, is because the project uses Git submodules, and they are not included in pulls).
This release adds two significant features:
- The ability to have a popup menu appear when logging in as an administrator, allowing the administrator to select their language.
- Support for the capability to send a message via email to meeting list administrators (This is actually a re-implementation of a feature that the 1.X version of the Root Server had).
#1 Allows a root server to be shared amongst administrators that speak different languages (for example, the Scandinavian countries in Europe, or bi-lingual provinces of Canada).
#2 will not be immediately obvious, as it will require support from the clients. The first client to take advantage of this will be the next version of the BMLT iOS App.
Here’s what will need to change in order to support these:
The auto-config.inc.php File
This is the basic configuration file for the Root Server. It is installed at the same level as the main_server directory, and contains the basic configuration for the server.
It will have the following four lines added by the installer wizard (or you can manually add them):
$g_enable_language_selector = FALSE; // Set this to TRUE (or 1) to enable a popup on the login screen that allows the administrator to select their language.
$g_enable_email_contact = TRUE; // If this is TRUE (or 1), then this will enable the ability to contact meeting list contacts via a secure email form.
$include_service_body_admin_on_emails = FALSE; // If this is TRUE (or 1), then any emails sent using the meeting contact will include the Service Body Admin contact for the meeting Service body (ignored, if $g_enable_email_contact is FALSE).
$include_every_admin_on_emails = FALSE; // If this is TRUE (or 1), then any emails sent using the meeting contact will include all Service Body Admin contacts (including the Server Administrator) for the meeting (ignored, if $g_enable_email_contact or $include_service_body_admin_on_emails is FALSE).
enables #1, and the next 3 concern #2.
The Language Selection Popup
If you set
to TRUE, you get the following popup when logging into the Root Server:
The Administrator Email Capability
If you set
to TRUE, then there is no immediate visible change. However, if you follow this link:
You will be able to send an email.
Of course, we have lots of stuff in there to prevent spammers from hijacking the process.
First of all, you cannot specify the email address that you want to send to. You can only specify your own email address.
You must provide the BMLT Root Server ID for both the meeting and the Service body to which the meeting belongs. If the Service body ID is not the one for the meeting Service body, the message is rejected as spam.
You provide a textual message with the comment. You cannot have more than two (2) URLs in the message, or it will be flagged as spam.
We will not send an auto-response, as spammers can hijack that.
The resulting URL is going to look like this:
These are the parameters:
-
<span style="color: red;">meeting_id</span>
This is the ID of the meeting itself. This is not the NAWS Committee Code. It is the internal ID used by the BMLT server to uniquely identify the meeting.
-
<span style="color: green;">service_body_id</span>
This is the ID of the meeting’s Service body. This is not the NAWS Committee Code. It is the internal ID used by the BMLT server to uniquely identify the Service body. Additionally, it must be the ID for the Service body identified by the meeting record.
-
<span style="color: blue;">from_address</span>
This is the from address (the address the user enters as their own email address). It must be in valid email form (address -at sign- domain). It can have the name of the user, in which case the email address needs to be surrounded by greater-than and less-than signs (<…>).
-
<span style="color: purple;">message</span>
This is the message text itself. It needs to be urlencoded (URL-escaped).
If you send to the above URL with no parameters, the server will return either “1” or “0”. If it is “0”, then that means that the capability is not supported (
is FALSE, or is not specified at all).
Of course, if you send to a pre-2.4.0 server, you get a 404.
There are a couple more settings in the
file:
If you set
to TRUE, then the Service Body admin email contact (entered in the Service Body Administration page of the Root Server) will be included. If the meeting itself doesn’t have an email address specified, then this will be the only email anyway. However, if the meeting has an address specified, then, instead of just sending to the email assigned to the meeting, it will also be sent to the Service Body email account (NOTE This does not send to the email associated with the “My Account” email. It will be the email that is assigned to the Service body).
This will include only 1 additional (if any additional) email address.
If you set
to TRUE, then every Service body’s admin email will be included (NOTE: This does not mean every admin on the Root Server; only the admins concerned with the meeting. For example, the ASC administrator, and the RSC administrator would be included, but no other ASC administrators will be included).
The Server Administrator would also be included.
The reason for this, is to ensure that no emails get “lost in the cracks.” Many emails sent using these forms will be cries for help, and some Service bodies want their Helpline or PI committees to be aware of the emails.
Two other features added with the 2.4.0 release mainly concern administrators: It is now possible to go directly to a meeting listing in the administration browser (the logged-in browser used by observers), and to get a meeting record for editors. These are indicated in the email received by the administrators, so this allows the convenience of going directly to the meetings indicated by the contact.