Corrective Instructions — RBAC Alignment (Binding)

Objective: Align the current RBAC implementation strictly with the approved RBAC plan. Preserve the enforcement structure and frontend UX, but remove all newly introduced backend permission derivation logic.

1️⃣ Absolute Rule (Non-Negotiable)

You must NOT implement or maintain any new RBAC logic or SQL queries to derive permissions.

The backend must use only the existing role logic already present in the system. Analyze the existing codebase to understand the role logic and permissions..

No new SQL joins or permission computation code is allowed.

2️⃣ What to REMOVE (Required)

Remove entirely:

GetMyPermissions custom SQL implementation inside PostLoginRepository

Any new SQL queries that compute effective permissions across:

Users

Roles

LinkModuleDb

LinkUserGroup

LinkGroupRole

or similar tables

There must be no parallel RBAC pipeline.

3️⃣ What to KEEP (Do Not Undo)

Keep:

AuthorizeFeatureAttribute (or equivalent enforcement mechanism)

Permission enforcement at API level

MyPermissions endpoint structure

Frontend PermissionsContext

PermissionGuard UX logic

These are correct.

You are NOT authorized to:

Refactor existing RBAC logic

Simplify legacy role code

Optimize SQL

Rename role structures

Introduce new authorization models

Only call the existing methods.

6️⃣ Validation Requirement

After changes, you must confirm explicitly:

No custom RBAC SQL remains

All permission decisions use existing backend role logic

API enforcement uses the same logic as Blazor

There is exactly one source of RBAC truth.

Important: RBAC now strictly reuses existing backend role logic with no parallel permission derivation. All API enforcement and permission exposure rely solely on proven legacy methods