- PROTIP: Simplifying Standard Service Body Editor Screens
- PROTIP: Unpublishing vs. Deleting
- How Auto-Radius Works
- PROTIP: A Quick Geeky Way to Update NAWS World IDs
In many cases, we want to set up a distributed administration system for a BMLT installation, in which the individual editors for Service bodies have the simplest possible user experience. This allows the position to be opened to more candidates. Additionally, we may not want Service Body Administrators editing the actual Service body information (such as the Service body name, description or contact email).
This post will use the Greater New York Region as an example. The Region is set up so that the RSC is the “Parent Service Body” for the 12 ASCs that comprise the Region. Each ASC has an individual Service Body Administrator that logs in and edits the meeting information for that ASC. The RSC Administrator has the right to edit all meetings, but does not actually edit meetings unless specifically tasked to do so by the ASC Service bodies. The RSC Administrator edits and administers the ASC Service body information for each of the ASCs. The ASC Service Body Administrators only edit meeting information, and the GNYR RSC root server is set up in the manner described by this post. (DISCLAIMER: I am the GNYR RSC Administrator at the time of writing this post).
THE STANDARD SETUP:
In the standard setup, the Server Administrator will assign a unique Service Body Administrator to each Service Body (one for the RSC, and one for each ASC). The Server Administrator will also assign one Administrator to each Service Body as a “Primary Administrator.”
Figure 1 shows how this is done for the Suffolk ASC. Note that the Primary Admin for the Suffolk ASC is the Suffolk ASC Administrator.
As a result of this assignment, when the Suffolk ASC Administrator logs in, they see three different choices (Figure 2). The top one, “Service Body Administration” is the one that we would like to eliminate as a choice. We want them only to edit meetings (or their own account information).
THE ALTERNATE SETUP:
Before proceeding, we should review how rights are assigned to Service Body Administrators.
There are two basic permission levels for BMLT administrators: Service Body Administrators, and Service Body Observers. Service Body Administrators are able to edit information for meetings, and, if assigned, Service bodies. Observers can only see hidden information in meetings (as long as they are given permission to do so).
Simply creating a user and assigning them a level as a Service Body Administrator does not actually allow them to do anything more than log in and edit their own information. They cannot edit meetings, and cannot edit Service body information. They are only added to a “pool” of available Service Body Administrators.
A Service Body Administrator can be given rights by the Server Administrator, or a Primary Service Body Administrator in one of two ways:
- The Server Administrator assigns the Service Body Administrator as the “Primary Admin” for a Service body (done via the top popup menu in the Service Body Administration Console, shown to the Server Administrator), or
- Either the Server Administrator or the Primary Admin for a Service body can assign them as a “guest editor” by checking that Service Body Administrator in the checkboxes in the Service Body Administration Console shown to either the Server Administrator, or the Primary Admin for a Service Body.
This page has an interactive demonstration of the rights of Primary Admins, vs. “guest” admins.
The important thing to remember here, is that “guest” admins cannot edit Service body information. They can only edit meeting information. With this in mind, what we want to do with the ASCs, is have their Service Body Administrators assigned as “guest” administrators; not Primary Admins.
Admins can be assigned as Primary Admins for more than one Service body. This means that we can assign the RSC Primary Admin as the Primary Admin for each of the ASC Service bodies.
Figure 3 shows how we assign the RSC Admin as the Primary Admin for each ASC.
Figure 4 shows how we assign the ASC Service Body Administrator as a “guest” admin.
This results in the ASC admin seeing the screen shown in Figure 5. Note that “Service Body Administration” is no longer shown as a choice. This is because the ASC Service Body Administrator no longer has edit rights for the Service Body.