## Нужно сделать

* Описания разделов API.
* Конструирование пользовательских ролей из разрешений.
* Возможность редактировать администраторами user email сотрудников.

## Открытые вопросы

1. Если у меня как у сотрудника нет прав на просмотр сотрудников, могу ли я видеть идентификатор владельца?

1. Идентификатор сотрудника **равен** идентификатору пользователя, это ок?

    В такой схеме есть небольшие утечки данных, вроде той, когда я как администратор могу понять, что пользователь состоит в тех же организациях, что и я. Непонятно, насколько это критично.

1. Если мы научимся 🌚 удалять магазины, как следить за консистентностью скоупов?

1. Ради простоты мы можем приравнять отзыв, принятие и протухание приглашения к его удалению, а по факту отзыва и принятия просто рассылать письма администраторам. Это избавит нас от необходимости держать все существовавшие когда-либо пришлашения в базе, и следить только за списком активных приглашений. Однако это может быть не очень дружественно к пользователям. Можем ли мы себе позволить это упрощение?