People, roles, and who sees what

Admins, members and guests, how to invite someone by email, and how to let a client into exactly one project.

Access in sjTasks is two dials, kept deliberately separate:

Role — what you are allowed to do.
Scope — where you are allowed to do it.

Two dials instead of one long list of permissions is what lets a client sit in your workspace seeing one project and nothing else.

The three roles

Role	Can do	Scope
Admin	Everything in the workspace: people, projects, watchers, settings	Always the whole workspace
Member	The work — create, edit and finish tasks, upload files, write notes, log time	The whole workspace, or only named projects. The admin chooses when inviting
Guest	Read, and write notes. Nothing else. No creating, editing, finishing, or uploading	Always limited to named projects. Never workspace-wide

There is no separate "owner" role. Somebody has to be able to close the workspace and somebody has to receive the bill, and that person is recorded — but in the role picker they are simply an admin. One fewer concept to explain.

Only admins and members can be assigned work or have time logged against them. A guest is never offered in an assignee list.

Scope belongs to the person, not the project

There are no private projects. A project is not hidden from some people and shown to others; instead, a person is either workspace-wide or scoped to a list of projects.

That is a deliberate trade. It means an admin can always see all of their own workspace — which matters the moment you are supporting somebody and need to know your view is complete — and it means there is exactly one rule to reason about:

You can see a project if you are an admin, or a workspace-wide member, or you have been added to that project by name.

Everything else follows from it. What tasks you see, what files you see, what a search returns, what a saved view counts, who is on a watcher list: all the same rule, so there is never a second place for access to go wrong.

Inviting someone

Team Settings, from the menu with your workspace's name in it. Admins get an invitation form with three things in it:

Their email address. This is fixed on the invitation — the link cannot be turned into a seat under a different address.
A role — admin, member, or guest.
Where they can work. Admins are always workspace-wide, so the choice disappears. Guests are always project-scoped, so the choice locks to specific projects the moment you pick Guest. For a member you choose: the whole workspace, or a list of named projects you tick.

Press invite and an email goes out with a link that is good for seven days.

What they see

The link opens a page that names your workspace, who invited them, and — if they were given specific projects — which ones. What happens next depends on who they are:

No account yet: they choose a name and a password, and they are in. Nothing else is asked, and no email verification step: opening mail sent to that address already proved the address is theirs.
Already have an sjTasks account: they are asked to sign in, and joining finishes itself.
Signed in as somebody else: the page says so, and says which address the invitation is for, rather than failing at them.
The link has expired, or has already been used: the page says which, and what to do about it.

Before they arrive

Team Settings lists everyone invited who has not joined yet, with who invited them and how long the link is good for. An expired row says "Expired 3 Sep — send it again". Two controls sit on each row:

Resend — a fresh link and seven more days, to the same address.
Withdraw — the link stops working immediately.

The common case: letting a client in

You run a workspace with ten client projects. Acme should see the Acme project only.

Invite the person by email.
Give them the role guest if they should read and discuss, or member if they will actually do work.
Tick the Acme project, and nothing else.

They sign in, see one project, and can write notes on it. They cannot see your other clients, cannot find them in search, and cannot see them in anybody's shared view. A guest with no projects yet sees nothing at all, which is the right default for an invitation that has been sent but not yet set up.

Guests, precisely

A guest can: read every task, note, and file in their projects; write notes; edit and delete their own notes; open and download files; follow or stop following a task so they hear about the thread they are in.

A guest cannot: create or edit a task, finish or reopen one, change a priority or a date, upload or remove a file, log time, be assigned work, or change anything about the project.

The interface reflects this rather than arguing with it — the buttons a guest cannot use are not shown, so nobody is invited to click something that will refuse them.

Changing your own details

Profile, under your name at the top right: your name, your email, your password, two-factor authentication, and signing other browsers out.

Notifications, in the same menu, is where you choose what sjTasks sends you — see Notifications and summaries.

Your timezone decides what "today", "overdue" and "this week" mean for you everywhere in the product, and it is worth having right. It is not yet something you can set yourself: tell us the zone you want and we will set it. Without one you inherit your workspace's. The same goes for the day your week starts on, which is a workspace-wide setting so that "this week" means one thing to everybody reading the same list.

More than one workspace

If you belong to more than one, the menu with your workspace's name in it switches between them. Nothing crosses over: projects, people, files, notification settings and search all belong to one workspace.