Configuring users
You can choose what data is stored with your users. The simplest form is for your users to only have a username — this might be all you need. Usernames are always lower case.
The server will display usernames with title case (intial caps) if config setting IS_PRETTY_USERNAME_TITLECASE is Yes.
For example, do this if the usernames you are giving students are based on their names.
You can also add other fields to users but these are not necessary. It might be helpful for you to add them so you can more easily identify the students when on the race server. By default, users have none of these extra fields. If you want them you need to explicitly add them — ideally during the set-up phase before you register any users.
These are the optional fields you can add:
- email address
- first name
- last name
- external username — for example, if students have a college username
- external ID — perhaps the ID from an online learning system like Moodle, Canvas, or Blackboard
If you use external username and external ID, you should configure the names of those columns too. For example, the external username might be “College username”, or the external ID “Moodle ID”. See notes on each, below.
You can change these settings after you’ve registered users, but be careful because if you add a new field after you’ve registered any user, the field will be blank (you must edit each user manually to fix it). Similarly, removing a field won’t purge its value from the database.
If your students are using GitHub, the GitHub account information is stored in addition to these fields. You don’t enter that, as the race server stores it when each student authenticates their GitHub account.
Email address
Currently, the race server never sends emails, so you only need add this if you think it will be helpful to disambiguate students.
First name and last name
Again, these are only used for identification. If you’ve allocated usernames based on names, then also storing one or both of these might be useful (for example, if you’ve allocated usernames like “olivia1” and “olivia2”).
External ID
External IDs are currently only for your convenience — the race server does not use them.
The external ID might be useful if you use an online learning system like Moodle, Canvas, or Blackboard. The buggy race server does not directly help with marking or assessment, but if you are going to need to automatically match buggy race usernames with students’ IDs on such a system, it might be useful to store this with the user.
External username
If students have another username or ID that you use, store it here. If you require your students to log into a remote server, using a different username to the one on the buggy race server, then set this here.
You can also set the name of this username (for example, “College username”) using the config setting EXT_USERNAME_NAME. This can help prevent confusion with students between different usernames. You should also set EXT_USERNAME_EXAMPLE to be an example username: it’s very helpful to students (and maybe staff) if the format of the username helps dismabiguate it from other usernames they might need in other contexts.
Placeholders and login message
If you’re running the buggy racing as part of an institution (such as a college), it can be confusing to students which username should be used on which website. You can set example placeholders for both the username and external usermname (if you’re using it) with the config settings USERNAME_EXAMPLE and EXT_USERNAME_EXAMPLE respectively.
You can also set a custom message that appears on the login page: see how to set announcements.
| Setting | Description |
|---|---|
IS_PRETTY_USERNAME_TITLECASE | Should usernames (which are always lower case) be displayed using title case? For example, choose Yes if the usernames you’re using are effectively students’ names. Login is always case insensitive, so this only affects how usernames are displayed, not what users need to type. Default value: Yes |
USERS_HAVE_EMAIL | Do users need email addresses? The server doesn’t send emails so you don’t need this field unless it’s a useful way of identifying a student. Default value: No |
USERS_HAVE_FIRST_NAME | Do users need to have a first name? You might be using each student’s first name as the username, in which case you don’t need this. Default value: No |
USERS_HAVE_LAST_NAME | Do users need to have a last name? If you can already identify your students from the other fields, you might not need this. Default value: No |
USERS_HAVE_EXT_USERNAME | Do users have an external username or account that’s specific to your organisation or institution? You might not need this, or you might already be using it as the username — in which case choose No. Note: the race server does not use this for authentication (i.e., there is no OAuth implementation). However, if your users need to log into a remote server for development and you are using VS Code workspace files, you will need this to be Yes — unless you’re simply using those external usernames as the students’ race server usernames when you register them. Default value: No |
USERS_HAVE_EXT_ID | Do users have an ID from an external system? This might be useful if you want to match students with their existing ID on another system like Moodle, Blackboard or Canvas. You don’t need this unless it’s a useful way of identifying a student. If you do set this to Yes, you should also set EXT_ID_NAME to describe what it is. Default value: No |
USERNAME_EXAMPLE | A placeholder string used in the login form. This can be especially helpful if students use a different username for accessing other college systems. You can set this to be blank. Default value: hamster |
EXT_USERNAME_NAME | If users have an external username, what is it called? For example: “College username”. This is to clearly differentiate the race server username (which students use to log into this race server) from this external one (which they presumably use to access other course systems). Keep it short, because it’s used on buttons in the admin. This setting is ignored if USERS_HAVE_EXT_USERENAME is No. Default value: Ext. username |
EXT_USERNAME_EXAMPLE | If users have an external username, provide an example format (e.g., abcd123 or ada@example.org). Note that this only serves as a placeholder suggestion when inputting — it’s not used to validate or force the format of inputs. This setting is ignored if USERS_HAVE_EXT_USERENAME is No. Default value: abcd123 |
EXT_ID_NAME | If user have an external ID, what is it called? For example: “Student number”, “Moodle ID”, “Blackboard ID”, “Canvas ID”. This setting is ignored if USERS_HAVE_EXT_ID is No. Default value: External ID |
EXT_ID_EXAMPLE | If users have an external ID, provide an example of what it might look like. This setting is ignored if USERS_HAVE_EXT_ID is No. Default value: 12345 |
IS_TA_EDIT_COMMENT_ENABLED | Teaching Assistants cannot edit user data. But do you want TAs to be able to add or edit comments left by staff? Default value: Yes |
IS_TA_PASSWORD_CHANGE_ENABLED | Administrators can change all other users’ passwords. Choose Yes if you also want Teaching Assistants to be able to change (non-staff) users’ passwords. Note that students who forget their passwords cannot reset them, and will need to ask a staff member to do it — so enabling TAs might be helpful. Changing a student’s password does not require the auth code. Default value: Yes |
USER_ACTVITY_PERIOD_S | The period (in seconds) over which each logged-in user’s activity is logged. Pragmatically, this avoids updating the database on every request, because usually you’re only concerned about whether or not a student has logged in recently, not the accuracy of the timestamp. This updates the “last activity” timestamp if the user sends a request this-number-of-seconds since the last recorded activity. Default value: 300 |
- Previous: Social sites config
- Next: Project config