BMLT Workflow for WordPress Admins
You must have a functioning WordPress installation to install this plugin. To use the plugin effectively, you require a functioning BMLT Root Server, with BMLT version number >= 2.16.4 , and a login on the BMLT Root Server that will be used to make meeting changes on behalf of trusted servants.
The plugin works by making changes to BMLT on behalf of WordPress users (Trusted Servants). To facilitate this, it requires you to create a BMLT Root Server user that will be used to make changes to BMLT meetings.
This BMLT Root Server user needs to be a Service Body Administrator, and enabled to edit for any of the service bodies you wish to use within the BMLT Workflow plugin. Pick a random password for this user and save it somewhere, as you'll need it to configure BMLT integration in the plugin.
Install the plugin by using Add New from your plugins menu:
Search for bmlt-workflow and if it looks similar to below, install.
First step is to configure the BMLT Integration settings. Find the BMLT Workflow menu in your WordPress administration bar and select 'Configuration'
Select 'Update BMLT Root Server Configuration'
Input your BMLT server address, plus the username and password for a user configured inside BMLT.
You need to test these settings before you are allowed to save. If you've configured this correctly, you will see some ticks showing that your BMLT Root Server is available and can be logged into with these details.
The Service Body configuration tab is where you can choose the BMLT Service Bodies that appear on the end user meeting change form. By ticking the 'display on end-user form' box, meetings associated with this service body will be searchable and changes/new meetings can be submitted. By adding users to the 'WordPress users with access' box, WordPress users (trusted servants) that you create can be given access to the submissions management page for this service body. If you add the same trusted servant to multiple service bodies, the submissions management page for this trusted servant will show the aggregate of all submissions for all authorised service bodies. For more information about configuring WordPress users, see [WordPress User Configuration] below.
Don't forget to press 'Save' to ensure your service body changes are saved to the plugin.
In the image below, trusted servants with WordPress accounts 'admin' and '2' are provided access to manage Mid-Hudson Area Service, and this service body is also shown on the end-user form.
Create a new page on your WordPress site to host the meeting change form.
Inside this page, you need to include the text '[bmltwf-meeting-update-form]'. Wherever this text is located, the form will be displayed when an end-user lands on this page.
If everything is going well, by selecting 'view' on your page from the WordPress pages tab, you should see a working BMLT Meeting Change form and be able to search for meetings and perform meeting change requests.
This section describes all the options currently available on the plugin configuration page.
-
Email From Address
- When the plugin sends notifications to a submitter, or notifies the trusted servants that they have a new submission to approve, this will be the email address used in the From: line
-
Default for close meeting submission
- Close meeting submissions can either unpublish or delete the meeting entirely. This setting chooses the default for trusted servants, but they can always override this at the time they approve a close meeting submission.
-
Trusted servants can delete submissions
- This setting determines whether the Delete button will be enabled for trusted servants within the submission page. Deleting a submission removes it entirely from the list, but does not affect the meeting it refers to.
-
Google Maps API Key
- BMLT Workflow requires Google Maps connectivity to display the map view in the quickedit window (Maps Javascript API) and to geolocate meetings before sending to BMLT (Geolocation API). BMLT Workflow can either use a Google Maps API retrieved from the BMLT Root Server, or you can provide a custom API key just for BMLT Workflow. If you have issues with Google Maps, such as having referer restrictions on your BMLT Root Server API key, you can use a custom API key here instead. See https://github.com/bmlt-enabled/bmlt-workflow/wiki/BMLT-Workflow-for-WordPress-Admins#google-maps-api-key for more details.
-
Remove Virtual Meeting details when venue is changed to 'face to face'
- If a user submits a meeting change and may adjust the venue type from Virtual Only to Face-to-Face. This setting determines whether we clear the virtual meeting settings entirely during this type of change, or if we leave them in BMLT.
-
Optional form fields
- Depending on your use of BMLT, you may want to enable or disable some form fields, make them required, or rename them entirely. For example, some countries may use the term 'Zip Code' and others may use 'Post Code'. This section allows you to change the display of these fields and the associated behaviour of the submission form.
-
Field Service Office configuration
- The Australian Region emails the local field service office on new meeting creation, to allow them to send out new meeting packs. This feature is optional, so this setting allows you to disable this functionality, or change the email address for your local FSO.
-
Email Template for New Meeting
- This is the email template sent to the form users when they successfully submit a meeting change.
You can add fields to the email templates to substitute content from the form submission
The following fields are currently supported:
Within fso template body only:
{field:submitter_name}{field:contact_number}{field:meeting_name}{field:starter_kit_postal_address}
Within submitter template body only:
{field:submission}
You can assign any WordPress user permission to manage submissions for a service body. As you will likely not want to give any more access to WordPress to most plugin users, you can assign them the 'BMLT Workflow Trusted Servant' role when creating them within WordPress. This role only has permission to view the submission page, and will be filtered by the service bodies that your user is assigned to.
The following settings should be configured for your custom Google Maps API key. Ensure you have created the restrictions on APIs to Maps Javascript API and Geolocation API.
Do not use an unrestricted key for this plugin.
