The Feng Office Software permission system is a layered, role-based access control model designed to balance operational flexibility with data security.
Permissions are determined through a structured combination of:
Each layer contributes to the final access level of a user. This document explains how permissions are defined, combined, and enforced throughout the platform.
The following table summarizes the permissions set for each user type.
| Quick description | |
|---|---|
| Super Administrator | Can do everything |
| Administrator | Can do everything, except managing other administrators and super administrators |
| Manager | Can do everything on Clients, Projects and Workspaces for which administrators granted Management permissions |
| Executive | Can work on everything, but cannot set permissions |
| Collaborator Customer | Is a Customer that can work on data but with restricted permissions, such as not creating or assigning tasks. Can link one object to another provided that they have edit permissions to that object |
| Internal Collaborator | Can work on data, but cannot create nor assign tasks. Can link one object to another provided that they have edit permissions to that object |
| External Collaborator | Can work on data, but cannot create nor assign tasks. Can link one object to another provided that they have edit permissions to that object |
| Guest Customer | Has limited access to view his/her own data. Cannot upload data. Only comments |
| Guest | Has limited access to view his/her own data. Cannot upload data. Can't comment |
This document explains how permissions work in Feng Office Software, including:
Permissions are determined by several layers working together.
| Permission Layer | Purpose | Applies To |
|---|---|---|
| Role | Defines the maximum permissions that users of a role may receive. | Users |
| Role Default Permissions | Defines the default permissions assigned to newly created users of that role. | New users |
| User Permissions | Additional permissions assigned directly to a specific user. | Individual users |
| Groups | Assign permissions and dimension access to multiple users simultaneously. | Group members |
| Module Permissions | Determines which modules are available to the user. | Users |
| Dimension Permissions | Determines which Projects, Clients, Organizations and other dimension members the user may access. | Dim members access |
| Default Dimension Member Permissions | Automatically grants access to newly created dimension members. | New Projects, Clients, Organizations, etc. |
| Object Permissions (without classification) | CRUD permissions for objects that are not classified into dimensions. | Full Access users |
A Role defines the maximum permissions a user may ever receive.
Roles act as the permission ceiling.
If a permission is disabled by the role, it cannot be granted later through users or groups.
Each role has its own configurable default permissions.
These defaults are automatically assigned whenever a new user is created using that role.
Changing the role defaults only affects users created afterwards.
Existing users keep their own permissions.
Settings → Users, Groups And Permissions →Manage Roles → Select a Role →
From this screen, administrators can configure the default permissions that will be automatically loaded when creating new users with that Role.
| Action | Result |
|---|---|
| Create a new user | Receives the role's default permissions |
| Change Role Defaults | Affects future users only |
| Existing users | No changes |
| Change permission ceiling | Not possible |
Important: Role Default Permissions do not modify the maximum permissions allowed by a role. They only define the initial permissions assigned when new users are created.
Settings → Users, Groups And Permissions →Manage Users → Add new user →
When a Role is selected while creating a new user, the system automatically loads the configured default permissions for that Role.
When creating a new user, Feng Office Software automatically loads a predefined set of permissions based on the selected Role.
These permissions act as the initial configuration for the new user, allowing administrators to quickly create users without manually configuring every permission.
The loaded permissions can be reviewed and modified before saving the user.
| Action | Result |
|---|---|
| Create a new user | Loads the default permissions configured for the selected Role. |
| Modify permissions before saving | Allowed. |
| Save the new user | The selected permissions become the user's own permissions. |
| Change the Role defaults later | Existing users are not affected. Only future users receive the updated defaults. |
An administrator configures the Manager Role so that new users receive:
When a new Manager user is created, these permissions are automatically preselected.
The administrator may still enable or disable any permission allowed by the Role before saving the user.
Changing the default configuration later will only affect Managers created afterwards.
Each permission can be in one of the following states:
| State | Meaning | Can the permission be granted? |
|---|---|---|
| Enabled | The selected Role allows this permission to be granted. It is available for administrators to enable for the user or through a Group. | ✅ Yes |
| Disabled | The selected Role does not allow this permission. It cannot be granted to the user under any circumstance. | ❌ No |
| Active | The permission is currently granted to the user. | Already granted |
Important: A permission must first be Enabled by the user's Role before it can become Active. If a permission is Disabled by the Role, neither User Permissions nor Groups can grant it.
Suppose the Manager Role allows the Manage Projects permission.
| Role allows the permission | Permission enabled for the user | User has the permission? |
|---|---|---|
| ❌ No | ✅ Yes | ❌ No |
| ✅ Yes | ❌ No | ❌ No |
| ✅ Yes | ✅ Yes | ✅ Yes |
In other words:
Permissions come from multiple sources.
Role
↓
Role Default Permissions
↓
User Permissions
↓
Groups
↓
Effective Permissions
System and module permissions use OR logic.
A permission is granted if any source grants it.
Possible sources include:
| Role Default | User | Group | Final Result |
|---|---|---|---|
| ❌ | ❌ | ❌ | Not Granted |
| ✅ | ❌ | ❌ | Granted |
| ❌ | ✅ | ❌ | Granted |
| ❌ | ❌ | ✅ | Granted |
| ✅ | ✅ | ✅ | Granted |
Business objects are classified into dimensions such as:
To access an object, the user must have access to every dimension member assigned to that object.
Project ✓ Client ✓ Organization ✗ Result: Object cannot be accessed.
| Project | Client | Organization | Can Access Object? |
|---|---|---|---|
| ✅ | ✅ | ✅ | ✅ Yes |
| ✅ | ❌ | ✅ | ❌ No |
| ❌ | ✅ | ✅ | ❌ No |
| ❌ | ❌ | ❌ | ❌ No |
Sometimes a dimension exists for classification purposes only.
If administrators do not want a particular dimension to restrict visibility, users (or groups) should be granted access to all members of that dimension.
This prevents that dimension from limiting access while still allowing objects to be properly classified.
Roles define the structural limits of each user type.
| Role Family | Typical Roles | Default Dimension Access | Object Permissions Without Classification |
|---|---|---|---|
| Guest | Guest, Guest Customer, Non-Executive Director | None | No |
| Collaborator | Internal Collaborator, External Collaborator, Collaborator Customer | None | No |
| Full Access | Executive, Manager, Administrator, Super Administrator | All dimension members | Yes |
Groups simplify permission management by assigning permissions to multiple users at once.
Groups may contain:
A user may belong to multiple groups. The effective permissions are the union of all permissions granted by those groups, provided the role allows them.
Settings → Users, Groups And Permissions →Manage Groups
Groups can be created, edited and assigned to users from this section.
| Role | Group | Result |
|---|---|---|
| Permission enabled | Group grants permission | Permission granted |
| Permission disabled | Group grants permission | Permission NOT granted |
Roles always define the permission ceiling.
Administrators can configure default access for newly created dimension members.
These defaults are automatically applied whenever a new member is created.
Examples include:
| When… | The System Automatically… |
|---|---|
| A new Project is created | Grants the configured default users and groups |
| A new Client is created | Grants the configured default users and groups |
| A new Organization is created | Grants the configured default users and groups |
| A new Service is created | Grants the configured default users and groups |
| A new Site is created | Grants the configured default users and groups |
Changing these defaults does not modify existing dimension members. Only future members receive the updated default access.
A user's effective permissions are the combination of several configuration sources.
| Source | Purpose |
|---|---|
| Role | Defines the maximum allowed permissions |
| Role Default Permissions | Initial permissions for new users |
| User Permissions | Additional individual permissions |
| Groups | Shared permissions assigned to multiple users |
| Dimension Permissions | Controls object visibility |
| Default Dimension Member Permissions | Automatic access for newly created dimension members |
When a user cannot access an object, verify the following in order:
| Step | Verify |
|---|---|
| 1 | User Role |
| 2 | Role Default Permissions |
| 3 | User Permissions |
| 4 | Groups |
| 5 | Dimension Permissions |
| 6 | Object Classification |
Remember that object visibility depends on the combination of all applicable permission layers.
| Concept | Rule |
|---|---|
| Role | Defines the permission ceiling |
| Role Default Permissions | Initial permissions for newly created users |
| User Permissions | Individual user-specific permissions |
| Groups | Shared permissions assigned to multiple users |
| System Permissions | OR logic |
| Module Permissions | OR logic |
| Dimension Permissions | AND logic |
| Default Dimension Member Permissions | Applied automatically to newly created dimension members |
In summary: