A jogosultsági motor – funkció-törzs, végrehajtási és megjelenítési kapu

A funkció-katalógus, a felderítő, a végrehajtási és a megjelenítési kapu döntési sorrendje, a hozzárendelés-tábla és a motor ismert korlátai.

Áttekintés

A motor minden admin-kérésnél fut: az indító lépés regisztrálja a könyvtárakat, a vezérlők a dlbtpermission metódusait hívják. Három réteg: 1) alap útvonal-jog (hozzáférés, módosítás), 2) funkciójog, 3) tartalmi hatókör. A táblanevek a telepítés saját előtagjával állnak az adatbázisban.

Funkció-törzs (feature)

Az egyetlen funkció-törzs: egy sor egy route + action_key pár. Fő mezők: module, name, access_type (UNMAPPED, BASE, SUBSCRIPTION, SYSTEM; alap UNMAPPED), visibility_rule (auto, never, always), parent_feature_id, list_price, currency, uom, usage_mode, limit_*, billing_period, permission_present, gate_covered, cron_related, cron_job_type, status.

Sorok forrása:

  1. Seed-migrációk, kifejezett besorolással.
  2. Vetítés a régi permission katalógusból minden migráció után (projectPermissionCatalogue(), INSERT IGNORE, UNMAPPED); a régi csoport-hozzárendelések role forrású csoport-sablonsorrá válnak. Visszafelé nem másol.
  3. Felderítés: a Funkciók törzs „scan” gombja (masterdata/feature::scan) a Dlbtfeature::scan()-t hívja.

A seedekben 523 route::kulcs pár van: BASE 45, SUBSCRIPTION 6, SYSTEM 44, UNMAPPED 78, további 350 csak a régi katalógusban (vetítés után UNMAPPED); 122 kódban ellenőrzött kulcs egyik seedben sincs. A Dlbtfeature::classify() kérésenként egyszer betölti az aktív törzset; ha a betöltött sorok száma 0, a kapu a régi útra esik vissza.

A felderítő (Dlbtfeature::scan())

  1. Csak az admin vezérlő-fájlokat olvassa; fájlonként az első route-definíciót veszi.
  2. A canAction( és canActionForGroup( hívásokat gyűjti; változóban átadott route esetén a fájl saját route-ja kerül be, a kulcsnak literálnak kell lennie.
  3. Nem ismeri fel: canSave(), canBulkAction(), canBulk(), canSee(), uiMode(), lockReason(), canActionForUser(), canSeeDeleted(), canStorageContext().
  4. Hozzáveszi a régi katalógus aktív sorait (unió), és a Dlbtcronhealth::JOBS alapján route → háttérfeladat térképet épít.
  5. Meglévő sornál csak a mért tényeket frissíti (az access_type, név, megjegyzés nem íródik felül); új sor UNMAPPED, státusz 1.
  6. Visszaad: added, updated, gap_permission, gap_gate; utána flush().

Végrehajtási kapu (canAction)

  1. Nincs bejelentkezett felhasználó → tilt; user_group_id = 1 → enged.
  2. Betöltött törzsnél: a törzsben nem szereplő kulcs → tilt; SYSTEM → minden bejelentkezett felhasználónak enged.
  3. Különben kell egy MA érvényes, access_mode = 'usable' sor a user_feature-ben (bármely forrás; a dátum mindkét vége beleszámít, NULL nyitott). Ha nincs, a függőség-nyitás dönt.
  4. Van sor → Dlbtentitlement::allows(): UNMAPPED és BASE engedett; SUBSCRIPTION engedett, kivéve lejárt tartozásnál (csak bekapcsolt tartozás-zár beállításnál, türelmi nappal; a felhasználó clientjének lejárt, nyitott számlái alapján).
  5. Üres vagy olvashatatlan törzsnél a régi csoport-szintű katalógus dönt, majd az allows() szűkíthet.

Függőség-nyitás (dependencyAllows): csak olvasó kulcsra (list, autocomplete, search, select, view, read), ha a felhasználónak használható sora van egy másik funkcióra, amelynek a feature_dependency táblában rendszer-típusú függősége erre mutat. Kereskedelmi típusú függőség nem nyit. Példa: a számla rögzítése nyitja a partner- és cégcsoport-listát, a számlatömb- és bankszámla-listát.

Megjelenítési kapu és felület-mód

  • canSee: super admin, üres törzs, a törzsben nem szereplő kulcs, visibility_rule = always és SYSTEM → látszik; never → nem. Egyébként MA érvényes (látható vagy használható) sor kell; a list akkor is látszik, ha a route bármely funkciójára van sora. Nem-list kulcsnál a route listájának és a menücsoport menu kulcsának is látszania kell (Permission::MENU_GROUPS).
  • uiMode: canAction → ok; különben canSee → upsell; különben none.
  • lockReason: törzsben lévő, nem SYSTEM funkció használható sor nélkül → subscription; tartozás → debt. Az indító lépés upsellGuard()-ja teljes oldal-betöltésnél ez alapján az ajánlóra irányít.
  • canSave($route, $id): id > 0 → edit; id = 0 → add, ha az a törzsben van, különben edit. canBulk, canBulkAction: a bulk előtagú kulcs dönt, ha létezik. canSeeDeleted: super admin vagy delete. getAllowedScopeValues: tartalmi szabályok (a felhasználó saját szabálya felülírja a csoportét; csak engedő értékek).

Hozzárendelés (user_feature)

Az egyetlen hozzárendelés-tábla: user_id (vagy csoport-sablonnál user_group_id), feature_id, date_from, date_to, source (role, subscription, order, manual), source_ref, origin, access_mode (visible, usable), offer_definition_id, is_override, korlát- és árazási mezők, definition_id, plan_id. A csoport-sor (user_id = 0, source = 'role') sablon, a kapu nem olvassa; a syncGroupRoleRows() és a fillUserRoleFromGroup() bontja felhasználónkénti sorokká. Író utak: Dlbtentitlement::grant() és grantStructure(), Dlbtprovision::materialise(), a funkciójog-modell saveUserFeatureRows() és addMeteredOrder(), Dlbtpayment::syncGrants(), Dlbtsignup::creditOnly(), az előfizetés-modell materialiseLimits().

Ismert korlátok

  • A source oszlop a kapuban nem számít: a fizetett forrást vizsgáló PAID_SOURCES és hasPaidFeature() a kódban sehol nincs meghívva.
  • A parent_feature_id hierarchiát sem a canSee, sem a canAction nem használja.
  • A MENU_GROUPS nem ismeri például a rendelési katalógus, a rendelések, a kiegészítő csomagok, a csomagcsaládok, a regisztráció, a teszt-felépítés és a pénztár route-ját; ezeknél a menücsoport-feltétel kimarad.
  • A régi visible oszlopot olvasó isVisibleGrant() nincs meghívva.
Kapcsolódó témák: funkciójog jogosultság előfizetés