[{"data":1,"prerenderedAt":60},["ShallowReactive",2],{"legacy:engine\u002Fperm:en":3},{"id":4,"title":5,"description":6,"keywords":7,"author":8,"robots":9,"bodyClass":10,"image":11,"jsonld":12,"html":59},"engine\u002Fperm","Permission Engine - Across Functions, Data & Page Fields - JEDP Digital Platform","JEDP Permission Engine: RBAC menu authorization, departmental data scope, control over form and list fields and buttons, covering process nodes and reports and dashboards, with both field-level and row-level control and auditable operations.","JEDP, authority engine, six engines, digital platform, Lang Bowan","Shenzhen Langbowan Information Technology Co., Ltd.","index, follow","page-engines","https:\u002F\u002Fwww.jedp.cn\u002Fres\u002Fimages\u002Fproduct\u002Fplatform-overview.webp",[13,30],{"@context":14,"@type":15,"itemListElement":16},"https:\u002F\u002Fschema.org","BreadcrumbList",[17,22,26],{"@type":18,"position":19,"name":20,"item":21},"ListItem",1,"Home","https:\u002F\u002Fwww.jedp.cn\u002F",{"@type":18,"position":23,"name":24,"item":25},2,"Platform","https:\u002F\u002Fwww.jedp.cn\u002Fengines",{"@type":18,"position":27,"name":28,"item":29},3,"Permission Engine","https:\u002F\u002Fwww.jedp.cn\u002Fengine\u002Fperm",{"@context":14,"@type":31,"@id":32,"name":33,"applicationCategory":34,"applicationSubCategory":35,"operatingSystem":36,"inLanguage":37,"description":6,"url":29,"provider":41,"isPartOf":43,"offers":45,"featureList":52},"SoftwareApplication","https:\u002F\u002Fwww.jedp.cn\u002Fengine\u002Fperm#software","JEDP Permission Engine","BusinessApplication","Enterprise Digital Platform Engine","Web (browser access; SaaS multi-tenant, private deployment assessed by scenario)",[38,39,40],"zh-CN","zh-TW","en",{"@id":42},"https:\u002F\u002Fwww.jedp.cn\u002F#organization",{"@id":44},"https:\u002F\u002Fwww.jedp.cn\u002F#software",{"@type":46,"url":47,"availability":48,"priceSpecification":49},"Offer","https:\u002F\u002Fwww.jedp.cn\u002Fcontact?from=engine-perm","https:\u002F\u002Fschema.org\u002FInStock",{"@type":50,"priceCurrency":51},"PriceSpecification","CNY",[53,54,55,56,57,58],"Function \u002F Menu Authorization: RBAC menu and function point authorization, roles can be combined into position-level permission packages. Multiple roles (planning, warehouse management, quality inspection, sales) can be assembled according to the principle of least privilege, rather than copying the administrator.","Data Range: Trim the list and visible rows of documents according to the department, the department and its subordinates, custom organization scope, etc. Having access to the menu does not mean you can see all the data — row-level scope is tied to organizational positions.","Fields and Buttons: Form\u002Flist fields are read-only or hidden, buttons are visible and controllable, and the rules are consistent between the front end and back end. Fake security like \"hiding the button on the front end while the API can still be modified\" is prohibited; the submission side must also perform the same validation.","Process and nodes: The handling, forwarding, and editing rights of node fields are still subject to permission and organizational analysis constraints. Agent recommendations and proxy operations also cannot bypass node authorization and data scope.","Reports and Dashboard: The scope of reports and cockpit displays can be authorized, and sensitive operational indicators are restricted according to roles. The on-site large screen and management cockpit share the authorization model to prevent sensitive data from spreading due to screen casting.","Audit and Recovery: Key authorization changes and sensitive operations are traceable; proxy, project team, and temporary authorizations have expiration dates and are regularly cleared, preventing permission debt from lingering after job transfers or project completion.","\u003Csection class=\"product-detail-section page-section\">\n    \u003Cdiv class=\"detail-container\">\n      \u003Cnav class=\"breadcrumb\" aria-label=\"Breadcrumb\">\n        \u003Ca href=\"\u002F\">Home\u003C\u002Fa>\n        \u003Cspan class=\"breadcrumb-sep\">\u002F\u003C\u002Fspan>\n        \u003Ca href=\"\u002Fengines\">Platform\u003C\u002Fa>\n        \u003Cspan class=\"breadcrumb-sep\">\u002F\u003C\u002Fspan>\n        \u003Cspan>Permission Engine\u003C\u002Fspan>\n      \u003C\u002Fnav>\n      \u003Cdiv class=\"product-detail\">\n        \u003Cdiv class=\"detail-header\">\n          \u003Cdiv class=\"detail-icon\">\u003Ci class=\"fas fa-user-shield\">\u003C\u002Fi>\u003C\u002Fdiv>\n          \u003Cdiv>\n            \u003Ch1>Permission Engine\u003C\u002Fh1>\n            \u003Cp class=\"detail-subtitle\">An authorization model that runs through menus, data rows, page fields, and buttons — minimum permissions configurable, operations auditable, inherited according to organizational scope\u003C\u002Fp>\n          \u003C\u002Fdiv>\n        \u003C\u002Fdiv>\n        \u003Cdiv class=\"detail-content\">\n\n          \u003Cdiv class=\"detail-section\">\n            \u003Ch2>Engine Positioning\u003C\u002Fh2>\n            \u003Cp class=\"detail-lead\">The permission engine consolidates 'which menus can be accessed, which rows can be viewed, which fields can be edited, and which buttons can be clicked' into configurable rules, rather than scattering them as hard-coded logic across various business pages. Based on departments and positions from the organizational engine, data scope can be filtered according to boundaries such as the current department, or the current department and its sub-departments. Workflow nodes, report dashboards, and field-level controls share the same authorization context, meeting the control requirements of manufacturing enterprises with multiple roles and multiple factories.\u003C\u002Fp>\n            \u003Cp class=\"detail-lead\">When cooperating with dual agents, both the design-phase and runtime capabilities are still subject to permission constraints: agents cannot bypass organizational boundaries to modify data they are not supposed to change. Audit trails support post-event accountability and compliance checks. Authorizations switch with the effective date of the position, and concurrent roles, secondments, and acting roles should be explicitly modeled and time-limited to prevent 'temporarily convenient access' from turning into permanent excessive privileges.\u003C\u002Fp>\n          \u003C\u002Fdiv>\n          \u003Cdiv class=\"detail-section\">\n            \u003Ch2>Where It Fits\u003C\u002Fh2>\n            \u003Cul class=\"pain-list\">\n              \u003Cli>Menu authorization and data row permissions are split, allowing access to the page but seeing data from the entire company, or vice versa—the rows that should be visible are missing.\u003C\u002Fli>\n              \u003Cli>Field and button control relies on front-end hiding, the interface layer does not perform unified validation, there is a risk of bypassing, and it is impossible to prove minimum permissions during an audit.\u003C\u002Fli>\n              \u003Cli>There are two separate systems for process node approvers and functional permissions. After a job transfer, situations may arise where one can 'approve but not view' or 'view but not approve'.\u003C\u002Fli>\n              \u003Cli>Report and dashboard permissions are broadly granted, sensitive business data spreads to unnecessary roles, or the on-site dashboard is inconsistent with the office version.\u003C\u002Fli>\n              \u003Cli>Temporary agents and project team authorizations are not revoked upon expiration, resulting in accumulating privilege debt, allowing continued unauthorized access even after resignation or transfer.\u003C\u002Fli>\n            \u003C\u002Ful>\n          \u003C\u002Fdiv>\n          \u003Cdiv class=\"detail-section\">\n            \u003Ch2>Capability Highlights\u003C\u002Fh2>\n            \u003Cul class=\"capability-list\">\n              \u003Cli>\u003Cstrong>Function \u002F Menu Authorization\u003C\u002Fstrong>\u003Cspan>RBAC menu and function point authorization, roles can be combined into position-level permission packages. Multiple roles (planning, warehouse management, quality inspection, sales) can be assembled according to the principle of least privilege, rather than copying the administrator.\u003C\u002Fspan>\u003C\u002Fli>\n              \u003Cli>\u003Cstrong>Data Range\u003C\u002Fstrong>\u003Cspan>Trim the list and visible rows of documents according to the department, the department and its subordinates, custom organization scope, etc. Having access to the menu does not mean you can see all the data — row-level scope is tied to organizational positions.\u003C\u002Fspan>\u003C\u002Fli>\n              \u003Cli>\u003Cstrong>Fields and Buttons\u003C\u002Fstrong>\u003Cspan>Form\u002Flist fields are read-only or hidden, buttons are visible and controllable, and the rules are consistent between the front end and back end. Fake security like \"hiding the button on the front end while the API can still be modified\" is prohibited; the submission side must also perform the same validation.\u003C\u002Fspan>\u003C\u002Fli>\n              \u003Cli>\u003Cstrong>Process and nodes\u003C\u002Fstrong>\u003Cspan>The handling, forwarding, and editing rights of node fields are still subject to permission and organizational analysis constraints. Agent recommendations and proxy operations also cannot bypass node authorization and data scope.\u003C\u002Fspan>\u003C\u002Fli>\n              \u003Cli>\u003Cstrong>Reports and Dashboard\u003C\u002Fstrong>\u003Cspan>The scope of reports and cockpit displays can be authorized, and sensitive operational indicators are restricted according to roles. The on-site large screen and management cockpit share the authorization model to prevent sensitive data from spreading due to screen casting.\u003C\u002Fspan>\u003C\u002Fli>\n              \u003Cli>\u003Cstrong>Audit and Recovery\u003C\u002Fstrong>\u003Cspan>Key authorization changes and sensitive operations are traceable; proxy, project team, and temporary authorizations have expiration dates and are regularly cleared, preventing permission debt from lingering after job transfers or project completion.\u003C\u002Fspan>\u003C\u002Fli>\n            \u003C\u002Ful>\n          \u003C\u002Fdiv>\n          \u003Cdiv class=\"detail-section\">\n            \u003Ch2>Works With Other Engines\u003C\u002Fh2>\n            \u003Cdiv class=\"platform-boost\">\n              \u003Carticle>\u003Ch3>Organization Engine\u003C\u002Fh3>\u003Cp>The data scope and role packages depend on the department tree, positions, and reporting relationships; without an effective date for the organization, permission changes inevitably drift, and old permissions persist for a long time after a job transfer.\u003C\u002Fp>\u003C\u002Farticle>\n              \u003Carticle>\u003Ch3>Form Engine\u003C\u002Fh3>\u003Cp>Field read-only\u002Fhidden settings are linked with button visibility and form configuration, and they are also effective on the submission API side, preventing the false security of 'hidden on the front end but still modifiable on the back end'.\u003C\u002Fp>\u003C\u002Farticle>\n              \u003Carticle>\u003Ch3>Workflow Engine\u003C\u002Fh3>\u003Cp>Node handling, transfer, and field editing rights are subject to permission constraints; agent and agent operations also do not bypass node authorization and row-level scope.\u003C\u002Fp>\u003C\u002Farticle>\n              \u003Carticle>\u003Ch3>Report Engine\u003C\u002Fh3>\u003Cp>Reports and large screens are authorized according to functionality and row-level scope. Sensitive indicators can be restricted to roles that need to know, and screen casting and exporting are also controlled.\u003C\u002Fp>\u003C\u002Farticle>\n            \u003C\u002Fdiv>\n          \u003C\u002Fdiv>\n          \u003C!-- engine-depth:BEGIN -->\n\n          \u003Cdiv class=\"detail-section\">\n            \n            \u003Ch2>Typical breakpoints\u003C\u002Fh2>\n\u003Cdiv class=\"table-scroll\">\u003Ctable>\u003Cthead>\u003Ctr>\u003Cth>Breakpoint\u003C\u002Fth>\u003Cth>Common cause\u003C\u002Fth>\u003Cth>Control lever\u003C\u002Fth>\u003C\u002Ftr>\u003C\u002Fthead>\u003Ctbody>\u003Ctr>\u003Ctd>Can access the menu but see data for the entire company\u003C\u002Ftd>\u003Ctd>Only equipped with functionality, not with data scope\u003C\u002Ftd>\u003Ctd>Role package simultaneously equips menu and row-level scope\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd>Frontend hidden fields are still modified by the interface\u003C\u002Ftd>\u003Ctd>Control only the presentation layer\u003C\u002Ftd>\u003Ctd>The same set of field\u002Fbutton rules for both frontend and backend\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd>Can approve but cannot view, or can view but cannot approve\u003C\u002Ftd>\u003Ctd>Separation of process permissions and functional permissions\u003C\u002Ftd>\u003Ctd>Alignment of node handling rights and document visibility rights\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd>Large screen casting leaks sensitive indicators\u003C\u002Ftd>\u003Ctd>The large screen has not been authorized separately\u003C\u002Ftd>\u003Ctd>The large screen and reports share the authorization model\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd>Can still log in to Collaboration after leaving the job\u003C\u002Ftd>\u003Ctd>Account and permissions were not revoked with the position.\u003C\u002Ftd>\u003Ctd>Account and authorization recovery after the end of the appointment\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd>The project team authorization is permanently valid\u003C\u002Ftd>\u003Ctd>Temporary authorization has no expiration set\u003C\u002Ftd>\u003Ctd>Authorization Ledger + Periodic Permission Review\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd>Supplier account sees internal price\u003C\u002Ftd>\u003Ctd>Gateway role not isolated\u003C\u002Ftd>\u003Ctd>Internal and External Role Manual + Spot Check\u003C\u002Ftd>\u003C\u002Ftr>\u003C\u002Ftbody>\u003C\u002Ftable>\u003C\u002Fdiv>\n            \u003Ch2>Promotion and Acceptance\u003C\u002Fh2>\n            \u003Cul class=\"accept-list\">\n              \u003Cli>Use 'the same role, the same document' to conduct a four-way comparison sampling inspection of list, details, export, and processing interfaces; any differences are considered defects.\u003C\u002Fli>\n              \u003Cli>Job transfer effective date scenario: the old department row is not visible, the new department row is visible, and the visibility strategy for pending and historical documents can be explained\u003C\u002Fli>\n              \u003Cli>Proxies and temporary authorizations automatically expire upon expiry or have a recovery work order; the audit log can trace the authorizer and the reason for the change\u003C\u002Fli>\n              \u003Cli>Pilot accounts for agent design mode\u002Foperation mode are configured with minimal privileges, and demonstrations show that unauthorized requests are intercepted.\u003C\u002Fli>\n              \u003Cli>The three types of entry points—report export, large screen projection, and mobile processing—have the same role scope.\u003C\u002Fli>\n              \u003Cli>Spot-checking shows that the differences in visible fields for the same order line between the SRM portal account and the internal procurement role are consistent with the design\u003C\u002Fli>\n              \u003Cli>Batch permission changes are prohibited during month-end closing, payroll, and major inventory count periods, unless there is a rollback plan and duty arrangement in place.\u003C\u002Fli>\n            \u003C\u002Ful>\n            \n            \u003Ch2>Implement in stages\u003C\u002Fh2>\n            \u003Cul class=\"accept-list\">\n              \u003Cli>\u003Cstrong>Phase One\u003C\u002Fstrong>: Job level role package template, menu and row-level scope baseline, audit log activation\u003C\u002Fli>\n              \u003Cli>\u003Cstrong>Phase II\u003C\u002Fstrong>: Process node handling rights, field-level rules, export\u002Finterface sampling test cases\u003C\u002Fli>\n              \u003Cli>\u003Cstrong>Phase Three\u003C\u002Fstrong>: Portal and multi-product joint debugging, temporary authorization recovery mechanism, permission debt cleanup rhythm\u003C\u002Fli>\n            \u003C\u002Ful>\n            \n            \u003Ch2>Create a landing prompt\u003C\u002Fh2>\n            \u003Cp class=\"detail-lead\">QMS quality inspectors, WMS warehouse staff, MES team leaders, and SRM purchasers often play multiple roles: permission sets should be assembled according to job templates, and when handling dual roles, data scopes should be explicitly superimposed rather than duplicating administrator packages. Supplier portal accounts and internal purchasing roles should have visibility of prices, drawings, and order lines listed separately in the acceptance checklist. Cost and salary fields must be intercepted at the interface level even if hidden in the UI, to prevent leaks during export.\u003C\u002Fp>\n            \u003Ch2>When not to apply\u003C\u002Fh2>\n            \u003Cul class=\"pain-list\">\n              \u003Cli>Hope to replace process orchestration or business state machines with a permission engine — the sequence of nodes and business rules are still handled by processes and forms\u003C\u002Fli>\n              \u003Cli>Refusing to organize master data governance but demanding dynamic authorization down to the individual level—should first have appointment and effective dates\u003C\u002Fli>\n              \u003Cli>Using a 'super account' as a long-term operation and maintenance method—temporary authorized access with auditability and expiration recovery should be used\u003C\u002Fli>\n              \u003Cli>Relying solely on training to require employees to 'consciously not look'—the system must be able to prove that it is invisible, non-extractable, and unmanageable.\u003C\u002Fli>\n            \u003C\u002Ful>\n          \u003C\u002Fdiv>\n          \u003C!-- engine-depth:END -->\n\n\u003Cdiv class=\"detail-section\">\n            \u003Ch2>Product Fit\u003C\u002Fh2>\n            \u003Cul class=\"related-cases\">\n              \u003Cli>EHR: Permission packages switch with the effective date of position, and concurrent post agents can be reclaimed\u003C\u002Fli>\n              \u003Cli>SRM: Scope of Procurement Organization Data and Decentralization of Supplier Portal\u003C\u002Fli>\n              \u003Cli>CRM: Sales Organization Line-Level Visibility and Price Field Protection\u003C\u002Fli>\n              \u003Cli>Dual agents: neither querying numbers nor modifying matches bypasses the authorized model\u003C\u002Fli>\n              \u003Cli>Case: Random inspection of permissions switching with position\u003C\u002Fli>\n              \u003Cli>Insight: Permissions are inherited with the position, how to revoke them for concurrent roles\u003C\u002Fli>\n            \u003C\u002Ful>\n          \u003C\u002Fdiv>\n          \u003Cdiv class=\"product-detail-cta scroll-reveal\">\n            \u003Ca href=\"\u002Fengines#engines\" class=\"btn btn-outline\">Back to Platform\u003C\u002Fa>\n            \u003Ca href=\"\u002Fcontact?from=engine-perm\" class=\"btn\">Book a Meeting\u003C\u002Fa>\n          \u003C\u002Fdiv>\n        \u003C\u002Fdiv>\n      \u003C\u002Fdiv>\n    \u003C\u002Fdiv>\n  \u003C\u002Fsection>\n\n  \n  \n  \n  \n  \n  \u003C!-- GEO:software-app:BEGIN · 由 scripts\u002Finject_geo.py 生成，请勿手改 -->\n  \n  \u003C!-- GEO:software-app:END -->",1793937990268]