Types and roles
What a person may do in ONLYOFFICE Apps depends on two separate things. Most access bugs come from mixing them up:
- Their portal user type: what they may do on the portal at all. For example, create rooms, manage accounts or open settings. It is set per person, portal-wide.
- Their role in a room: what they may do inside one room. The room's owner or manager grants it, and it never goes beyond what the person's type allows.
A Guest invited to a room as Editor can edit files in that room. They still cannot create a room or open My documents. A Full admin who is not a member of a room cannot edit the room or invite people into it: a room's contents are reached through membership, not rank.
The tables below come from the product's access-rights specification, which is the source of truth. Click a column header to highlight that type or role down the table. Hover over a header to see its enum value.
The two vocabularies
Portal user types
Several flags can be true on one person: an owner is also an admin. To turn them into one
type, use getUserType(user) rather than reading a single flag. It checks them in the order
above and stops at the first match. It also counts someone with any listAdminModules as a
Full admin. getUserTypeTranslation(type, t) gives the UI name.
Room roles
Room owner and Room manager are open only to Owners, Full admins and Room admins. Every other role is open to every type, Guests included. Nobody can change their own role.
What each portal user type can do
My documents
A Guest has no My documents at all, so there is nothing to create or upload there.
| Action | Owner | Full admin | Room admin | User | Guest |
|---|---|---|---|---|---|
| Open the section | ✓ | ✓ | ✓ | ✓ | — |
| Create, upload, move, copy, rename, download, delete | ✓ | ✓ | ✓ | ✓ | — |
Rooms
Nobody, not even the Owner, can edit someone else's room, invite people into it, change roles in it, remove its members, or see the links of someone else's public room.
Archive
The Archive is read-only for everyone: no creating, editing, inviting, role changes, removals or pinning. What is left:
Accounts
Users and Guests never reach this section, so they have no column. A Room admin can invite and promote people up to User and no further: nobody grants a rank they do not hold. Guests are never added to groups, whoever asks.
Portal settings
Sharing files
What each room role can do
The room
Files and folders in a room
Third-party storage has no version history in the portal, whatever the role.
Archived rooms
In an archived room every role can only read: members, history, room info, content and comments, copy, print and download. Room owners, managers, content creators and editors can also see version history. Owners, managers and content creators can copy files out into My documents. Only the room owner can restore or delete the room.
How room types differ
Only the differences from the tables above:
- Virtual data room. No Reviewer and no Commentator. Only the room owner and managers can
invite people and set their roles. It adds a PDF-form workflow:
- creating, uploading and setting up filling: owner, manager, content creator;
- editing forms: the same, plus editor;
- seeing forms not yet set up: owner, manager, content creator, editor, viewer;
- seeing set-up forms one takes part in: all of those, plus form filler.
- Form filling room. Only four roles: owner, manager, content creator, form filler.
Only the owner and managers can invite, and form fillers cannot see comments.
- Starting and stopping collection, creating, uploading and editing forms, and syncing results to a spreadsheet: owner, manager, content creator.
- Turning on XLSX collection and database sync: owner and manager.
- The form list (running, in progress, completed): every role in the room.
Checking access in code
Ask the portal, not the matrix. The server already applies these rules to every room,
folder and file it sends. It sends a security object with one flag per action (see
TRoomSecurity and TFolderSecurity in types/). A check derived from a type or a role
by hand can drift from the server. Then the UI offers an action that ends in a 403, or hides
one the person is allowed.
import { useApi } from "@onlyoffice/apps-ui-kit/providers/api";
const { roomsApi } = useApi();
const room = (await roomsApi.getRoomInfo({ id: roomId })).data.response;
// "May this person invite people here?" This already includes the room
// type's narrowing (virtual data rooms and form filling rooms let only
// owners and managers invite).
const canInvite = room.security?.EditAccess;
The portal user type is the right question only for something that belongs to no room. For example, whether to offer Create room at all:
import { EmployeeType, getUserType } from "@onlyoffice/apps-ui-kit";
const type = getUserType(me);
const canCreateRooms =
type === EmployeeType.Owner ||
type === EmployeeType.Admin ||
type === EmployeeType.RoomAdmin;
Two rules the server does not spell out in security, which an invite screen has to follow
itself:
- Only free roles for Users, Guests and groups. Room owner and Room manager count as paid
roles. When the person being invited is a User, a Guest or a group, ONLYOFFICE Apps offers
only the free roles, and in an AI room a Guest can only be a Viewer. The kit's
AccessRightSelectdraws the choice; which options to pass it is up to the screen. - No Guests in groups.
PeopleSelectorshows the Guests tab only withwithGuests, so a group member picker that leaves it out never offers them.
When a change touches one cell, read the whole row. The same action usually appears again in the Archive, among the room roles and for a room type, and those copies drift apart one fix at a time.