Document authorization

docs/index.md

@@ -21,6 +21,7 @@ Feel free to trial it using the demo deployment: [https://demo.otf.ninja](https:
 
 * Linux - the server and agent components are tested on Linux only; the client CLI is not tested on other platforms but should work.
 * PostgreSQL - at least version 12.
+* Terraform >= 1.2.0
 * An SSL certificate.
 
 ## Installation
@@ -304,6 +305,47 @@ And enter the token when prompted. It'll be persisted to a local credentials fil
 !!! note
     This is recommended only for testing purposes. You should use your SSO account in most cases.
 
+## Authorization
+
+The authorization model largely follows that of TFC/E. An organization comprises a number of teams. A user is a member of one or more organizations. If they are not a member of a team within an organization then they implicitly put into a 'guest' team, which has very limited privileges. To enjoy further privileges they need to be a member of an actual team.
+
+### Owners team
+
+Members of the owners team enjoy broad privileges across an organization. "Owners" are the only users permitted to alter organization-level permissions. They are also automatically assigned all the organization-level permissions; these permissions cannot be unassigned.
+
+### Synchronisation
+
+Upon signing in, a user's organizations and teams are synchronised or "mapped" to those of their SSO provider. If an organization or team does not exist it is created.
+
+The mapping varies according to the SSO provider. If the provider doesn't have the concept of an organization or team then equivalent units of authorization are used. Special rules apply to the mapping of the Owners team too. The exact mappings for each provider are listed here:
+
+|provider|organization|team|owners|
+|-|-|-|-|
+|Github|organization|team|admin role or "owners" team|
+|Gitlab|top-level group|access level|owners access level|
+
+### Personal organization
+
+A user is assigned a personal organization matching their username. They are automatically an owner of this organization. The organization is created the first time the user logs in.
+
+### Permissions
+
+Permissions are assigned to teams on two levels: organizations and workspaces. Organization permissions confer privileges across the organization:
+
+* Manage Workspaces: Allows members to create and administrate all workspaces within the organization.
+* Manage VCS Settings: Allows members to manage the set of VCS providers available within the organization.
+* Manage Registry: Allows members to publish and delete modules within the organization.
+
+Workspace permissions confer privileges on the workspace alone, and are based on the [fixed permission sets of TFC/TFE](https://developer.hashicorp.com/terraform/cloud-docs/users-teams-organizations/permissions#fixed-permission-sets):
+
+* Read
+* Plan
+* Write
+* Admin
+
+See the [TFC/TFE documentation](https://developer.hashicorp.com/terraform/cloud-docs/users-teams-organizations/permissions#fixed-permission-sets) for more information on the privileges each permission set confers.
+
+
 ## VCS Providers
 
 To connect workspaces and modules to git repositories containing Terraform configurations, you need to provide OTF with access to your VCS provider.

modd.conf

@@ -10,7 +10,7 @@ db/queries/*.sql {
     daemon: _build/otfd --log-level trace --log-color true --dev-mode --log-http-requests
 }
 
-**/*.css **/*.tmpl **/*.js {
+**/*.css **/*.tmpl **/*.js **/*.svg {
     daemon: devd -c ~/.localhost.crt -mq https://localhost:8080
 }