The Basic Meeting List Toolbox

The Root Server Version 2.4.0 Release

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:

  1. The ability to have a popup menu appear when logging in as an administrator, allowing the administrator to select their language.
  2. 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).
$g_enable_language_selector

enables #1, and the next 3 concern #2.

The Language Selection Popup

If you set

$g_enable_language_selector

to TRUE, you get the following popup when logging into the Root Server:

NewPopup

The Administrator Email Capability

If you set

$include_service_body_admin_on_emails

to TRUE, then there is no immediate visible change. However, if you follow this link:

<em>&lt;WHATEVER YOUR ROOT SERVER URL IS&gt;</em>/client-interface/contact.php

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:

<em>&lt;WHATEVER YOUR ROOT SERVER URL IS&gt;</em>/client-interface/contact.php?<span style="color: red;">meeting_id=1234</span>&amp;<span style="color: green;">service_body_id=1234</span>&amp;<span style="color: blue;">from_address=Spasmodic+Von+Knucklehead+&lt;sknucklehead@example.com&gt;</span>&amp;<span style="color: purple;">message=This+meeting+has+moved+its+location+to+123+Main+Street.</span>

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 (

$include_service_body_admin_on_emails

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

auto-config.inc.php

file:

If you set

$include_service_body_admin_on_emails

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

$include_every_admin_on_emails

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.

Leave a Reply

Your email address will not be published.