Apps and permissions

Most of the Weavy building blocks are backed by a corresponding app in your Weavy environment. The apps are required for permission and access control, and also for storing the content generated by users of the building block.

Apps

You can think of apps like containers for content. For instance, the chat building block stores messages sent in the chat in a corresponding chat app on the Weavy environment.

Apps are identified by a uid which is a string that uniquely identifies the app. Typically you can use the id of something already in your app such as a product, or page id. You can also use an URL as uid if you want.

Note that the uid cannot contain whitespace and must contain at least one non-digit.

Apps are typically created automatically by the building blocks when needed, but for better access control and individually assiging permissions to users you can also use the Web API to create apps ahead of time.

When you create an app using the web API you must also assign it a type. The type of app controls which content it can contain. You create a chat app for storing messages, a files app for storing files, and a posts app for storing posts.

A common use case for creating apps using the Web API is to configure what users should have access to it and their permissions inside the app.

Permissions

Controlling access to apps can be done on two levels. First you can set the access and directory properties whan creating an app. These properties are used to control permissions for users that are not members of the app.

The access property can have the following values:

  • none (default): non-members cannot access the app.
  • read: non-members can see the app and it's content but cannot add, update or delete anything.
  • write: non-members can access and modify content in the app.

The directory property let's you reference a user directory and is used in combination with access to specify that only users in a specific directory can access the app.

By adding members to an app you can override the default access property for individual users. Adding members to an app is done with the Add member endpoint in the Web API.

Examples

If you want an "open" app where all authenticated users are allowed to create content: Create an app with access=write.

If you want a "read-only" app where users can see content but cannot create anything: Create an app with access=read.

If you want a "closed" app that only members can access: Create an app with access=none.

Use cases

If you have a large number of users you want to access an app with the same permissions it is convenient to use the combination of directory and access even though members will work as well.

If you want to set fine grained control for specific users then you should use members.

You can also combine them to give write access for a few members, and read access to many.

A special case is to set a user directory with read or write access, and then define a few members with none as access to block these users from the app.

Weavy Docs