08.01 Permission Dictionary

Статус: черновик для обсуждения

1. Назначение документа

Этот документ описывает permission dictionary для MVP.

Permissions нужны, чтобы:

• управлять доступом к Back Office actions;
• разделить platform и merchant capabilities;
• скрыть provider/internal data от merchant users;
• дать merchant admins возможность управлять users внутри своего context;
• сделать все sensitive actions явными и контролируемыми.

2. Основной принцип

Permissions не разделяются отдельно на Platform section и Merchant section.

Одна permission может работать и для platform user, и для merchant user, но scope будет разный.

Пример:

can_view_transactions

Для platform user эта permission может дать доступ к transactions в platform scope.

Для merchant user эта permission дает доступ только к transactions доступных merchants / merchant groups.

Итоговый доступ всегда определяется через:

• user type;
• role;
• permission;
• assignment context;
• merchant access;
• merchant group access;
• entity visibility rules;
• sensitive data rules.

User type является взаимоисключающим:

• platform user не имеет merchant roles/access;
• merchant user не имеет platform roles/access;
• один user account не может объединять оба типа доступа.

3. Naming convention

Permission naming style:

can_action_object

Примеры:

can_view_transactions
can_resend_tx_callback
can_edit_payment_method_routing
can_view_provider_raw_data

Permissions могут быть action/feature-based.

Не все permissions должны быть CRUD-style.

Например, для resend callback нужна отдельная capability:

can_resend_tx_callback

4. Transactions

Permission	Назначение
can_view_transactions	Смотреть transaction list в доступном scope.
can_view_transaction_details	Смотреть transaction details.
can_export_transactions	Экспортировать transactions с учетом visibility/masking.
can_correct_transaction_status	Делать manual status correction.
can_resend_tx_callback	Делать resend merchant callback/webhook по transaction.
can_view_transaction_timeline	Смотреть transaction timeline с учетом visibility level и masking rules.
can_view_provider_raw_data	Смотреть raw provider request/response/callback/error. Только для platform/internal-sensitive access.
can_view_hidden_routing_details	Смотреть hidden/internal routing details. Только для users с sensitive access.

Merchant users не должны видеть provider raw data или hidden routing details без explicit sensitive permission.

Merchant-facing error visibility не требует отдельной permission: merchant видит unified error code + description через transaction permissions.

5. Merchant Webhooks

Permission	Назначение
can_view_webhook_deliveries	Смотреть webhook delivery history.
can_view_webhook_payload	Смотреть webhook payload, который система отправила merchant.
can_view_webhook_response	Смотреть merchant response code/body.
can_resend_webhook	Делать resend webhook из webhook-related UI.

can_resend_tx_callback и can_resend_webhook могут вести к одному backend action, но используются в разных UI contexts:

• transaction actions;
• webhook delivery page/section.

Backend может требовать одну или обе permissions в зависимости от final implementation.

6. Merchants, Merchant Groups, Brands

Permission	Назначение
can_view_merchants	Смотреть merchants.
can_create_merchant	Создавать merchant.
can_edit_merchant	Редактировать merchant.
can_view_merchant_groups	Смотреть merchant groups.
can_create_merchant_group	Создавать merchant group.
can_edit_merchant_group	Редактировать merchant group.
can_view_brands	Смотреть brands.
can_create_brand	Создавать brand.
can_edit_brand	Редактировать brand.

Brand permissions работают в merchant / merchant group context.

7. Users

Permission	Назначение
can_view_users	Смотреть users в доступном scope.
can_create_user	Создавать user.
can_invite_user	Отправлять invite user-у.
can_edit_user	Редактировать user data/status.
can_disable_user	Отключать user.
can_delete_user	Soft-delete user-а.
can_manage_user_merchant_access	Управлять доступом merchant user-а к merchant и назначать role в merchant context.
can_manage_user_merchant_group_access	Управлять доступом merchant user-а к merchant group. Доступно только platform users.
can_terminate_user_sessions	Terminate sessions других users.
can_reset_user_2fa	Reset 2FA setup user-а в доступном scope.

Own profile и own sessions доступны всем authenticated users без отдельной permission.

Merchant users с permission могут управлять доступом других merchant users только в merchant context.

Merchant group access может выдавать только platform user с permission can_manage_user_merchant_group_access.

Merchant roles в MVP не назначаются в merchant group context.

8. Roles And Permissions

Permission	Назначение
can_view_roles	Смотреть roles.
can_create_role	Создавать role.
can_edit_role	Редактировать role and permissions.
can_assign_role	Назначать role user-у в context.
can_view_permissions	Смотреть permission list/dictionary в UI.

Roles и permissions редактируют только platform users с соответствующими permissions.

Merchant admin может назначать merchant roles только внутри своего merchant context, если имеет нужные permissions, но не может менять permissions внутри roles.

Merchant group role assignment в MVP не поддерживается.

9. API Keys

Permission	Назначение
can_view_api_keys	Смотреть API key metadata.
can_create_api_key	Создать merchant API key.
can_rotate_api_key	Запустить API key rotation.
can_revoke_api_key	Revoke API key.

Отдельная permission для sensitive API key metadata не нужна.

Metadata вроде last used at, created by, rotated at видна через:

can_view_api_keys

Secret value не должен быть виден повторно после создания.

10. Audit Logs

Permission	Назначение
can_view_audit_logs	Смотреть audit logs в доступном scope.
can_export_audit_logs	Экспортировать audit logs с учетом visibility и secret data rules.

Audit log visibility всегда учитывает permissions, merchant access, merchant group access and entity visibility rules.

Secret values не хранятся в audit logs и не попадают в export.

11. Legacy Transaction Migration

Permission	Назначение
can_run_legacy_transaction_migration	Запустить временный migration tool для переноса old transactions.

Для migration не нужна отдельная permission:

can_view_migration_reports

Migration report генерируется сразу после запуска.

Migration tool является временным operational functionality:

• его планируется использовать ограниченное время;
• отдельная долговременная report модель не нужна;
• отдельное хранение migration report не требуется;
• отдельный audit log для migration не требуется.

12. Payment Method / MID

Permission	Назначение
can_view_payment_methods	Смотреть Payment Method / MID configurations.
can_create_payment_method	Создавать Payment Method / MID.
can_edit_payment_method	Редактировать basic Payment Method / MID fields.
can_disable_payment_method	Отключать Payment Method / MID.
can_view_payment_method_routing	Смотреть first-level routing blueprint.
can_edit_payment_method_routing	Редактировать first-level routing blueprint.

can_edit_payment_method_routing покрывает изменения MASTER MID GROUP внутри Payment Method / MID routing:

• sequence;
• weight;
• fallback;
• connected MASTER MID.

13. MASTER MID

Permission	Назначение
can_view_master_mid	Смотреть MASTER MID в доступном merchant context.
can_create_master_mid	Создавать MASTER MID.
can_edit_master_mid	Редактировать basic MASTER MID fields.
can_disable_master_mid	Отключать MASTER MID.
can_view_master_mid_routing	Смотреть MASTER MID routing blueprint.
can_edit_master_mid_routing	Редактировать MASTER MID routing blueprint.
can_manage_master_mid_processing_fee	Настраивать processing fee на MASTER MID.

can_edit_master_mid_routing покрывает изменения SUB MID GROUP внутри MASTER MID routing:

• candidates;
• sequence;
• weight;
• fallback.

14. SUB MID

Permission	Назначение
can_view_sub_mid	Смотреть SUB MID в доступном merchant context.
can_create_sub_mid	Создавать SUB MID, если merchant/provider access позволяет.
can_edit_sub_mid	Редактировать SUB MID settings.
can_disable_sub_mid	Отключать SUB MID.
can_view_sub_mid_credentials	Смотреть non-secret config и masked/configured state secret fields у доступного SUB MID.
can_edit_sub_mid_credentials	Редактировать non-secret config и заменять secret values у доступного SUB MID.

Merchant user может видеть non-secret config и masked/configured state secret fields только у merchant-created SUB MID, если имеет provider access, merchant context access and permission.

Platform user с permission может видеть non-secret config и менять secret values любого SUB MID в platform scope.

Secret values SUB MID нельзя повторно открыть после сохранения.

Secret values SUB MID можно только заменить новым введенным значением.

Non-secret config fields SUB MID можно повторно открыть после сохранения.

Изменение SUB MID credentials/config не требует OTP / 2FA confirmation.

15. SUB MID AGGREGATOR

Permission	Назначение
can_view_sub_mid_aggregators	Смотреть SUB MID AGGREGATOR configurations.
can_create_sub_mid_aggregator	Создавать SUB MID AGGREGATOR.
can_edit_sub_mid_aggregator	Редактировать SUB MID AGGREGATOR.
can_disable_sub_mid_aggregator	Отключать SUB MID AGGREGATOR.
can_view_sub_mid_aggregator_credentials	Смотреть non-secret config и masked/configured state secret fields SUB MID AGGREGATOR.
can_edit_sub_mid_aggregator_credentials	Редактировать non-secret config и заменять secret values SUB MID AGGREGATOR.

SUB MID AGGREGATOR является platform-only reusable configuration.

Merchant user не может создавать, редактировать или самостоятельно добавлять SUB MID AGGREGATOR.

Merchant user не видит credentials/config SUB MID AGGREGATOR.

Secret values SUB MID AGGREGATOR нельзя повторно открыть после сохранения.

Secret values SUB MID AGGREGATOR можно только заменить новым введенным значением.

Non-secret config fields SUB MID AGGREGATOR можно повторно открыть после сохранения platform user-ом с permission.

Изменение SUB MID AGGREGATOR credentials/config не требует OTP / 2FA confirmation.

16. Provider Access

Permission	Назначение
can_grant_provider_access_to_merchant	Выдать merchant-у или убрать у merchant-а доступ к конкретному provider.

Provider access выдается platform user-ом merchant-у, а не конкретному user-у.

Доступ выдается отдельно на каждого provider.

Пример:

Merchant A gets access to INTERKASSA.
Merchant A gets access to JETON.

Это не означает доступ ко всем providers сразу.

Если merchant получил access к provider, он видит все provider methods этого provider при создании SUB MID.

Provider access не выдается отдельно на provider method.

Provider access можно revoke.

После revoke существующие SUB MID этого provider остаются active, но merchant users больше не видят их provider-sensitive data и не могут создавать новые SUB MID этого provider.

Provider access grant/revoke должен попадать в audit log.

Отдельная permission для просмотра merchant provider access в MVP не нужна.

17. Velocity Limits

Permission	Назначение
can_view_velocity_limits	Смотреть velocity limits.
can_edit_velocity_limits	Редактировать velocity limits.
can_view_velocity_usage	Смотреть velocity usage/current counters.

Velocity visibility зависит от SUB MID / SUB MID AGGREGATOR visibility.

18. FX And Fees

Permission	Назначение
can_view_fx_fees	Смотреть FX / conversion fee settings and transaction values.
can_edit_fx_fees	Редактировать FX / conversion fee settings.
can_view_processing_fee	Смотреть processing fee.
can_edit_processing_fee	Редактировать processing fee.

Processing fee относится к MASTER MID.

Conversion fee относится к SUB MID / SUB MID AGGREGATOR.

19. Error Details

Отдельная permission для error mapping в MVP не нужна.

Merchant users не видят real provider errors.

Merchant users видят только:

• unified error code;
• human-readable description.

Platform/internal users могут видеть real provider errors через:

can_view_provider_raw_data

20. Monitoring

Back Office permissions для monitoring в MVP не нужны.

Prometheus/Grafana находятся в internal ops scope и не связаны с Back Office permissions.

21. System Settings

System Settings page и permissions не входят в MVP.

Runtime configuration в MVP управляется через environment variables / code-level configuration.

22. Hosted Payment Form Styling

Отдельные permissions для hosted payment form styling в MVP не нужны.

Brand styling customization не входит в MVP.

23. Own Profile And Sessions

Own profile и own sessions доступны всем authenticated users без отдельных permissions.

Все users могут:

• смотреть own profile;
• смотреть own active sessions;
• terminate own session.

Platform admin может terminate sessions других users через:

can_terminate_user_sessions

24. Legacy Transactions

Отдельные permissions для legacy migrated transactions не нужны.

Legacy transactions покрываются:

• can_view_transactions;
• can_view_transaction_details;
• can_export_transactions.

Actions по legacy transactions ограничены read-only behavior, а не отдельными permissions.

25. Acceptance Criteria

Permission Dictionary считается согласованным для MVP, если:

• Permission naming использует стиль can_action_object.
• Permissions context-aware и могут работать для platform/merchant scopes.
• Transaction permissions включают view/details/export/correction/resend/timeline/raw data/hidden routing.
• Webhook permissions включают delivery/payload/response/resend.
• Merchant, merchant group, brand permissions описаны.
• User permissions описаны.
• Role permissions описаны.
• API key permissions описаны.
• Audit log permissions описаны.
• Migration имеет только can_run_legacy_transaction_migration.
• Payment Method / MID permissions включают view/create/edit/disable/view routing/edit routing.
• MASTER MID permissions используют routing, а не blueprint, в permission names.
• MASTER MID GROUP не требует отдельной permission, покрывается can_edit_payment_method_routing.
• SUB MID GROUP не требует отдельной permission, покрывается can_edit_master_mid_routing.
• SUB MID permissions описаны.
• SUB MID AGGREGATOR permissions описаны.
• Provider access permission выдает доступ merchant-у к конкретному provider.
• Velocity permissions описаны.
• FX/Fee permissions описаны.
• Error mapping не требует отдельной permission в MVP.
• Monitoring не требует Back Office permissions в MVP.
• Own profile/sessions доступны без permission.
• Legacy transactions не требуют отдельной permission.

26. Open Questions

Product open questions отсутствуют.

Technical/design follow-up:

1. Определить final machine naming convention.
2. Определить exact permission grouping in UI.
3. Определить default platform Admin role permissions.
4. Определить default merchant admin role permissions.
5. Определить backend authorization policy format.