API

Удалить роль

Любую роль, кроме владельца, и только после того, как вы скажете, куда денутся её носители.

DELETEapi.openemail.uk/roles/{id}

Выполняет настоящий запрос в вашем рабочем пространстве, с вашим собственным ключом.

DELETE /roles/{id}

Любую роль, кроме владельца, и только после того, как вы скажете, куда денутся её носители.

Пример

Требует roles:write. reassignTo называет роль, на которую переходят каждый участник и каждый ключ API с этой роли.

curl

curl -X DELETE "$OE/roles/role_2b81de079c1f0a4b7e05d386?reassignTo=role_c40a95f21cc65d31c2a89e07" \  -H "$AUTH"

Ответ

{  "object": "role",  "id": "role_2b81de079c1f0a4b7e05d386",  "deleted": true,  "reassigned": 3,  "keysReassigned": 1}

reassignTo передаётся как ПАРАМЕТР ЗАПРОСА, а не в теле. Тело у DELETE допустимо и широко не поддерживается (несколько рантаймов его отбрасывают, как и ряд прокси), а отброшенный reassignTo неотличим от того, который никогда не отправляли, — а это ровно тот случай, который этот эндпоинт отклоняет, а не пытается угадать.

Он обязателен с того момента, как роль хоть кто-то держит: без него будет role_in_use, 409, с param: "reassignTo", что и есть подсказка к исправлению. Под капотом колонка объявлена как ON DELETE RESTRICT, поэтому нет пути, на котором удаление роли тихо меняло бы то, что кому-то можно делать.

Ключи API перенаправляются, а не остаются сиротами, и это та самая тонкость. Ключ, чья роль исчезла, откатился бы к NULL-потолку, а нулевой потолок ШИРЕ только что удалённой роли, так что удаление ограничивающей роли иначе молча повысило бы в правах каждый ключ, который она сдерживала.

Два счётчика разделены, потому что это две разные вещи, которые нужно пойти и проверить: reassigned — это люди, которые заметят, а keysReassigned — это программы, которые не заметят.

Роль владельца удалить нельзя (role_undeletable, 409), потому что она называет аккаунт, к которому привязано рабочее пространство, а не работу, которую кто-то выполняет. Все остальные роли можно удалить — и созданные при заполнении Admin, Member, Viewer, Developer и Billing в той же мере, что и написанную кем-то вручную: это отправная точка, и рабочему пространству без интеграций незачем хранить строку Developer, от которой ему не позволено избавиться. Проверяйте deletable, прежде чем предлагать кнопку; false отвечает только владелец.

Удаление СОЗДАННОЙ ПРИ ЗАПОЛНЕНИИ роли не окончательно, поэтому не формулируйте диалог так, будто оно окончательно. GET /roles заново создаёт любую отсутствующую шаблонную строку, а удаление не оставляет надгробия, так что следующее чтение списка вернёт Developer под новым id. Прекратить это можно переименованием (переименованная строка сохраняет свой builtin и продолжает конфликтовать с шаблоном) или тем, что имя займёт другая роль, поскольку заполнитель пропускает строку, чьё имя уже занято.