Jogosultsági rendszer – Rendszerleírás

A három réteg

1. Core route-jog: az OpenCart saját access/modify listája (oc_user_group.permission JSON) — ez engedi be a felhasználót a route-ra.
2. Funkciójog: a doliBIT saját akciókatalógusa — MINDEN publikus controller-metódus a modell hívása ELŐTT ellenőrzi (dlbtpermission->canAction(route, action)); jog hiányában a metódus el sem jut az adatig (early return / JSON-hiba), a twig a gombot nem rendereli.
3. Tartalmi scope: cég-szintű adatvédelem — a felhasználó KIZÁRÓLAG a scope-jában lévő cégek (és cégcsoportjaik) adatait látja, minden listában, szűrőben, AJAX-végpontban és a front-portálon is. A szuperadmin mindhárom rétegen korlátlan.

Adatmodell

• doliBIT_permission (permission_id, route, action_key) — az akciókatalógus; UNIQUE (route, action_key).
• doliBIT_permission_description — nyelvenkénti megnevezés a Permissions UI-hoz.
• doliBIT_permission_to_user_group — csoport-kiosztás (a feloldás user_group szinten történik).
• doliBIT_permission_scope (user_id|user_group_id, object_type, scope_key, scope_value_int/str) — tartalmi jogok: cég-scope (object_type=company), tárhely-scope (storage_account: engedélyezett account_id-k; storage_create: mappa-létrehozás), jövőben owner_only.

Tartalmi scope — egyetlen forrás

A cégcsoport+cég szűrés KIZÁRÓLAG a company model getCompanyGroupFilter(user_id, group_id, is_super) hívásán át történhet (visszaad: groups, allowed cég-lista vagy null=korlátlan, disabled flag), a jogosult cégeket a getAllowedCompanyIds adja. TILOS ugyanerre másik modulban új SELECT-et írni — ettől volt korábban eltérés (csoport-szivárgás a szűrőkben), 2026-08-02 óta minden modul (invoice, transaction, company, documents, folders, event, topic, front-portál) ugyanezt hívja. Egyetlen jogosult csoport/cég esetén a szűrő auto-kijelöl és disabled; jogosult cég hiányában a szűrő tiltott és a lista üres.

Akciókatalógus (a v8 seed szerint)

Alap akciók modulonként: list / edit / delete / status / debug. Modul-specifikus akciók: finance/invoice: image (számlakép), mol (MOL-letöltés), quick (quick-rögzítés), pdf (PDF-generálás), accounting (könyvelés-tétel); masterdata/apiaccount: list/edit/delete/connect/debug (a route 2026-08-02-től masterdata/googleaccount helyett — kompat-shim és átnevező SQL biztosítja a folytonosságot); company/company: navapi (a NAV API belépő-blokk láthatósága és mentése); masterdata/bankaccount: status (csoportos állapot-váltás); document/document + document/folders: csoportos műveletek. Minden canAction-nal védett route+action KÖTELEZŐEN szerepel a katalógusban és a Permissions UI-n — enélkül nem kiosztható.

Tárhely-scope (storage)

A storage_account scope sorai mondják meg, mely API-fiókok (Google Drive / OneDrive) használhatók a felhasználónak feltöltési célként; üres scope = korlátlan (szuperadmin-viselkedés). A storage_create scope a mappa-létrehozás joga. A Target storage választó nem-szuperadmin esetén tovább szűkül a getAllowedStorageDriveIds szerint az ügyfélcégekhez kötött meghajtókra. Az API-fiók törzsében megadható gyökér-mappa (root_folder_id, OneDrive-nál útvonal) a Graph/Drive hívások szintjén korlátozza a látható mappafát.

UI és karbantartás

A Users → Permissions oldal a bal-menü struktúrája szerint csoportosít (Companies … System sorrend), reszponzív, sortörés-mentes ráccsal; a Users → Scope oldal kezeli a tartalmi és tárhely-jogokat. A katalógust seed-migrációk töltik (permission_catalog_v8.sql, apiaccount_route_rename.sql). Új modul Definition of Done: canAction minden publikus metódusban a modell előtt; content scope a cég-kötésű adaton; route+action a katalógus-seedben; jog-kötött menüpont.

Kapcsolódások

A cron-értesítések címzett-köre is a tartalmi scope-ból oldódik fel (a cégre jogosult felhasználók) — lásd: Cron-motor és ütemezési módszertan – Rendszerleírás. A Dokumentumtár tárhely-választói a storage-scope-ot érvényesítik — lásd: Dokumentumtár modul – Rendszerleírás.