A Tab I Expect Is Missing: Causes and Fixes

When a module tab you expect is not on screen, the cause is almost always a permission code your assigned roles do not grant, and the fix is to add that code to a role you hold. EDGEBIC by User Solutions hides tabs a user has no permission to view rather than showing them grayed out, so a missing permission looks like a missing feature.

This post is the detailed version of the missing-tab symptom in the EDGEBIC troubleshooting guide. For the underlying model, what an effective permission is explains how roles and overrides combine.

What You Are Seeing

A colleague describes a screen you do not have. Reports, Work Centers, Import, or the Master Production Schedule simply is not among your tabs. Nothing is grayed out, no error appears, and reinstalling changes nothing. On another workstation, signed in as an administrator, the tab is right there.

The absence is the diagnostic. A grayed-out control means the module is present but an action inside it is blocked. A missing tab means the module's View permission is not in your effective set.

Why It Happens

Cause 1: Your roles never granted the module's View code. Permissions are organized as a tree of sections, then modules, then actions. Every module has its own View code, and a role that grants scheduling actions does not automatically grant master data or reporting views. A role assembled for one job function commonly omits sections nobody thought to tick.

Cause 2: A custom role did not pick up a new code after an update. On startup, the permission catalog is compared against the codes the software defines. New codes are inserted and every new code is granted to the Administrator role. Custom roles are deliberately not touched. That is the right default, because an upgrade should never silently widen what a Planner or Shop Supervisor can reach, but it means a newly shipped module is invisible to everyone except administrators until someone edits the custom roles.

Cause 3: You do not hold the role you are looking at. It is easy to inspect a role, confirm the View code is ticked, and conclude the configuration is fine, without checking that the user is actually assigned to that role. Roles with similar names make this worse. Because permissions come only from roles, and roles only ever add, no user-level exception can be subtracting the code, so a correct-looking grant that has no effect almost always means the assignment is not what you assumed.

Cause 4: The permission was added while you were signed in. Your permission set is captured at sign-in and held for the session. A grant made after you signed in does not reach you until you sign out and back in. That case has its own post: a permission change did not take effect.

Cause 5: Startup did not complete the permission sync. If startup fails before the catalog sync runs, for example because a pending database update did not apply, older codes remain in place and newly gated screens can fail their checks silently. Resolve the startup problem first, then restart.

How to Fix It

1. Identify the code that gates the module. Open Settings, Security, Roles, edit any role, and expand the permission tree. Sections group modules, modules group actions. Find the module by name and note its View code.
2. Check the user's roles. Open Settings, Security, Users, select the user, and open the edit dialog. The role selections show every role assigned.
3. Check each role's matrix. Open each assigned role and confirm whether the module's View code is ticked. If none of them tick it, that is your answer.
4. Compare against a colleague who can see the tab. Read their role selections alongside the affected user's. The difference between the two lists is usually the whole answer, and it catches similar-name mistakes faster than reading a permission tree does.
5. Grant the code. Add the View code to the role that should carry it, which is the durable fix for a job function. When just one person needs it, build a narrow add-on role and assign it alongside their existing one: how to give one user extra access covers that route.
6. Have the user sign out and back in. The session's permission set is captured at sign-in, so the tab appears on the next login and not before.

A Worked Example

A Planner role is built with the Production section (manufacturing orders, schedule generate, drag reschedule, edit and log actuals, routing view and edit), the Sales section (quote view, add, edit, simulate, plus customer view), the Insights section (report view and export, dashboard view and configure), and the Data section (import run and mask management). It grants Settings View but deliberately omits the clear-data and data-source codes.

A planner on that role can schedule, quote, import, and report. If nobody ticked the Master Data section, that planner cannot see Products, Work Centers, Shifts, or Holidays. Everything else works, which is exactly why the gap goes unnoticed until someone tries to add a machine.

How to Prevent It

• Build roles from a written job description, section by section. Walk the whole permission tree once per role rather than ticking codes as complaints arrive. The section headings make omissions visible.
• Re-review custom roles after every update. New modules ship with new codes, and only the Administrator role gets them automatically. Add a role review to your upgrade checklist.
• Name add-on roles for the capability, not the person. An Import Operator role assigned to two people stays readable a year later; a role called Dave Extra does not.
• Check the assignment before escalating. When a role clearly grants a code and the tab is still missing, the user not holding that role, or not having signed out and back in, covers nearly every remaining case.
• Never rename a permission code. Audit rows store the code string, so a rename orphans history and breaks existing grants. User and permission mistakes catalogs the rest of these traps.