Guru's Verification engine ensures consistency, confidence, and trust in the knowledge your organization shares. Learn more.

2. Authorization and Access Control

Authorization and access control

Function introduction

There are four main tier in Anffy, namely super administrator (workspace creator), system administrator, sub-administrator, and ordinary members. The main permissions of the four identities are summarized in the table below.

Detailed introduction of permissions

Application management

  • Contains permissions such as application use, application creation, application editing, application deletion, and data management.

Address book permissions

  • Management permissions for departments, members, roles, etc. in the address book

Paid permission

  • Permission to view payment information and make payments
  • Only super administrators and system administrators have paid management rights
  • Function entrance: [Management]-[Workspace Overview]-[Upgrade/Purchase Quota]

Set system administrator permissions

  • Function entrance: [Management]-[Permission Management]-[Add Administrator]

Transfer to super administrator

  • Function entrance: [Management]-[Basic Information]-[Super Administrator]
  • The super administrator must supplement the security information in the personal center before making the transfer.
  • After the super administrator transfers his or her identity, other permissions and identities will not be affected.

Sub-administrator management

  • Add, modify, or remove sub administrators' permissions

Sub-administrator

1 Introduction

1.1 Function introduction

Members who are set as sub-administrators can be granted management permissions for individual applications, which can refine application management permissions and improve the efficiency of corporate organizations.

The differences between sub-administrators and members with other permissions are as follows:

1.2 Usage scenarios

It is suitable for scenarios where application management permissions need to be refined in enterprises with complex organizational structures, such as assigning different responsible persons to manage application packages of different departments.

1.3 Effect display

As shown in the figure below, set the supervisors of different departments as sub-administrators, and grant them the application package management permissions of the corresponding responsible departments, so that they can separately manage their own department's business systems in Anffy and improve work efficiency.

2. Setup steps

2.1 Function entrance

The super administrator/system administrator enters the "Permission Management" interface of the "Admin Backstage", selects "Sub Administrator", and clicks "Add Sub Administrator" to set up the "Sub Administrator"

2.2 Function setting steps

2.2.1 Name

You can set the name of the sub-administrator. Click the input box below "Name" and enter the name of the sub-administrator to complete the sub-administrator name setting.

2.2.2 Administrator

You can select members, members of a department, or members of a certain role and set them as sub-administrators. Click the "+" button to select sub-administrators

2.2.3 Application/portal permissions

You can set the "management scope" and "operation permissions" of sub-administrators for applications/portals

Management scope : The scope of applications/portals that sub-administrators can operate. Including "Application Package" scope and "Application/Portal" scope. Click "Add Management Scope" to perform function settings

"Application package" scope: includes the basic information of the application package, as well as all applications, groups and portals in the application package, and also includes subsequent applications/portals added to the application package.

"Application/portal" scope: includes designated applications/portals, excluding basic information of the application package to which the application/portal belongs and subsequent applications/portals added to the application package.

Operation permissions : Sub-administrators have permissions to perform specific operations on the application/portal. Including "Application Package Editing", "Application/Portal Editing", "Application/Portal Creation", "Application/Portal Deletion" and "Data Management". Check the "Operation Permissions" option to complete the function settings

Application package editing: You can edit the basic information of the selected application package, as well as all applications, groups and portals in the application package.

Application/portal editing: You can edit the selected application/portal, but you cannot edit the basic information of the application package to which the application/portal belongs.

Application/portal creation: Applications, groups and portals can be created under the selected application package

Application/portal deletion: You can delete the selected application/portal, and you can also delete the applications, groups and portals under the selected application package, but you cannot delete the application package itself.

Data management: You can manage reports, views and all data in the selected application/portal.

2.2.4 Address book permissions

You can set the sub-administrator's permissions to edit the address book, including "Manage Full Volume" and "Manage Partial Volume". After turning on the "Address Book Permissions" button, check the permissions you want to enable as needed to configure the "Address Book Permissions" related settings.

Full management: Can edit all departments and roles in the address book.
Management component: Only the selected departments and roles in the address book can be edited.

2.2.5 Light mall permissions

Sub-administrators can install solutions in the light mall and manage the permissions of extension plug-ins and connectors. After turning on the "Light Mall Permissions " button, check the permissions you want to enable as needed to complete the light mall permission settings for the sub-administrator.

Image

4. Precautions

  • Each sub-administrator group can only authorize the same application 50 times. When you click Save, the verification of the upper limit is triggered. The error text returns the application name that reaches the upper limit.
    After more than 50 times, the sub-administrator can still see the application in the authorization items in the background (the front-end is not affected), but cannot configure data permissions and report/view visibility permissions.
  • The upper limit for system administrators is 1000 times

member

1 Introduction

1.1 Function introduction

authorize members in the workspace in batches and configure the members' data permissions in the application dimension. Improve the efficiency of permission management, and make permission configuration efficient and flexible.

1.2 Usage scenarios

Suitable for scenarios where batch configuration or member permission changes are required.

For example, when the system is about to be put into use, the permissions in the workspace can be configured in batches for employees; or when the organizational structure of the enterprise changes, the permissions can be updated uniformly in the management background.

1.3 Effect demonstration

As shown in the figure below, in "Permission Management" - "Members", authorize the "Sales Department" with the permissions of the "Tendering Materials" application package and the "Pre-investment Information Collection & Evaluation" application, and set the permissions that this department can only see Data initiated by this department.

2 Setup steps

2.1 Function entrance

Click the "More" button on the homepage to enter the "Management Backstage" interface. Click "Members" under "Permission Management" to view historical authorization records in the Management Backstage. Click "Add Authorization" to enter the page for authorizing members.

2.2 Function setting steps

2.2.1 Select the role of the operation

In a workspace, the same account can be in multiple sub-administrator groups, or be both a system administrator and a sub-administrator. At this time, people with multiple management roles come to the page to authorize members, and first need to select the administrator role for the operation .

Because of different roles, the scope of authorized resources is different:

  • The system administrator or super administrator can authorize all resources in the workspace;
  • Sub-administrators can only authorize the resource scope that they have the authority to manage.

Notice:

  • Role switching only takes effect on the current page and will not affect the use of other functions.
  • If an account only exists in one sub-administrator group, then there is no need to select an operating role. By default, there is only one management role.

2.2.2 Authorize members

2.2.2.1 Authorization name and scope of authorization

Click "Add Authorization" to enter the page for authorizing members.

You need to fill in the name of this authorization to facilitate a permission query.

You need to select the scope of authorization. You can select multiple members, departments, and roles.

2.2.2.2 Authorization items

Authorization items need to be selected:

1. Authorization items are arranged in a tree structure in the list. The first level is the application package, and the second level is the portal or application


2. In the authorization item list, you can configure the visible permissions of the application package, application, portal, and the data permissions of the application

If a sub-administrator does not have editing permissions for the application package, but has editing permissions for the applications under the application package, the application package will still be displayed, but "-" will be displayed under "Visible Permissions"
. If the sub-admin does not have editing permissions for the application, but If the application has data permissions, the application will still be displayed, but "-" will be displayed under "Visible Permissions"
. Except for the above two cases, resources without editing permissions will not be displayed.

3. The data permissions of the application are effective for all views and reports in the application. For example, to
authorize the data permissions of the "Pre-investment Information Collection & Evaluation" application for the "Sales Department" , configure the conditions-- data scope: data initiated by the current user's department. Field permissions: Visible only .
Then when members of the sales department enter the custom view or report in the "Pre-investment Information Collection & Evaluation" application, they can only view the data of their own department, and it can only be read.

4. Reports and views belong to the application and visibility permissions can be configured

Data Permissions—Data Scope Description

Options

Effect

All data

Can view all data for the app

Data initiated by the current user

You can only view data you initiated in the app

Data initiated by the current user’s department

You can view data initiated by all members of your department

Custom data range

Customize the viewable data range

When serving as "direct supervisor", data initiated by subordinates

only available for private clouds . You can view data initiated by subordinates, including your own

2.2.2.3 Release authorization

Click the "Confirm" button on the upper right side of the authorization page to issue the authorization. Permissions take effect immediately.

If you click "Return to Authorization List" in the upper left corner, a secondary confirmation pop-up window will appear. If you confirm to exit, the authorized configuration will not be retained .

2.2.3 View historical authorization

In the authorization list, you can view historical authorizations. Click the view icon to enter the sub-page to view the details of the authorization.

If you need to modify the authorization, click the "Edit" button in the upper right corner to enter the edit mode for modification. After modification, you need to click "Confirm" in the upper right corner again for the modified authorization to take effect.

2.2.4 Delete historical authorization

In the authorization list, click the delete icon to delete historical authorizations. After deleting historical authorization, the permission relationship matched by the authorization will become invalid.

2.2.5 View/report permission configuration

Authorization can be configured in batches in the management background, and data permissions can be configured using dimensions.
When creating a view or report, if you do not want the view/report to follow the configured application data permissions, you can select "Custom Permissions" when editing the view/report, and the custom data permissions will only take effect for the current view/report.

If you want to follow the configured application data permissions, you can select "Manage background configured data permissions" when editing views/reports. After selecting, you can view the data permissions in effect in the management background.

2.2.6 Decryption of masked fields

Click [Management Backstage] - [Permission Management] - [Members] - [Data Permissions] - [Field Permissions] to decrypt the fields configured with

3 things to note

  • The same member/department/role can be authorized multiple times in the management background, and the final effective permissions are the union.
    For example, the "sales department" is assigned the visibility permission of application A in one authorization, and is assigned the visibility permission of application B in another authorization. The final effect is that application A and application B are visible to the sales department
  • field permissions are not configured in the frontend , the field permissions configured in the backend take effect.
    When a member is authorized multiple times in the background and different field permissions are configured, the union is obtained. "Editable" is compatible with "visible" and "hidden", and "visible" is compatible with "hidden";
    when field permissions are configured in the frontend, the configuration in the backend will be overwritten. However, the effective scope is limited to this view/report, and it takes effect within the entire visible range of this view/report.
  • the data range is not configured in the foreground , the data range configured in the background takes effect.
    When a member is authorized multiple times in the backend and different data ranges are configured, the union is taken;
    when the data range is configured in the frontend, the backend configuration will be overwritten. However, the effective scope is limited to this view/report and takes effect within the full visible range of this view/report.
  • The authorization items of a sub-administrator are limited to the resource management scope of the sub-administrator group. Resources with editing permissions can be granted "visible permissions"; applications with data management permissions can be granted "data permissions"
  • If the sub-administrator group is deleted, the historical authorizations configured by the sub-administrators of the group for members will not become invalid . System administrators or super administrators can manage it in "All Authorizations"

You must have Author or Collection Owner permission to create Guru Cards. Contact your team's Guru admins to use this template.