Projects

Projects on Sundog do two jobs.

• they organise groups of experiments into a larger data structure, making it easy to collect related work.
• they allow you to control more fine-grained access to experiments within them - both to members inside the lab, and guests from outside it.

A Sundog project maps well to a real-world project.

Why would an experiment be in more than one project?

Sundog Projects work a bit like a photo album on your phone. A photograph might belong to both “Summer 2025 France Trip” and “My Favourite Pictures”. Neither contradicts the other; they’re just different categorisations. And you might use them to decide who gets to see them - the full holiday album might be private to your family, but you might share all your favourites publicly.

In the same way, a Sundog experiment might belong to its main project, before being added to a “for publication” project, or a “best lab pictures 2026” project.

This is particularly useful if you have a subset of experiments in a project you’d like to share with guests (see below).

To begin with, we recommend trying to minimise the number of projects an experiment is in.

The lab’s project page lists all the projects in a lab, and the button top right lets you make a new one.

An individual project page shows a description of the project, latest experiments and activity within the project, plus the users who have access to the project. It’s very similar to the lab page.

The projects sub-menu throughout links to pages listing experiments and users in the project. Any project owners can also manage the experiments in the project, and users with access to it, from this page.

Creating a project

Any lab member can create a project within a lab they belong to. Projects are as useful for managing your own private work as for collaborating with others.

From the project creation form, you can name the project and write a description. The slug - used in the URL - will be auto-generated from the name, but you have an opportunity to edit it at creation if you’d like.

Finally, you can choose the base level for the project. This sets the default access level for anybody else in the lab.

Project access levels

Access to a project is controlled via levels. Your level on a project determines what you can do and see within it. There are five levels of access:

Label	Description
Owner	Owns the project. Can add/remove people to/from the project and change their access levels. Can add/remove experiments from the project. Full access to experiments in the project. Can alter the project itself, including deleting it. The project creator is its owner by default, but other users can be given this permission.
Experimenter	Full access to experiments to the project, including creating/adding them, making stacks and uploads, etc - but no rights to alter the project or its users.
Commenter	No rights to add/create experiments in the project, but can see experiments in the project and comment/annotate stacks.
Viewer	Can see experiments and stacks in the project, but cannot comment/annotate
None	Cannot see the project at all.

Other users can be granted explicit permission to access the project, with a specific level.

A project must have at least one owner.

Using the base level

The base level of a project specifies what every lab member can do on it. This is an easy way to establish a “default” level of access to the project, and it can be changed at any time. For instance:

• to keep a project private, set the base level to none. This will mean that only you can see a project and its contents. To let users see experiments, comment on them, or add them, add them manually on the Users page.
• to allow everyone in the lab to see and comment on the project, but not alter its experimenters, set the base level to commenter, and give specific experimenters the experimenter role.
• to a colleague administrative control over a project, make them another owner. This is also useful if you want to hand management of the project over to them, and get yourself demoted/removed.
• set a base level of experimenter to allow any lab member to add and manipulate experiments in the project.

Projects → Experiments

The experiments page in a project lists and paginates all the experiments in a project. The buttons top right give you a shortcut to creating a new experiment in this project, and to the experiment manager for the project.

The experiment manager lists all experiments in the lab, and lets you add / remove experiments to the project. The bulk add/remove functionality is enabled by selecting rows with checkboxes. The filter textbox will search the lab for specific experiments.

When you remove a project from an experiment, you’ll be asked to confirm your action before it is remove. If doing so will make the experiment visible to more people than it previously was, you will be warned of this.

Experiments gaining visibility on removal

How can an experiment grow in visibility when removed from a project?

Labs have a “default level” of access for experiments not in any project. For instance, set to experimenter, this would mean anyone can add/remove stacks/uploads/comments to an experiment not in a project. Or set to commenter, would mean that anyone can comment on experiments not in a project.

If the act of removing this experiment from a project would leave it in no projects, and if the default level of the lab is “viewer” or up, then that experiment would now become visible by anyone in the lab. That means something that may have been private to people with permissions on the project would now be less private. And so Sundog warns you of this fact.

In general, we recommend organising work in projects, and trying to avoid having experiments outside them - but Sundog is flexible enough to let your organise your work how you’d like.

Projects → Users

The users page for a project lists everyone with access to a project: first, anyone with an explicit permission on the project, and then anyone else in the lab who has access via the base level if there is one.

Click change level to alter the level of an explicit permission, or to create an explicit permission for someone with a base level.

Click revert to remove an explicit permission from a user when there is a base level present for the project.

Click remove to remove an explicit permission from a user who is not eligible for a base level (the base level is None, or the user is a guest).

You cannot remove your own permission.

Revert vs Remove

Imagine a project with a base level of commenter. Everybody in the lab will have access to the project as a commenter.

Giving a user an explicit permission of experimenter will allow them to create stacks and uploads within the project’s experiments.

This permission would appear in the Users list with a revert button by it. Deleting the explicit experimenter permission would mean that user would fall back to still having project access, at the level of commenter.

By contrast, a guest on the same project would still have a remove button by their name: as someone who isn’t a lab member, removing their explicit permission would remove all their access to the project.

Revert is a reminder that there is a base level of access, and removing an enhanced level will just fall back to the base level; Remove will remove a user from a project entirely.

Adding users to a project

Click “add user” from the Users page to add someone in the lab to the project.

There are two tabs on this page. Which to select depends on who you wish to invite.

“From the lab”

This tab adds lab members to a project. They will be immediately given access upon clicking “add”.

The “user” field autocompletes by username or display name - search for the user you’d like and select them by clicking on them. Then, specify the access level you’d like them to have.

“As a guest”

This tab allows you to invite people outside the lab as a guest to the project. Instead of autocompleting their username, you will put in the email address you wish the invitation to be sent to.

As a guest, they can only have a level of viewer or commenter.

Finally, there is an option to add a message. If the person you are inviting has never used Sundog before, this is a good opportunity to quickly explain what they are being invited to. Clicking Invite will then invite them to the project.

Pending guest invitations can be seen on the Invited guest users tab of the Project → Users page. (Once their invitation is accepted, they will appear on the Users with access tab).