maytonГрант "на кнопку" никогда не выдаётся. Я сколько работаю - не встречал подобной архитектуры. А вот на формочку - да.
Ну а например кнопка - "показать оклад".
Какому-то пользователю можно на форме нажимать эту кноку, а кому-то нильзя.

Roman39
Вот в этом и вопрос: на что выдавать гранты?
Гранты лучше выдавать на функции, а не на кнопку.
Потому как одна функция может выполнятся с разных мест: с кнопок, пунктов меню и прочее.
Программа смотрит - может ли кнопка выполнить функцию - нет, то disable.
Доступы на функции хранятся в базе в табличном виде.
При загрузке формы происходить анализ и установка доступности элементов для данного пользователя (в самой форме). Для каждой формы нужно писать код, который будет читать данные по доступу для данного ползователя и настраивать форму.
Для работы с администрированием доступа нужно будет написать спец. софт.
Ну для простоты администрирования можно еще создать группы доступа.
Примерно в таком ключе.

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

Можно еще почитать про "Механизмы безопасности в .NET", раз .NET используется.
А в общем случае, я думаю так и решается эта проблема.
У меня одна программа так работает, я, в принципе, доволен.
У меня даже закладки скрываются на tab'ах в зависимости от прав доступа для конкретного пользователя.

mayton
Я-бы постарался сделать две формы: одну с просмотром персонала, и другую с просмотром персонала и окладов.
Кстати, да, это второй подход:
Делаются варианты форм с различным доступом. И просто указывается доступ на форму - есть он или нет.
Есть некоторые трудности, правда, в плане сопровождения - придется сопровождать синхронно две формы с примерно одинаковой математикой, что не очень удобно. Ну и это годно, если небольшое количество объектов администрируется. У меня на одной форме администрируются - 6 закладок (скрыта/открыта) и 7 гридсеток (только чтение/ редактирование). Пришлось сделать разраничение доступа. Тем более, что это не сложно оказалось.

mayton
Я представил себе сколько кода надо написать чтобы реализовать все эти переходники и ужаснулся.
Мало. У меня не очень большой проект.
Там один класс.
Он строит меню по доступам + у него есть функции, которыми можно определить доступ.
Писано, правда на дельфи.
Вот пример установка прав доступа на гридсетку:
У меня общий код есть настроек всех гридсеток таблиц, поэтому этот кусок для каждой гридсетки повторять не надо.
В общем, при желании можно написать удобную систему, главное хорошо продумать.

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

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

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

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