Ця стаття призначена для Організацій, створених за моделлю доступу Beta, де адміністратор надавав дозволи кожному Учаснику індивідуально. Тепер доступ формується на основі Профілів робочих процесів і Ролей облікових записів, а Kraken виконує конвертацію Вашої Організації автоматично.
Перед конвертацією зверніть увагу на два моменти:
account_id, щоб вибрати інший Обліковий запис, і сприймайте успішний виклик виведення як запит, а не як підтвердження переміщення коштів. Докладніше — у розділі «Перегляд поведінки API» нижче.Конвертація не скасовує жодного доступу. Усі дозволи кожного Учасника зберігаються.
Наявні API-ключі не відкликаються і не перевипускаються. Їхні облікові дані, дозволи та привʼязка до Облікових записів зберігаються. Наявні виклики, що не передають account_id, продовжують виконуватись на основному Обліковому записі Організації. Перевірте, як Ваша інтеграція обирає інший Обліковий запис і зчитує відповіді на запити виведення.
Вибір конкретного Облікового запису за потреби
Якщо account_id не вказано, приватний запит виконується на основному Обліковому записі:
Bash
POST /0/private/AddOrderЩоб виконати операцію на конкретному Обліковому записі, передайте account_id як параметр запиту в URL:
Bash
POST /0/private/AddOrder?account_id=W5PB62NTPNYT6TYHПередавайте його в URL, а не в тілі запиту. Явно вказаний account_id має пріоритет над резервним основним обліковим записом. Це не розширює привʼязку ключа до Облікових записів і не змінює його дозволи.
Ознайомтеся з новою відповіддю на запит виведення
WithdrawFunds повертає approval_request_id разом із refid:
Bash
{
"error": [],
"result": {
"refid": "FTcLNGa-4ZWmo4GCo8wrBNZz5v53v9",
"approval_request_id": "656a021a-1d55-42c9-853a-aea57bf5abd1"
}
}WithdrawStatus не означає, що виведення не подавалося.Автоматизація, яка сприймає refid як підтвердження завершення, відображатиме виведення як закриті, поки вони ще перебувають у черзі на схвалення. Повну модель описано в розділі Ключі API.
Після конвертації Ваша Організація отримує два набори стандартних будівельних блоків.
Workflow Profiles
Workflow Profile визначає, що Учасник може робити в кожному керованому робочому процесі. Кожен Учасник має рівно один профіль.
Профіль | Що включає |
|---|---|
Адміністратор | Усі рівні в кожному робочому процесі, включно з Execute |
Ініціатор | Перегляд та ініціювання в кожному робочому процесі. Не може схвалювати |
Approver | Перегляд та схвалення в кожному робочому процесі. Не може ініціювати |
Auditor | Перегляд у кожному робочому процесі. Не може діяти |
Менеджер коштів | Перегляд, ініціювання та схвалення в запитах на виведення та переказ. Перегляд та ініціювання в розділі «Керування адресами» |
Ролі облікових записів
Роль облікового запису визначає, що Учасник може робити з Вашими обліковими записами. Стандартні ролі поширюються на всі поточні та майбутні облікові записи — Учасник із роллю «Торгувати всім» зможе торгувати на обліковому записі, який Ви створите завтра.
Роль | Що надається для кожного облікового запису |
|---|---|
Читати все | Прочитайте |
Торгувати всім | Торгівля |
Усі кошти | Переказ, виведення, Earn Allocate, Earn Deallocate |
Повний доступ | Усі дозволи облікового запису |
Стандартні профілі та ролі розвиваються разом із продуктом: щойно з'являється новий робочий процес, Учасники з відповідним профілем автоматично отримують потрібний рівень доступу. Повну модель описано в розділі Ролі, профілі та дозволи.
Якщо дозволи Учасника не відповідають жодному стандартному профілю, його переводять на роль із тим самим набором дозволів, який він мав. Учасники з однаковими дозволами отримують спільну роль, тож Ваша Організація матиме значно менше ролей, ніж Учасників.
Назви цих ролей формуються з позначок, які Ви вказували поруч із Учасником: наприклад, Учасник із позначкою «Trader» отримує роль trader. Учасники без позначки отримують роль migrated-role. Кожна така роль містить позначку migrated, яка означає, що назва згенерована автоматично та може бути змінена.
Найкраще перше завдання після конвертації — перейменувати ці ролі відповідно до того, як Ви насправді називаєте цих людей. Редагування ролі знімає позначку migrated.
Чому Ваші Учасники з роллю «Admin» не перебувають у профілі Admin
Позначка «Admin» у бета-версії дозволяла переглядати, ініціювати та схвалювати запити, але не завершувати власні запити без другого схвалення. Профіль Admin включає цю можливість — рівень Execute.
Щоб не надавати цей рівень автоматично, Учасників зі старою позначкою призначено на роль beta-admin, яка містить саме ті дозволи, що вони вже мали. Перевести їх до Admin можна в будь-який момент — це одне призначення.
beta-admin — це одна з Ваших власних ролей, тому учасники, які її мають, не отримуватимуть нові робочі процеси автоматично, як це відбувається зі стандартними профілями. Це ще одна причина переглянути ці ролі невдовзі після конвертації.
Власника призначають на профіль Admin: він зберігає всі наявні права й автоматично отримує нові робочі процеси. Власник також має роль Read all, яку не можна видалити.
Якщо Ви навмисно обмежили права Власника, це рішення зберігається: Власника конвертують у роль із його фактичними правами — як і будь-якого іншого учасника.