EA043942B1 - METHOD OF OBTAINING AN EMAIL ACCOUNT BY A USER/EMPLOYEE IN THE SYSTEM - Google Patents

Description

Field of technology

The invention relates to a method for managing email accounts in a management software system such as ERP (Enterprise Resource Planning), and in particular to a method for obtaining an email account for a user/employee in the system.

Prior Art

Role-Based Access Control (RBAC) is one of the most studied and developed permission management mechanisms for databases in recent years. It is considered an ideal option to replace the conventional Mandatory Access Control (MAC) and Discretionary Access Control (DAC). The basic idea of role-based access control (RBAC) is to separate different roles according to different functional positions within an enterprise organization, encapsulate access permission to database resources in roles, and allow users indirect access to database resources by assigning different roles for users.

Large-scale application systems often have a large number of tables and views built into them, making database resource management and authorization significantly more complex. It is very difficult for the user to directly control access and permissions of database resources. This requires the user to have a deep understanding of the database structure and knowledge of the SQL language. As application system design or security requirements change, a large number of complex and extensive permission changes are required, which is very likely to result in information security vulnerabilities caused by unexpected authorization errors. Therefore, developing a simple and effective way to manage permissions for large-scale application systems has become a common requirement for systems and system users.

The role-based permission management mechanism makes it easy and efficient to manage system permissions, which greatly reduces the burden and cost of system rights management, and makes system rights management more compatible with the technical requirements of application system business management.

However, the traditional way of managing user permissions based on roles uses a one-to-many role-to-user relationship mechanism, where the role represents a group/class. This means that one role can simultaneously correspond to or be associated with multiple users, and the role is similar to a position/title/type of work or other concepts. In this communication mechanism, authority authorization for a user is mainly divided into three forms: 1) as shown in FIG. 1, direct authorization of user authority has the disadvantage of high workload and frequency and volume of operations; 2) as shown in Fig. 2, a role (having the nature of a class/group/position/type of work) is authorized (one role can be associated with several users), and the user receives authority through his role; 3) as shown in Fig. 3, the above two kinds are combined.

In descriptions 2 and 3 above, it is necessary to authorize a role that has a class/group nature. The method of authorization through a role having the nature of a class/group/position/type of work has the following disadvantages.

1. Difficulties in performing operations if user permissions change. During actual use of the system, user permissions are subject to frequent changes. For example, during the process of changing an employee's authority, when the employee's authority associated with a role changes, it is not practical to change the authority of the entire role because the authority of an individual employee has changed, since the role is also associated with other employees whose authority has remained unchanged. As a result, either a new role is created corresponding to the employee whose permissions were changed, or the permissions are directly allocated to the employee (not associated with the role) based on the permission requirements. The above two processing methods are not only time-consuming, but also easily lead to errors in role authorization in case the role has high authority. The user has to do a lot of work, which results in errors that lead to losses for the system user.

2. It is difficult to retain the specific powers contained in the role in memory for a long time. If a role has many functional authorities, over time it is difficult to remember the role's specific authorities, and even more difficult to remember the differences in authority between roles with similar authorities. If you need to associate a new user, it is not possible to know exactly how to select an association.

3. As user permissions change, more roles will be created (if new roles are not created, the immediate authorization for the user will increase significantly), and it will be more difficult to find specific differences between role permissions.

4. When transferring a user to another position and need to assign a large number of powers of the transferred user to other users, it is necessary to separate the powers of the transferred user and create roles to communicate with other users accordingly during processing. Such operations are not only complex and time-consuming, but also prone to errors.

- 1 043942

Nowadays, emails are an important means of communication for companies, organizations, etc., and the development of many tasks depends on emails. However, existing email management methods have the following disadvantages: First, one email account is allocated to multiple employees, which leads to information leakage. For example, an email account is allocated to Merchant A, Merchant B, and Merchant C. Therefore, Merchant A can view the email information that Merchant B and Merchant C exchange with their customers, resulting in Merchant B and Merchant C's information being leaked.

Secondly, the email account is used by different employees consecutively, which leads to information leakage. For example, an email account A containing a large amount of confidential R&D information is first allocated to Employee A in the R&D department and then allocated to Employee B in the Sales department after Employee A is fired, and therefore Employee B can view the original confidential information about research and development in Employee A's email account.

Third, the employee registers an email account to carry out company work. After leaving the job, the employee is reluctant to give up the email account because it contains private, confidential information. However, the email account also contains company information, which leads to information leakage.

Fourthly, an email sender does not want to send emails to an email address whose user is constantly changing because it causes sensitive information to be leaked very easily. For example, an employee is late for work, but his manager refrains from deducting Employee A's wages due to Employee A's good business performance, and the manager explains this by sending an email to Employee A. If Employee A's email account is subsequently used by others, this email will disclosed to others, which does not contribute to the management of the company.

Fifth, whenever an employee is hired or transferred from a position, an email account must be associated with the employee (this method of manually associating an email account with an employee has obvious disadvantages: in the long-term process of re-association, the employee's workload may sharply different or even completely different from the corresponding email account, but the email account has been put into operation or even used for a long period of time, which will cause serious obstacles and problems in subsequent work, and invaluable losses), causing large workloads. In addition, there is some lag in re-associating the email account with the employee, which will affect the normal performance of the related work. For example, when Employee A is transferred from a Production Manager to a Sales Manager, after Employee A's existing email account is transferred to his successor, if Employee A is not associated with the new email account, Employee A will be unable to perform the related work due to for not having an email account. If Employee A's existing email account is not transferred to his successor, the successor will not be able to learn the relevant archived email information, which is detrimental to the progress of the job. In another example, Employee A, who serves as the Production and After Sales Manager, is now removed from his role as Production Manager (Employee A's email account is not suitable for transfer to his successor because it contains emails about the After Sales Manager's work). If a new email account is re-allocated to a successor production manager, the appropriate individuals (such as equipment maintenance personnel and third party manufacturers) must be notified. This not only requires a large workload, but also imposes additional work on the partner. Additionally, Employee A may still view subsequent production-related emails (for example, in the event that the sender of the emails is unaware that Employee A has been removed from his position as Production Manager). In another example, when transferring Employee A from a Production Manager position to a Sales Manager position, if a new email account is not allocated to Employee A immediately after Employee A's existing email account is transferred to his successor, Employee A will not be able to check emails for previous sales during this period, which is unfavorable for the normal course of work.

Disclosure of the invention

Technical tasks.

The object of the present invention is to overcome the disadvantages of the prior art and provide a method for a user/employee to obtain an email account in a system. When an employee is assigned to a position (job), they are simultaneously allocated a corresponding role-based email account without the need to separately allocate a role-based email account to the employee, which reduces the workload of assigning email accounts.

- 2 043942

The solution of the problem.

Technical solutions.

The purpose of the present invention is realized using the following technical solutions. A method for a user/employee to obtain an email account in the system includes associating a role-based email account with a role in accordance with the work content of the role in the system, wherein during one period one role can be associated with only one role-based email account character, and one role-character email account can only be associated with one role; wherein said role is an independent subject rather than a group/class, and during the same period one role can only be associated with a unique user, and one user can only be associated with one or more roles; and creating an association between the user and the role, wherein for any user, the role-character email accounts associated with all roles associated with the user are used as the role-character email accounts of the user and/or employee corresponding to the user.

These two steps can be performed in any order.

Preferably, once a role-based email account is associated with a role, the role-based email account associated with the role cannot be replaced; or Once a role-based email account is associated with a role and is used, the role-based email account associated with the role cannot be replaced.

Preferably, when a user's role-based email account needs to be replaced, the role's association with the original role-based email account is unlinked and the role is associated with the new role-based email account.

Preferably, said role-based email account is a mailbox application email account on said system or a mailbox service email account provided by a third party.

Preferably, the method for obtaining an email account by a user/employee in the system further includes: selecting one or more roles as controlling roles, and setting a controlled role for each controlling role, respectively, such that a user associated with a controlling role or an employee corresponding user can manage role-based email accounts associated with all controlled roles corresponding to the controlling role.

Preferably, the method of obtaining an email account for a user/employee in the system further includes: associating an individual email account with the user/employee, wherein during one period only one user/employee can be associated with one email account individual, and one individual email account can only be associated with one user/one employee.

Preferably, once an individual email account is associated with a user/employee, the individual email account associated with the user/employee cannot be replaced; or Once an individual email account is associated with a user/employee and is used, the individual email account associated with the user/employee cannot be replaced.

Preferably, when a personal email account is associated with a user, the personal email account associated with the user is obtained as the personal email account of an employee corresponding to the user.

Preferably, when the individual email account is associated with an employee, the individual email account associated with the employee is obtained as the individual user email account corresponding to the employee.

Preferably, the method for obtaining an email account by a user/employee in the system further includes: selecting one or more roles as controlling roles, and setting a controlled role for each controlling role, respectively, so that: a user associated with a controlling role, or an employee, corresponding to the user, can manage individual user email accounts associated with all controlled roles corresponding to the controlling role; or a user associated with a controlling role, or an employee corresponding to a user, can manage the individual email accounts of an employee corresponding to a user associated with all controlled roles corresponding to the controlling role.

- 3 043942

Positive effects of the invention

Positive effects.

The present invention has the following beneficial effects.

(1) According to the present invention, a role-based email account is associated with each role, and a corresponding role-based email account is allocated to an employee while a position number or job is assigned to the employee at the same time, without the need to allocate a role-based email account to the employee. character separately. In case of dismissal, job transfer, recruitment, etc. There is no lag in role-based email account provisioning, which reduces the burden on email account provisioning.

For example, after a user corresponding to Employee A is associated with Role A and Role B, the role-based email accounts associated with Role A and Role B are automatically allocated to Employee A, without the need to separately allocate an email account to Employee A .

(2) After an employee is transferred from a position or terminated, the role-related email account associated with the role that needs to be allocated to another employee will not be allocated to the employee who is not performing the job content of the role, thereby preventing emails in the account from being leaked email to unrelated parties while the email account is transferred to another user.

For example, the user corresponding to Employee A is associated with both the Device Seller 1 role and the Software Seller 1 role. Since Employee A has resigned (when Employee A leaves, both the Device Seller 1 role and the Software Seller 1 role are released from being associated with the user corresponding to Employee A, and therefore Employee A or the user corresponding to Employee A automatically loses authority to using a role-based email account associated with device vendor 1 and a role-based email account associated with software vendor 1), device vendor 1 is associated with a user corresponding to employee B (employee B receives a role-based email account associated with device vendor 1), and software vendor 1 is associated with a user corresponding to employee C (employee C receives a role-based email account associated with software vendor 1). So Employee B can only check and receive emails for device sales, but cannot check or receive emails for software sales. Likewise, Employee C can only check and receive software sales emails, but cannot check or receive device sales emails.

(3) In the present invention, the role is associated with the role-character email account according to the work content, so the email sender does not need to worry about whether the sent emails in the role-character email account are leaked to unrelated persons, because that the current user of the role-based email account is most likely responsible for the related work.

For example, the work content of role A is attendance statistics, and role A is associated with A's email account. Therefore, after role A is associated with the user corresponding to employee A, employee A becomes the current user of A's email account and the current content Employee A's work certainly includes attendance statistics. Once the email sender sends an attendance related email to email account A, the attendance related email will be invisible to any other person.

(4) Once a role is associated with a role-based email account, the role-based email account associated with the role cannot be replaced. This way, all emails related to the role's job content are sent to the same email account, and there is no need to worry about whether the email account is changed midway.

For example, if role A is associated with email account A, role A is not available to associate with other email accounts, and email account A is also unavailable for association with other roles.

(5) The user/employee corresponding to the controlling role manages the email account of the role nature of the controlled role, for example, having one or more permissions to check the contents of email, send email, delete email, etc., makes it easier for the manager to control and managing the work of subordinates or related roles.

(6) An individual email account is established for a user/employee for the purpose of sending and receiving private informational emails to the user

- 4 043942 tel/employee, thus separating work emails (the role email account handles work emails) from private emails (the individual email account handles private emails). Since a user/employee's individual email account is never allocated to other employees/users, the user/employee does not have to worry about leakage of private information caused by handing over the email account after changing jobs.

For example, if Employee A is late for work, but his manager refrains from deducting Employee A's wages due to Employee A's good business performance, the manager can explain this by sending an email to Employee A's individual email account without worrying about the risk of adverse impact against the company due to a leak of an email to a successor who takes over Employee A's job after Employee A's dismissal or transfer.

(7) The traditional authority management mechanism determines the nature of the group, type of work, class, or the like. as a role. The role is in a one-to-many relationship with the user. During actual use of the system, user permissions are subject to frequent changes. For example, during the process of changing an employee's authority, when the employee's authority associated with a role changes, it is not practical to change the authority of the entire role because the authority of an individual employee has changed, since the role is also associated with other employees whose authority has remained unchanged. As a result, either a new role is created corresponding to the employee whose permissions were changed, or the permissions are directly allocated to the employee (not associated with the role) based on the permission requirements. The above two processing methods are not only time-consuming, but also easily lead to errors in role authorization in case the role has high authority. The user has to do a lot of work, which results in errors that lead to losses for the system user.

However, according to the method proposed in this application, since the role is an independent entity, the goal can be achieved by changing the authority of the role. Although the method of the present application appears to increase the workload during system initialization, by copying or the like, a role can be created or authorized more efficiently than conventional roles having a group nature. Since there is no need to consider the commonality of roles having a group nature when satisfying associated users, the solutions proposed in this application make the setting of permissions clear and unambiguous. In particular, after using the system for a certain period of time (after dynamically changing the user/role permissions), the solutions according to the present application can significantly improve the efficiency of authority management for the system user when using the system, make dynamic authorization simpler, more convenient, clearer and more understandable, and also improve the efficiency and reliability of setting permissions.

(8) The usual method of authorizing a role with the character of a group is prone to error. The method provided in this application significantly reduces the likelihood of authorization errors, since the method described in this application must consider the role only as an independent entity, without considering the commonality of multiple users associated with the role having a group nature in the conventional method. Even if authorization errors occur, only the user associated with the role is affected. However, in the case of a generic role that is in the nature of a group, all users associated with that role are affected. Even if authorization errors occur, the correction method according to the present application is simple and takes little time, while in the case of a normal role having the nature of a group, the commonality of authority of all users related to the needs of the role must be taken into account when correcting errors. With a large number of feature points, modification is cumbersome, complex, and error-prone, and in many cases the problem cannot be solved without creating a new role.

(9) In the traditional group-based role authorization method, if a role has many functional powers, over time it is difficult to remember the specific powers of the role, and even more difficult to remember the differences in powers between roles with similar powers. If you need to associate a new user, it is not possible to know exactly how to select an association. In the method according to the present application, the role itself has the character of a job number/station number, so that the selection can be made easily.

(10) When transferring a user to another position and needing to assign a large number of powers of the transferred user to other users, during processing it is necessary to separate the powers of the transferred user and create roles for communication with other users accordingly. Such operations are not only complex and time-consuming, but also prone to error.

The method according to the present application is as follows: the transferred user is associated with several roles. When you transfer a user, the association between the user and roles in the original department is first unlinked (unlinked roles can be reassociated with other users), and

- 5 043942 The user is then associated with a role in the new department. The operation is simple and not prone to errors.

(11) When creating a role or after it, you must select a department. Once a department has been selected for a role, the department cannot be changed. The reasons why the department that owns the role cannot be replaced are as follows. Reason 1: Since the role according to this application is essentially equivalent to a workstation number or job number, different station numbers or job numbers have different job content or authority. For example, sales role 1 in the sales department and developer role 1 in the technical department have two completely different station numbers or job numbers, and have different authorities. Reason 2: If the department (sales department) that owns the Salesperson 1 role is replaced by the technical department without changing the authority of the salesperson 1 role, then a role exists in the technical department that owns the sales department authority. This leads to management confusion and security vulnerabilities.

Brief description of graphic materials

Description of graphic materials.

In fig. 1 is a schematic representation of direct user authorization in the prior art;

in fig. 2 is a schematic representation of the role authorization of a group or class nature in the prior art;

in fig. 3 is a schematic representation in which direct user authorization is combined with prior art group or class role authorization;

in fig. 4 is a flowchart of an embodiment according to the present invention;

in fig. 5 shows a user authorization scheme based on a role having the nature of an independent subject, according to the present invention.

Carrying out the invention

Description of embodiments of the invention.

The technical solutions according to the present invention will be described below in more detail with reference to the accompanying figures, but the scope of protection of the present invention is not limited to the following description.

As shown in FIG. 4, the method of obtaining an email account by a user/employee in the system includes step 2: linking an email account of a role nature with a role in accordance with the work content of the role in the system (for a role, this step can also be considered as: linking an email account mail with a role in accordance with the content of the role in the system and the use of an email account as an email account of a role nature), and during one period one role can be associated with only one email account, and one email account of a role nature can be associated with only one role.

A role-based email account is an email account that is in the nature of a job number or station number. That is, one role-based email account corresponds to one job number or station number, and one job number or station number corresponds to one role-based email account.

In this embodiment, the role-based email account associated with the role meets two conditions: replaceable and non-replaceable, as detailed below. First, the role-based email account associated with a role is non-fungible. That is, once a role-based email account is associated with a role, the role-based email account associated with the role cannot be replaced; or Once a role-based email account is associated with a role and is used, the role-based email account associated with the role cannot be replaced. Even after a role is suspended, the role-based email account associated with the role still cannot be associated with other roles, but the user associated with the controlling role of the corresponding role, or the employee associated with the user, can still manage the account. role-based email entry. Second, the role-based email account associated with the role is replaceable. When you need to replace a user's role-based email account, you must unassociate the role from the original role-based email account, and associate the role with the new role-based email account.

The role-based email account comes from one or two of the following sources.

1. A role-based email account is an email account of an email application (software) on the system (i.e.

- 6 043942 email entry in the system). In this case, the method further includes the step of creating an email account or a role-based email account.

2. A role-based email account is an email account on an email service provided by a third party, such as a Netease email account, a QQ email account, etc.

As shown in FIG. 5, the role represents an independent entity, not a group/class. During one period, one role can only be associated with a unique user, and one user can be associated with one or more roles. The user is granted permissions for the corresponding role. When or after a role is created, a department is selected for the role, so the role belongs to the department. The authorization of a role is done according to the scope of its work, the role name is unique in the department, and the role number is unique in the system.

Role definition.

A role is not inherently a group/class/category/position/position/job type or the like, but is not collective in nature. The role is unique and represents an independent entity. The role used in an enterprise or institution is equivalent to the position number (in this case, the position number is not a position, and one position can simultaneously have several employees, but during one period one position number can correspond to only one employee).

For example, the following roles can be created in the company's system: General Manager, Deputy General Manager 1, Deputy General Manager 2, Beijing Sales Manager I, Beijing Sales Manager II, Beijing Sales Manager III, Shanghai Sales Engineer 1, Shanghai Engineer Sales 2, Shanghai Sales Engineer 3, Shanghai Sales Engineer 4, Shanghai Sales Engineer 5 and so on. The relationship between users and roles is as follows: if Zhang San (the system creates user Zhang San for Zhang San), an employee of the company, acts as deputy general manager 2 and at the same time acts as manager of Beijing Sales Department I, then Zhang San should be associated with the role of Deputy General Manager 2 and the role of Beijing Sales Department Manager I, that is, Zhang San has the authority of two roles.

The concept of traditional roles is essentially a group/class/position/position/job type, and one role can correspond to multiple users. However, in this application, the concept of a role is equivalent to a job number/job number, and is also similar to a role in film and television drama: one role (in childhood, adolescence, middle age...) can only be performed by one actor or actress at a time, but one actor or an actress can play several roles.

When a user is transferred from one department to another, the user is unassociated with a role in the original department and the user is associated with a role in the new department. After a role is created, a user can be associated with the role during the user creation process, or can be associated with a role at any time after the user is created. Once a user is associated with a role, the user can be released from the role's association at any time, and an association between the user and another role can be created at any time.

One employee corresponds to one user, one user corresponds to one employee, and the employee assigns (gets) permissions based on the role associated with the user corresponding to the employee. The employee is bound to the user for the entire duration of the contract. Once a user is associated with an employee, the user is matched with the employee, and the user cannot be associated with other employees. If an employee leaves, the user cannot match with other employees. When an employee is rehired, they are still the same as the original user.

The method further includes step 2: creating an association between the user and the role, wherein for any user, role-based email accounts associated with all roles associated with the user are used as user and/or employee role-based email accounts , corresponding to the user.

When an email is received/sent, one or more types of information are recorded and displayed, such as the user receiving/sending the email, the employee receiving/sending the email, the role receiving/sending the email, and the time the email was received/sent. which makes it easier to verify which employee, which role and which user receives/sends email, and when the email is received/sent.

The method for obtaining an email account by a user/employee in the system further includes: selecting one or more roles as controlling roles, and setting a controlled role for each controlling role respectively, so that a user associated with a controlling role or an employee corresponding to a user can manage role-based email accounts associated with all controlled

- 7 043942 roles corresponding to the controlling role. Operations performed by a user associated with a controlling role, or an employee corresponding to a user in a role-based email account associated with a controlled role, include one or more of the following: checking email content, deleting email, sending email and so on. If verified email is never verified by the user associated with the supervised role and the employee associated with the user, the verified email still appears as being in an unverified state after being reviewed by the user associated with the supervised role or the employee associated with the user. In addition, after a user associated with a controlling role, or an employee corresponding to a user, manages a role-based email account associated with a controlled role, the role-based email account records and displays information about transactions performed by anyone other than the user/employee. For example, the information includes one or more of the following: a supervisory role that performs the operation, a user associated with the supervisory role, an employee corresponding to the user, the time of the operation, the specific content of the operation, and the like.

The method for obtaining an email account by a user/employee in the system further includes: associating an email account of an individual nature with the user/employee (for the user/employee, this step can be further considered as associating with the user/employee an email account serving as an account individual user/employee email account), and during the same period one user/employee can be associated with only one individual email account, and one individual email account can only be associated with one user/employee employee.

Once an employee is terminated, the individual email account associated with the employee and the employee's corresponding user will be suspended, i.e. the individual email account will also not be assigned to another employee/user, thus preventing leakage of email contents in the individual account. email records. However, if permitted, the employee's supervisor may still manage the individual email account. If an employee is rehired by a company after being terminated, the employee's original email account is automatically re-allocated to the employee/user corresponding to the employee (in a once associated individual email account, the association is always persistent and irreplaceable; in a once associated employee individual email account, the connection is always stable and irreplaceable).

When sending emails, work-related email is sent through the associated role-related email account, and non-work-related email is sent through the individual email account. When setting up an individual email account for a user/employee to receive non-work emails, work emails are separated from non-work emails, thereby making it easier to protect personal private information.

Once an individual email account is associated with a user/employee, the individual email account associated with the user/employee cannot be replaced; or Once an individual email account is associated with a user/employee and is in use, the individual email account associated with the user/employee cannot be replaced.

When an individual email account is associated with a user, the individual email account associated with the user is obtained as the individual email account of an employee corresponding to the user. When an individual email account is associated with an employee, the individual email account associated with the employee is obtained as the individual user email account corresponding to the employee.

The individual email account comes from one or both of the following sources: 1) The individual email account is the email account of the email application (software) on the system (that is, the email account on the system). In this case, the method further includes the step of creating an email account or an individual email account; 2) A personal email account is an email account on an email service provided by a third party, such as a Netease email account, a QQ email account, etc.

-

Claims (8)

The method for obtaining an email account by a user/employee in the system further includes: selecting one or more roles as controlling roles, and setting a controlled role for each controlling role respectively, so that: a user associated with a controlling role or an employee corresponding to the user , can manage individual user email accounts associated with all controlled roles corresponding to the controlling role; or a user associated with a controlling role, or an employee corresponding to a user, can manage the individual email accounts of an employee corresponding to a user associated with all controlled roles corresponding to the controlling role. The foregoing represents only preferred embodiments of the present invention. It should be understood that the invention is not limited to the embodiments disclosed herein and should not be construed to exclude other embodiments, but may be used in various other combinations, modifications and environments. It can also be modified through the above principles or technologies and knowledge in related fields. All changes and modifications made by those skilled in the art without departing from the spirit and scope of the present invention are intended to be within the scope of the appended claims. CLAIM 1. A method for obtaining an email account by a user/employee in a system, including associating a role-based email account with a role in accordance with the work content of the role in the system, wherein during one period one role is associated with only one email account role-based, and one role-based email account is associated with only one role; wherein said role is an independent subject rather than a group/class, and during the same period one role is associated only with a unique user and one user is associated with one or more roles; and creating an association between a user and a role, wherein for any user, the role-character email accounts associated with all roles associated with the user are used as the role-character email accounts of the user and/or employee corresponding to the user; wherein, when a user's role-based email account needs to be replaced, the role's association with the original role-based email account is unlinked and the role is associated with the new role-based email account. 2. The method of claim 1, wherein said role-based email account is an email account for a mailbox application on said system or an email account for a mailbox service provided by a third party. 3. The method of claim 1, further comprising selecting one or more roles as controlling roles and setting a controlled role for each controlling role respectively, so that a user associated with the controlling role or an employee corresponding to the user can manage accounts role-based emails associated with all controlled roles corresponding to the controlling role. 4. The method of claim 1, further comprising associating an individual email account with a user/employee, wherein during one period only one user/employee is associated with one individual email account and one email account individual mail is associated with only one user/one employee. 5. The method of claim 4, wherein once the individual email account is associated with the user/employee, the individual email account associated with the user/employee cannot be replaced; or Once an individual email account is associated with a user/employee and is used, the individual email account associated with the user/employee cannot be replaced. 6. The method of claim 4, wherein after associating the individual email account with the user, the individual email account associated with the user is obtained as the individual email account of the employee corresponding to the user. 7. The method of claim 4, wherein after associating the individual email account with the employee, the individual email account associated with the employee is obtained as the individual user email account corresponding to the employee. 8. The method according to claim 4, further comprising selecting one or more roles as con- -