Exercise 1: Roles, Privileges and System Users

The exercises in this article are generally applicable to the System Administrator.

Roles are the means by which access Privileges are assigned to Users. Privileges determine which parts of Beacon a User may access and the tasks they may carry out according to their role requirements.

When a new site is created a number of default Roles and Privileges are already set up and these may be sufficient for a new U3A. 

The first exercise below (a) demonstrates how to create Roles and how to allocate Privileges to those Roles. Further guidance can be found in 8.2 Roles and Privileges.

The second exercise (b) demonstrates how to create System Users. Further guidance can be found in 8.1 System Users.

a) Creating Roles and Privileges
Access is given to users of the Beacon system according to the needs/requirements of given Roles. The first thing to do is create the Roles and Privileges for Users (Note: the access to these Roles can always be edited at a later date).

From the main screen go to the right-hand column and select: Roles and privileges

From this screen you can create or remove Roles.

As there are probably Roles already created for you in your demo system, Why not create roles for an Assistant Treasurer, an Assistant Membership Secretary and an Assistant Groups Coordinator?

As time passes, it is possible that Role holders will require changes to the access allocated to their Role. As System Administrator you have access to everything on the system, and so if you wanted to test a given Role’s access privileges and view the functions that they can see, you would need to log in as that Role.

Tip: Because this is a test environment you could create a fictional Role e.g. ‘assistant to treasurer’ and provide both these treasurer roles with identical privileges. The assistant Role can then be allocated to a fictional name for you to use, so that you can log out of the Administrator Role and then log back in as the test Role you have created, enabling you to review/test the access of that Role’s privileges.

By clicking on any given Role, you can see the list of access privileges on offer (snapshot below). Tick any one as appropriate.

b) Adding System Users
System Users are holders of those Roles which are required to perform some administration on the system. Having created Roles and Privileges you now need to allocate the Roles to your System Users.

To add a new User, select System Users from the Set up section on the home page.

Select: Add New User from the top of the page.

Now allocate their name to a Role:
Select a name of the member from the drop-down list and allocate a login (in a real environment this would show a list of your members).  Remember you are using fictional data so any name can be selected from the list, just make sure you advise the role holder of this.

The log-in name will be the initial and last name all in lower case (no spaces). When saving the User a password is created for them (shown further down below).  Now select the Role that is allocated to the User, by ticking one of the boxes below.  This is then linked to the allocated Privileges for that Role.

Access privileges can (only) be edited by the System Administrator - at any time.

Note: In a real live situation the log-in name will always be in lower case with no blank spaces that is personal to the user (e.g. jbloggs), and not relating to a Role (e.g. Membership Secretary).

Temporary Password: Always remember that passwords are case sensitive and MUST be typed as they appear on screen.

When the new User logs in to Beacon using their temporary password, they will be asked to change this password immediately to a password of their choice. Should a User forget their password it can be re-set by the SA from this screen.

Note: Role assignments can be changed when a User changes their Role, without having to change their log-in details.

See also section 8.2 for setting Roles and Privileges.

End of exercise