EA045223B1

EA045223B1 - METHOD TO CONFIGURE AN APPROVAL ROLE ACCORDING TO DEPARTMENT IN THE WORKFLOW APPROVAL NODE

Info

Publication number: EA045223B1
Application number: EA201992753
Authority: EA
Inventors: Дачжи Чень
Original assignee: Чэнду Цяньнюцао Информейшн Текнолоджи Ко., Лтд.
Priority date: 2017-05-23
Filing date: 2018-05-22
Publication date: 2023-11-03

Description

Область техникиField of technology

Данное изобретение относится к способу настройки и управления ролью утверждения в узле утверждения рабочего процесса в программной системе управления, такой как ERP-система; в частности, к способу настройки роли утверждения в соответствии с отделом в узле утверждения рабочего процесса.This invention relates to a method for configuring and managing an approval role in a workflow approval node in a management software system such as an ERP system; specifically, the way the approval role is configured according to department in the workflow approval node.

Уровень техникиState of the art

Управление доступом на основе ролей (RBAC) является одним из наиболее изученных и совершенных механизмов управления доступом к базам данных в последние годы. Данный механизм считается идеальным кандидатом для замены традиционных систем мандатного управления доступом (MAC) и избирательного управления доступом (DAC). Традиционная система избирательного управления доступом обладает высокой гибкостью, но низкой безопасностью. Традиционная система мандатного управления доступом является высокобезопасной, но излишне ограничительной. Система управления доступом на основе ролей сочетает в себе элементы обеих вышеперечисленных систем: она не только легка в управлении, но в то же время снижает сложность, затраты и вероятность ошибок. Поэтому система управления доступом на основе ролей получила стремительное развитие в последние годы. Основная идея управления доступом на основе ролей (RBAC) состоит в том, чтобы разделить различные роли в соответствии с различными функциональными позициями в организационном представлении предприятия, инкапсулировать разрешение доступа к ресурсам базы данных в ролях и разрешить пользователям косвенный доступ к ресурсам базы данных путем назначения различных ролей пользователям.Role-based access control (RBAC) is one of the most studied and advanced database access control mechanisms in recent years. This mechanism is considered an ideal candidate to replace traditional mandatory access control (MAC) and selective access control (DAC) systems. The traditional selective access control system has high flexibility but low security. Traditional mandatory access control systems are highly secure but overly restrictive. A role-based access control system combines elements of both of the above systems: it is not only easy to manage, but at the same time reduces complexity, costs and the likelihood of errors. Therefore, role-based access control has developed rapidly in recent years. The basic idea of role-based access control (RBAC) is to separate different roles according to different functional positions in the organizational view of an enterprise, encapsulate access permission to database resources in roles, and allow users to indirectly access database resources by assigning different roles for users.

В крупномасштабные прикладные системы зачастую встроено большое количество таблиц и представлений, что значительно усложняет управление ресурсами базы данных и авторизацию. Пользователю крайне сложно напрямую управлять авторизацией и ресурсами базы данных. Это требует от пользователя глубокого понимания структуры базы данных и знания языка SQL. С изменением структуры прикладной системы или требований к безопасности требуется большое количество сложных и объемных изменений полномочий, что весьма вероятно приводит к возникновению уязвимостей информационной безопасности, вызванных непредвиденными ошибками авторизации. Поэтому разработка простого и эффективного способа управления полномочиями для крупномасштабных прикладных систем стала общим требованием для систем и пользователей систем.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 extremely difficult for the user to directly manage authorization and 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 access control mechanism allows you to easily and effectively manage system permissions, which significantly reduces the burden and cost of system rights management, and makes system rights management more compatible with application system operational management specifications.

Тем не менее, традиционные способы управления правами пользователей на основе ролей и способы управления рабочим процессом используют механизм связи роль к пользователю - один-ко-многим, где роль является группой/классом. Это означает, что одна роль может одновременно соответствовать или быть связана со многими пользователями; роль аналогична положению, должности, типу работы и тому подобным понятиям. В этом механизме связи авторизация прав пользователей в основном делится на три формы: 1. как показано на фиг. 1, прямая авторизация пользователей, недостатком которой является высокая рабочая нагрузка, а также частота и объемность операций. В процессе утверждения пользователь является субъектом операции утверждения узла утверждения, и в узле утверждения рабочего процесса сотрудник или пользователь выбирается непосредственно в качестве субъекта утверждения. Когда происходят изменения в сотруднике (например, перевод или увольнение), все процессы, связанные с сотрудником, должны быть соответствующим образом скорректированы. В частности, при смене сотрудника на руководящей должности предприятия задействованы многие процессы утверждения. Поскольку корректировка процессов сопряжена с большими рабочими нагрузками и является объемной, возможны ошибки или упущения, влияющие на нормальную деятельность предприятия и приводящие к непредсказуемым потерям.However, traditional role-based user rights management and workflow management methods use a one-to-many role-to-user relationship mechanism, where the role is a group/class. This means that one role can simultaneously correspond to or be associated with many users; role is analogous to position, position, type of work, and similar concepts. In this communication mechanism, user rights authorization is mainly divided into three forms: 1. as shown in FIG. 1, direct user authorization, the disadvantage of which is the high workload, as well as the frequency and volume of operations. In the approval process, the user is the subject of the approval operation of the approval node, and in the approval node of the workflow, the employee or user is selected directly as the subject of the approval. When changes occur in an employee (such as transfer or termination), all processes associated with the employee must be adjusted accordingly. In particular, when replacing an employee in a management position within a business, many approval processes are involved. Because process adjustments are workload-intensive and voluminous, errors or omissions are possible, affecting normal business operations and resulting in unpredictable losses.

Даже если изменение происходит только в полномочиях на утверждение сотрудника, тем не менее приходится соответствующим образом корректировать связанные с сотрудником процессы, что приводит к возникновению вышеизложенных проблем.Even if the change occurs only in the approval authority of the employee, the processes associated with the employee still have to be adjusted accordingly, which leads to the above problems.

2. Как показано на фиг. 2, для авторизации роли типа класс/группа/должность/вид работы (одна роль может быть связана со многими пользователями) пользователь получает полномочия посредством своей роли, а субъектом операции утверждения является роль группового или классового характера. 3. Как показано на фиг. 3, вышеизложенные два способа сочетаются.2. As shown in FIG. 2, to authorize a role of class/group/position/job type (one role can be associated with many users), the user obtains authority through his role, and the subject of the approval operation is a role of a group or class nature. 3. As shown in FIG. 3, the above two methods are combined.

В вышеприведенных описаниях 2 и 3 необходимо проводить авторизацию роли типа класс/группа. Способ авторизации и управления рабочим процессом посредством роли типа класс/группа/должность/вид работы имеет следующие недостатки: 1. возникновение сложностей с выполнением операций в случае изменения полномочий пользователя. В процессе реального использования системы полномочия пользователя подвергаются частым изменениям. Например, в процессе изменения полномочий, когда изменились полномочия сотрудника, связанные с ролью, является нецелесообразным изменять полномочия всей роли по причине изменения полномочий отдельного сотрудника, поскольку роль также связана с другими сотрудниками, чьи полномочия остались неизменными. В результате необходимо либо создать новую роль, соответствующую сотруднику, чьи полномочия были изменены, либо непосредственно пре- 1 045223 доставить полномочия сотруднику (исключенному из роли) на основании требований к полномочиям.In descriptions 2 and 3 above, it is necessary to authorize the role of the class/group type. The method of authorization and management of the work process through a role of the class/group/position/type of work type has the following disadvantages: 1. difficulties in performing operations if the user’s permissions change. During actual use of the system, user permissions are subject to frequent changes. For example, during an authority change process where the employee's authority associated with a role has changed, it is not appropriate to change the authority of the entire role because an individual employee's authority has changed because the role is also associated with other employees whose authority has remained the same. As a result, you must either create a new role corresponding to the employee whose permissions have been changed, or directly grant permissions to the employee (removed from the role) based on the permission requirements.

Вышеописанные два способа обработки не только занимают много времени, но также легко приводят к ошибкам авторизации роли в случае, если роль обладает большими полномочиями. Пользователю приходится выполнять объемную работу, в результате чего происходят ошибки, приводящие к потерям для системного пользователя.The above two processing methods not only take a long time, but also easily lead to role authorization errors in case the role has high authority. The user has to do a lot of work, resulting in errors that result in losses for the system user.

При изменении полномочий на утверждение сотрудника/пользователя (в случае если сотрудник/пользователь исключается из роли), в узле утверждения рабочего процесса либо непосредственно выбирается сотрудник/пользователь в качестве субъекта утверждения, либо добавляется роль для удовлетворения требований процесса утверждения. В первом случае, когда произошли изменения в сотруднике (например, перевод или увольнение), все процессы, связанные с сотрудником, должны быть соответствующим образом скорректированы. В частности, при смене сотрудника на руководящей должности предприятия задействованы многие процессы утверждения. Поскольку корректировка процессов сопряжена с большими рабочими нагрузками, возможны ошибки или упущения, влияющие на нормальную деятельность предприятия и приводящие к непредсказуемым потерям. Даже если изменение происходит только в полномочиях на утверждение сотрудника, тем не менее приходится соответствующим образом корректировать связанные с сотрудником процессы, что приводит к возникновению вышеизложенных проблем. Во втором случае добавление роли содержит создание, связь и авторизацию роли. В частности, когда существует много ролей и много пользователей, связанных с этими ролями, сложно вспомнить, какие именно пользователи связаны с конкретной ролью.When you change the approval authority of an employee/user (if the employee/user is removed from a role), the workflow approval node either directly selects the employee/user as the subject of the approval, or adds a role to satisfy the requirements of the approval process. In the first case, when there has been a change in the employee (for example, transfer or dismissal), all processes associated with the employee must be adjusted accordingly. In particular, when replacing an employee in a management position within a business, many approval processes are involved. Because process adjustments involve heavy workloads, errors or omissions may occur that affect normal business operations and result in unpredictable losses. Even if the change occurs only in the approval authority of the employee, the processes associated with the employee still have to be adjusted accordingly, which leads to the above problems. In the second case, adding a role involves creating, associating, and authorizing the role. In particular, when there are many roles and many users associated with those roles, it is difficult to remember which users are associated with a particular role.

2. Сложно удержать в памяти конкретные полномочия, содержащиеся в роли, в течение длительного времени. Если у роли большой функционал полномочий, с течением времени сложно вспомнить конкретные пономочия роли, и еще труднее вспомнить различия в полномочиях между ролями с аналогичными полномочиями. Полномочия сходных ролей также легко перепутать друг с другом. Если нужно связать нового пользователя, невозможно точно определить, как выбрать отношение.2. It is difficult to retain the specific powers contained in the role in memory for a long time. If a role has a large amount of authority, it is difficult over time to remember the role's specific authority, and even more difficult to remember the differences in authority between roles with similar authority. It is also easy to confuse the responsibilities of similar roles with each other. If you need to associate a new user, it is impossible to know exactly how to select the relationship.

3. Поскольку полномочия пользователя изменяются, это приводит к созданию большего количества ролей (если новые роли не создаются, то значительно повышается прямая авторизация для пользователя), и становится более трудно различить конкретные различия полномочий между ролями.3. As user permissions change, more roles are created (if no new roles are created, direct authorization for the user increases significantly), and it becomes more difficult to discern specific permission differences between roles.

4. При переводе пользователя на другую должность и необходимости назначить другим пользователям большого количества полномочий переведенного пользователя, необходимо разделить полномочия переводимого пользователя и создать роли для связи с другими пользователями. Такие операции не только сложны и трудоемки, но также подвержены ошибкам.4. When transferring a user to another position and the 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 for communication with other users. Such operations are not only complex and time-consuming, but also error-prone.

При настройке узла утверждения в существующем рабочем процессе, как правило, выбирается соответствующее лицо. Для компании с большим количеством сотрудников довольно сложно выбрать сотрудника для утверждения. Кроме того, когда обязанности сотрудника корректируются, необходимо выбрать нового сотрудника для передачи соответствующих обязанностей, что приводит к возникновению ошибок.When setting up an approval node in an existing workflow, you typically select the appropriate person. For a company with a large number of employees, it is quite difficult to select an employee for approval. In addition, when an employee's responsibilities are adjusted, a new employee must be selected to transfer the corresponding responsibilities, which leads to errors.

Краткий обзор изобретенияBrief overview of the invention

Техническая задача.Technical problem.

Задача данного изобретения состоит в преодолении недостатков предшествующего уровня техники и предоставлении способа настройки роли утверждения в соответствии с отделом в узле утверждения рабочего процесса. При настройке роли утверждения необходимо только выбрать соответствующий отдел, в результате операция выполняется быстро и удобно.It is an object of the present invention to overcome the shortcomings of the prior art and provide a method for setting up an approval role according to department in a workflow approval node. When setting up an approval role, you only need to select the appropriate department, resulting in a quick and convenient operation.

Решение задачи. Технические решения.The solution of the problem. Technical solutions.

Задача данного изобретения достигается следующими техническими решениями: способ настройки роли утверждения в соответствии с отделом в узле утверждения рабочего процесса включает в себя: создание отделов и ролей, включенных в организационную структуру системы; настройку роли руководителя отдела в каждом отделе; отображение потенциальных отделов при настройке узла утверждения в рабочем процессе; выбор одного или нескольких отделов из числа потенциальных отделов, где роль руководителя отдела в выбранном отделе служит в качестве роли утверждения указанного узла утверждения.The object of the present invention is achieved by the following technical solutions: a method for setting up an approval role according to a department in a workflow approval node includes: creating departments and roles included in the organizational structure of the system; setting up the role of the department head in each department; Display potential departments when setting up an approval node in a workflow; selecting one or more departments from among the candidate departments, where the department head role in the selected department serves as the approval role of the specified approval node.

Предпочтительно, чтобы каждая роль была независимым лицом, а не группой или классом; одна роль в течение одного и того же периода может быть связана только с уникальным пользователем, и один пользователь может быть связан с одной или несколькими ролями.It is preferable for each role to be an independent individual rather than a group or class; one role during the same period can only be associated with a unique user, and one user can be associated with one or more roles.

Предпочтительно, чтобы способ создания рабочего процесса включал в себя: построение трехуровневой структурной модели пользователь-роль-полномочия, которая включает в себя: уровень роли, где субъект операции утверждения процесса в рабочем процессе является ролью; каждая роль является независимым лицом, а не группой или классом; одна роль в течение одного и того же периода может быть связана только с уникальным пользователем, и один пользователь может быть связан с одной или несколькими ролями; уровень полномочий, который состоит из полномочий, необходимых для использования при выполнении рабочего процесса, причем полномочия предоставляются непосредственно роли; уровень пользователя, где пользователь определяет задачу утверждения в рабочем процессе посредством связанной с ним роли, а также выполняет операцию утверждения с полномочиями связанной с ним роли; использование трехуровневой структурной модели для управления рабочим процессом, где один процессPreferably, the method for creating a workflow includes: constructing a three-level user-role-authority structural model, which includes: a role level, where the subject of the process approval operation in the workflow is a role; each role is an independent individual, not a group or class; one role during the same period can only be associated with a unique user, and one user can be associated with one or more roles; permission level, which consists of the permissions required to be used to execute the workflow, with permissions granted directly to the role; user level, where the user defines the approval task in the workflow through his associated role, and also performs the approval operation with the permissions of his associated role; using a three-level structural model to manage a workflow, where one process

- 2 045223 утверждения включает в себя: один начальный узел, инициирующий процесс утверждения; по крайней мере один узел утверждения, предоставляющий (или устанавливающий) полномочия на утверждение соответствующей роли утверждения; один конечный узел, в котором завершается процесс утверждения;- 2 045223 approval includes: one initial node that initiates the approval process; at least one approval node granting (or establishing) approval authority to the corresponding approval role; one end node where the approval process is completed;

а также определение задачи утверждения, подлежащей обработке, в соответствии со связанной с пользователем ролью, и выполнение операции утверждения с полномочиями связанной роли.and determining the approval task to be processed according to the user's associated role, and performing the approval operation with the authority of the associated role.

Предпочтительно, чтобы только роль, имеющая полномочия на инициирование рабочего процесса, могла инициировать/запрашивать/отправлять рабочий процесс в качестве роли инициирования.Preferably, only a role that has permission to initiate a workflow can initiate/request/submit a workflow as an originating role.

Предпочтительно, чтобы роль принадлежала определенному отделу и была авторизована в соответствии с рабочим содержанием роли.Preferably, the role belongs to a specific department and is authorized according to the operational content of the role.

Предпочтительно, чтобы имя роли было уникальным в рамках отдела, а номер роли был уникальным в системе.Preferably, the role name should be unique within the department and the role number should be unique within the system.

Предпочтительно, чтобы во время перевода пользователя между отделами связь пользователя с ролью в исходном отделе отменялась и пользователь становился связан с ролью в новом отделе.Preferably, when a user is transferred between departments, the user's association with the role in the original department is unassigned and the user becomes associated with the role in the new department.

Предпочтительно, чтобы пользователь определял полномочия посредством своей связи с ролью, один сотрудник соответствовал одной учетной записи пользователя и одна учетная запись пользователя соответствовала одному сотруднику.Preferably, a user defines permissions through his association with a role, one employee corresponds to one user account, and one user account corresponds to one employee.

Предпочтительно, чтобы формы отображения потенциальных отделов включали список, древовидную схему организационной структуры и схему архитектуры организационной структуры.Preferably, the display of potential departments should include a list, an organizational tree diagram, and an organizational structure architecture diagram.

Способ настройки роли утверждения в соответствии с отделом в узле утверждения рабочего процесса включает в себя: создание отделов и ролей, включенных в организационную структуру системы; настройку роли руководителя отдела в каждом отделе; выбор (конфигурирование) настроек роли утверждения в соответствии с отделом; отображение потенциальных отделов при настройке узла утверждения рабочего процесса; выбор одного или нескольких отделов из числа потенциальных отделов, где роль руководителя отдела в выбранном отделе служит ролью утверждения указанного узла утверждения.The method for setting up the approval role according to the department in the workflow approval node includes: creating departments and roles included in the organizational structure of the system; setting up the role of the department head in each department; selecting (configuring) approval role settings according to the department; Display potential departments when setting up a workflow approval node; selecting one or more departments from among potential departments, where the department head role in the selected department serves as the approval role of the specified approval node.

Положительные эффекты изобретенияPositive effects of the invention

Положительные эффекты.Positive effects.

Данное изобретение имеет следующие полезные эффекты: (1) персоналу, ответственному за настройку рабочего процесса системы, при настройке роли утверждения необходимо только выбрать соответствующий отдел, и затем роль руководителя отдела в данном отделе служит в качестве роли утверждения. Даже если роль руководителя отдела в отделе изменилась, текущая роль руководителя отдела в отделе служит в качестве роли утверждения и не требуется выполнять сброс роли утверждения, что, соответственно, ускоряет и упрощает проведение операций, а также значительно снижает вероятность возникновения ошибок.This invention has the following beneficial effects: (1) the personnel responsible for setting up the system workflow, when setting up an approval role, only needs to select the appropriate department, and then the department head role in that department serves as the approval role. Even if the department head's role in the department has changed, the current department head's role in the department serves as the approval role and there is no need to reset the approval role, which consequently makes operations faster and easier, and greatly reduces the possibility of errors occurring.

Например, при подаче сотрудником заявления на отпуск, ему требуется утверждение административного отдела. В данном изобретении необходимо только выбрать административный отдел в узлах утверждения. Роль руководителя отдела в административном отделе служит ролью утверждения и сотрудник, соответствующий роли руководителя отдела, получает задачу утверждения посредством роли руководителя отдела, а также выполняет утверждение согласно соответствующим полномочиям роли руководителя отдела. Нет необходимости выбирать конкретного сотрудника для настройки утверждения, что делает выполнение операций простым и удобным. Если роль руководителя отдела в административном отделе изменяется с роли А на роль В, то сотрудник, соответствующий роли В, выполняет утверждение без необходимости повторной настройки роли утверждения.For example, when an employee applies for leave, he needs approval from the administrative department. In the present invention, it is only necessary to select the administrative department in the approval nodes. The Department Head role in the administrative department serves as the approval role, and the employee corresponding to the Department Head role receives the approval task through the Department Head role, and also performs the approval according to the corresponding authority of the Department Head role. There is no need to select a specific employee to set up approval, making operations simple and convenient. If the department manager role in an administrative department is changed from role A to role B, then the employee assigned to role B performs the approval without having to reconfigure the approval role.

(2) Субъектом операции утверждения в рабочем процессе является роль, которая является независимым лицом, а не традиционной ролью группового или классового характера. Даже если произошли изменения в сотруднике или пользователе (например, перевод или увольнение) или если полномочия на утверждение сотрудника изменились, необходимо только связать сотрудника с новой ролью или соответствующим образом настроить полномочия на утверждение существующей роли, но нет необходимости сбрасывать или корректировать процессы. По мере того как настройка удобна и никакие ошибки или упущения не произойдут, нормальная деятельность предприятия не будет затронута, в результате чего значительно повышается надежность рабочего процесса. Роль принимается в качестве субъекта авторизации на утверждение в соответствии со свойствами номера должности в узле утверждения. Пользователь определяет, какие задачи утверждения доступны в соответствии с ролью. Пользователю необходимо только выполнить операции утверждения на основе полномочий связанной роли, это ясно и доступно для понимания. Каждая роль, которая является номером должности или номером рабочей станции, по сути является минимальной единицей субъекта работы. Данная заявка способна удовлетворять различным требованиям утверждения каждой роли.(2) The subject of an approval operation in a work process is a role that is an independent person, rather than a traditional role of a group or class nature. Even if there is a change in an employee or user (such as a transfer or termination), or if the employee's approval authority changes, you only need to associate the employee with the new role or adjust the approval authority of the existing role accordingly, but there is no need to reset or adjust processes. As long as the setup is convenient and no errors or omissions occur, normal plant operations will not be affected, resulting in significantly improved workflow reliability. The role is accepted as the subject of authorization for approval according to the job number properties in the approval node. The user determines which approval tasks are available according to the role. The user only needs to perform approval operations based on the permissions of the associated role, this is clear and easy to understand. Each role, which is a job number or a workstation number, is essentially the minimum unit of the subject of work. This application is capable of satisfying the different approval requirements of each role.

(3) В данной заявке роль связывается с пользователем один-к-одному Одна роль может быть связана только с уникальным пользователем в течение одного и того же периода. Преимущество состоит в том, что для получения полномочий необходимо только связать пользователя с ролью (то есть пользователь получает полномочия связанной с ним роли), и изменения в полномочиях роли намного меньше, чем изменения в полномочиях пользователя в традиционном механизме. Незначительные изменения происходят в количестве ролей, каждая из которых по сути является независимым лицом (по сути номер(3) In this application, a role is associated with a user one-to-one. One role can only be associated with a unique user during the same period. The advantage is that to gain permissions, you only need to associate a user with a role (that is, the user gains the permissions of the associated role), and the changes to the role's permissions are much smaller than the changes to the user's permissions in a traditional mechanism. Minor changes occur in the number of roles, each of which is essentially an independent person (essentially a number

- 3 045223 должности или номер рабочей станции). Несмотря на большую текучесть кадров, в номере должности/номере рабочего места изменения незначительны (вплоть до отсутствия изменений в определенный период времени, то есть роль не меняется). Это значительно упрощает управление полномочиями пользователей и снижает накладные расходы системы.- 3 045223 position or workstation number). Despite the high turnover of personnel, changes in the position number/workplace number are insignificant (up to no changes in a certain period of time, that is, the role does not change). This greatly simplifies the management of user permissions and reduces system overhead.

(4) Такие операции как динамическое управление, набор и перевод персонала, являются простыми, удобными, эффективными и высоконадежными. Заявление о приеме на работу, увольнении или переводе в процессе утверждения является простым. Субъектом операции утверждения в рабочем процессе является роль. При изменении сотрудника или пользователя процесс утверждения не требуется сбрасывать (достаточно отменить связь или связать пользователя с ролью). Для пользователя, который больше не является в роли номера должности или номера рабочей станции, связь с ролью отменяется, и пользователь, который принимает номер должности или номер рабочей станции, становится связан с ролью номера должности. Таким образом, пользователь, связанный с ролью, автоматически получает связанные задачи и полномочия роли в рабочем процессе утверждения, без сброса рабочего процесса утверждения или повторной авторизации роли в рабочем процессе, что значительно повышает эффективность, безопасность и надежность настройки процесса.(4) Operations such as dynamic management, recruitment and transfer of personnel are simple, convenient, efficient and highly reliable. Applying for a job, leaving or transferring through the approval process is straightforward. The subject of an approval operation in a workflow is a role. When an employee or user changes, the approval process does not need to be reset (just unlink or associate the user with a role). For a user who is no longer in the job number or workstation number role, the association with the role is released, and the user who assumes the job number or workstation number becomes associated with the job number role. In this way, the user associated with the role automatically receives the associated tasks and permissions of the role in the approval workflow, without resetting the approval workflow or re-authorizing the role in the workflow, greatly improving the efficiency, security, and reliability of process setup.

Например, в силу того что пользователь Чжан Сань перемещается или уходит с должности, Чжан Сань более не работает в качестве роли покупатель 3, и связь Чжан Саня с данной ролью отменяется. Между тем, Ли Сы принимает на себя работу в роли покупатель 3, затем устанавливается связь Ли Сы с данной ролью, в результате чего Ли Сы автоматически приобретает задачи утверждения и полномочия на утверждение роли покупатель 3 в процессе утверждения.For example, because user Zhang San moves or leaves his position, Zhang San no longer works as the role buyer 3, and Zhang San's association with that role is canceled. Meanwhile, Li Si takes over the role of Buyer 3, then Li Si is linked to the role, causing Li Si to automatically acquire the approval tasks and authority to approve the role of Buyer 3 in the approval process.

(5) Традиционный механизм управления полномочиями определяет группу, вид работы, класс и тому подобное в качестве роли. Роль к пользователю находится в отношении один-ко-многим. В процессе реального использования системы полномочия пользователя подвергаются частым изменениям. Например, при обработке изменений в полномочиях сотрудника, когда изменились полномочия сотрудника, связанные с ролью, является нецелесообразным изменять полномочия всей роли по причине изменения полномочий отдельного сотрудника, поскольку роль также связана с другими сотрудниками, чьи полномочия остались неизменными. В результате необходимо либо создать новую роль, соответствующую сотруднику, чьи полномочия были изменены, либо непосредственно предоставить полномочия сотруднику (исключенному из роли) на основании требований к полномочиям. Вышеописанные два способа обработки не только занимают большое количество времени, но также легко приводят к ошибкам авторизации роли в случае, если роль обладает большими полномочиями. Пользователю приходится выполнять объемную работу, в результате чего происходят ошибки, приводящие к потерям для системного пользователя.(5) The traditional authority management mechanism defines a group, job type, class and the like as a role. The role to the user is in a one-to-many relationship. During actual use of the system, user permissions are subject to frequent changes. For example, when processing changes to an employee's permissions when the employee's permissions associated with a role have changed, it is not practical to change the permissions of the entire role because an individual employee's permissions have changed because the role is also associated with other employees whose permissions have remained the same. As a result, you must either create a new role that matches the employee whose permissions have been changed, or directly grant permissions to the employee (removed from the role) based on the permission requirements. The above two processing methods not only take a lot of time, but also easily lead to role authorization errors in case the role has high authority. The user has to do a lot of work, resulting in errors that result in losses for the system user.

Тем не менее, согласно способу данной заявки, поскольку роль является независимым лицом, цель может быть достигнута путем изменения полномочий данной роли. Несмотря на то что способ в данной заявке, вероятно, увеличивает рабочую нагрузку во время инициализации системы посредством копирования или тому подобного, тем не менее, роль может быть создана или авторизована более эффективно, чем традиционные роли группового характера. Поскольку при удовлетворении связанных пользователей нет необходимости учитывать унифицированность ролей группового характера, решения, предусмотренные в данной заявке, делают настройку полномочий ясной и точной. Особенно после того, как система была использована в течение определенного периода времени (после динамического изменения полномочий пользователя/роли), решения, предусмотренные в данной заявке, могут значительно повысить эффективность управления полномочиями для системного пользователя, сделать динамическую авторизацию более простой, более удобной, более ясной и точной, а также повысить эффективность и надежность настройки полномочий.However, according to the method of this application, since the role is an independent person, the goal can be achieved by changing the authority of the role. Although the method herein is likely to increase the workload during system initialization through copying or the like, a role can still be created or authorized more efficiently than traditional group-based roles. Since there is no need to consider the uniformity of group roles when satisfying associated users, the solutions provided in this application make the configuration of permissions clear and precise. Especially after the system has been used for a certain period of time (after the user/role authority has been dynamically changed), the solutions provided in this application can greatly improve the efficiency of authority management for the system user, making dynamic authorization easier, more convenient, more clear and precise, and improve the efficiency and reliability of setting permissions.

(6) Традиционный способ на основе групповой авторизации ролей подвержен ошибкам. Способ, предоставленный в данной заявке, значительно снижает вероятность ошибок авторизации, поскольку в способе данной заявки роль рассматривается только в качестве независимого лица, без учета унифицированности множества пользователей, связанных с ролью группового характера по традиционному способу. Даже если возникают ошибки авторизации, затрагивается только пользователь, связанный с ролью. Однако в случае традиционной роли группового характера затрагиваются все пользователи, связанные с ролью. Даже если возникают ошибки авторизации, способ исправления в данной заявке прост и занимает непродолжительный период времени, в то время как в случае традиционной роли группового характера при исправлении ошибок необходимо учитывать унифицированность полномочий всех пользователей, связанных с ролью. Если у роли большой функционал, исправление является объемным, сложным и подверженным ошибкам, и во многих случаях проблема не может быть решена до тех пор, пока не будет создана новая роль.(6) The traditional method based on group role authorization is error-prone. The method provided in this application significantly reduces the likelihood of authorization errors, since in the method of this application the role is considered only as an independent person, without taking into account the uniformity of the set of users associated with the role of a group nature in the traditional way. Even if authorization errors occur, only the user associated with the role is affected. However, with a traditional group role, all users associated with the role are affected. Even if authorization errors occur, the correction method in this application is simple and takes a short period of time, while in the case of a traditional role of a group nature, when correcting errors, it is necessary to take into account the uniformity of the powers of all users associated with the role. If a role has a lot of functionality, the fix is lengthy, complex, and error-prone, and in many cases the problem cannot be resolved until a new role is created.

(7) В традиционном способе групповой авторизации ролей, если у роли большой функционал полномочий, с течением времени сложно вспомнить конкретные пономочия роли, и еще труднее вспомнить различия в полномочиях между ролями с аналогичными полномочиями. Если нужно связать нового пользователя, невозможно точно определить, как выбрать отношение. В способе данной заявки сама роль имеет характер номера должности или номера рабочей станции, что значительно упрощает выбор.(7) In the traditional method of group role authorization, if a role has a large functionality of authority, over time it is difficult to remember the specific authority of the role, and even more difficult to remember the differences in authority between roles with similar authority. If you need to associate a new user, it is impossible to know exactly how to select the relationship. In the method of this application, the role itself has the character of a position number or workstation number, which greatly simplifies the choice.

- 4 045223 (8) При переводе пользователя на другую должность и необходимости назначить другим пользователям большого количества полномочий переводимого пользователя, необходимо разделить полномочия переводимого пользователя и создать роли для связи с другими пользователями. Такие операции не только сложны и трудоемки, но также подвержены ошибкам.- 4 045223 (8) When transferring a user to another position and it is necessary 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 for communication with other users. Such operations are not only complex and time-consuming, but also error-prone.

Способ в данной заявке заключается в следующем: переводимый пользователь связан с несколькими ролями. При переводе пользователя сначала отменяется связь между пользователем и ролями в исходном отделе (отмененные роли могут быть повторно связаны с другими пользователями), и затем устанавливается связь пользователя с ролью в новом отделе. Операция проста и не подвержена ошибкам.The method in this application is as follows: the transferred user is associated with several roles. When you transfer a user, you first unassociate the user from roles in the original department (unlinked roles can be reassigned to other users), and then associate the user with a role in the new department. The operation is simple and error-free.

(9) Роль принадлежит определенному отделу и отдел роли не может быть заменен. Причины, по которым отдел, которому принадлежит данная роль, не может быть заменен, заключаются в следующем. Причина 1: поскольку роль в данной заявке по сути эквивалентна номеру рабочей станции или номеру должности, различные номера рабочих станций или номера должностей имеют разное содержание работы или полномочия. Например, роль продавца 1 в отделе продаж и роль разработчика 1 в техническом отделе - это два совершенно разных номера рабочих станций или номера должностей, и имеют разные полномочия. Причина 2: если отдел (отдел продаж), которому принадлежит роль продавца 1, заменяется техническим отделом без изменения полномочий роли продавца 1, то в техническом отделе существует роль, которой принадлежат полномочия отдела продаж. Это приводит к беспорядку в управлении и уязвимостям безопасности.(9) The role belongs to a specific department and the department of the role cannot be replaced. The reasons why the department that owns the role cannot be replaced are as follows. Reason 1: Because the role in this requisition is essentially equivalent to a workstation number or job number, different workstation 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 are two completely different workstation numbers or job numbers, and have different authority. 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 the attached graphic materials

Описание прилагаемых графических материалов.Description of the attached graphic materials.

На фиг. 1 представлено схематическое изображение непосредственной авторизации пользователя в системе в предшествующем уровне техники;In fig. 1 is a schematic representation of direct user authorization in the system in the prior art;

на фиг. 2 представлено схематическое изображение авторизации роли группового или классового характера в предшествующем уровне техники;in fig. 2 is a schematic representation of the role authorization of a group or class nature in the prior art;

на фиг. 3 представлено схематическое изображение непосредственной авторизации и пользователя, и роли группового или классового характера в системе в предшествующем уровне техники;in fig. 3 is a schematic representation of the direct authorization of both the user and the role of a group or class nature in the system in the prior art;

на фиг. 4 представлена блок-схема способа настройки роли утверждения в соответствии с отделом в узле утверждения рабочего процесса согласно данному изобретению;in fig. 4 is a flowchart of a method for setting up an approval role according to a department in a workflow approval node according to the present invention;

на фиг. 5 представлено схематическое изображение рабочего процесса в согласно данному изобретению;in fig. 5 is a schematic representation of the work process according to the present invention;

на фиг. 6 представлена блок-схема способа настройки роли утверждения в соответствии с отделом в узле утверждения рабочего процесса согласно данному изобретению.in fig. 6 is a flowchart of a method for setting up an approval role according to a department in a workflow approval node according to the present invention.

Осуществление изобретенияCarrying out the invention

Описание вариантов осуществления.Description of embodiments.

Технические решения данного изобретения будут описаны ниже более подробно со ссылкой на прилагаемые графические материалы, но защищенная область данного изобретения не ограничивается нижеследующим.The technical solutions of the present invention will be described below in more detail with reference to the accompanying drawings, but the protected scope of the present invention is not limited to the following.

Вариант осуществления 1. Как показано на фиг. 4, способ настройки роли утверждения в соответствии с отделом в узле утверждения рабочего процесса включает в себя: создание отделов и ролей, включенных в организационную структуру системы.Embodiment 1 As shown in FIG. 4, the method of setting up the approval role according to the department in the workflow approval node includes: creating departments and roles included in the organizational structure of the system.

Определение роли: роль по своей сути не является группой/классом/категорией/должностью/положением/видом работы или тому подобным, но носит неколлективный характер. Роль уникальна и является независимым лицом. Применяемая на предприятии или в учреждении, роль эквивалентна номеру должности (при этом номер должности не является должностью, одна должность может одновременно иметь несколько сотрудников, но один номер должности может соответствовать только одному сотруднику в течение одного и того же периода).Role Definition: A role is not inherently a group/class/category/position/position/job type or the like, but is non-collective in nature. The role is unique and independent. When used in an enterprise or institution, a role is equivalent to a position number (a position number is not a position; one position can have several employees at the same time, but one position number can correspond to only one employee during the same period).

Например, в системе компании могут быть созданы следующие роли: генеральный менеджер, заместитель генерального менеджера 1, заместитель генерального менеджера 2, менеджер Пекинского отдела продаж I, менеджер Пекинского отдела продаж II, менеджер Пекинского отдела продаж III, Шанхайский инженер по продажам 1, Шанхайский инженер по продажам 2, Шанхайский инженер по продажам 3, Шанхайский инженер по продажам 4, Шанхайский инженер по продажам 5 и так далее. Отношение между пользователями и ролями выглядит следующим образом: если Чжан Сань, сотрудник компании, выступает в качестве заместителя генерального менеджера 2 и в то же время выступает в качестве менеджера Пекинского отдела продаж I, то Чжан Сань должен быть связан с ролью заместителя генерального менеджера 2 и ролью менеджера Пекинского отдела продаж I, то есть Чжан Сань обладает полномочиями двух ролей.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, an employee of a company, acts as Deputy General Manager 2 and at the same time acts as a 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.

Каждая роль является независимым лицом, а не группой или классом; одна роль может быть связа- 5 045223 на только с уникальным пользователем в течение одного и того же периода, и один пользователь может быть связан с одной или несколькими ролями.Each role is an independent individual, not a group or class; one role can only be associated with a unique user during the same period, and one user can be associated with one or more roles.

Роль принадлежит определенному отделу, роль авторизуется в соответствии с рабочим содержанием роли, роль состоит из названия должности и номера должности, имя роли уникально в рамках отдела и номер роли уникален в системе.A role belongs to a specific department, a role is authorized according to the work content of the role, a role consists of a job title and a position number, a role name is unique within a department, and a role number is unique in the system.

При переводе пользователя между отделами связь пользователя с ролью в исходном отделе отменяется и пользователь становится связан с ролью в новом отделе. После создания роли, пользователь может быть связан с ролью в процессе создания пользователя или может быть связан с ролью в любое время после создания пользователя. После того, как пользователь связан с ролью, пользователь может быть освобожден от связи с ролью в любое время, и связь между пользователем и другой ролью может быть создана в любое время.When a user is transferred between departments, the user's association with the role in the original department is unassigned and the user becomes associated with the role in the new department. Once a role is created, the user can be associated with the role during the user creation process, or can be associated with the 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.

Пользователь определяет полномочия посредством своей связи с ролью; один сотрудник соответствует одной учетной записи пользователя, и одна учетная запись пользователя соответствует одному сотруднику.A user defines permissions through their association with a role; one employee corresponds to one user account, and one user account corresponds to one employee.

Настройка роли руководителя отдела в каждом отделе.Set up the role of the department head in each department.

Отображение потенциальных отделов при настройке узла утверждения рабочего процесса. Формы отображения потенциальных отделов включают список, древовидную схему организационной структуры и схему архитектуры организационной структуры.Display potential departments when setting up a workflow approval node. Forms for displaying potential departments include a list, an organizational tree diagram, and an organizational structure architecture diagram.

Как показано на фиг. 5, способ создания рабочего процесса включает в себя: построение трехуровневой структурной модели пользователь-роль-полномочия, которая включает в себя: уровень роли, где субъектом операции утверждения процесса в рабочем процессе является роль; каждая роль является независимым лицом, а не группой или классом; одна роль может быть связана только с уникальным пользователем в течение одного и того же периода, и один пользователь может быть связан с одной или несколькими ролями; уровень полномочий, который состоит из полномочий, необходимых для использования при выполнении рабочего процесса, причем полномочия предоставляются непосредственно роли; уровень пользователя, где пользователь определяет задачу утверждения в рабочем процессе посредством связанной с ним роли, и выполняет операцию утверждения с полномочиями связанной с ним роли; использование трехуровневой структурной модели для управления рабочим процессом, где один процесс утверждения включает в себя: один начальный узел, где в качестве начального узла является узел, инициирующий/запрашивающий/отправляющий рабочий процесс, или первый узел утверждения; по крайней мере один узел утверждения, предоставляющий (или устанавливающий) полномочия на утверждение соответствующей роли утверждения; один конечный узел, в котором завершается процесс утверждения, где конечный узел не выполняет операцию утверждения, или последний узел утверждения служит конечным узлом и конечный узел должен выполнить операцию утверждения; определение задачи утверждения, подлежащей обработке, в соответствии со связанной с пользователем ролью, и выполнение операции утверждения с полномочиями связанной роли.As shown in FIG. 5, the method for creating a workflow includes: building a three-level user-role-authority structural model, which includes: the role level, where the subject of the process approval operation in the workflow is a role; each role is an independent individual, not a group or class; one role can only be associated with a unique user during the same period, and one user can be associated with one or more roles; permission level, which consists of the permissions required to be used to execute the workflow, with permissions granted directly to the role; user level, where the user defines an approval task in a workflow through his associated role, and performs the approval operation with the authority of his associated role; using a three-level structural model to manage the workflow, where one approval process includes: one starting node, where the starting node is the node initiating/requesting/submitting the workflow or the first approval node; at least one approval node granting (or establishing) approval authority to the corresponding approval role; one end node at which the approval process is completed, where the end node does not perform the approval operation, or the last approval node serves as the end node and the end node must perform the approval operation; Determining the approval task to be processed according to the user's associated role, and performing the approval operation with the permissions of the associated role.

Выбор одного или нескольких отделов из списка потенциальных отделов, где роль руководителя отдела в выбранном отделе служит ролью утверждения указанного узла утверждения.Select one or more departments from a list of potential departments, where the department manager role in the selected department serves as the approval role of the specified approval node.

Вариант осуществления 2. В данном варианте осуществления настройка роли утверждения в рабочем процессе заявления на отпуск используется в качестве примера для иллюстрации данного изобретения.Embodiment 2 In this embodiment, setting the approval role in the leave application workflow is used as an example to illustrate the present invention.

Компания включает в себя административный отдел и отдел продаж. В отделе продаж имеются роль A, роль B и роль C. В административном отделе имеются роль D, роль E и роль F. При этом роль A является ролью руководителя отдела в отделе продаж и роль D является ролью руководителя отдела в административном отделе. Заявления на отпуск в компании утверждаются административным отделом. Настройка узла утверждения в рабочем процессе заявления на отпуск включает в себя следующие этапы: создание отдела продаж и административного отдела, где в отделе продаж имеются роль A, роль B и роль C, а в административном отделе имеются роль D, роль E и роль F.The company includes an administrative department and a sales department. In the sales department there is role A, role B and role C. In the administrative department there is role D, role E and role F. In this case, role A is the role of the department head in the sales department and role D is the role of the department head in the administrative department. Applications for leave in the company are approved by the administrative department. Setting up an approval node in the leave application workflow involves the following steps: Creating a Sales Department and an Administration Department, where Sales has Role A, Role B, and Role C, and Administration has Role D, Role E, and Role F.

Роль A устанавливается в качестве роли руководителя отдела в отделе продаж, а роль D - в качестве роли руководителя отдела в административном отделе.Role A is set as the department manager role in the sales department, and role D is set as the department head role in the administrative department.

В рабочем процессе заявления на отпуск выбирается один узел утверждения, где отображаются потенциальные отделы, и потенциальные отделы включают отдел продаж и административный отдел.In the leave application workflow, one approval node is selected where the potential departments are displayed, and the potential departments include the sales department and the administrative department.

Выбирается административный отдел, где в данном случае роль руководителя отдела в административном отделе служит в качестве утверждающего в узле, то есть роль D служит в качестве роли утверждения узла утверждения.The administrative department is selected, where in this case the department head role in the administrative department serves as the approver in the node, that is, role D serves as the approval role of the approval node.

Предполагается, что в связи с корректировкой разделения труда в административном отделе, роль E служит в качестве новой роли руководителя отдела в административном отделе. В данном случае роль E является ролью утверждения узла утверждения, и нет необходимости проводить сброс роли утверждения.It is assumed that due to the adjustment of the division of labor in the administrative department, role E serves as the new role of the department head in the administrative department. In this case, role E is the approval role of the approval node, and there is no need to reset the approval role.

Предполагается, что пользователь, с которым связана роль D, изменяется с Чжан Саня на Ли Си. Необходимость заново устанавливать роль утверждения также отсутствует.It is assumed that the user associated with role D changes from Zhang San to Li Xi. There is also no need to reinstall the approval role.

Вариант осуществления 3. Как показано на фиг. 6, способ настройки роли утверждения в соответст-Embodiment 3 As shown in FIG. 6, the method of setting the approval role according to

Claims

The view with the department in the workflow approval node includes: creating departments and roles included in the organizational structure of the system; setting up the role of the department head in each department; selecting (configuring) approval role settings according to the department; Display potential departments when setting up a workflow approval node; selecting one or more departments from among potential departments, where the department head role in the selected department serves as the approval role of the approval node.

The foregoing represents only preferred embodiments of the present invention, and it is to 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 guidance or technology and knowledge in related fields. All changes and modifications made by those skilled in the art shall be within the scope of the appended claims.

CLAIM

1. A computer-implemented method for setting up an approval role according to a department in a workflow approval node, characterized in that it includes:

creation of departments and roles included in the organizational structure of the system;

setting up the role of the department head in each department;

Display potential departments when setting up a workflow approval node;

selecting one or more departments from among the candidate departments, wherein the department head role in the selected department serves as an approval role of said approval node;

each role is an independent person, not a group or class; During the same period, one role can only be associated with a unique user, and one user can be associated with one or more roles.

2. The method according to claim 1, characterized in that the method for creating a workflow is as follows:

building a three-level structural model user-role-authority, which includes:

role level, where the subject of the process approval operation in the workflow is the role; each role is an independent individual, not a group or class; one role can only be associated with a unique user during the same period, and one user can be associated with one or more roles;

permission level, which consists of the permissions required to be used to execute the workflow, with permissions granted directly to the role;

user level, where the user defines the approval task in the workflow through his associated role, and also performs the approval operation with the permissions of his associated role;

Using a three-tier structural model to manage workflow, where one approval process includes:

one seed node that initiates the approval process;

at least one approval node granting approval authority to the corresponding approval role;

one end node where the approval process is completed;

Determining the approval task to be processed according to the user's associated role, and performing the approval operation with the permissions of the associated role.

3. The method according to claim 2, characterized in that only a role that has authority to initiate a workflow can initiate/request/submit a workflow as an initiation role.

4. The method according to claim 1, characterized in that the role belongs to a specific department, and the role is authorized in accordance with the work content of the role.

5. The method according to claim 4, characterized in that the role name is unique within the department and the role number is unique in the system.

6. The method according to claim 4, characterized in that during the transfer of the user between departments, the user's association with the role in the original department is canceled and the user becomes associated with the role in the new department.

7. The method according to claim 1, characterized in that the user defines the authority through his association with the role, one employee corresponds to one user account and one user account corresponds to one employee.

8. The method according to claim 1, characterized in that the forms for displaying potential departments include a list, a tree diagram of the organizational structure and an architecture diagram of the organizational structure.

-