Table type piecework data filtering processing method and system with editing authority restriction
Patent Information
- Application Number
- CN202611145046.1
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2026-07-30
- Publication Date
- 2026-08-28
AI Technical Summary
[0004]但是在计件业务数据涉及多岗位层级、多计件类型以及多字段差异化控制的情况下,前一种方式的权限控制层级局限于整表或单一字段级,难以同时限制字段可见、字段可编辑以及字段可作为过滤条件的能力,且难以根据记录金额异常状态动态收回编辑权限;后一种方式则容易出现查询条件越权、敏感字段间接泄露、规则更新滞后以及审计日志易被篡改的问题;因此,相关技术中的计件数据权限控制方案难以兼顾细粒度权限管理、异常数据动态收权以及访问过程可追溯性
1、通过获取企业组织架构和计件业务数据,按照用户角色、数据字段和计件类型建立三维权限矩阵,并将矩阵交点元素定义为包括可见权限、可编辑权限和可作为过滤条件的权限集,能够把原本粗粒度的整表级或单一字段级授权拆解为角色、字段和计件类型交叉维度下的细粒度权限单元,从而同时约束字段查看、字段修改以及字段筛选能力,解决相关技术中权限粒度较粗、难以兼顾多岗位层级和多计件类型差异化控制的问题;通过在角色层级树中引入父子角色继承与覆写的量化计算机制,能够在新增班组、代理岗位或层级调整时保持权限传播清晰且结果唯一确定,从而降低权限维护工作量并减少漏配、冲突和歧义带来的越权风险。
Smart Images

Figure CN122655110A_ABST
Abstract
Description
Technical Field
[0001] This invention relates to the field of data processing and database access control technology, specifically to a method and system for filtering and processing tabular piecework data with editing permission restrictions. Background Technology
[0002] Existing piece-rate pay management systems typically include a front-end spreadsheet, a server-side component, and a database system. Companies can use such systems to input, query, filter, verify, and statistically analyze piece-rate business data generated by different workshops, work groups, and positions.
[0003] In related technologies, in order to control the access scope of piecework data, a static permission configuration method based on user roles at the whole table level or field level is usually adopted to grant different positions the ability to view or edit; or, a combination of fixed query conditions, manual review rules and ordinary log recording mechanisms is used to manage abnormal piecework amount data and data access behavior.
[0004] However, when piecework data involves multiple job levels, multiple piecework types, and multiple fields with differentiated control, the former approach's access control level is limited to the entire table or a single field level, making it difficult to simultaneously restrict field visibility, field editability, and the ability of fields to be used as filtering conditions, and it is also difficult to dynamically revoke editing permissions based on abnormal record amounts. The latter approach is prone to problems such as unauthorized query conditions, indirect leakage of sensitive fields, delayed rule updates, and easy tampering of audit logs. Therefore, the piecework data access control schemes in related technologies cannot simultaneously achieve fine-grained access management, dynamic revoke of permissions for abnormal data, and traceability of the access process. Summary of the Invention
[0005] The purpose of this invention is to provide a tabular piecework data filtering and processing method and system with editing permission restrictions, which solves the following technical problems: realizing fine-grained permission control, automatic retrieval of permissions for abnormal amounts, and traceable logging of access behavior, and enabling permission control to converge in real time with data risks, thereby realizing automatic protection and review of abnormally high piecework records.
[0006] The objective of this invention can be achieved through the following technical solutions: A method for filtering tabular piecework data with edit permission restrictions, applied to a data processing server including a front-end and database system, includes the following steps: Step S1: Obtain the enterprise organizational structure and piecework business data, divide them according to user roles, data fields, and piecework types, and establish a three-dimensional permission matrix containing user roles, data fields, and piecework type dimensions. Define the intersection elements of the matrix as the operation permission set; Step S2: Obtain historical piecework data and perform statistical analysis on piecework types, extract the average piecework amount and standard deviation of each piecework type within a preset historical period, and set a dynamic trigger threshold based on a preset risk tolerance coefficient to establish dynamic permission control conditions based on piecework data attributes. Step S3: Extract the corresponding role based on the current user's identity information, and calculate the effective permission dataset for the current user's current session by combining the piecework type and data field dimension set; Step S4: Intercept the tabular piecework data filtering request initiated by the current user on the front end and parse it into an abstract syntax tree. Based on the effective permission dataset and dynamic trigger threshold, perform condition injection and reconstruction on the abstract syntax tree. After reconstruction, parse it into a standard query statement and hand it over to the database engine for execution to obtain query results with edit permission restrictions; Step S5: Obtain permission rule changes or piecework business data access operations for the three-dimensional permission matrix, record the above operations using hash chain technology, and generate tamper-proof audit logs.
[0007] Further, in step S1, a role hierarchy tree containing parent roles and child roles is defined in the enterprise organizational structure. When a child role does not have explicitly configured operation permissions, it inherits the permissions of the corresponding parent role. The operation permission set corresponds to a permission quantification value. The final effective permission quantification value of the intersection element in the three-dimensional permission matrix is calculated as follows: final effective permission quantification value = permission quantification value configured by the child role itself × overwrite identifier + permission quantification value of the parent role × (1 - overwrite identifier). Wherein, when a targeted overwrite configuration is performed on the child role, the overwrite identifier is 1; otherwise, the overwrite identifier is 0.
[0008] Further, step S2 includes: step S21: calculating the average piece-rate amount and standard deviation of a specific piece-rate type over the past 30 days from historical piece-rate data; step S22: adding the average piece-rate amount to the product of the risk tolerance coefficient and the standard deviation to obtain the dynamic trigger threshold; configured as follows: if the piece-rate amount of a single piece-rate data in historical piece-rate data is greater than the dynamic trigger threshold, the editable permission of that piece-rate data will automatically be invalidated, forcibly downgraded to visible permission, and the preset review and approval status flag will be updated in the database system; otherwise, the current editable permission status of that piece-rate data will be maintained.
[0009] Further, step S3 includes: Step S31: Monitor the change log of the database system, and when a modification of the three-dimensional permission matrix or risk tolerance coefficient is detected, load the updated rules into the memory structure; Step S32: Based on the current user's role, match the corresponding operation permission set in the memory structure to generate an effective permission dataset; wherein, the effective permission dataset includes a list of piecework types that can be queried, a field mask that can be viewed, and a list of fields that can be used as filtering conditions.
[0010] Further, in step S4, the process of injecting and reconstructing the abstract syntax tree based on the effective permission dataset includes: traversing the condition nodes of the abstract syntax tree, and concatenating the list of allowed query piecework types in the effective permission dataset as a mandatory condition into the original query condition; configured as follows: if the current user requests to filter piecework types that they do not have permission to access, then in the abstract syntax tree reconstruction stage, the request is replaced with a constant false condition to block the query; otherwise, the original condition node is retained; traversing the query field nodes of the abstract syntax tree, and comparing the allowed field masks in the effective permission dataset; configured as follows: if the filtering request contains data fields that are not visible, then the query node of that data field is rewritten with a preset character mask replacement function; otherwise, the original query field node is retained.
[0011] Furthermore, in step S4, the process of injecting and reconstructing the abstract syntax tree based on the dynamic trigger threshold includes: converting the judgment logic of the dynamic trigger threshold into a conditional judgment statement and injecting it into the abstract syntax tree, so that the returned query results with editing permission restrictions include a dynamically generated identifier field indicating whether the data is currently editable; wherein, the conditional injection and reconstruction process for the filtering request is completed synchronously when the database engine scans the data.
[0012] Further, step S5 includes: each time the three-dimensional permission matrix is changed or a forced downgrade is triggered, an audit log entry containing the operator, operation time, matrix state before the change, and matrix state after the change is generated; the hash value calculation of the current audit log entry depends on the hash value of the previous audit log entry, and the calculation formula is: current hash value = Hash(current log content + hash value of the previous audit log entry); where + indicates a string concatenation operation.
[0013] Furthermore, in step S1, the set of operation permissions includes one or more of the following: visibility permissions, editable permissions, and permissions that can be used as filtering conditions.
[0014] This is a tabular piecework data filtering and processing system with edit permission restrictions, applied to a data processing server that includes a front-end and a database system. It includes the following modules: a matrix construction module, used to acquire the enterprise's organizational structure and piecework business data, divide the data according to user roles, data fields, and piecework types, and establish a three-dimensional permission matrix containing user role dimension sets, data field dimension sets, and piecework type dimension sets. The intersection elements of the three-dimensional permission matrix are defined as operation permission sets; a threshold setting module, used to acquire historical piecework data, perform statistical analysis on piecework types based on this data, extract the average piecework amount and standard deviation for specific piecework types within a preset historical period, and set dynamic trigger thresholds based on pre-configured risk tolerance coefficients to establish dynamic permission control conditions based on piecework data attributes; and a permission calculation module, used for... The system extracts the corresponding role based on the current user's identity information. Combining the piecework type dimension set and the data field dimension set, it calculates the effective permission dataset for the current user's current session using a permission calculation program. The query reconstruction module receives and intercepts tabular piecework data filtering requests initiated by the current user on the front end. It parses the filtering requests into an abstract syntax tree (AST), injects and reconstructs the AST based on the effective permission dataset and dynamic trigger thresholds, parses the reconstructed AST into a standard query statement, and executes it through the database engine in the database system to obtain piecework data query results with edit permission restrictions. The log auditing module acquires permission rule change operations for the three-dimensional permission matrix or data access operations for piecework business data. It uses hash chain technology to record change operations or access operations, generating tamper-proof audit logs.
[0015] The beneficial effects of this invention are: 1. By acquiring enterprise organizational structure and piecework business data, a three-dimensional permission matrix is established according to user roles, data fields, and piecework types. The intersection elements of the matrix are defined as permission sets including visibility permissions, editable permissions, and filtering conditions. This decomposes the original coarse-grained whole-table or single-field-level authorization into fine-grained permission units under the cross-dimensional framework of roles, fields, and piecework types. This simultaneously constrains field viewing, field modification, and field filtering capabilities, solving the problem of coarse-grained permissions in related technologies and the difficulty in taking into account the differentiated control of multiple job levels and multiple piecework types. By introducing a quantitative calculation mechanism for parent-child role inheritance and overriding in the role hierarchy tree, the propagation of permissions remains clear and the result is uniquely determined when adding new work groups, acting positions, or adjusting levels. This reduces the workload of permission maintenance and reduces the risk of unauthorized access caused by omissions, conflicts, and ambiguities.
[0016] 2. By statistically analyzing the average piece-rate amount and standard deviation of a specific piece-rate type within a preset historical period based on historical piece-rate data, and combining this with a pre-configured risk tolerance coefficient to set a dynamic trigger threshold, access control can be linked to the monetary attributes of the record itself. This allows for the automatic revocation of original editing permissions while retaining visibility and review status when abnormally high piece-rate records appear, solving the problem in related technologies where static permission configurations are difficult to dynamically revoke permissions based on abnormal monetary status. By employing convergence strategies such as conservative thresholds, aggregated statistical values, or direct transfer to a manual review queue when historical samples are insufficient, statistical results are abnormal, or the record monetary format is abnormal, the security and stability of permission determination can be maintained even when statistical conditions are unstable, thereby reducing the risk of misallocation of permissions and misjudgment.
[0017] 3. By extracting the corresponding role based on the current user's identity information and loading the updated permission matrix and risk tolerance coefficient into the memory structure after monitoring the database system change log, an effective permission dataset is generated, including a list of allowed piecework types, a mask of allowed fields, and a list of fields allowed as filtering conditions. This enables session-level permission profiles to reflect the latest system requirements in near real-time, thus solving the problems of lagging rule updates and logged-in users continuing to use old rules in related technologies. By intercepting the tabular piecework data filtering requests initiated by the front end and parsing them into an abstract syntax tree, mandatory conditions are injected into piecework types that are not authorized to be accessed at the syntax tree level, unauthorized type requests are replaced with constant false conditions, and fields without visible permissions are rewritten with preset character mask replacement functions. This can block unauthorized conditions and complete the desensitization of sensitive fields at the query generation stage, thereby avoiding the problems of unauthorized query conditions and indirect leakage of sensitive information through field selection and filtering results.
[0018] 4. By converting the dynamic trigger threshold judgment logic into conditional judgment statements and injecting them into an abstract syntax tree, the database engine can synchronously generate an identifier field indicating whether the data is currently editable when scanning data. This allows permission verification, data filtering, and editing status determination to be pushed down to the database execution chain, thereby reducing the performance overhead and state asynchrony issues caused by repeated traversal of result sets at the application layer and secondary judgments between the front-end and back-end. By using hash chain technology to record events such as permission rule change operations, sensitive data access operations, and triggering of edit permission downgrades, the hash value of the current audit log entry depends on the hash value of the previous log entry. This allows the chain-based verification of mismatches to expose tampering behavior when someone attempts to modify, delete, or forge earlier logs, thereby improving the traceability, tamper resistance, and audit compliance capabilities of permission adjustment and access processes. Attached Figure Description
[0019] Other features, objects, and advantages of the invention will become more apparent from the following detailed description of non-limiting embodiments with reference to the accompanying drawings: Figure 1 This is a flowchart illustrating a tabular piecework data filtering method with editing permission restrictions in an embodiment of this application.
[0020] Figure 2 This is a schematic diagram of a tabular piecework data filtering and processing system with editing permission restrictions provided in an embodiment of this application. Detailed Implementation
[0021] The technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.
[0022] Please see Figure 1 A method for filtering tabular piecework data with edit permission restrictions, applied to a data processing server including a front-end and database system, includes the following steps: Step S1: Obtain the enterprise organizational structure and piecework business data, divide them according to user roles, data fields, and piecework types, and establish a three-dimensional permission matrix containing user roles, data fields, and piecework type dimensions. Define the intersection elements of the matrix as the operation permission set; Step S2: Obtain historical piecework data and perform statistical analysis on piecework types, extract the average piecework amount and standard deviation of each piecework type within a preset historical period, and set a dynamic trigger threshold based on a preset risk tolerance coefficient to establish dynamic permission control conditions based on piecework data attributes. Step S3: Extract the corresponding role based on the current user's identity information, and calculate the effective permission dataset for the current user's current session by combining the piecework type and data field dimension set; Step S4: Intercept the tabular piecework data filtering request initiated by the current user on the front end and parse it into an abstract syntax tree. Based on the effective permission dataset and dynamic trigger threshold, perform condition injection and reconstruction on the abstract syntax tree. After reconstruction, parse it into a standard query statement and hand it over to the database engine for execution to obtain query results with edit permission restrictions; Step S5: Obtain permission rule changes or piecework business data access operations for the three-dimensional permission matrix, record the above operations using hash chain technology, and generate tamper-proof audit logs.
[0023] This embodiment provides a tabular piece-rate data filtering mechanism with edit permission restrictions. Specifically, the mechanism is deployed in the piece-rate pay management server of an electronic assembly factory. The factory has a surface mount workshop, a welding workshop, an assembly workshop and a quality inspection department. The front end is a pay management table page, and the database system stores daily piece-rate details, personnel organizational relationships, permission configurations and historical access records.
[0024] This mechanism revolves around the complete business chain of team entry, supervisor review, financial accounting, and audit traceability, so that the same piecework record can be displayed in different visible, editable, and filterable states under different positions, different fields, and different piecework types.
[0025] Specifically, the matrix is constructed first; the server reads the set of roles from the organizational structure table, which can be set as payroll specialist R0, workshop supervisor R1, team leader R2, and operator R3.
[0026] Extract a set of fields from the piecework business table, such as piecework quantity F1, piecework unit price F2, pass rate F3, piecework amount F4, and review status F5; extract a set of piecework types from the business rules table, such as welding piecework T1, assembly piecework T2, and packaging piecework T3.
[0027] Generate a three-dimensional permission matrix to represent the set of operation permissions for any role on any field in any piecework type.
[0028] For ease of explanation, a simplified example is used: when element M(R2,F1,T1) corresponds to the team leader's authority over the number of pieces in the welding piecework system, this element can be stored as {visible=1, editable=1, filterable=1}.
[0029] When element M(R2,F2,T1) corresponds to the team leader's permission for the piece rate price in welding piecework, it can be stored as {visible=1, editable=0, filterable=0}; through the above configuration, the single-level whole table data access permission is converted into a structured permission unit under cross-dimensional.
[0030] Furthermore, dynamic threshold settings are implemented; the server grouped and statistically analyzed the data within the preset historical period from the historical piecework details table by piecework type.
[0031] Taking welding piece rate T1 as an example, read the piece rate amount of the past 30 days to obtain the mean and standard deviation; if the data sample is [92,95,100,96,117], the mean can be approximated as 100, and the standard deviation is calculated to be about 8.87 according to the data statistics rules; if the risk tolerance coefficient is 2, the dynamic trigger threshold is set to 117.74.
[0032] At this point, if the piece-rate amount of a subsequent welding piece-rate record is greater than 120, the original editable permission of the record will be forcibly downgraded at runtime, retaining only the visible state, and a pending review mark will be added simultaneously; thus, the permission is no longer a completely static configuration result, but is linked to the record's own monetary attribute.
[0033] Based on this, the current session's permission resolution is performed; after the user logs in to the front end, the server extracts the user's job role based on the identity authentication result, and then calculates the effective permission dataset for the current session by combining the piece-rate type dimension and field dimension in the matrix.
[0034] The dataset is preferably stored in an in-memory structure and contains at least three parts: a set of piecework types that are allowed to be accessed, a mask of fields that are allowed to be viewed, and a set of fields that are allowed to be used as filtering conditions.
[0035] To illustrate with a simplified example: If the current user is a welding workshop team leader, the piece rate type they can access may be T1, and the visible field mask may be {F1=1,F2=1,F3=1,F4=1,F5=1}, but the editable field mask is only {F1=1,F3=1,F5=0}, and the set of filterable fields can be {date, team, employee number, piece rate type}.
[0036] In this way, within the same session period, the server can quickly determine whether any query or edit action falls within the permitted scope.
[0037] The server intercepts and reconstructs front-end filtering requests. When the front-end table page initiates a request such as querying the piecework welding fee for this week and the piecework fee is greater than 110, the server does not directly concatenate the original query statement, but first parses the request into an abstract syntax tree. This abstract syntax tree includes at least query field nodes, condition nodes, sorting nodes, and pagination nodes.
[0038] The server injects mandatory piecework type constraints into the condition nodes, such as writing the requirement that the piecework type must belong to the set accessible to the current user into the syntax tree.
[0039] Simultaneously, the field mask is checked in the query field node, and fields without viewing permissions are de-identified and rewritten; then the aforementioned dynamic threshold logic is injected as a judgment expression to generate the return field indicating whether the field is currently editable.
[0040] The reconstructed abstract syntax tree is then restored to a standard query statement and executed by the database engine, so that permission verification and data filtering are completed synchronously when the database scans data, instead of repeatedly traversing the result set at the application layer.
[0041] The server generates audit logs. Whenever there are operations such as changes to the permission matrix, adjustments to the risk coefficient, access to sensitive piecework data, or triggering a downgrade of editing permissions, the server immediately generates an audit log, writes it to the log storage area, and concatenates the current log content with the hash value of the previous log to recalculate the hash, forming a chain structure. In this way, even if someone tries to modify an earlier log later, the chain check value of all entries will mismatch, thus exposing the tampering behavior.
[0042] If the organization structure table has missing roles, business fields are newly added but permissions are not yet configured, or the historical data sample size is insufficient to support stable statistics, the server adopts a default convergence strategy. Specifically, it can be set as follows: new fields are not editable by default and cannot be used as filtering conditions, and are only visible to administrators; when the number of historical samples is lower than the minimum threshold, the statistical threshold is not used, and a preset conservative threshold is used instead; if the abstract syntax tree parsing fails, the query is directly rejected and an abnormal audit entry is recorded.
[0043] If the version of the permission rules in memory is outdated compared to the database configuration version, the execution of the current request is paused, and the rules are refreshed first to prevent the old permissions from taking effect.
[0044] In the end-of-month payroll calculation scenario of this electronic assembly factory, the welding workshop team leader needs to check the welding piecework records of his team for the most recent 7 days; he filters the welding piecework, employee number A012, and date as this week on the front end; the server generates the effective permission dataset for the current session based on the user role, allowing access only to welding type data, and restricting the filterable fields to employee number, team, date, and piecework type.
[0045] There is a record in the database with a piece-rate amount of 128, while the dynamic threshold for welding piece-rate in this workshop is 120. Therefore, the record can still display fields such as quantity, amount, and pass rate in the query results, but the editability flag is set to no, and the review status is updated to pending supervisor approval. If the team leader further attempts to filter the assembly piece-rate type, the server will replace the corresponding condition with a constant false condition during the abstract syntax tree reconstruction stage, thus returning an empty result instead of out-of-authority data.
[0046] The purpose of this step is to unify the dynamic risk status of role dimension, field dimension, piecework type dimension, and piecework amount into a single query processing chain, thereby achieving fine-grained access control, automatic retrieval of permissions for abnormal amounts, and traceable record of access behavior.
[0047] In a preferred embodiment of the present invention, in step S1, a role hierarchy tree containing parent roles and child roles is defined in the enterprise organizational structure. When a child role does not have explicitly configured operation permissions, it inherits the permissions of the corresponding parent role. The operation permission set corresponds to a permission quantification value. The final effective permission quantification value of the intersection element in the three-dimensional permission matrix is calculated as follows: final effective permission quantification value = permission quantification value configured by the child role × overwrite identifier + permission quantification value of the parent role × (1 - overwrite identifier). Wherein, when a targeted overwrite configuration is performed on the child role, the overwrite identifier is 1; otherwise, the overwrite identifier is 0.
[0048] This embodiment provides a permission inheritance and overriding mechanism suitable for hierarchical manufacturing organizations. Specifically, in the aforementioned electronic assembly plant, the organizational hierarchy is not a flat structure, but a tree-shaped job system of payroll supervisor, workshop supervisor, team leader, and operator. If the matrix is manually configured one by one for each role, field, and piece rate type, the workload of permission maintenance will increase when the workshop is temporarily expanded, rotated, or new teams are added, and omissions and conflicts are likely to occur. Therefore, this embodiment introduces a role hierarchy tree and quantitative overriding rules in the matrix construction stage.
[0049] Specifically, the server constructs a role hierarchy table. Taking the factory mentioned above as an example, the root node can be set as the payroll supervisor R0, under which is the welding workshop supervisor R1, under which is the welding team leader R2, and under which is the welding operator R3. Each matrix intersection element no longer stores only simple yes or no, but stores a set of quantifiable permission values. These permission values can be expressed in binary or multi-valued form, as long as they can distinguish between visible, editable, and filterable.
[0050] In a simplified example, for the piecework quantity field F1 and the welding piecework price T1, if the parent role R1 sets the permission value of its corresponding element M(R1,F1,T1) to 1, it means that it can be edited; if the child role R2 does not have its element M(R2,F1,T1) configured separately, the overwrite identifier is set to 0, and the final effective value is calculated as child role's own configuration value × 0 + parent permission value × 1, which means that R2 automatically inherits R1's editing ability; if it is later found that the team leader should not modify the welding piecework price F2, the administrator will give R2 a targeted configuration of its own permission value of element M(R2,F2,T1) to 0 and set the overwrite identifier to 1. At this time, the final effective value becomes 0 × 1 + parent permission value × 0, which is 0, thus blocking the inheritance.
[0051] Furthermore, to prevent ambiguity in multi-level inheritance, the server preferably adopts a top-down recursive calculation; that is, the basic permissions of the root role are determined first, and then propagated down layer by layer; once a certain layer has an overwrite flag of 1, that layer directly cuts off the continued influence of the upper layer on the element at the same intersection.
[0052] Taking a specific set of data as an example: For the permission intersection formed by the piece-rate amount field F4 and the welding piece-rate type T1, if the root role R0 has a visible value of 1 for the intersection element M(R0,F4,T1), the child role R1 does not override its own corresponding intersection element M(R1,F4,T1), and the grandchild role R2 does not override its own corresponding intersection element M(R2,F4,T1), then the visible value ultimately inherited by R2 is still 1; if R1 changes its visible value to 0 and overrides it, then R2 inherits R1's 0 when not configured separately, and no longer traces back to R0's 1.
[0053] This ensures that the permission calculation result is uniquely determined. In the exception handling mechanism, when there is a broken chain in the hierarchy tree, a role is incorrectly attached to multiple parent nodes, or a role inherits the permissions of two parallel positions at the same time, the server adopts a pre-set conflict resolution rule.
[0054] Preferably, the principle of least privilege priority or explicit overwrite priority can be adopted; if the system detects that a certain sub-role has multiple parent nodes and no conflict resolution strategy is configured, the data editing request of the role will not be allowed for the time being, only the read-only state will be retained and a configuration exception log will be generated.
[0055] For newly created roles that have not yet been assigned to a hierarchy tree, the default minimum permission template can be temporarily inherited to avoid exceeding permissions; when expanding the night shift in the factory, a new acting team leader position for Welding Group 2 was created; the administrator did not configure all fields for it item by item, but only explicitly stipulated that it can view the piecework amount for welding, but cannot edit the piecework unit price.
[0056] Based on this, the system allows the welder to inherit the welding workshop supervisor's permissions for fields such as piecework quantity pass rate, which are not configured separately, while overwriting the piecework price field with a value of 0.
[0057] The next day, after the acting team leader logged into the system, he could filter and view the welding piecework data normally, but the editing entry for the unit price column was closed, and the unit price was not allowed as a filter field in the relevant query conditions.
[0058] The purpose of this mechanism is to simplify the permission node configuration logic of large-scale hierarchical organizations and to ensure that permission propagation in hierarchical organizations is clear, stable and unambiguous through computable inheritance and overriding logic.
[0059] In a preferred embodiment of the present invention, step S2 includes: step S21: calculating the average piece-rate amount and standard deviation of a specific piece-rate type over the past 30 days from historical piece-rate data.
[0060] Step S22: Add the product of the average piece-rate amount, the risk tolerance coefficient, and the standard deviation to obtain the dynamic trigger threshold; the configuration is as follows: if the piece-rate amount of a single piece-rate data in the historical piece-rate data is greater than the dynamic trigger threshold, the editable permission of that piece-rate data will be automatically invalidated, forcibly downgraded to visible permission, and the preset review and approval status flag will be updated in the database system; otherwise, the current editable permission status of that piece-rate data will be maintained.
[0061] This embodiment provides a dynamic threshold triggering mechanism for abnormal piecework amounts. Specifically, in the actual operation of the aforementioned factory, relying solely on a static permission matrix can only determine who can usually edit what, but it is difficult to handle situations where a record, although belonging to their daily responsibilities, has an abnormally high amount, and the editing right should be temporarily revoked. Therefore, this embodiment introduces a dynamic threshold that changes with the piecework type based on historical statistics.
[0062] Specifically, the server extracts records of the same type from the historical piecework details table at a fixed time every day, and calculates the average piecework amount and standard deviation according to the piecework type.
[0063] To facilitate understanding, a specific sample can be constructed: In the past 30 days, the average amount per piece of welding work is 100 CNY, the standard deviation is 8 CNY, and the risk tolerance coefficient is 2.5. Then the dynamic trigger threshold is 100 + 2.5 × 8 = 120 CNY.
[0064] When a newly submitted welding piecework record has an amount of 118 CNY, the system maintains the original editable permissions because it does not exceed 120 CNY; when the amount is 126 CNY, the system determines that it falls into the abnormal range, directly downgrades the editability of the record to read-only, and changes the review and approval status from never triggered to pending supervisor review.
[0065] Furthermore, this dynamic judgment is not only executed once during data entry, but can be triggered multiple times during querying, editing and submission, batch importing, and nighttime inspection tasks. In this way, even if a record has a normal amount when it is initially entered, but the amount increases due to subsequent price supplementation, quantity correction, or process coefficient adjustment, it can be re-judged and dynamically reclaimed upon re-access. The server can add a threshold snapshot version number or the most recent judgment time field for each record to record which round of statistical results the record was judged based on, so as to facilitate subsequent auditing and traceability.
[0066] Compared to the previous solution, without this dynamic judgment mechanism, if a role in the matrix has editing permissions for a certain type of field, the system will still allow the editing action even if the amount suddenly increases abnormally, which poses a risk that salary data may be mistakenly modified or unexpectedly amplified. Because static matrices cannot express record-level risks, this embodiment introduces a trigger condition of mean + risk tolerance coefficient × standard deviation to incorporate statistical fluctuations into permission control. In the anomaly handling mechanism, when the sample size of the past 30 days is too small, for example, when there are only 2 historical records of a certain type of newly established process, the standard deviation calculation may lose stability.
[0067] To address this, the server can set a minimum sample threshold, such as no less than 10 records. If this is insufficient, the aggregated statistical value of the relevant process category will be used, or a manually set conservative threshold will be adopted. If the statistical results are abnormal, such as a standard deviation of zero but the actual business amount is not constant, it indicates that there may be a cleaning error in the data source. In this case, the system can pause automatic degradation, mark the type as pending statistical verification, and notify the administrator for processing. If the amount field of a record is empty, negative, or contains an unparseable format, the record will be directly entered into the manual review queue without being granted editing permissions.
[0068] During a certain data entry period, the welding workshop submitted a batch of high-value piece-rate records. The system statistics showed that the threshold for this type of process over the past 30 days was 120 CNY. When the team leader viewed an employee's record at the front end, he found that one of the records was for 135 CNY, and the editing function in the table was automatically set to unavailable, with the review mark indicating that it was pending confirmation from the workshop supervisor. Another record was for 112 CNY, and the quantity and remarks could still be corrected within the specified field range. In this way, the same user could perceive the differentiated permission status triggered by abnormal amounts when facing different records.
[0069] The purpose of this step is to enable access control to converge in real time as data risks arise, thereby achieving automatic protection and review of abnormally high piecework records.
[0070] In a preferred embodiment of the present invention, step S3 includes: step S31: monitoring the change log of the database system, and when a modification of the three-dimensional permission matrix or risk tolerance coefficient is detected, loading the updated rules into the memory structure; step S32: matching the corresponding operation permission set in the memory structure based on the current user's role, and generating an effective permission dataset; wherein, the effective permission dataset includes a list of piecework types that can be queried, a field mask that can be viewed, and a list of fields that can be used as filtering conditions.
[0071] This embodiment provides a rule hot-loading and session-level effective permission dataset generation mechanism for real-time business adjustments. Specifically, in the aforementioned factory, permission configuration and risk tolerance coefficient will change with salary, process adjustments, and temporary audit requirements. If the rules are reloaded by restarting the server after each modification, it will not only interrupt the team's data entry and review process, but also cause logged-in users to continue using the old rules for a period of time. Therefore, this embodiment monitors the database change log and loads the update results into the memory structure to keep permission calculation and business changes synchronized with low latency.
[0072] Specifically, a rule-listening process is set up on the server side to continuously subscribe to change logs in the database system. The monitored data includes at least the permission matrix configuration table, role hierarchy table, risk tolerance coefficient table, and field filterable configuration table. When any addition, modification, or deletion is detected in any of these tables, the listening process extracts the primary key range and version number corresponding to the change record and reconstructs the updated rules into an in-memory structure suitable for fast querying. This in-memory structure is preferably a concurrent mapping table that is indexed by role, then indexed by piecework type, and finally mapped to the corresponding permission status.
[0073] To illustrate in detail, the specific configuration of role R1 under type T1 is as follows: the field mask that can be viewed is represented in memory as viewing bitmap 10111, and the list of fields that can be used as filtering conditions is represented in memory as filtering bitmap 10010; each bit in the bitmap is mapped to F1 to F5 respectively, with 1 representing allowed and 0 representing prohibited; in this way, it is not necessary to access the database configuration table one by one during the query, but only to complete the mapping and matching of the corresponding mask once in memory, which strictly corresponds to the field mask and field list required by the effective permission dataset.
[0074] Furthermore, when a user logs in or refreshes a session, the server reads their identity information to obtain context such as role code, workshop, and temporary agent position. Then, it extracts the complete set of operation permissions corresponding to the role from the memory structure and combines them to form the effective permission dataset for the current session. If a user holds two positions simultaneously, such as a welding team leader during the day and a substitute quality inspector at night, the server can use a union or intersection strategy to generate the effective permission dataset for the session.
[0075] Preferably, the union of visibility permissions can be used to avoid missing necessary information; the union of editable and filterable permissions can be used, that is, only when both positions allow it or there is explicit authorization, to reduce the risk of unauthorized access; the final dataset should include at least a list of piecework types that can be queried, a mask of fields that can be viewed, and a list of fields that can be used as filtering conditions.
[0076] Compared to a solution that loads rules only once at system startup, if the workshop supervisor temporarily tightens the viewing permissions for the welding amount field at 10:00 AM, and the server only takes effect after restarting in the evening, then all queries generated between 10:00 AM and the restart may be executed based on expired rules. Because static loading causes rule lag, this embodiment introduces log monitoring and memory hot updates to enable the session's effective permission dataset to reflect the latest system requirements in near real-time.
[0077] In the exception handling mechanism, if the change log subscription is interrupted, the memory update fails, or the rule version is not continuous, the server can switch to the security protection mode. Specifically, it can be set to: suspend the opening of new editing sessions and retain only the verified read-only queries; at the same time, trigger a full configuration reconstruction task to pull the permission matrix and risk parameters from the database master table again; if the reconstruction still fails, use the most recently verified rule snapshot, but attach a rule version confirmation flag to the query results and write it to the audit log.
[0078] If a character's configuration cannot be found in memory, the system will by default only return the basic record of the user's own employee ID after de-identification, to avoid directly reporting an error or granting unlimited privileges.
[0079] Before the afternoon shift started, the factory payroll administrator lowered the risk tolerance coefficient for welding piecework from 2.5 to 2.0 and added a new rule that team leaders could no longer use piecework amount as a filtering condition. After the configuration was written to the database, the rule monitoring process immediately captured the change and refreshed the welding-related memory entries. A few minutes later, when the same team leader opened the table page again, the list of fields allowed as filtering conditions in the new effective permission dataset no longer included the amount field, and the dynamic threshold was also more stringent due to the lowered coefficient. When the user tried to filter records by amount range, the front-end request was identified as not being in the filterable list.
[0080] The purpose of this mechanism is to keep permission rules and business system changes in sync quickly, thereby enabling real-time generation of session-level permissions and low-latency, high-frequency access.
[0081] In a preferred embodiment of the present invention, step S4, the process of injecting and reconstructing the abstract syntax tree based on the effective permission dataset, includes: traversing the condition nodes of the abstract syntax tree, and concatenating the list of allowed query piecework types in the effective permission dataset as a mandatory condition into the original query condition; configured as follows: if the current user requests to filter piecework types that they do not have permission to access, then in the abstract syntax tree reconstruction stage, the request is replaced with a constant false condition to block the query; otherwise, the original condition node is retained; traversing the query field nodes of the abstract syntax tree, and comparing the allowed field masks in the effective permission dataset; configured as follows: if the filtering request contains a data field that is not visible, then the query node of that data field is rewritten with a preset character mask replacement function; otherwise, the original query field node is retained.
[0082] This embodiment provides an abstract syntax tree condition injection and field reconstruction mechanism for query requests. Specifically, in the aforementioned factory scenario, users often customize filter conditions, select display columns, and export results through a table page. If the database is only checked after returning the results to see if it contains unauthorized piecework types or sensitive fields, there will be unnecessary data transmission and caching risks. Therefore, this embodiment injects the effective permission dataset into the syntax tree level in advance to reduce the generation of unauthorized data from the source.
[0083] Specifically, after receiving a request from the frontend, the server first parses it into an abstract syntax tree; this can be simplified into two parts: a condition node tree and a list of query field nodes.
[0084] To illustrate with a specific example, a team leader initiates a request to select the fields {employee ID, piecework quantity, piecework unit price, piecework amount}, with the filter conditions {piecework type = assembly piecework, date = this week}. After parsing, the condition nodes contain piecework type = assembly piecework and date = this week, and the field nodes contain F0 employee ID, F1 quantity, F2 unit price, and F4 amount. If the user's effective permission dataset only allows querying welding piecework T1, the system finds that the piecework type requested by the user is not in the allowed list when iterating through the condition nodes. Therefore, it forcibly changes the condition node to a constant false condition, such as 1 = 0. In this way, even if the original request syntax is valid, no assembly data will be returned.
[0085] Furthermore, if the piecework type requested by the user is within the permitted range, but the selected fields contain columns that the user does not have permission to view, the server will rewrite the field node instead of simply reporting an error and interrupting the process. For example, a welding team leader can view the quantity and amount, but not the unit price. When the unit price F2 appears in the field node, the system reconstructs the node into a character mask replacement function. This function can output a fixed mask, null values, or partially desensitized values. Thus, the final query result can still return the user's authorized fields as expected, while maintaining structural compatibility with unauthorized fields, facilitating normal rendering of the front-end table and preventing overall failure due to restrictions on individual fields.
[0086] Compared to the basic solution, if only the ability to execute queries is controlled without controlling how fields are returned, the front-end interface will experience a technical problem of overall rendering failure when requesting unauthorized data fields. However, if the fields are completely allowed and then covered up on the front end, plaintext data may be exposed at the interface layer. To solve the technical defects of data access being fully intercepted or transmitted in plaintext, this embodiment introduces syntax tree node-level reconstruction to eliminate the leakage of sensitive fields without interrupting the page structure.
[0087] If complex nested conditions appear in the abstract syntax tree, such as multiple OR combinations, subqueries, or function expressions, the server should first perform normalized expansion of the syntax tree before performing permission node injection to avoid bypass construction.
[0088] If the user does not specify a piece-rate type filter, the system will automatically add the piece-rate type belonging to the allowed list as a mandatory condition.
[0089] If a field node references an alias, computed column, or aggregate expression, the server will trace its underlying field source. If it contains a base field that the user does not have permission to view, the entire computed column can be rewritten as a masked result or removed directly from the returned structure. If a certain type of custom expression cannot be safely parsed, the expression will not be executed, and an exception audit record will be generated.
[0090] Before the monthly reconciliation, the welding team leader attempted to export the assembly piecework records for the week, along with a piecework price column, hoping to compare wage differences across workshops. After parsing the request, the system first detected that the piecework type was out of bounds, so the condition node was rewritten as a constant false condition, returning an empty result. The user then changed the query to this week's welding piecework. This time, the type condition was valid, but because the user did not have permission to view the unit price column, the piecework price column in the exported result was displayed as a preset mask, while the employee number, quantity, and amount columns were returned normally. The purpose of this mechanism is to simultaneously implement type-level and field-level permission convergence during the query generation stage, thereby achieving the interception of out-of-bounds conditions and seamless desensitization of sensitive fields.
[0091] In a preferred embodiment of the present invention, step S4, the process of injecting and reconstructing the abstract syntax tree based on the dynamic trigger threshold, includes: converting the judgment logic of the dynamic trigger threshold into a conditional judgment statement and injecting it into the abstract syntax tree, so that the returned query result with editing permission restrictions includes a dynamically generated identifier field indicating whether it is currently editable; wherein, the conditional injection and reconstruction process for the filtering request is completed synchronously when the database engine scans the data.
[0092] This embodiment provides a mechanism for directly writing dynamic threshold determination into the edit status generation of the query execution chain. Specifically, in the aforementioned factory, if all records are retrieved first, and then the application layer determines whether each record is editable based on its amount, additional memory usage and data traversal overhead will occur when the number of records exceeds the preset threshold. Furthermore, after the front-end page obtains the results, it needs to call an additional determination interface, which may cause the display and edit status of the same batch of data to be out of sync. Therefore, this embodiment rewrites the threshold determination logic into a conditional judgment statement during the abstract syntax tree reconstruction stage, so that the database generates a dynamic identifier field indicating whether the record is currently editable when scanning records.
[0093] Specifically, during syntax tree reconstruction, the server generates a conditional expression based on the dynamic threshold corresponding to the piecework type to which the record belongs, and inserts the expression into the query field node.
[0094] Here's a specific example: Assuming the welding piecework amount T1 corresponds to a threshold of 120 CNY, the system appends an identifier field E1 to the query results indicating whether the work is currently editable. The logic is that when the piecework amount is ≤120, output 1 to indicate editability; otherwise, output 0 to indicate visibility only. If the user's original request only queries the employee number, quantity, and amount, the system will automatically add the identifier field E1 after reconstruction. When the database engine scans each record, if it reads a record with an amount of 112, E1=1; if it reads a record with an amount of 128, E1=0. The front-end table can then directly display the editable or viewable status without needing a secondary determination.
[0095] Furthermore, the dynamically generated identifier field can be output in conjunction with the aforementioned field mask, type conditions, and review flags. For example, for records exceeding the threshold, in addition to E1=0, a pending approval status code can also be returned synchronously, allowing the front end to display a yellow warning message on the same line. Since these logics are all completed during database scanning, the query results are naturally consistent with the current rule version, avoiding the timing deviation of returning old data first and then recalculating the new status.
[0096] Compared to the approach of determining whether a record exceeds a threshold only in the backend business code, this approach directly writes the determination into the syntax tree and pushes it down to the database for execution. This has two improvements: First, the database only needs to perform in-situ calculations when scanning rows, without having to transmit all the results to the application layer before traversing them; Second, each record received by the frontend already has an editable state, reducing cross-interface synchronization issues. Because traditional application-layer determinations are prone to performance degradation and state inconsistencies, this embodiment pushes the generation of editable states down to the query execution channel.
[0097] If a certain record belongs to a piece-rate type that has not yet generated a threshold in the current statistical period, the system can inject a default read-only flag for that type, or perform a judgment according to a preset security threshold.
[0098] If the user requests an aggregate query, such as summarizing the amount by work group, rather than a list of individual records, the system can decide whether to output an editable identifier at the aggregation level based on the business configuration.
[0099] Preferably, the aggregation results are not allowed to be directly edited; they are simply marked as uneditable. If the database engine does not support a certain complex conditional expression, the server can degenerate into generating a database-compatible basic judgment statement after reconstruction, ensuring that the logic is still completed on the database side.
[0100] When the workshop supervisor reviews the weekly welding piecework details, a new column is added to the front-end list indicating whether the work is currently editable. This column is not from the original business table but is a dynamically generated identifier field during the query process. The system injects a judgment statement with a threshold of 120 CNY for the welding type. In the result, one record with an amount of 118 CNY is displayed as "yes," while another record with an amount of 132 CNY is displayed as "no." At the same time, the latter's review status is "pending supervisor approval." The supervisor can distinguish which records can still be modified and which can only be reviewed within the same table without switching pages or triggering additional validations.
[0101] The purpose of this mechanism is to generate dynamic permission status and data query results synchronously, thereby enabling real-time identification of editing capabilities and low-overhead push-down execution.
[0102] In a preferred embodiment of the present invention, step S5 includes: each time the three-dimensional permission matrix is changed or a forced downgrade is triggered, an audit log entry containing the operator, operation time, matrix state before the change, and matrix state after the change is generated; the hash value of the current audit log entry depends on the hash value of the previous audit log entry, and the calculation formula is: current hash value = Hash(current log content + hash value of the previous audit log entry); where + represents a string concatenation operation.
[0103] This embodiment provides a chain-based auditing mechanism for permission changes and dynamic downgrade events. Specifically, the piece-rate pay data in the aforementioned factory is directly related to the basic pay calculation data. Once the permission is adjusted or an abnormal amount causes the editing right to be revoked, it often needs to be reviewed and audited by the workshop, human resources, and internal audit departments. If the log is stored separately in the form of a regular table, there is a technical risk that the audit log may be tampered with without authorization. Therefore, this embodiment writes matrix changes and forced downgrade events into a unified hash chain-based audit log. Specifically, whenever two types of key events occur, the system will generate an audit entry: one is when the administrator modifies the permission configuration corresponding to the role, field, or piece-rate type.
[0104] Another type is when a record triggers a downgrade in editing permissions due to exceeding a dynamic threshold; each log entry must contain at least the operator, operation time, operation object, state before change, state after change, and event source; let's illustrate with a specific example: the first log entry records that the payroll administrator changed the team leader's viewing permission for the welding unit price field from 1 to 0 at 08:30. Let the content of the first log entry be Data1, and calculate the first hash H1.
[0105] The second log entry records that at 09:12, the system changed the edit status of the record unique identifier = 8754 from 1 to 0. The content of this second log entry is denoted as Data2. At this time, the hash value of this second audit log entry is not calculated on Data2 alone, but on the result of concatenating Data2 with the hash H1 of the previous audit log entry to obtain the current hash H2. This process continues, forming a chain structure that is sequentially linked in time.
[0106] Furthermore, to ensure that logs can support accountability and review, the state before and after a change should preferably be preserved as a structured snapshot, rather than simply recording the modification of a certain permission. For example, for matrix changes, the permission bitmap of the relevant intersection elements before and after the change can be saved; for forced downgrade events, the piecework type, the effective threshold at the time, the trigger amount, and the edit flags before and after the downgrade can be saved. In this way, during subsequent audits, it is possible not only to know who changed what, but also to know why the system automatically revoked the editing rights.
[0107] Compared with ordinary logs that only record the final result, this chain auditing method overcomes the following two defects: First, if ordinary logs are deleted or forged records are inserted, it is difficult to directly detect the break in the time chain; Second, if the state before the change is not saved, but only the state after the change is saved, it is impossible to restore the specific process of permission adjustment. Because traditional logs lack traceability and tamper resistance, this embodiment enhances traceability by using content snapshots + pre-order hash dependency.
[0108] If the hash of the previous log entry is missing, the log write transaction fails, or the chain check fails, the system can immediately freeze new permission modification operations and switch the current system to read-only audit protection mode, waiting for the administrator to fix it. For batch permission changes, two strategies can be implemented: changing one log entry at a time or changing one summary log entry per transaction.
[0109] Preferably, during batch operations, a detailed snapshot of each sub-change is retained to avoid overly coarse audit granularity. If the log storage space is insufficient, the system can perform partitioned archiving, but the checksums of the beginning and end of the chain are still retained before and after archiving to maintain continuity. In a quarterly audit of the factory, the auditor randomly checked a welding piecework record with an abnormal amount and found that it had been automatically downgraded to read-only by the system at 09:12. After the audit platform retrieved the corresponding log, it could be seen that the log before this event was a permission configuration adjustment record at 08:30, and many subsequent logs depended on the hash value of the 09:12 event. If someone attempts to delete or modify the content of the 09:12 event afterward, all subsequent hash checks will mismatch, and the auditor can immediately detect that the chain has been broken.
[0110] The purpose of this mechanism is to ensure that the process of adjusting and dynamically reclaiming permissions has a non-repudiable, replayable, and verifiable record, thereby achieving audit compliance in payroll data governance.
[0111] In a preferred embodiment of the present invention, in step S1, the set of operation permissions includes one or more of the following: visibility permission, editability permission, and permissions that can be used as filtering conditions.
[0112] This embodiment provides a mechanism for structurally splitting the set of operation permissions. Specifically, in the aforementioned factory scenario, if access to a certain field is simply understood as a single permission, a common drawback will occur: some positions should be able to see a certain field, but should not be able to modify it; other positions can view a certain field, but should not use it for filtering and retrieval, otherwise sensitive information may be indirectly inferred through the filtering results; therefore, this embodiment splits the set of operation permissions in each matrix intersection element into at least one or more of the following: visible, editable, and usable as filtering conditions.
[0113] Specifically, when defining matrix elements, the server establishes at least three independent flag bits for each intersection of role, field, and piecework type.
[0114] To illustrate in detail, for the piece-rate price field in welding piecework, the team leader can be configured with {visible=1, editable=0, filterable=0}; for the piece-rate quantity field, it can be configured with {visible=1, editable=1, filterable=1}; and for the review status field, it can be configured with {visible=1, editable=0, filterable=1}. In this way, the system can clearly distinguish three actions: seeing the field, modifying the field, and using the field to construct filtering conditions. After separating the three, different positions can obtain more granular capabilities that are more in line with their business responsibilities.
[0115] Furthermore, this splitting is not limited to a three-digit binary representation, but can also be extended to a combined permission structure; for example, editability can be further subdivided into allowing direct modification and allowing submission of modification requests; however, in this embodiment, as long as at least the aforementioned three basic permissions can be expressed, it can support the linked control of querying, filtering and editing of tabular piecework data.
[0116] With this structured definition, the aforementioned query reconstruction mechanism knows whether to return, de-identify, or reject a field node as a filtering condition when it encounters it. The aforementioned dynamic degradation mechanism also knows whether to only revoke editing rights or control viewing rights as well.
[0117] Compared to coarse-grained authorization without splitting, this additional dimension can be used as a filtering condition, which can prevent a hidden risk: that is, although users cannot see the amount field, if filtering by amount range is still allowed, the distribution of high-amount records may be deduced from the changes in the number of results; because of this indirect information leakage, this embodiment separates the filtering capability from the viewing capability.
[0118] If a field is only declared as visible in the configuration but the other two fields are not declared, the system defaults to it being uneditable and unfilterable. If a job position is configured as editable but not visible, the system will determine it as an illegal configuration and automatically correct it to be at least visible before it can be edited, or directly revert it to read-only status.
[0119] For newly added fields in the system, the initial template should preferably be set to be visible only to administrators, with all other roles having 0 permissions for all three categories. These permissions will be gradually released after business confirmation.
[0120] In the welding workshop of this factory, the team leader needs to quickly filter records by employee number and date, so the employee number and date fields are given filtering permissions; the team leader also needs to correct errors in piecework quantity entry, so the quantity field has editing permissions; however, the unit price is maintained by the payroll specialist, who can only view it and not edit or filter it; the team leader can see the unit price column on the front end, but cannot filter it by unit price greater than a certain value, nor can he directly modify the content of the column.
[0121] The purpose of this mechanism is to separate and model different operational semantics, thereby achieving precise constraints on field access, field modification, and field retrieval capabilities.
[0122] Please see Figure 2This is a tabular piecework data filtering and processing system with edit permission restrictions, applied to a data processing server that includes a front-end and a database system. It includes the following modules: a matrix construction module, used to acquire the enterprise's organizational structure and piecework business data, divide the piecework business data according to user roles, data fields, and piecework types, and establish a three-dimensional permission matrix containing user role dimension sets, data field dimension sets, and piecework type dimension sets, defining the intersection elements of the three-dimensional permission matrix as operation permission sets; a threshold setting module, used to acquire historical piecework data, perform statistical analysis on piecework types based on historical piecework data, extract the average piecework amount and standard deviation of specific piecework types within a preset historical period, and set dynamic trigger thresholds based on pre-configured risk tolerance coefficients to establish dynamic permission control conditions based on piecework data attributes; and a permission calculation module, using... The system extracts the corresponding role based on the current user's identity information, combines the piecework type dimension set and the data field dimension set, and calculates the effective permission dataset for the current user's current session through a permission calculation program. The query reconstruction module receives and intercepts tabular piecework data filtering requests initiated by the current user on the front end, parses the filtering requests into an abstract syntax tree, injects and reconstructs the abstract syntax tree based on the effective permission dataset and dynamic trigger thresholds, parses the reconstructed abstract syntax tree into a standard query statement, and delivers it to the database engine in the database system for execution, resulting in piecework data query results with edit permission restrictions. The log auditing module obtains permission rule change operations for the three-dimensional permission matrix or data access operations for piecework business data, records the change operations or access operations using hash chain technology, and generates tamper-proof audit logs.
[0123] This embodiment provides a tabular piecework data filtering and processing system with edit permission restrictions for implementing the aforementioned method. Specifically, the system is still deployed on the data processing server of the aforementioned electronic assembly plant, and works collaboratively with the front-end table page, business database, organizational structure library, and audit log storage area. The system is not a simple combination of functions, but a sequentially linked processing chain around a piecework query request: first define permissions, then form thresholds, then generate an effective permission dataset, then perform syntax tree reconstruction, and finally complete audit solidification.
[0124] Specifically, the matrix construction module is responsible for reading basic metadata from the organization structure table, field configuration table, and piecework type table, and forming a three-dimensional permission matrix. This module preferably supports role-level inheritance, targeted overriding, and field-level operation permission splitting, thereby providing a unified permission foundation for all subsequent modules.
[0125] The threshold setting module is responsible for calculating the distribution of piece-rate amounts over the past 30 days by piece-rate type and outputting a dynamic threshold table based on the risk tolerance coefficient.
[0126] When a user logs in or refreshes their session, the permission calculation module generates an effective permission dataset based on the user's identity, role, agent responsibilities, and the current rule version.
[0127] The query reconstruction module is located between the front-end request and the database execution. It intercepts the table filtering request, converts it into an abstract syntax tree, injects allowed piecework types, field masks and dynamic editable states, and then hands it over to the database engine for execution.
[0128] The log auditing module records events such as permission configuration changes, access to sensitive data, and triggering dynamic degradation as hash chain logs.
[0129] To more clearly illustrate the module collaboration process, a simplified chain simulation can be performed: After a team leader logs into the system, the permission calculation module reads that his role is R2 and obtains the effective permission dataset: allowed piecework type {T1}, field view bitmap 10111, filter bitmap 10011; he requests a query on the front end to check the welding piecework this week, which displays the worker number, quantity, unit price, and amount.
[0130] The query reconstruction module parses the request into a syntax tree and finds that the unit price field is 0 in the bitmap. It then rewrites it as a mask function.
[0131] At the same time, the current threshold of 120 CNY for T1 is read from the threshold setting module, and the current editable derived field is appended; when the database returns the result, the row with an amount of 118 CNY is displayed as editable, and the row with an amount of 128 CNY is displayed as non-editable.
[0132] If the team leader attempts to modify the 128CNY record, the system will refuse to write it because the dynamic status is uneditable, and the log audit module will record this access and the previously occurred forced downgrade event.
[0133] Compared to the implementation method where all permission judgments are completed by a single application service, the systematic decomposition in this embodiment improves the system's deployability and scalability.
[0134] The matrix construction module is responsible for static rule expression, the threshold setting module is responsible for dynamic risk modeling, the permission calculation module is responsible for session-level orchestration, the query reconstruction module is responsible for pre-execution interception and pushdown, and the log auditing module is responsible for post-execution solidification; the boundaries between each module are clear, thereby reducing coupling and facilitating expansion.
[0135] For example, if the number of abnormal piece counts is added as another dynamic risk factor in the future, only corresponding judgments need to be added to the threshold setting module and query reconstruction module, without having to rewrite the entire permission framework; if any module is unavailable, the system adopts a tiered degradation strategy; if the matrix construction module fails to load, the system will not enable editing functions; if the threshold setting module does not produce a new threshold on the same day, the most recent valid threshold will be used and marked with a version number; if the permission calculation module cannot generate a complete and effective permission dataset, only basic read-only queries will be allowed; if the query reconstruction module fails to parse, the request will be terminated to prevent the original statement from directly accessing the database; if the log auditing module temporarily fails, the system can first cache the logs to be written in a local persistent queue and rewrite them after recovery, and restrict high-risk editing operations before the rewriting is completed.
[0136] On the morning of the month-end settlement, the payroll specialist adjusted the risk tolerance coefficient for welding piecework, and the matrix construction module and threshold setting module completed configuration updates; at noon, the welding team leader logged into the system, and the permission calculation module generated a new effective permission dataset; in the afternoon, when the team leader queried the details for the week, the query reconstruction module output the dynamic edit status according to the latest threshold; in the evening, the workshop supervisor reviewed the abnormally high records, and the log audit module solidified the viewing, approval, and previous automatic downgrade events into the hash chain; the entire process constitutes a complete lifecycle from rule configuration, data access, abnormal permission retrieval to audit tracking.
[0137] The purpose of this system is to modularly implement the multi-dimensional access control, dynamic threshold determination, query pushdown rewriting, and anti-tampering traceability of the aforementioned methods, thereby achieving a deployable, scalable, and adaptable server-side processing architecture for real piece-rate payroll business.
[0138] The foregoing has provided a detailed description of one embodiment of the present invention, but this description is merely a preferred embodiment and should not be construed as limiting the scope of the invention. All equivalent variations and modifications made within the scope of the claims of this invention should fall within the patent coverage of this invention.
Claims
1. A method for filtering piecework data in a tabular format with edit permission restrictions, characterized in that: For data processing servers that include front-end and database systems, the following steps are included: Step S1: Obtain the enterprise organizational structure and piecework business data, divide them according to user roles, data fields and piecework types, establish a three-dimensional permission matrix containing the dimensions of user roles, data fields and piecework types, and define the intersection elements of the matrix as the operation permission set; Step S2: Obtain historical piecework data and perform statistical analysis on the piecework type, extract the average piecework amount and standard deviation of the piecework type within a preset historical period, set a dynamic trigger threshold in combination with a preset risk tolerance coefficient, and establish dynamic permission control conditions based on piecework data attributes. Step S3: Extract the corresponding role based on the current user's identity information, and calculate the effective permission dataset for the current user's current session by combining the piecework type and data field dimension set; Step S4: Intercept the tabular piecework data filtering request initiated by the current user on the front end and parse it into an abstract syntax tree. Based on the effective permission dataset and the dynamic trigger threshold, perform condition injection and reconstruction on the abstract syntax tree. After reconstruction, parse it into a standard query statement and hand it over to the database engine for execution to obtain query results with editing permission restrictions. Step S5: Obtain permission rule changes or piecework business data access operations for the three-dimensional permission matrix, record the above operations using hash chain technology, and generate tamper-proof audit logs.
2. The method for filtering piecework data in a table format with edit permission restrictions according to claim 1, characterized in that, In step S1, a role hierarchy tree containing parent roles and child roles is defined in the enterprise organizational structure. When the child role does not have explicitly configured operation permissions, it inherits the permissions of the corresponding parent role. The set of operation permissions corresponds to a permission quantification value. The final effective permission quantification value of the intersection element in the three-dimensional permission matrix is calculated as follows: The final effective permission quantification value = the permission quantification value configured by the child role itself × the overwrite identifier + the permission quantification value of the parent role × (1 - overwrite identifier); Specifically, when the sub-role is configured for targeted overriding, the overriding identifier is 1; otherwise, the overriding identifier is 0.
3. The method for filtering piecework data in a table format with edit permission restrictions according to claim 1, characterized in that, Step S2 includes: Step S21: Calculate the average piece-rate amount and standard deviation for a specific piece-rate type over the past 30 days from the historical piece-rate data; Step S22: Add the product of the average piece-rate amount, the risk tolerance coefficient, and the standard deviation to obtain the dynamic trigger threshold; configured as follows: if the piece-rate amount of a single piece-rate data in the historical piece-rate data is greater than the dynamic trigger threshold, the editable permission of that piece-rate data will automatically become invalid, be forcibly downgraded to visible permission, and the preset review and approval status flag will be updated in the database system; otherwise, the current editable permission status of that piece-rate data will be maintained.
4. The method for filtering piecework data in a table format with edit permission restrictions according to claim 1, characterized in that, Step S3 includes: Step S31: Monitor the change log of the database system. When a modification to the three-dimensional permission matrix or the risk tolerance coefficient is detected, load the updated rules into the memory structure. Step S32: Based on the current user's role, match the corresponding set of operation permissions in the memory structure to generate the effective permission dataset; The effective permission dataset includes a list of piecework types that can be queried, a mask of fields that can be viewed, and a list of fields that can be used as filtering conditions.
5. The method for filtering piecework data in a table format with edit permission restrictions according to claim 1, characterized in that, Step S4, the process of conditionally injecting and reconstructing the abstract syntax tree based on the effective permission dataset, includes: Traverse the condition nodes of the abstract syntax tree and append the list of allowed piecework types in the effective permission dataset as a mandatory condition to the original query condition; the configuration is as follows: if the current user requests to filter piecework types that they do not have permission to access, then during the abstract syntax tree reconstruction phase, the request is replaced with a constant false condition to block the query; otherwise, the original condition nodes are retained. Traverse the query field nodes of the abstract syntax tree and compare them with the allowed field masks in the effective permission dataset; the configuration is as follows: if the filtering request contains a data field without visibility permission, then rewrite the query node of that data field with a preset character mask replacement function; otherwise, retain the original query field node.
6. The method for filtering and processing tabular piecework data with editing permission restrictions according to claim 1, characterized in that, In step S4, the process of conditionally injecting and reconstructing the abstract syntax tree based on the dynamic trigger threshold includes: The judgment logic of the dynamic trigger threshold is converted into a conditional judgment statement and injected into the abstract syntax tree, so that the returned query results with editing permission restrictions include a dynamically generated identifier field indicating whether the data is currently editable. The condition injection and reconstruction process for the filtering request is completed synchronously when the database engine scans the data.
7. The method for filtering piecework data in a table format with editing permission restrictions according to claim 3, characterized in that, Step S5 includes: Each time the three-dimensional permission matrix is changed or a forced downgrade is triggered, an audit log entry is generated that includes the operator, operation time, matrix status before the change, and matrix status after the change. The hash value of the current audit log entry depends on the hash value of the previous audit log entry. The calculation formula is as follows: Current hash value = Hash(current log content + hash value of the previous audit log entry); The "+" symbol represents a string concatenation operation.
8. The method for filtering piecework data in a table format with edit permission restrictions according to claim 1, characterized in that, In step S1, the set of operation permissions includes one or more of the following: visibility permissions, editable permissions, and permissions that can be used as filtering conditions.
9. A tabular piecework data filtering and processing system with edit permission restrictions, characterized in that it is used to implement the tabular piecework data filtering and processing method with edit permission restrictions as described in any one of claims 1-8, and is applied to a data processing server including a front-end and a database system, comprising the following modules: The matrix construction module is used to obtain the enterprise's organizational structure and piecework business data, divide the piecework business data according to user roles, data fields and piecework types, establish a three-dimensional permission matrix containing user role dimension set, data field dimension set and piecework type dimension set, and define the intersection elements in the three-dimensional permission matrix as operation permission sets; The threshold setting module is used to acquire historical piecework data, perform statistical analysis on the piecework type based on the historical piecework data, extract the average piecework amount and standard deviation of a specific piecework type within a preset historical period, and set a dynamic trigger threshold in combination with a pre-configured risk tolerance coefficient to establish dynamic permission control conditions based on piecework data attributes. The permission calculation module is used to extract the corresponding role based on the current user's identity information, and combine the piecework type dimension set and the data field dimension set to calculate the effective permission dataset for the current user's current session through the permission calculation program. The query reconstruction module is used to receive and intercept the tabular piecework data filtering request initiated by the current user on the front end, parse the filtering request into an abstract syntax tree, inject and reconstruct the abstract syntax tree based on the effective permission dataset and the dynamic trigger threshold, parse the reconstructed abstract syntax tree into a standard query statement, and hand it over to the database engine in the database system for execution to obtain piecework data query results with editing permission restrictions. The log auditing module is used to obtain permission rule change operations for the three-dimensional permission matrix or data access operations for the piecework business data, and to record the change operations or access operations using hash chain technology to generate tamper-proof audit logs.
