Overview

Wasabee has a highly flexible permission model that can be used in ways ranging from the very simple to the extremely complex. Because it is so flexible, it can sometimes be confusing.

The basics

To give a team permission to access an operation (not "add" agents or teams to ops) use the Operation Settings dialog, the permissions button, or using the permissions interface in the WebUI. You can only grant permissions to an operation once the operation is uploaded to a wasabee server.

There are three basic classes of permissions

• Read
• Write
• "Assigned Only"

Read Permissions

Basic read permissions allows agents on the team which has been granted permission the ability to see the operation data. They cannot make changes to the operation or update the operation on the server. Agents on teams with read permissions can update their individual key counts for anchor portals or "get keys" markers. Such agents can also claim markers, acknowledge tasks assigned to them, reject tasks assigned to them, and mark tasks assigned to them as completed.

Write Permissions

Write permissions allows agents on the team which has been granted the permission to edit the operation. Write permission implies full read permission. Agents on a team with write permission can see the entire operation (all zones) and make changes to any part of the operation data except permissions and ownership.

"Assigned Only"

Assigned only permission allows agents on the team to see only tasks (markers and links) assigned to the individual agent. This is useful to restrict access to "less-than-fully-trusted" agents, allowing them to use the tools without exposing link lanes, and other sensitive information.

Zones

Read access can be granted to a team on a per-zone basis. For example, an operation might have 4 zones. A team would need to be created for each zone, and each of these teams would be given read access to the specific zone. Agents on each team would be able to see all tasks which are designated as being in their zone, but nothing from other zones. This is useful for very large operations where some degree of compartmentalization is required, but agents still are trusted enough to "claim" markers in their area, or have a voice in their assignments.

If an agent is on a team with access to one zone (e.g. "pink"), but has an assignment in a different zone (e.g. "orange"), the assigned task will be visible as well as the full "pink" zone for this particular agent. That is to say, assigned tasks are always visible to the assignee. If an agent is on multiple teams, each with different zone access, the agent will see all zones for which they have access.

Write access is always for all zones.

"Assigned Only" is irrelevant with zones. An operation might use both a single "Assigned Only" team as well as multiple per-zone teams.

Examples

Small, trusted team

A small group of agents, who have worked together for years, might simply give read access to a single team with all the agents on that one team. The operator is the operation owner, and has de facto write access (due to owning the operation), so there is no need for any additional permissions

• one read team

Small team, multiple operators

As above, the operation chief decides that all the agents can be trusted with all operational details, but the complexity of the operation requires multiple operators to be making edits on the operation at the same time. So there is a single "read" team and a small "write" team with just the operators.

• one read team
• one write team

Larger operation, multiple new agents

If the operation requires recruiting new, unknown, or untrusted agents, an additional team for these individual can be created and granted "assigned only" permission. This is common for teams clearing blocking links where the agents do not need to see the link data or other tasks not assigned to them

• one read team (for agents doing the linking)
• one "assigned only" team (for agents clearing blockers)
• maybe a write team for multiple operators, if necessary

Continent cover

For very large operations, zones are a good way to enlist help without exposing the entire operation to a large number of agents.

• Zone-A team: read access to zone-a
• Zone-B team: read access to zone-b ...
• Zone-N team: read access to zone-n
• Operator team: write access
• Linker team: read access to all zones
• "last minute boots" team: "assigned only" access for agents pulled in to help clear specific portals or otherwise help out as things change