User management

Contents of this page:

User management

The Users admin page lists all the users registered on the race server, showing data for each and providing links to investigate and edit each one.

Students are listed before staff.

You can choose which columns are displayed by clicking the white buttons at the top of the table: they toggle the display of the respective column. The show/hide choices are stored in your browser, so will be used whenever you revisit this page.

In general, only administrators who know the authorisation code can change other users’ data.
Depending on config settings (in the “Users” group), Teaching Assistants may be able to add staff comments and reset students’ passwords.

Active vs. inactive users

If you mark a user as inactive, they are effectively suspended: they won’t be able to log in, their existing login session will be terminated, and they won’t be included in any downloads.

Types of user

A user can be an enrolled student. This is used to distinguish students who are actively engaged in the project from other users (such as staff — although these are not mutually exclusive). In general, the race server decides if a user should be included in the following collections based on their student status:

display of task texts
download of student data
download of buggy data

It is possible for a staff user to also be a student. This may be useful before the project starts so staff can familiarise themselves with the server. In general, you probably won’t want staff to be marked as students once your enrolled students have been registered. If you do, staff activity will be included in the “students” statistics and downloads.

Staff users: administrators and Teaching Assistants

There are two types of staff user:

Administrator
Administrators are staff users with access to all the admin features of the race server.
Some admin changes require the admin user to also know the site’s authorisation code.
Teaching Assistants
Teaching Assistants (TAs) are staff users with mostly read-only access.
TAs may be able to set (i.e., change) students’ passwords if the config setting IS_TA_PASSWORD_CHANGE_ENABLED is Yes, and edit staff comments on a user’s record if IS_TA_EDIT_COMMENT_ENABLED is Yes.

The username you nominated as the admin user during the setup-up phase is automatically an administrator.

Inspect a user

When you’re looking at the list on the Users page, you can click on ✱ to view the for-staff-only comment. The JSON button (with a spanner icon) displays the last-uploaded JSON.

You can click on the username to inspect the user’s settings and task texts in detail.

Commenting on a user

Staff users can leave comments on a user that are only displayed to other staff users on the server (that is, students do not see these comments). By default Teaching Assistants can edit comments as well as read them (although you can disable this by setting IS_TA_EDIT_COMMENT_ENABLED to No). You’ll see comments (if any) when you inspect a user, but there’s also a button (marked ✱) for quick inspection when you’re listing all users (Admin → Users).

Changing passwords

Any user can change their own password while logged in.

If you’re an admin user — or a Teaching Assistant and the server has enabled this — you can change any other user’s password (but if they are an admin, you’ll need the auth code too).

If you forget your password and you’re not logged in, you cannot reset your password from outside (the server doesn’t send emails, so can’t send you a reminder). You need a staff member to reset it for you.

Here’s the emergency procedure for when no staff members can log in (try not to let this happen ;-) ).

Edit a user

If you click on the username in the Users list, you can inspect all the settings for that user, including their task texts and buggy data. From there you can choose to Edit or Change password.

You can change the staff status of any user when you edit them.

Be careful not to revoke administrator status from all the staff users. If you do, you’ll need to create a new administrator by overriding config settings using environment variables.

Deleting a user’s GitHub details

If a user has a GitHub username (or an access token, which is issued to the server if it’s granted access via the app), you can use the Delete GitHub details button on their edit page.

This might be useful if they’ve accidentally linked to the “wrong” GitHub account (this sometimes happens if students have more than one GitHub account). The server doesn’t let you edit these, because they are only set as a consequence of the OAuth app allocating them. Similarly, users cannot delete (or change) their own GitHub details.

Deleting GitHub details simply removes the data from the database. It will not make any changes on GitHub, so if the user has cloned the editor repo, that will still be there. The race server will no longer offer the user a link to it, of course, because that requires the GitHub username, which you’ve just deleted.

Deleting a user

You can delete a user record. Go to edit them, and click on Show delete form. The delete form requires confirmation and the authorisation code.

When you delete a user, their buggy and task texts (if any) will also be deleted. You can’t get them back; there is no undo. For this reason, consider marking them as inactive (set Is active? to No), which effectively suspends them without destroying any data.

An user who has been marked as not active cannot log in.

Downloading user data

You can download a comma-separated values (CSV) file containing the current user data.