Ця стаття призначена для Організацій, створених у межах моделі доступу Beta, де адміністратор надавав дозволи кожному Учаснику окремо. Тепер доступ будується на основі Профілів робочих процесів та Ролей облікових записів, а Kraken автоматично переводить вашу Організацію на нову систему.
Перед переходом зверніть увагу на два моменти:
Процес переходу не скасовує жодних прав доступу. Усі дозволи, які мав кожен Учасник, зберігаються.
Ваші існуючі API-ключі не скасовуються і не перевипускаються. Їхні облікові дані, дозволи та прив’язка до облікових записів зберігаються. Змінюється лише те, як ваш код адресує запити та зчитує відповіді.
Вибирайте обліковий запис у кожному запиті
API-ключ Організації охоплює один або кілька Облікових записів і не має значення за замовчуванням, тому в кожному приватному запиті потрібно вказувати, до якого Облікового запису він застосовується. Передавайте account_id як параметр запиту в URL, а не в тілі запиту:
Bash
POST /0/private/AddOrder?account_id=W5PB62NTPNYT6TYHЦе стосується торгівлі, запитів щодо балансу та реєстру, історії ордерів і угод, експорту даних, а також переміщення коштів.
Перед переходом протестуйте кожен шлях виклику в середовищі, відмінному від робочого (non-production), включаючи ті, які, на вашу думку, не повинні були змінитися. Приватний запит без параметра account_id може повернути успішний, але порожній результат замість помилки, що можна легко помилково сприйняти як Обліковий запис без активності.
Зчитуйте нову відповідь щодо виведення коштів
WithdrawFunds повертає approval_request_id разом із refid:
Bash
{
"error": [],
"result": {
"refid": "FTcLNGa-4ZWmo4GCo8wrBNZz5v53v9",
"approval_request_id": "656a021a-1d55-42c9-853a-aea57bf5abd1"
}
}WithdrawStatus ніколи не означає, що запит на виведення не був поданий.Автоматизація, яка вважає refid підтвердженням завершення, звітуватиме про виведення коштів як про завершені, навіть якщо вони все ще перебувають у черзі на схвалення. Див. API-ключі для ознайомлення з повною моделлю.
Після переходу ваша Організація отримає два набори стандартних базових елементів.
Профілі робочих процесів
Профіль робочого процесу визначає, що Учасник може робити в межах кожного регульованого робочого процесу. Кожен Учасник має лише один такий профіль.
Профіль | Що він містить |
|---|---|
Адміністратор | Усі рівні в кожному робочому процесі, включаючи Execute |
Ініціатор | Перегляд та ініціювання в кожному робочому процесі. Не може схвалювати |
Схвалювач | Перегляд та схвалення в кожному робочому процесі. Не може ініціювати |
Аудитор | Перегляд у кожному робочому процесі. Не може виконувати дії |
Менеджер коштів | Перегляд, ініціювання та схвалення для Withdrawal Request та Transfer Request. Перегляд та ініціювання для Manage Addresses |
Ролі облікових записів
Роль облікового запису визначає, що Учасник може робити з вашими Обліковими записами. Стандартні ролі охоплюють усі поточні та майбутні Облікові записи, тому Учасник із роллю «Trade all» може торгувати на Обліковому записі, який ви створите завтра.
| Please provide the JSON batch you would like me to translate. I am ready to process it according to the specified rules. | Що це надає для кожного акаунта |
|---|---|
Читати все | Читати |
Торгувати все | Торгувати |
Кошти: все | Переказ, виведення, розподіл у Earn, скасування розподілу в Earn |
Повний доступ | Усі дозволи для акаунта |
Стандартні профілі та ролі оновлюються синхронно з продуктом: коли додається новий робочий процес, учасники, які їх використовують, автоматично отримують відповідний рівень доступу. Повний опис моделі див. у статті Ролі, профілі та дозволи.
Якщо дозволи учасника не збігаються з жодним стандартним профілем, для нього створюється роль, яка містить точно такі самі дозволи, які він мав раніше. Учасники з ідентичними дозволами використовують одну й ту саму роль, тому у вашій Організації буде значно менше ролей, ніж учасників.
Ці ролі отримують назву з мітки, яку ви вказали поруч із учасником, тому учасник із міткою «Trader» отримує роль з назвою trader. Учасники без мітки отримують роль migrated-role. Кожна з них має значок migrated, що означає, що назва була згенерована автоматично і ви можете змінити її.
Перейменування цих ролей відповідно до того, як ви насправді називаєте цих людей, — це перше, що варто зробити після переходу. Редагування ролі видаляє значок migrated.
Чому ваші учасники зі статусом «Admin» не отримали профіль Admin
Мітка «Admin» у бета-версії дозволяла переглядати, ініціювати та схвалювати запити, але не завершувати власні запити без другого схвалення. Профіль Admin містить таку можливість — це рівень Execute.
Замість того, щоб надавати цей рівень автоматично, учасники зі старою міткою отримали роль beta-admin, яка містить точно ті самі дозволи, що були у них раніше. Ви можете будь-коли змінити їхню роль на Admin одним призначенням.
beta-admin — це одна з ваших власних ролей, тому учасники, які її мають, не будуть автоматично отримувати нові робочі процеси, як це відбувається зі стандартними профілями. Це ще одна причина переглянути ці ролі невдовзі після переходу.
Власник отримує профіль Admin, зберігає всі попередні дозволи та автоматично отримує нові робочі процеси. Власник також має рівень доступу «Читати все», який неможливо видалити.
Якщо ви навмисно обмежили дозволи Власника, це рішення зберігається: Власник отримує роль, яка містить його фактичні дозволи, як і будь-який інший учасник.