In short
People sign in with a local account — a username and password held by Linkr; an agent comes in with a user’s personal API key. Rights are described by resource and action (read, write, delete, execute) and grouped into roles, granted at workspace level then inherited by its projects, which a project may override. The right to run code is kept separate from the rest: it is the most sensitive one.
All of this assumes server mode
In browser mode there is no account and no authentication: whoever is at the screen has access to everything their browser holds. The Users and Roles pages there show a notice saying a server is required.
Signing in
Authentication is local: Linkr keeps accounts in its own database, and the password is compared against a hash. The first administrator is created by the setup wizard, described in Production install.
Single sign-on does not exist yet
LDAP, OIDC and SAML are planned — the internal structure anticipates them, an account being markable as managed by an external directory — but none is implemented. Do not put Linkr into your single sign-on chain today.
A user cannot change their own password
The button exists in the profile but goes nowhere: the function is not available server-side. In practice, only an administrator resets a password, from the user’s record.
There is also no email sending: no reset by mail, no invitations. Passing the password on is up to you.
Personal API keys
A second way in exists, for programs rather than people: the API key. Each user creates their own in User settings › API keys, and an external client — Linkr’s MCP server, plugged into LibreChat or OpenCode — uses it to act as them, with their permissions, without knowing their password.
- Shown once, on creation. Linkr keeps only a fingerprint of it: a lost key is replaced, not recovered.
- Expires after 30 days, 90 days, a year — or never, if you choose so.
- Can be revoked at any time, with immediate effect.
- Does not mint other keys. Creating, listing or revoking a key takes a real sign-in: a stolen key cannot be used to make another.
Every action taken with a key shows as such in the access log — see Configuration. Connecting a client step by step: MCP server.
Accounts
The Settings › Users page manages accounts: username, password, global role, first and last name, email, affiliation, profession and ORCID.
The ORCID is worth filling in: it follows the user into everything they publish, and it is how another instance recognises the author of an imported entity instead of crediting whoever imported it.
The guardrails
Several operations are refused by the server, and rightly so:
- You cannot disable yourself, nor delete your own account.
- The last active administrator can be neither demoted, disabled nor deleted — so the door cannot be locked from the inside.
- An account with no password cannot be enabled: it could not sign in.
- Deleting a user does not delete their content. The projects and entities they produced remain, with their authorship recorded.
User management
Manage users and their roles.
| Username | Role | Status | ||||
|---|---|---|---|---|---|---|
| admin | Claire | Martin | Hôpital Nord | Administrator | Active | |
| m.dupont | Marc | Dupont | Hôpital Nord | User | Active | |
| s.nguyen | Sophie | Nguyen | Université Exemple | User | Active | |
| l.bernard | Léa | Bernard | Hôpital Nord | User | Disabled |
Hover a button to read what it does — or why it is greyed out.
The directory is open to any signed-in user
To add someone to a workspace, you have to be able to find them. A reduced list — name, affiliation, profession, ORCID — is therefore readable by any signed-in user. It carries neither email nor role, and managing accounts stays with administrators.
Organizations
Settings › Organizations holds the instance’s directory of institutions: hospital, university, research institute, company, consortium. Each carries its name, country, website, a reference identifier — a ROR, an institutional code — and free-form fields.
An organization serves two purposes: attaching a workspace to the institution behind it, and co-signing what you publish. A shared entity therefore stays attributable to the institution it came from, even after several reuses.
Reading open, writing protected
Any signed-in user can consult the directory — it is a shared reference. Creating and editing require the matching permission, genuinely enforced by the server.
Roles
This is the heart of the model. A right is written resource : action, and a role is a list of rights.
Account-level roles governing instance-wide management (users, roles, organizations, application database). "All workspaces" / "All projects" grant access to every workspace or project without being a member.
| Permission | Administrator System | User System | Auditor |
|---|---|---|---|
| Users | |||
| Read | |||
| Write | |||
| Delete | |||
| Roles | |||
| Read | |||
| Write | |||
| Delete | |||
| Organizations | |||
| Read | |||
| Write | |||
| Delete | |||
| Application database | |||
| Read | |||
| Write | |||
| Delete | |||
| Workspaces | |||
| Write | |||
| All workspaces | |||
| Read | |||
| Write | |||
| Delete | |||
| All projects | |||
| Read | |||
| Write | |||
| Delete | |||
| Access log | |||
| Read | |||
The actions
Read
Consult.
Write
Create and modify.
Delete
Remove.
Execute
Run code. Only a few resources carry it.
Not every resource carries all four actions: you do not “delete” a summary page, and only a few accept execution.
Two scopes
- Workspace roles describe what a member may do in a workspace — and, by inheritance, in its projects.
- Global roles cover instance administration: accounts, roles, organizations, the access log, creating workspaces.
The roles that ship
| Role | Scope | What it allows |
|---|---|---|
| Viewer | Workspace | Consult, without modifying or executing anything. |
| Editor | Workspace | Create, modify and run code. Does not manage members. |
| Owner | Workspace | Everything, including deleting and managing members. |
| Administrator | Global | Everything, everywhere, without needing to be a member. |
| User | Global | No global rights. Access comes from workspace membership. |
These roles cannot be deleted, but their rights remain editable: you may decide that an editor, at your institution, does not run code.
One deliberate exclusion from the Editor role
An editor sees the member list but does not change it — that is an owner’s responsibility. An administrator can still grant that right to a custom role.
How a right is resolved
The order matters, and it answers most questions.
The administrator comes first
They bypass the permission system. That is what guarantees a mistake in the role matrix cannot lock everyone out.
The role set on the project
It may widen or restrict the inherited role. Set to “none”, the project disappears for that member, even though they belong to the workspace.
The role inherited from the workspace
The common case: you are an editor of a workspace, therefore an editor of its projects.
Two global rights cut across everything: all workspaces and all projects grant access without membership — convenient for a support lead, to be used with judgement.
A third global right, other projects’ server folders, allows importing a server file from a folder bound to another project (its IDE, scripts or datasets folder). Without it, those folders are refused and hidden in the picker, even inside the allowed roots; administrators always have it.
Creating a workspace and editing a workspace are two different rights
The first is global: it allows creating them. The second belongs to one given workspace: it allows editing that one. Their names look alike; their scopes have nothing in common.
Accounts and roles stay administrator-only
The matrix does show rights over users and roles, but the server requires the administrator role for those two screens. Granting those rights to a custom role will make the tabs visible without making them usable. Organizations and reading the access log, by contrast, really can be delegated.
Code execution, kept apart
This is the most sensitive right: it allows arbitrary code to run on the server. It is therefore separable from everything else — a role can read everything and execute nothing.
Linkr distinguishes two things that could be confused:
- Running in the IDE — R, Python or SQL written by the user. This is the right to watch.
- Displaying a widget — running the code of an already-defined analysis, at display time. Far more limited, and still distinct from the above.
The boundary is held server-side: rendering a built-in component runs a program belonging to the application from a validated description, never code sent by the browser.
And the master switch
Independently of roles, LINKR_ENABLE_CODE_EXECUTION=false turns execution off across the instance. For a locked-down deployment it is the most useful setting — see Configuration.
What someone without the right sees
Three behaviours, depending on the case — and in all of them the real check is done by the server: the interface only explains.
- A tab stays visible, its contents replaced by a notice: “Your account doesn’t have permission to access this section.” Showing that a feature exists beats making it vanish.
- A button stays visible but inactive, with a tooltip explaining why.
- A project disappears when its role is set to “none” — there, discretion is the intent.
Going further
- Configuration — the execution switch and other instance settings.
- Members and roles — granting these roles day to day.
- Production install — creating the first administrator.
- Files on the server — the rights that open the server picker.