Skip to main content

Sharing

Sharing controls who can see and edit a project in the online environment. The desktop client does not support sharing — it is single-user by design. Sharing in Siter is token-based: an Admin generates a share token, the recipient submits a request using the token, and the Admin accepts the request with a chosen role. For the click-by-click flow, see Sharing projects.

Learning objectives

By the end of this lesson you should be able to:

  • Generate a share token and send it to a collaborator
  • Pick the appropriate role when accepting an access request
  • Recognize the difference between the four project roles
  • Change a member's Read / Write / Administer permissions, or remove a member, without opening the project
  • Stop sharing or revoke an existing token

The four project roles​

When accepting an access request, an Admin picks one of four roles for the requesting user:

RoleWhat it allows
Read OnlyView features, results, drawings, and forms, and run analysis; cannot modify anything else. A run replaces the project's stored results for everyone, including saved arc selections
Read and WriteEdit features, run analysis, modify result sets, generate drawings and forms
Just AdministratorManage sharing and access requests, but does not have edit rights to the project's features
Full AdministratorCombination of Read and Write + Administrator — edit rights and sharing-management

Roles are project-scoped: the same user can be Read Only in one project, Read and Write in another, and Full Administrator in a third. There is no global role.

note

Sharing is online-only. The desktop client does not synchronize between machines and does not support multi-user collaboration.

How sharing works​

Sharing is a three-step flow, not a direct invite:

  1. Generate a token on the project's Sharing tab — via Manage Access on the Project Management page, or the dashboard's Sharing tab. Siter produces a short share-token string with an expiration date.
  2. Send the token to the collaborator out-of-band (email, chat, etc.). They use it to submit an access request from their own Siter account (the key icon on the Project Management page).
  3. Review the request. The Project Management page's Access requests inbox collects pending requests across every project you administer — a badge shows how many are waiting, and both update live as requests arrive or are handled. Each request lists Project, Status, User Name, Organization, Email, and Requested time. Accept (with a role of your choosing) or reject. Requests also appear on the individual project's Sharing tab.

The token is reusable — multiple collaborators can submit requests using the same token until it expires. Each request requires its own accept/reject decision.

Changing or removing a member's access​

The role chosen at accept time is not final. On the Users tab of the Manage Access dialog (or the in-project editor's Users tab), click a member's row to expand a Permissions panel with three checkboxes — Read, Write, Administer — that map onto the four roles above (Read Only = Read; Read and Write = Read + Write; Just Administrator = Administer; Full Administrator = all three). Tick or clear, then Save. Remove User in the same panel drops the member immediately after a confirmation.

Two guard rails apply everywhere: a project must always keep at least one active administrator, and every member must keep Read. Clearing your own Administer box is allowed, but Siter warns you and asks you to confirm — after that you cannot get back in to manage the project.

Stopping or revoking sharing​

The Sharing tab carries a Stop Sharing action that invalidates the active token. New requests can no longer be submitted with it. Existing accepted users keep their access until removed explicitly — expand their row on the Users tab and click Remove User. If the token has expired naturally, a Share It Again button appears to mint a new one.

When sharing does not survive​

A few operations break sharing:

  • Importing a project from a snapshot — sharing is not preserved on import. The imported project starts with no shares; the importer must reassign permissions explicitly. See Export and import.
  • Copying a project — the copy is private to the user who created it; collaborators on the source do not automatically get access to the copy.
  • Archiving a project — does not remove shares, but archived projects drop out of shared users' active project list until restored, and Manage Access is not offered on an archived project — restore it first to change who has access.

Try it​

In an online project where you have an Admin role:

  1. On the Project Management page, open the project's Manage Access dialog, switch to the Sharing tab, and click Share It to generate a token
  2. Note the token's expiration date
  3. Have a colleague submit an access request using that token (key icon on their Project Management page)
  4. Accept the request at Read Only from the Access requests inbox and confirm the colleague can open the project and run analysis, but cannot edit features or clear analysis
  5. Back in Manage Access, expand the colleague's row on the Users tab, tick Write, and Save — confirm they can now edit features
  6. Expand their row again, click Remove User, confirm, and check that the project disappears from their project list