Members
Add people to a team, give them a role, and answer "who did that" afterwards.
How it works
Everything in Deplo belongs to a team, and a person reaches it through a membership. A membership carries a role, which is a named set of capabilities.
There is no email invite flow. Deplo does not send mail on its own, and a self-hosted instance often cannot. Instead there are two paths:
- The person already has an account here: you add them to your team directly.
- The person has no account: an instance admin mints a registration link and sends it to them however they like.
Add somebody who already has an account
Open members settings
Open Settings -> Members.
Add a member
Click Add member.
Search, pick, assign
Search by username, pick them, choose the role, then Add to team.
They see your team in their team switcher immediately.
Invite somebody new
This needs an instance admin.
Open users settings
Open Settings -> Users, the system section.
Create the user
Start Create a new user and follow the wizard.
Get the link
Deplo mints a single-use link. It works once and expires in 24 hours.
Share it
Share this link with them, over whatever channel you already trust.
They open it, choose a username and a password, and land in their own team. Add them to yours from Settings -> Members.
Pending links are listed on the same page, and can be revoked before use. Only a hash of the link is stored, and it is consumed atomically, so it cannot be used twice even by two people clicking at the same time.
Roles and limited access
Each member row shows their role. Two badges are worth recognising:
- Primary owner is the founder's crown. Nobody can remove, demote or edit them, including instance admins. It transfers only from Settings -> Members -> the member -> Advanced, only by the owner, only to a member of that team, and only with the password and second factor re-entered.
- Limited access means their real reach is narrowed or widened by per-folder grants, so their role name alone does not tell the whole story.
Open a member to get Permissions (their role, plus the per-node scope tree) and Advanced (instance admin, transfer ownership, remove them), plus Activity - the full trail, narrowed to what they have done.
A member whose permissions were edited by hand stops following their role: editing the role no longer rewrites their set. Assigning them a role again, from the member page or the API, puts them back on it, and the next role edit reaches them like everyone else.
Remove somebody
From the member's Advanced tab. Their memberships end, their sessions in that team stop resolving, and every API token they created loses whatever it inherited from them. Their account and their own team are untouched.
Two more things go with them, so adding the person back later starts clean:
- Every folder share and per-app grant they held in this team is revoked.
- Folders they owned pass to the primary owner. A folder is private to its owner and the people it is shared with, so one left with somebody who is gone would vanish from everyone's Overview. The hand-over is written to Activity, and the primary owner can share the folder on from there.
Limits and gotchas
- A team always keeps somebody who can administer it. No role edit and
no removal may leave zero holders of
manage_members,manage_rolesormanage_team. - Teams are isolated. Adding somebody to this team gives them nothing anywhere else.
- Servers are shared, not team-owned. Which teams may deploy to a server is set on the server, by an instance admin.
- Two-factor can be required at the team level, and an unenrolled member then resolves nothing there at all. See Account security.
If it does not work
- The user search finds nobody: they have no account on this instance yet. Use a registration link.
- A registration link says it is used or expired: mint a new one.
- They are in the team but see nothing: the team requires two-factor and they have not enrolled, or their role has almost no capabilities.
See Sign-in and access for more.
See also
Did this page help you?