Հարթակի կառավարում

Պարզ ասած՝ սա ամբողջ հարթակի կառավարման սենյակն է, ոչ թե որևէ մեկ կազմակերպության — ստորև վեց էջերը (Organizations, Users, Products, Platform Roles, Staff, Audit Log) թույլ են տալիս P4P-ի սեփական թիմին կառավարել հարթակն օգտագործող յուրաքանչյուր ընկերություն, ոչ միայն իրենը։ Սա առանձին տարածք է «Workspace» էջերից, որոնք տեսնում է կազմակերպության սովորական անդամը։

Ամեն ինչ /platform/*-ի տակ։ Հասանելի է /dashboard-ի Platform Administration մուտքի կետից, տեսանելի ցանկացածին, ով ունի ցանկացածPlatformRole (middleware/platform-access.ts), ոչ միայն SUPER_ADMIN-ը — առանձին բաժինների հասանելիությունն այնուհետև փակված է ըստ իրավունքի, read/manage-ի հետևողական բաժանմամբ ողջ մոդուլում (դիտումը առանց :manage իրավունքի թույլատրված է. փոփոխող գործողությունը թաքցված է կամ արգելափակված)։

Բոլոր կոնտրոլերները այստեղ գտնվում են @UseGuards(PlatformRoleGuard)-ի հետևում կոնտրոլերի մակարդակում (ինքնաբավ, առանց TenantGuard-ի հերթականությունից կախվածության — ի տարբերություն կազմակերպության մակարդակի PermissionsGuard-ի, տես IAM)։ SUPER_ADMIN-ը անվերապահորեն շրջանցում է PlatformRoleGuard-ը։

Ինչպես անել...

Խմբավորված է նույն կերպ, ինչ տեխնիկական բաժինները ստորև — յուրաքանչյուր էջի օգնության պատկերակը տանում է հենց իր խումբը, ոչ թե այս ամբողջ ցանկը։

Կազմակերպություններ

Ստեղծել կազմակերպություն հարթակի կողմից — «Organizations» → Նոր աշխատանքային տիրույթ → Անուն/տիրույթի URL/Տեսակ → Ստեղծել։ Տես դաշտերի ուղեցույցը ստորև։

Վերցնել կառավարումը կանգնած կազմակերպության — բացիր կազմակերպությունը → Դառնալ սեփականատեր → նշիր Պատճառը → Շարունակել → հաստատման համար մուտքագրիր տիրույթի անունը։ Միայն SUPER_ADMIN։ Տես դաշտերի ուղեցույցը ստորև։

Տալ կամ հետ վերցնել կազմակերպության հասանելիությունը մի արտադրանքի — բացիր կազմակերպությունը → դրա Products բաժինը → Ակտիվացնել/Ապաակտիվացնել տվյալ արտադրանքը։ (Ինքը «Products» էջը խմբագրում է միայն կատալոգը՝ անուն/նկարագրություն/ակտիվություն, ոչ թե ով ինչին է բաժանորդագրված)։

Ստեղծել կազմակերպություն — դաշտերի ուղեցույց

• Անուն (պարտադիր) — 2–100 նիշ։
• Տիրույթի URL (պարտադիր) — 2–50 նիշ, միայն փոքրատառ լատինատառեր, թվեր և գծիկներ։ Ինքնաբերաբար լրացվում է Անունից, մուտքագրման ընթացքում (օրինակ՝ «Acme Corp» → acme-corp) — սկսիր ինքդ խմբագրել այն, և այս ինքնալրացումը մշտապես կանգնում է այս երկխոսության մնացած ընթացքի համար, նույնիսկ եթե հետո նորից փոխես Անունը։ Պետք է լինի եզակի ամբողջ հարթակում; զբաղված արժեքը բռնվում է միայն ուղարկելիս, ոչ մուտքագրման ընթացքում։
• Տեսակ — Company / Individual / Agency / Service provider / Platform / Personal։ Միայն Personal կազմակերպություններն են ստեղծվում արդեն Active; ցանկացած այլ տեսակ սկսվում է Pending-ով (կարգավիճակների նշանակությունները տես կազմակերպության սեփական մանրամասների էջում)։

Դառնալ սեփականատեր — դաշտերի ուղեցույց

Այս կոճակը երևում է միայն նրա կողքին, ով հենց հիմա ունի OWNER դերը, և միայն այն SUPER_ADMIN-ի համար, ով ինքը այդ սեփականատերը չէ։ Այն թույլ չի տալիս սեփականությունը հանձնել ընտրված անդամին — դրա վրա կտտոցը միշտ դարձնում է նոր սեփականատեր հենց քեզ, սեղմող ադմինիստրատորին (անհրաժեշտության դեպքում նախ միացնելով քեզ կազմակերպությանը, եթե արդեն անդամ չես); նախկին սեփականատերն իջեցվում է սովորական MEMBER-ի, ոչ հեռացվում։

• Պատճառ (1-ին քայլ, ոչ պարտադիր) — ազատ տեքստ, զուտ գրառում նրա համար, ով հետո կարդում է աուդիտի մատյանը; երկարությունը ոչինչ չի ստուգում, և պարտադիր չէ լրացնել։
• Հաստատման տեքստ (2-րդ քայլ, պարտադիր) — պետք է մուտքագրես կազմակերպության ճշգրիտ Անունը (մեծատառ/փոքրատառի և եզրերի բացատների նկատառմամբ), նախքան վերջնական Դառնալ սեփականատեր կոճակն այլևս ապաակտիվ չլինի։ Մասնակի համընկնման հուշում չկա — մեկ նիշով սխալվես, և կոճակը պարզապես կմնա ապաակտիվ՝ առանց բացատրելու, թե ինչու։

Օգտատերեր

Ջնջել օգտատիրոջ հաշիվը — «Users» → տողը → Ջնջել → հաստատել։

Հեռացնել ինչ-որ մեկին հարթակի անձնակազմից — բացիր օգտատիրոջը → Հեռացնել թիմից։ Փակում է նրա անձնակազմի անդամակցությունը և բոլոր հարթակային դերերը, բայց չի ջնջում հենց հաշիվը։

Տալ ինչ-որ մեկին հարթակային դեր կամ դարձնել հարթակի նոր սեփականատեր — բացիր օգտատիրոջը → Հարթակի դերեր → նշիր դերերը → Պահպանել դերերը։ Հենց սերմային Owner/SUPER_ADMIN դերի փոխանցումը առանձին կոճակ է նույն էջում՝ Փոխանցել սեփականությունը այս մարդուն։

Ուղարկել աշխատակցին արձակուրդ կամ վերադարձնել այնտեղից — այս գործողությունը այստեղ ընդհանրապես չկա; դա «⋯» մենյուն է նրա պրոֆիլի վրա Staffing → Աշխատակիցներ-ում, թեև այն կանչում է հենց այս մոդուլի backend route-երը։

Հրավերներ հարթակի անձնակազմ

Հրավիրել ինչ-որ մեկին P4P-ի ներքին թիմ — «Staff» → Հրավիրել հարթակի անձնակազմ → Email, ցանկության դեպքում նախապես նշիր Հարթակի դերեր → Ուղարկել հրավեր։ Տես դաշտերի ուղեցույցը ստորև։

Հրավիրել հարթակի անձնակազմ — դաշտերի ուղեցույց

Այս գործողությունը տեսնում է միայն SUPER_ADMIN-ը կամ P4P Owner-ը — այն ընդհանրապես չի փոխանցվում որևէ սովորական իրավունքով, ի տարբերություն այս մոդուլի հրավերի/կառավարման մյուս գործողությունների մեծ մասի։

• Email (պարտադիր) — միակ իրական ստուգումը «ոչ դատարկ» է; հաճախորդի կողմից ձևաչափի ստուգում ընդհանրապես չկա (ակնհայտորեն սխալ հասցեն բռնվում է միայն իրական ուղարկելիս, սերվերում)։ Հասցե, որն արդեն հարթակի անձնակազմում է, կամ արդեն ունի սպասող հրավեր, նույնպես բռնվում է միայն ուղարկելիս։
• Հարթակի դերեր (ոչ պարտադիր, չեքբոքսեր) — բոլորը դատարկ թողնելը լիովին նորմալ է. հրավիրվածը միևնույն է կստանա բազային «P4P Member» դերը, ոչ թե ամբողջովին առանց հասանելիության կմնա, ուստի սա նախապես լրացուցիչ դերեր նշանակելու միջոց է, ոչ պարտադիր քայլ։ SUPER_ADMIN-ը և Owner-ը երբեք չեն երևում այս ցանկում — դրանք հրավերով հնարավոր չէ տալ, միայն «Դառնալ սեփականատեր»-ի կամ օգտատիրոջ էջից ուղղակի դերի փոխանցման միջոցով։
• Ուղարկել հրավեր-ը սահմանափակված է րոպեում 3 ուղարկումով — գերազանցելիս ցույց է տալիս առանձին «չափազանց շատ հարցումներ» հաղորդագրություն և կարճ ժամանակով ապաակտիվացնում կոճակը՝ տեսանելի հետհաշվարկով, ոչ թե սովորական ընդհանուր սխալով։

Ապրանքներ և բաժանորդագրություններ

Խմբագրել, ինչպես է արտադրանքը երևում կատալոգում — «Products» → տողի ⋯ → Խմբագրել → Անուն/Նկարագրություն → Պահպանել փոփոխությունները։ Արտադրանքի ամբողջ հարթակով միացում/անջատումը առանձին գործողություն է նույն մենյուից; կոնկրետ կազմակերպության հասանելիության տրամադրումը/հետ վերցնելը արվում է հենց այդ կազմակերպության էջից — տես Կազմակերպություններ վերևում։ Տես դաշտերի ուղեցույցը ստորև։

Խմբագրել արտադրանք — դաշտերի ուղեցույց

• Անուն (պարտադիր) — 2–100 նիշ։
• Նկարագրություն (ոչ պարտադիր) — մինչև 500 նիշ։
• Այստեղ ուրիշ ոչինչ չի խմբագրվում — արտադրանքի Կոդը (իր կայուն ներքին նույնականացուցիչը) և ինքն էության գոյությունը սահմանվում են մեկ անգամ, կոդում, երբ համապատասխան հավելվածն իրապես կառուցվում է; այս երկխոսությունը միայն այն է փոխում, թե ինչպես է արտադրանքը նկարագրված կատալոգում։
• Ակտիվացնել/ապաակտիվացնել (ամբողջ հարթակով) այս երկխոսության մաս չէ — դա տողի սեփական անջատիչ գործողությունն է, հետադարձելի, առանց հաստատման։ Արտադրանքն այստեղ անջատելը միանգամից թաքցնում է այն բոլոր կազմակերպությունների համար, անկախ նրանց յուրաքանչյուրի բաժանորդագրության կարգավիճակից։

Դերեր

Ստեղծել սեփական հարթակային դեր — «Roles» → Ստեղծել դեր → անվանիր, ընտրիր իրավունքներ → պահպանիր։ Տես դաշտերի ուղեցույցը ստորև։

Խմբագրել, կրկնօրինակել կամ ջնջել դերը — դերի ⋯ → Խմբագրել, Կրկնօրինակել կամ Ջնջել։ Օգտատիրոջը դեր նշանակելը/հեռացնելը կատարվում է հենց օգտատիրոջ էջից — տես Օգտատերեր վերևում։ Նույն դաշտերի ուղեցույցը ստորև Խմբագրելու համար; Կրկնօրինակել-ը նախապես լրացնում է նույն ձևը գոյություն ունեցող դերի իրավունքներով, անվանելով «Կրկնօրինակ ⟨օրիգինալ⟩» — ոչինչ չի պահպանվում, մինչև իրապես ուղարկես ձևը։

Ստեղծել/խմբագրել հարթակային դեր — դաշտերի ուղեցույց

5 սերմային համակարգային դերերը (օրինակ՝ SUPER_ADMIN) երևում են նույն ցանկում, բայց չեն կարող վերանվանվել — նրանց Անուն դաշտն արգելափակված է; Նկարագրություն-ը և Իրավունքներ-ը մնում են ամբողջովին խմբագրելի, և ջնջել դրանք երբեք հնարավոր չէ (միայն իրական պատվերով ստեղծված դերերը)։

• Անուն (պարտադիր) — պետք է լինի եզակի բոլոր չջնջված հարթակային դերերի մեջ։ Ինքը երկխոսությունը լրացուցիչ մերժում է 2 նիշից պակասը, թեև միայն backend-ը կընդուներ մեկ նիշն էլ — գործնականում այս տարբերությունը երբեք չես տեսնի, քանի որ հաճախորդն արգելափակում է առաջինը։ Մինչև 100 նիշ։
• Նկարագրություն (ոչ պարտադիր) — մինչև 500 նիշ։
• Իրավունքներ (չեքբոքսեր, խմբավորված ըստ տիրույթի — Organizations/Users/Roles և այլն) — նվազագույն չկա; ոչ մի նշված իրավունք չունեցող դերը վավեր է և պարզապես ոչինչ չի տալիս։
• Պահպանել/Ստեղծել-ը ակտիվանում է միայն երբ բեռնվածից իրապես ինչ-որ բան փոխվել է — ստեղծելիս սա նշանակում է առնվազն մեկ դաշտի դիպչել դատարկից; խմբագրելիս՝ դերի ընթացիկ անվան, նկարագրության կամ իրավունքների հավաքածուի իրական փոփոխություն, ոչ միայն նույն արժեքների կրկին բացում ու ուղարկում։

Աուդիտի մատյան

Կարգավորելու բան չկա — դա միայն դիտման համար է։ Ֆիլտրիր ըստ գործող անձի/գործողության/ժամանակահատվածի հենց էջում; տես Աուդիտի մատյան ստորև, թե կոնկրետ ինչ է գրանցվում և ինչու է դա առանձին սովորական ադմինիստրատիվ աշխատանքից։

Կազմակերպություններ (/platform/organizations, /platform/organizations/[id])

Պարզ ասած՝ հարթակն օգտագործող յուրաքանչյուր ընկերություն/գործակալություն/անհատ, որոնելի և կառավարելի մեկ ցանկից։ Ներառում է վթարային «վերցնել սեփականությունը» գործողություն այն դեպքի համար, երբ կազմակերպության իրական սեփականատերը անհասանելի է։

admin-organizations.controller.ts, տեղադրված է admin/organizations-ի վրա։

• Ցանկ / մանրամասներ / անդամներ (GET) — platform:organizations:read։
• Արխիվացված կազմակերպության վերականգնում (POST :orgId/restore, փոխադրում է ARCHIVED → ACTIVE, գրանցվում է որպես org.restored) — հաստատված է (2026-08-04, որոնում apps/portal-ում). frontend մուտքի կետ չկա։ Միակ «restore» UI-ն, որը ընդհանրապես գոյություն ունի պորտալում, կապ չունեցող Shared Documents ֆունկցիա է (փափուկ ջնջված ֆայլի վերականգնում աղբարկղից, POST /organizations/{id}/files/{fileId}/restore) — չշփոթել այս երկուսը։ Քանի որ արխիվացումն էլ UI չունի, կազմակերպությունը, որը դառնում է ARCHIVED, այսօր UI ուղի չունի հետ՝ ACTIVE վերադառնալու համար — միայն API-ով երկու ուղղություններով էլ։
• Force owner transfer (POST :orgId/force-owner-transfer, «Take ownership» մանրամասների էջում) — SuperAdminGuard, ոչ թե ընդհանուր :manage իրավունքը։ Սա հստակորեն «SUPER_ADMIN վերականգնման ուղին» է (ըստ կոդի մեկնաբանության) այն դեպքի համար, երբ կազմակերպությունը կանգնած է առանց հասանելի OWNER-ի — platform:organizations:manage ունեցողը, ով SUPER_ADMIN չէ, չի կարող օգտագործել այն։

«New workspace» պատուհանը ցանկի էջում ստեղծում է կազմակերպություն ուղղակիորեն հարթակի կողմից (նույն POST /organizations-ը, ինչ ինքնուրույն ստեղծման դեպքում — տես IAM); նրա կոճակը փակված է :manage իրավունքով, թեև հենց էջը պահանջում է միայն :read։

Ուղղված է, 2026-08-04. այս պատուհանը նախկինում փլուզվում էր 500-ով յուրաքանչյուր ուղարկման ժամանակ — կազմակերպությունը իրականում ստեղծվում էր տվյալների բազայում (գործարքը կատարվում է HTTP պատասխանը կառուցվելուց առաջ), բայց OrganizationsService.create()-ը վերադարձնում էր Prisma-ի հում տողը՝ OrganizationDto-ի փոխարեն, և Organization.storageQuotaBytes/storageUsedBytes-ը (BigInt սյուներ, ավելացված docs/storage/ADR-001-file-storage.md-ի համար) փլուզում են JSON.stringify-ը — այնպես որ ադմինը տեսնում էր սխալ և ոչ մի կերպ չգիտեր, որ աշխատավայրը գոյություն ունի։ getById()-ը արդեն խուսափում էր սրանից՝ ձեռքով ձևավորելով վերադարձվող արժեքը. հիմա create()-ն էլ նույնն է անում։ Հայտնաբերվել է scripts/e2e/menu/platform-admin.mjs-ի միջոցով, որը իրապես գործարկում է այս պատուհանը յուրաքանչյուր անգամ։

Օգտատերեր (/platform/users, /platform/users/[id])

Պարզ ասած՝ P4P հաշիվ ունեցող յուրաքանչյուր մարդ, բոլոր կազմակերպություններում։ Այսօր ինտերֆեյսը թույլ է տալիս միայն ամբողջովին ջնջել հաշիվը — ժամանակավոր կասեցում/արգելափակում պետք է անել ուղղակի API-ի միջոցով (կոճակ դեռ չկա)։

admin-users.controller.ts, տեղադրված է admin/users-ի վրա։

• Ցանկ / platform-staff ցանկ / platform-staff-invitations ցանկ / մանրամասներ (GET) — platform:users:read։
• Օգտատիրոջ հաշվի ջնջում (DELETE :id) — platform:users:manage, միակ հաշվի կարգավիճակի գործողությունը, որը իրապես կա այս էջի UI-ում (տողի գործողություն /platform/users-ում)։
• Suspend / activate / lock / unlock (POST :id/suspend|activate|lock|unlock) — հաստատված է (2026-08-04, որոնում apps/portal-ում). frontend մուտքի կետ չկա այս չորսից ոչ մեկի համար, չնայած որ բոլոր չորսը լիովին իրականացված են և փակված իրավունքով սերվերում։ Եթե հիմա հաշիվը պետք է կասեցնել կամ ապաարգելափակել, դա ուղղակի API-կանչ է, կոճակ չկա։
• Impersonate — «Impersonate» գործողություն այս էջում գոյություն չունի։ Հաստատված է 2026-08-04-ին. Impersonation-ը ամբողջությամբ backend-ային է (POST /auth/impersonate, միայն SUPER_ADMIN) — այս էջում դրան կապակցված կոճակ չկա, թեև սա բնական տեղն է դրա համար։
• Հեռացնել platform staff-ից (DELETE :id/platform-staff) — platform:users:manage։ Փակում է մարդու PlatformStaffMembership-ը և բոլոր PlatformRole նշանակումները. տարբերվում է նրա User հաշիվն ամբողջությամբ կասեցնելուց։
• Leave / return from leave (POST :id/leave, POST :id/return-from-leave) — platform:users:manage։ Ներքին անձնակազմի կարգավիճակ (արձակուրդում/ակտիվ), ոչ թե հաշվի մակարդակի կասեցում — ազդում է Staffing մոդուլում առաջադրանքի/նախագծի նշանակման հասանելիության վրա, ոչ թե մուտք գործելու հնարավորության։

Հրավերներ հարթակի թիմ (/platform-staff-invitations/[token])

Պարզ ասած՝ ինչպես է ինչ-որ մեկը միանում P4P-ի սեփական ներքին թիմին (ի տարբերություն հաճախորդ կազմակերպության անդամ լինելու)։ Ուղարկվում է /platform/staff-ից — առանձին հոսք ընկերության աշխատավայր ինչ-որ մեկին հրավիրելուց։

platform-staff-invitations.controller.ts։ Հրավերի ուղարկումը (POST /platform-staff-invitations) փակված է SuperAdminOrOwnerGuard-ով — ոչ նույնը, ինչ SuperAdminGuard-ը, որն օգտագործվում է impersonation-ի և force-owner-transfer-ի համար։ Այն թույլատրում է SUPER_ADMIN-ին կամ ցանկացածին, ով ունի P4P Owner հարթակային դերը, միտումնավոր. ինչ-որ մեկին հարթակի թիմ հրավիրելը սովորական անձնակազմի աշխատանք է, որը ընկերության Owner-ը պետք է կարողանա անել ուղղակիորեն, ի տարբերություն անվտանգության վերականգնման գործողությունների, որոնք մնում են միայն SUPER_ADMIN-ի համար։ Հրավերը երբեք չի կարող կրել SUPER_ADMIN դերի տրամադրում (ստուգվում է սերվերում, նույնիսկ եթե ուղարկումն արդեն փակված է)։ Ընդունումը (GET/POST :token[/accept], հանրային) ստեղծում է PlatformStaffMembership գրառում — նախապայման ցանկացած PlatformRole ունենալու համար (տես Բառարան)։

Ապրանքներ և բաժանորդագրություններ (/platform/products)

Պարզ ասած՝ ապրանքների կատալոգը, որոնց կարող են բաժանորդագրվել կազմակերպությունները, և ով ինչին է բաժանորդագրված։ Հենց ապրանքներն ավելացնում են ինժեներները, ոչ թե այս էջից — այս էջը միայն խմբագրում է, թե ինչպես են գոյություն ունեցող ապրանքները երևում, և տալիս/չեղարկում է կազմակերպության հասանելիությունը դրանց։

admin-products.controller.ts, տեղադրված է admin-ի վրա (routes. products, products/:productId, organizations/:orgId/subscriptions, subscriptions/:subscriptionId)։

• Ապրանքների կատալոգի ցանկ — platform:products:read; ստեղծում/խմբագրում/ ապաակտիվացում — platform:products:manage։ Էջի խմբագրման/ակտիվացման ցանկը տեսանելի է :read-ով, բայց օգտագործելի է միայն :manage-ով։
• Կազմակերպության բաժանորդագրություններ — ցանկը պահանջում է platform:subscriptions:read, տրամադրում/չեղարկում — platform:subscriptions:manage։ Ինքնուրույն բաժանորդագրման հոսք այսօր չկա — կազմակերպությունը չի կարող ինքն իրեն բաժանորդագրել ապրանքին. դա անում է հարթակի ադմինը։

Դերեր (/platform/roles)

Պարզ ասած՝ նույն գաղափարը, ինչ կազմակերպության Roles-ը (IAM), բայց P4P-ի սեփական ներքին թիմի համար, ոչ թե հաճախորդի — ամբողջովին առանձին դերերի և իրավունքների հավաքածու, երբեք չի խառնվում կազմակերպության հետ։

platform-roles.controller.ts, տեղադրված է admin/platform-roles-ի վրա։ Նույն ձևը, ինչ կազմակերպության մակարդակի Roles էջինը (IAM), բայց PlatformRole/PlatformPermission-ի համար՝ Role/Permission-ի փոխարեն — կառուցվածքով առանձին աղյուսակների զույգ, երբեք չի բաժանվում կազմակերպության RBAC-ի հետ։

• Դերերի ցանկ + իրավունքների կատալոգի ցանկ — platform:roles:read։
• Սերմանված SUPER_ADMIN/սեփականատիրոջ համարժեք դերի փոխանցում (PATCH owner/transfer) — միտումնավոր առանց@RequirePlatformPermission decorator-ի (տես կոդի մեկնաբանությունը 49-րդ տողում). PlatformRoleGuard-ի սեփական տրամաբանությունն այս route-ի համար ապահովում է ինչ-որ բան ավելի խիստ, քան կարող է արտահայտել իրավունքների համակարգը։ Մի ենթադրիր, թե «decorator չկա» նշանակում է «պաշտպանված չէ»։
• Հատուկ platform դերի ստեղծում / խմբագրում / ջնջում, օգտատիրոջը դեր նշանակում/հանում, դերի իրավունքի ավելացում/հեռացում — բոլորը պահանջում են platform:roles:manage։ Ինչպես նկարագրված է Հարթակի կառավարում → Օգտատերեր-ի կապակցված կատալոգի նշումներում. platform:roles:manage ունեցողը դեռ կարող է ուղղակիորեն տալ SUPER_ADMIN արդեն ակտիվ platform-staff անդամին POST :roleId/users/:userId-ի միջոցով՝ առանց լրացուցիչ պաշտպանության — հայտնի, այս պահին ընդունված բաց (տես docs/iam/PERMISSIONS_CATALOG.md, «Still open»)։

Սերմանված դերեր. SUPER_ADMIN (համակարգային, ամբողջական շրջանցում), P4P Owner և P4P Super Admin (բացահայտորեն ստանում են ամբողջ իրավունքների կատալոգը, UI-ում ցուցադրելու նպատակով — տես Բառարան), P4P Admin (ընտրված ենթաբազմություն, չի ներառում platform:roles:manage), P4P Member (կանխադրված տրամադրում նոր platform staff-ի համար, ներառում է platform:staffing:manage_own)։

Audit log (/platform/audit)

Պարզ ասած՝ միայն կարդալու դիտիչ նույն հարթակային պատմության համար, որը նկարագրված է IAM → Audit log-ում։ Միտումնավոր պահվում է առանձին «P4P Admin»-ից, ամենօրյա ադմինի դերից — բոլորի ակտիվության պատմությունը կարդալը համարվում է ավելի զգայուն, քան սովորական ադմինական աշխատանքը։

admin-audit.controller.ts, տեղադրված է admin/audit-log-ի վրա, platform:audit:read։ Միայն կարդալու դիտում միայն ավելացվող AuditLog-ի վրա (գրանցվում է ամբողջ հարթակից, ոչ միայն այս մոդուլից — տես IAM → Audit log)։ Միտումնավոր բացառված է հարմարավետ P4P Admin դերից — «ով է հսկում հսկողներին» ավելի նեղ է, քան ընդհանուր ադմինական աշխատանքը, նույն տրամաբանությունը, որ platform:roles:manage-ը պահում է այդ դերից դուրս։

Այս մոդուլի թեստավորում

scripts/e2e/menu/platform-admin.mjs-ը (10 ստուգում) գործարկում է այս մոդուլի հիմնական հոսքերը սկզբից մինչև վերջ և սահմանում lastVerified-ը վերևում։ Ավտոմատացմամբ չծածկված, դեռ արժե ձեռքով ստուգել — տես docs/MANUAL_TESTING.md. read/manage իրավունքով փակում յուրաքանչյուր էջի փոփոխող կառավարիչների վրա, SUPER_ADMIN դերի արգելափակում staff հրավերում, ապրանքի բաժանորդագրության տրամադրում/չեղարկում, platform դերերի սեփականատիրոջ փոխանցման ուղին, և platform:audit:read-ի փակումը հենց Audit Log էջում։