# Members and Permission Management
Usually within a project, members of different functional roles are required to participate to maximize the value of data analysis. Project managers can add members to the project and assign them flexible, customized functions and data rights to control their actions in TA.
TA controls the functional permissions of members in the project through [Project Roles], and controls the data permissions of members in the project through [Data Permissions].
This chapter mainly includes the following contents:
# I. Project Member Management
# 1.1 Add Members
Project Administrator or supervisor, enter 'Project Management', select 'Member Management' from the left navigation to enter the Member Management page.
There are three ways to add project members:
① Create a new member
- The account name does not exceed 50 characters, and supports numbers, uppercase and lowercase letters, underlined lines, and special characters such as. @().
② Add existing members
- If the member to be added already exists in another project in the system, you can select 'Add Existing Members'. Select the member account to be added from the existing account in the system, assign the project role and data rights, then click OK to add.
③ Import members
- Bulk import members directly from other projects in the system, this will import members and roles under the project at the same time.
Once the addition is complete, members can log in to view the project.
# 1.2 Create a Member Group
In TA daily use, such as dashboard sharing, it becomes a tedious task to set up sharing for multiple dashboard by members. And when new members are added to the project, the shared status of dashboard needs to be changed continuously for new members.
Membership groups are used to solve such scenario problems. Members of the same function can be added to a member group, such as a product group, an operation group, etc., and sharing can be created quickly for members within the group. When a new member is added to a project, the member can view the project assets shared with the member group by simply adding the member to the created member group.
- One member may belong to more than one member group.
- Member groups can only be created in the project, no system-level member groups are currently available.
- Maximum project creation limit for member groups is 50.
Once created, when dashboard shares, you can choose to add shares as a member group. After sharing, the dashboard is visible to all members of the member group.
# 1.3 Manage Members in the Project
# 1.3.1 Member Management in System Management
TA Supervisor can enter [System Administration] → [Rights Management] to view and manage all the members in the system, the items they belong to, etc. Includes member project details, reset passwords, freeze members, and delete member.
- Member project details: You can view the project to which the member belongs, the role and data rights information under the project.
- Reset Password: You can reset the login password for members who have forgotten their password.
- Frozen members: use when you need to suspend a member's access. After freezing, the member will not be able to log in to the TA system; you can unfreeze the frozen member
- Delete member: Delete a member from the system, this operation will delete the project assets created by the member under all projects
WARNING
After deleting a member from the system, all assets under the member will be cleared. To transfer project assets, go to the project where the member is located, select the asset transfer object in [Project Management] and delete the member.
# 1.3.2 Member Management in Project Management
TA supervisor or project administrator can enter [Project Management] → [Member Management], view all members and rights information in the project, and perform member management operations.
| Role | Operation |
|---|---|
| TA Supervisor | Modify the member display name, project permissions, reset the member password, and remove the member from the project |
| Project Manager | Modify the project roles and data permissions of members below the administrator, and remove members below the administrator from the project |
::: tips
When removing a member, in order to ensure that project data is not lost, please transfer the member's assets to other members of the project before removing.
:::
# II. Project Role Management
Roles are a set of [functional operating rights], which control the TA functional modules that members can use. For example, only the 'TA Supervisor' can access the functions in [System Management]; Only 'TA Supervisor' and 'Project Administrator' can configure [Project Management] function modules.
TA presets four types of roles: supervisor, administrator, analyst, and ordinary member, and supports users to customize roles according to usage, and assign appropriate function permissions to system users.
A user can correspond to only one role in a single project.
# 2.1 Preset Roles
TA system default preset supervisor, administrator, analyst, ordinary member four role types:
| Role | Character description |
|---|---|
| TA Supervisor | With full functional permissions |
| Administrator | Full project-level functional permissions |
| Analyst | Permissions with project-based model analysis, Kanban usage and other functions |
| Ordinary members | View and use permissions with only Kanban and other functions |
The function details of each preset role, supervisor and administrator members can click on the role name in [System Administration] or [Project Management] to view.
# 2.2 Custom Roles
TA Supervisor can choose to create a system-level role in System Administration → [Rights Management] → [System Role Management]. After creation, the role can be used in any project in the system.
A project administrator or TA Supervisor can create a project-level role in Project Management → Role Management, which will only be used in the current project after creation.
The maximum number of system-level role creation is 20, and the maximum number of project-level role creation for each project is 30.
# 2.2.1 Create a Role
Click 'Create Role' to enter the role creation page. You can choose to customize the role based on 'Analyst' or 'Ordinary Member':
Analyst-based: Role can be given access to higher-level functions such as group/tag creation, warning management, buried points management, etc.
Ordinary member-based: Function permissions such as analysis model usage and dashboard creation/editing can be granted based on default rights of ordinary members.
Once created, you can assign the role to members when they are added to the project.
# 2.2.2 Management Roles
On the 'Role Management' page, in the list of roles on the left, you can view all the roles available for the current project, including system roles and in-project roles:
- System Roles: Includes System Preset Roles and System Custom Roles created by Supervisors in System Administration.
- In-project roles: roles created under this project.
Move the mouse to the role name in the project, click the edit entry on the right, and you can choose to edit the role or delete the role:
- If you delete a custom role that has been created, all users under the role will be assigned to the system preset role on which the role was created
# III. Data Permission Management
The 'Data Permission' controls the data that members can access in the project, assigning different data permissions to analysts and regular members, as well as other custom roles.
The configuration of data permissions includes the following three parts:
- Visible settings: Sets whether events, event attributes, or user features are visible
- Data range: Filter the available data range based on attribute rules, and only access data that meets the filter condition.
- Data desensitization: Desensitizing and displaying sensitive attributes drilled into events or user lists and user behavior sequences.
# 3.1 Create Data Permissions
(1) Visible Settings
Visible events, event attributes, or user features can be set; only selected events or attributes can be used in the analysis or their analysis results can be viewed, including:
- Individually initiated queries with a choice of events or attributes to analyze
- Whether the query shared by others can be viewed normally (if the query uses invisible events or attributes, it will prompt that there is no viewing permission)
On the left side of the settings bar, you can set whether the new event or attribute is visible by default. The default is 'The new event (or attribute) is visible by default', that is, after the visible permission is set, the new event or attribute put into the library will have viewing permission by default.
If you want to control the visibility of new events or attributes, you can turn off this state. After turning off, users under this data permission cannot use new events or attributes in the project by default.
(2) Data Range
You can optionally limit the range of data members can access in the project based on event attributes or user features. Once set, members can only access ranges of data that match the filter condition, including:
- Individual initiates query, data range of calculation results
- View queries shared by others, data range of calculation results
Depending on the set attribute, the data range entry rules are as follows:
| Filter attributes | Data range | Example |
|---|---|---|
| Event attributes | Only event data that matches the filter criteria can be accessed | If you filter the event property [Server ID = 1], you can only access event data with server ID 1 |
| User features | Access to only filtered users and their event data | If you filter user features [source channel = Huawei App Store], you can only access users from Huawei App Store and event data generated by these users |
After setting the data range, the same dashboard or report will display different calculation results according to different data ranges for members with different data permissions. In order to ensure that members in the project clearly know the data calculation requirement, the data permission and function permission configuration of the account can be viewed in [account center] → [project permission].
(3) Data Desensitization
Event attributes and user attributes fields that need to be desensitized can be selected. The desensitization field only works for detail information, including drilldown lists (including event lists and user lists), and user behavior sequences. The desensitized field set will be invalidated with special characters (*).
After the creation is completed, members below the administrator can be assigned corresponding data permissions in Member Management.
# 3.2 Manage Data Permissions
Once the creation is complete, you can view the data permission information that has been created in the project in the data permission list.
- Mouse over the 'Data Content' column to view an overview of the settings of data permissions.
- You can edit, save as, and delete created data permissions. When deleting, if a member belongs to the data permission, you can choose to transfer the member to another data permission.
# 3.3 Application Description of Data Range
In the analysis model, members will use the data or view the calculation results according to the configured data permissions. In the following function modules, the [Data Range] restriction through attribute filter has different rules of action and is specially described:
(1) Tag
TA tags use user behavior data to explore user characteristics through flexible configuration. The created tags can be filtered or grouped for analysis again in the analysis model.
In order to ensure the usability of tags to different members, and consider that the user's tag characteristics need to be calculated from the user's complete behavior data in most scenarios. If a member with partial data permissions creates a tag, the tag result is still calculated according to [All Data] when creating. However, when members with partial data rights enter the label list to view the label details, they will still only be able to view the tag details of some users with data rights.
- Examples:
The data rights of member A in project A are [only the referrer channel can be the user data of Huawei Application Mall]. If member A has the data permission to create tags, when member A creates tags, the tag value will be calculated according to the full amount of data. However, when member A views the tag details or the tag data in dashboard, he can only view the tag data and details corresponding to the users from Huawei Application Mall.
TIP
The permission logic of other user groups (conditional groups, ID groups) except result groups is the same as the user tag.
(2) Warning
In the warning configuration, the creator needs to create warning trigger rules according to the index performance characteristics, so the calculation range of warning data needs to be consistent with the user's query data range in the analysis model, so that the creator can set appropriate warning rules; In addition, all created warnings under the project are maintained in the warning management module in a unified way, and the warning and warning conditions created by others under the project can be viewed. That is, it is necessary to ensure that different members have the same understanding of the warning conditions.
Therefore, when a warning is created by a member with some data permissions, the data range condition will be automatically brought in to ensure the consistency of the data calculation range and the same understanding of the warning trigger condition from different members.
(3) SQL Query
In general, the calculation logic of SQL queries is the same as other analysis models such as event analysis, that is, the creator can only create SQL reports based on fields with data permissions, and the report viewer can access the calculation results of SQL reports according to his own data permissions.
When saving reports in cross-project queries, you can set whether the viewer needs project permission to query all items involved, defaulting to open and close optionally. Examples of permission changes when opening/closing:
If a cross-project query report involves project A and project B, the shared member a only has project permissions of project A (that is, the account number of member a is not added to project B). If 'All project permissions involved in the query are required' is turned on, member A will not be able to view the report. If this option is turned off, member A can view the report, and because member A does not belong to project B, it cannot obtain its data permission configuration, and the data results will be calculated and displayed according to 'all data' of project B by default.
# 3.4 Best Applications
Scenario 1: Visible Settings
If fields such as cost, attribution, etc. are reported in user attributes, a member of the project has no viewing rights for such attributes. Data permissions can be created, which are set to invisible in the visible settings and assigned to that member.
Scenario 2: Data Range
For businesses involving intermodal transport, e.g. distribution of games through multiple third parties; If you want the issuer of Channel A, you can only view user data under Channel A. Data isolation can be achieved by creating data rights, setting user filters such as filters (source channel = A) and assigning that data permissions to issuer members.
Scenario 3: Data Range
For a new member, the administrator wants to gradually open his data access rights. If he only wants to open the data access rights for the last 30 days, he can set the event filter (the event time is between -30 days and 0 days relative to the current date), which can control the range of data query.
