Roles and Permissions

Imagine you have added your colleague minji.kim@example.com to the Space for your clothing store. You want to let them register and edit products, but you are not comfortable letting them delete products or make them publicly available. A Space Role (SpaceRole) is the bundle of permissions that decides exactly this: "what a member can and cannot do within a single Space."

Instead of assigning permissions to each member one by one, a SpaceRole lets you prepare a bundle of permissions in advance and attach it to members. For example, once you create a role that "can only read and edit products," you can attach that one role to every colleague you want to handle product registration. Even as your team grows, you do not have to define permissions from scratch each time.

This page first looks at what a SpaceRole is and what permissions it holds, and then walks through creating a "Product Editor" role directly in your clothing store Space.

Space roles are different from Organization roles

WEEGLOO has two places where permissions are decided. They are easy to confuse, so let's draw the boundary first.

• Organization roles (Owner, Admin, Member) are your rank across the whole company. They decide who can do things that span the entire Organization, such as inviting members or creating a new Space.
• A SpaceRole is a permission within one specific Space. It decides how far a member can go in handling content inside that workspace, such as creating, editing, and publishing products.

You can give the same colleague a different SpaceRole in each Space. For example, you can let them edit products in your shopping mall Space, while letting them only read in an internal-announcements Space. This page covers only SpaceRole. Organization roles, member invitations, and assignment are covered in Organizations and Spaces.

What a role holds: which actions, on what

A single SpaceRole holds "which action, on what target, to allow or deny."

First, the targets a permission can be set on are divided into three kinds.

• Content Type: the form template for things like products or announcements
• Content: each individual product made from that template
• Media: uploaded files such as photos and videos

The actions you can allow or deny for each target are as follows.

The actions are shown in English on screen. Here is what each action means.

In the clothing store example, the "Product Editor" role allows Read, Create, and Edit on Content (products) while leaving out Delete and Publish. That way your colleague can create and edit products, but cannot delete them or make them publicly available.

What Publish is, and how publishing makes something publicly available (delivered) externally, is covered in detail in States and Publishing.

Allow and Deny

The role screen has a separate Allowed list and Denied list. You add the actions you want to permit, one rule per line, to the Allowed list. The important part is that any action you do not add to the allow list is automatically denied. So if you put only the actions you want to give your colleague into the allow list, the rest are blocked without you having to block them separately.

The Denied list is a safeguard for when you want to "allow broadly but make an exception that blocks just one specific part." When a single action is caught by both allow and deny, deny always wins.

Narrowing the scope to a specific kind or a specific person

When you allow an action, you can narrow that permission down to a single kind or a specific condition. For example, the following kinds of narrowing are possible.

• To one kind only: applies only to the "Products" Content Type, and not to other Content Types.
• To only what they created: lets the member handle only the Content they created themselves, so they cannot touch what others made.
• To only what carries a specific Tag: applies only to Content or Media that has a chosen Tag.

If you do not narrow the scope, the action applies to the entire target. For example, if you allow reading Content without narrowing it, the member can read all Content; if you narrow it to the "Products" Content Type, they can read only products.

What a Tag is is covered in Tag.

The Administrator role that comes with every Space

When you create a new Space, a role called Administrator is automatically created along with it. This role is the highest-privilege role that can handle everything inside that Space. The person who creates the Space starts out holding this Administrator role.

The Administrator role is a role the system provides, so it cannot be edited or deleted. If you want to give a colleague a narrower set of permissions, instead of editing Administrator, create a new role separately as shown below and give them that.

Creating the "Product Editor" role

Now let's create the "Product Editor" role directly in your clothing store Space to give to your colleague. This role will be able to Read, Create, and Edit products (Content), but will not be able to delete or publish them.

1. In the left menu, click Roles & Permissions.
2. Click the Create button at the top right of the list.
3. In the name box on the Role detail tab, enter Product Editor. You may leave the description box empty.

Next, decide what this role can do with products (Content). You add actions as rules, one per line, in the Allowed list, and on the same line you also choose the scope (Content Type) to apply them to.

4. Go to the Content tab.
5. Click the + under Allowed to add one rule line.
6. On that line, set the action to Read and set the Content Type to apply it to as "Products." (Leave the author and Tag boxes at "All…" to apply to everything.)
7. In the same way, add Create and Edit rules, one line each. Keep the Content Type as "Products" on all three lines.
8. Do not add Delete or Publish to the allow list. Because any action not added to the allow list is automatically denied, your colleague will be unable to delete products or make them publicly available.

9. Click the Save button at the top right.

Once Product Editor appears in the list, the role has been created. It shows up alongside the Administrator that was there from the start.

Giving the role you made to a colleague

Creating a role does not automatically apply it to anyone. A role you created takes effect only once you attach it to a member.

When you assign a colleague to a Space, you also choose the role they will hold inside that Space, and that is when you can choose the Product Editor you just made. If the colleague is already in the Space, you can also change their role from the member list to apply it. You can also give a single member several roles at once. In that case the actions allowed by each role are combined, and the member can do any action that is allowed by at least one of the roles. (Deny overriding allow happens only within the same role. Even if one role denies an action, the member can still do it if another role allows it.)

The specific steps for assigning a member to a Space and choosing their role are covered in Organizations and Spaces.

What to do next

• Organizations and Spaces: assign a colleague to a Space and attach the role you just made.
• Tokens: covers the access tokens that let an external site or program, rather than a person, read content. You can attach a SpaceRole to a token too, to narrow its permission scope.
• API Reference: covers the technical specifications, such as request formats, that you need when creating roles or handling permission rules directly from a program.