A Permission Change Did Not Take Effect: Causes and Fixes

When a permission you granted does not reach the user, the usual cause is that their session captured its permission set at sign-in, so the change takes effect only after they sign out and back in. EDGEBIC by User Solutions resolves effective access once per session rather than re-checking on every click, which keeps a screen consistent while a user works but delays new grants until the next login.

This post is the detailed version of the permission-lag symptom in the EDGEBIC troubleshooting guide. For the model behind it, what an effective permission is explains how roles and overrides combine into one set.

What You Are Seeing

You edit a role, tick the code the user is asking for, and save. The user tries the action again and gets the same permission denied message, or the button is still grayed out, or the tab is still absent. You re-open the role and the code is clearly ticked. Nothing about the configuration looks wrong, because nothing about the configuration is wrong.

Why It Happens

Cause 1: The session holds the permission set captured at sign-in. This is the answer in the large majority of cases. Effective access is resolved once when the user authenticates, and that immutable set is what every screen consults for the rest of the session. A grant added afterward is in the database but not in the running session. Signing out and back in re-resolves the set.

Note the difference between closing a window and signing out. Users often report "I restarted it" when they closed a screen and reopened it inside the same session. Only a genuine sign-out and sign-in refreshes the set.

Cause 2: You are hunting for a per-user override that does not exist. Administrators who have used other access systems often start looking for a user-level exception that is quietly blocking the grant. There isn't one. Permissions come only from roles, and roles only ever add, so nothing is subtracting this code from one person. That is worth knowing early, because it means the answer is always in the roles the user holds and the causes below are the whole list.

Cause 3: The code was granted on a role the user does not hold. Roles with similar names are easy to confuse, and a user can hold more than one. Confirm the role assignment on the user, not just the tick on the role.

Cause 4: You granted a neighboring code. Modules commonly expose several actions: view, add, edit, delete, plus module-specific ones such as generating a schedule, drag rescheduling, editing actuals, logging actuals, running imports, or managing import masks. Granting View when the user needs Edit produces exactly this symptom. Read the blocked action and match the code to it.

Cause 5: A newly shipped code never reached the custom role. The catalog sync at startup inserts codes the software defines and grants every one of them to the Administrator role. Custom roles are left alone on purpose so an update cannot silently widen access. A screen gated by a new code stays invisible to custom roles until an administrator ticks it.

Cause 6: Startup did not finish the sync. If startup stops before the catalog sync runs, for example because a pending database update failed to apply, the catalog stays stale and permission checks against new codes fail silently. Fix the startup problem first, then restart and re-check.

How to Fix It

1. Have the user sign out and sign back in. Do this before changing anything else. It resolves the majority of these reports and costs less than a minute.
2. Confirm the exact code the blocked action needs. Open Settings, Security, Roles, edit a role, and read the permission tree by section, module, and action. Match the code to the action the user is attempting, not the module they are standing in.
3. Confirm the user actually holds the role you edited. Open Settings, Security, Users, select the user, and read the role selections in the edit dialog.
4. Compare against a colleague who can do it. Open somebody who performs the action successfully and read their role selections. The difference between the two lists is the fix, and this catches wrong-role and similar-name mistakes faster than reading a permission tree does.
5. If the code belongs to the job, add it to the main role rather than a side one. A grant that lives on the role matching the person's function stays legible six months later. See how to create a role and how to give one user extra access when only one person needs it.
6. Re-test after a fresh sign-in. Any change made in steps 3 to 5 needs one more sign-out and sign-in before it reaches the user.

How to Prevent It

• Make "sign out and back in" the standard closing line of every permission change. Tell the requester at the time you make the grant so they are not left retrying a stale session.
• Grant at the role level whenever the need belongs to a job function. Role grants reach every holder of that role on their next sign-in, and they stay legible six months later. When only one person needs it, assign a narrow add-on role rather than widening the shared one.
• Read the user's role assignments before the role's permission tree. The commonest contradiction is a correct grant on a role the person does not actually hold, and the user record is where that shows up.
• Add a custom-role review to your upgrade checklist. After each update, walk each custom role's permission tree and tick the newly shipped codes that role should have.
• Match the code to the action, not the module. Reading the blocked action literally, and finding the code that names it, is faster than reasoning backward from a grayed-out button. If the module is missing entirely rather than blocked, a tab I expect is missing covers that variant, and user and permission mistakes catalogs the wider set.