- The address the person signs in with, and their identity across BrainSTEM. It is also what an Admin group matches on when applying security policy by domain, so an institutional address rather than a personal one is usually what you want.
- First name / Last name
- How the person is shown wherever a name appears — as the creator of an entry, as the performer of a procedure, in member lists. Worth filling in: an account with no name shows as a bare email address everywhere.
- Email verified
- Whether the address has been confirmed. Set by the sign-up flow rather than by hand in the ordinary case.
- Active
- Whether the account can sign in. Turn it off rather than deleting when someone leaves: their entries stay attributed to them and their history stays intact, which deleting would destroy.
- Administrative roles
- Area-wide authority, each granted separately: project admin, user admin, group admin, and the reviewer roles for taxonomies, resources, and dissemination. The three reviewer roles are what let someone accept or reject submissions to the shared catalogs. These apply across all of BrainSTEM, not to particular records, so grant them narrowly.
- Staff / Superuser
- Django's own access flags. Superuser bypasses object permissions entirely, so it should be rare and deliberate — the administrative roles above are the right tool for delegating a specific area.
- Profile
- The person's own details, edited inline: image, bio, institution, department, city, country, website, ORCID, and Google Scholar. It also holds two working preferences — the preferred atlas, which pre-selects the Atlas filter on every region selector, and the active-projects filter, which narrows selectors to the projects the person is currently working on.
- Name used in storage
- The person's directory name in your file storage, when data are organised by user and it differs from their name here.
Feedback & community