What Is an Effective Permission?

An effective permission is the final yes-or-no answer to whether a user may perform an action, after every role they hold is combined into one set. It is what the system checks the instant a planner clicks a button or runs a command. Roles supply the rights, a user can hold more than one, and what they can do is the union of all of them. The effective set is the single source of truth for access, not any one role in isolation.

EDGEBIC by User Solutions computes an effective permission set for each user at sign-in. This article defines the term. To see where you configure the pieces, read how EDGEBIC handles users and roles.

How It Works

Access in EDGEBIC is built from roles, and only from roles.

A role is a named bucket of permissions such as Planner or Shop Floor Supervisor. Assign a user to one or more roles and they inherit the union of everything those roles grant. There is no separate per-user permission list in the current application: if a right is not in one of the roles a person holds, they do not have it.

The rule that follows from this matters more than it first appears: roles only ever add. Assigning a second role can never remove something the first one granted. That makes adding a role a safe operation, and it makes subtracting a single capability impossible by assignment. To give somebody less than a role provides, you build a narrower role and assign that one instead.

The built-in Administrator role is the exception worth knowing about. It always holds every permission, including new ones that arrive with product updates, and it cannot be deleted. Custom roles are deliberately left alone by updates, so a newly shipped capability reaches Administrator automatically and reaches a custom Planner role only when somebody ticks it.

The formula is plain arithmetic on sets: take the union of every role the user holds. What remains is the effective permission set, and every access check is a fast lookup against it.

A Concrete Example

Alice is a planner. She needs to edit a bill of routing, which the Planner role does not include, and she should not be deleting manufacturing orders, which the Planner role does include.

Those are two different problems with two different fixes.

For the extra capability, her administrator builds a small Routing Editor role containing just that permission and ticks it on Alice's user record alongside Planner. For the capability she should not have, adding anything is useless, because Planner keeps granting delete no matter what else is assigned. Instead the administrator builds a Planner (no delete) role and assigns that in place of Planner.

Now walk the calculation:

Alice's effective set ends up as: generate a schedule, edit a bill of routing, and everything else the narrower Planner role gives, but not delete a manufacturing order. When she tries to delete a job the check fails and she sees an access-denied message. Every other planner, still on the original Planner role, is completely unaffected, because role definitions were never edited, only assignments.

How EDGEBIC Uses It

EDGEBIC loads a user's effective permission set when they sign in and keeps it in memory for the session, so each check is instant. Every screen, menu, and command consults it: tabs and buttons appear only when the effective set allows the action, and the underlying command refuses to run if the check fails, so hiding a button is never the only guard.

Because the set is captured at sign-in, a change made while somebody is working does not reach them until they sign out and sign back in. That catches people out constantly, and it is the first thing to rule out when a correct-looking change appears to have done nothing.

The single-layer model also keeps day-to-day administration simple: build roles for job functions, name them for what they do, and compose them on the user when somebody is an exception. When you are diagnosing why someone can or cannot do something, the question is always which roles do they hold, and the answer is on their user record rather than in any one role's permission tree.

For the wider access-control picture, see how EDGEBIC handles users and roles and the sibling term security audit trail. You can browse related definitions in the manufacturing glossary.