Roman39Не всегда удается предусмотреть все возможные объекты к которым следует ограничить доступ на этапе проектирования ПО.
Это и понятно, а куда от этого дется-то? Есть ли универсальное средство от всех проблем?
Я думаю нет.
Надо добавить доступ - if AppPolicy.GetDostup(...) {делаем, что-то}
И все. При отладке можно сделать доступ ADMIN - и тогда будет полный доступ. А когда нужно будет делать для группы доступа, тогда и добавляются записи в таблицы. Не вижу трудностей в сопровождении.

Roman39А как лучше описывать в таблице разграничиваемы функции? Надо чтобы и пользователю (администратору) было удобно раздавать привелегии и при разработке чтобы каши не было. Ну скажем для администратора можно ввести описательное поле, чтобы была понятна суть операции. А что лучше выбрать в качестве идентификатора операции? Или другими словами какой строкой удобнее идентифицировать конкретную операцию.
Все зависит от того как вы всю систему построете.
Если у вас есть слой бизнес-логики, то там можно регулировать доступ.
Администратор, например, в объекте "работник" уберет флажок "показывать оклад". И значит во всех формах должны отсутствовать поля с окладами и кнопки для просмотра окладов.
При таком подходе доступ нужно продумывать вместе с проектом.
Хотя никто не мешает рефакторингом заниматься.
Если нет, то тогда придется "регулировать" формы.
Администратору можно будет предоставить древовидную структуру, для простоты настройки.
Например форма, а внутри - список функций либо список имен объектов.

В общем, нет универсального подхода, все затачивается под конкретный проект.
Но лучше продумать и оценить все заранее, иначе могут быть следующие проблемы:
1) слишком сложная система, затрудняющая разработку/сопровождение.
2) слабая система. В результате может возникнуть такая ситуация невозможности реализации разграничения доступа на какие-то операции, без серьезной переделки проекта, в связи с непродуманностью на стадии проектирования.

УнрегистередТакой подход предполагает частую настройку доступа. Если же права настраиваются редко (или никогда), то админу ненадо вмешиваться.
Приведу пример из области медицинских систем. Права на доступ к документам (таблицам/формам) могут меняться и настраиваются админами.
Но в любых документах: группам врачей и медсестер никогда нельзя видеть напр. цены медикаментов, группа медсестер никогда не может делать назначения. И тд.
Это решается при разработке формы.
Почему частую?
Группы доступа - врачь, медсестра. Хранятся в базе. К каждой группе привязаны настройки доступа по поводу цен и возможности назначения, видимости кнопок и.т.д.
Админу нужно подключить нового пользователя - медсестра.
Он для данного пользователя, подключает группу доступа "медсестра" и все. Мелких настроек на кнопки он не делает. Все просто.