A Project groups the subjects, sessions, cohorts, and collections that
belong to one line of work. It is also the permission boundary for nearly
everything in BrainSTEM: your access to a Subject, a Session, a Procedure,
or a Data acquisition comes from the Projects it belongs to, not from the
entry itself.
Why the project matters more than it looks
Because access flows downward, adding someone to a Project gives them the
same access to every Subject and Session in it, and to all the Procedures,
acquisitions, manipulations, and logs hanging off those. Removing a Project
from an entry removes that route in. This is why Subject and Session require
at least one Project: an entry with no project would be reachable by nobody.
The lab's own resources — Setups and their Equipment, Inventories and their
stock, Protocols, Licenses, Behavioral assays, Data storages — sit outside
this and keep their own permissions, shared with people and groups directly.
A project collaborator does not automatically get your rig or your reagent
inventory.
Roles
- Member
-
Can read the project and everything that inherits from it.
Cannot create or change entries.
- Contributor
-
Can create and edit entries in the project. This is the level
most forms check: a Subject or Session selector only offers
projects where you are at least a Contributor.
- Manager
-
Everything a Contributor can do, plus managing who has access.
- Owner
-
Full control of the project, including deletion.
Project fields
The add form asks only for the name and the groups that get access.
Select Create and continue to open the full form for
the description, publications, sharing, and repository details.
-
Name
Required
Text
-
How the project is identified everywhere it is selected.
Users pick projects by this name in most other forms, so
make it recognisable to collaborators, not just to you.
Names are unique across all of BrainSTEM, not just within
your own records, so a name another lab has already used
will be refused. Include something identifying — the lab,
the study — rather than a generic label like "Pilot".
-
Authenticated groups
Create only
Multiple selections
-
The groups given access when the project is created. This is
the fastest way to share a project with a lab. After creation,
access is managed from the project's own page rather than from
this form, where you can also invite individual people.
-
Description
Rich text
-
What the project is for. This is the first thing a new
collaborator — or a reader of your public project — will use to
understand the work, so say what the question is and what the
data are, not only the title in longer form.
-
Public access
Consequential
Yes/no
-
Publishes the project and everything that inherits from it to
the public portal, readable without an account. This is
one-click sharing, so treat it as a deliberate act: check what
the project contains first, because subjects, sessions,
procedures, and notes all become visible together.
-
Publications
Multiple selections
-
The papers this project's data support. Linking them is what
lets a reader move from a publication to the underlying
records.
-
Tags
Multiple selections
-
Free labels for organising and filtering. Tags are shared across
BrainSTEM, so prefer an existing tag over a near duplicate. The
suggestions offered are the tags already used in your projects.
-
Name used in storage
Text
-
The name this project has in your file storage, when it differs
from the name above. It is what connects records here to
directories on disk.
-
Repository links
Structured details
-
Links to where the data or code live externally — a DANDI
set, a GitHub repository, an institutional archive.
-
Extra content
Structured details
-
Additional key/value details the standard fields do not cover.
Prefer a real field where one exists: extra content is not
searchable or comparable in the same way.
Permissions
A Project's own access is held directly on it, by group and by person, rather
than inherited from anywhere. You need Manager or Owner to change who has
access. Deleting a project is an Owner action and affects everything that
depends on it for access, so check what inherits from it first.
API access
Projects can be read and written through
/api/private/stem/project/. The corresponding public route is
read-only and exposes only projects marked for public access.
Project documentation
