Я разработал довольно стандартную и общую систему разрешений для внутреннего бизнес-приложения.
Есть несколько ролей с наборами разрешений;системный администратор может создавать новые роли и назначать им разрешения;У каждого метода веб-контроллера есть атрибут, который проверяет наличие определенного разрешения.Пока все хорошо.
Но тогда у меня следующий разговор с заказчиком:
Заказчик: «Пожалуйста, сделайте возможным скрыть определенные поля формы в конкретных формах для конкретной роли».
I: «Хорошо, у пользователей этой роли не должно быть разрешений на изменение этих полей, верно? Я также могу добавить проверку прав доступа к методу, который сохраняет данные».
Клиент: «Нет, нет, это не проблема разрешения как таковая, это просто удобство - эта роль не должна работать с этими полями, и мы хотим сделать интерфейс пользователя менее загроможденным. Пользователи этой роли не должныпросматривать эти поля только в этой форме, однако существуют другие формы, в которых можно видеть эти поля вполне нормально. Конечно, позже мы могли бы создать новые роли, которые должны будут видеть эти поля в этой форме, но по умолчанию поля должны бытьскрыто. "
И поэтому система разрешений загромождена" псевдо-разрешениями ", такими как" Смотрите поле X в форме Y ".Они существуют только для удобства пользовательского интерфейса и не имеют ничего общего с авторизацией для выполнения действий с данными.
Полезно ли управлять пользовательским интерфейсом с помощью ролей и разрешений, даже если конкретное разрешение не имеет никакого отношения кделать с авторизацией обработки данных?Есть ли чистое решение, чтобы не загромождать реализацию системы разрешений такими псевдо-разрешениями только для пользовательского интерфейса и при этом предоставлять заказчику детальный контроль для достижения более чистого пользовательского интерфейса для определенных ролей?