Здравствуйте, AndrewVK, Вы писали:
A> Здравствуйте, Cokkab, Вы писали:
A>
C>> Существует событие — нажатие на кнопку.
C>> Это событие должно выполниться если:
C>> 1. Текущему пользователю разрешено это сделать;
C>> 2. Значение комбобокса равно X;
A>
A> Попытка назначать права исходя из пользовательского интерфейса
A> изначально неверный подход. Попытка определять права исходя из
A> вычисления каких то формул как правило неприе6млема из-за слишком низкой
A> производительности.
Почему? В данном случае человек описывает довольно типичный сценарий: есть некий граф состояний, переход по которому может осуществляться несколькими путями, в зависимости от роли пользователя. Например, система отслеживания версий. Есть поле — состояние Change Request. Все могут наблюдать текущее состояние CR, но только некоторые могут его переводить, например, из состояния Submitted в состояние Closed. Я бы в данном случае не привязывался вообще к UI. Надо попытаться определить этот граф, идентифицировать возможные состояния, и одной таблицы должно хватить для описания этой схемы. Что-то типа:
— идентификатор роли (или пользователя, в зависимости от выбранной схемы)
— идентификатор начального состояния.
— идентификатор следующего состояния.
Тогда в диалоге пользователь может изменять значение поля, только если в этой таблице для него есть строка (строки) с текущим состоянием. Причем выбрать он сможет только одно из тех состояний, которые указаны для него в поле "Идентификатор следующего состояния".
-- Всего хорошего!
-- Alex Alexandrov, e-mail: alexandrov_alex@fromru.com
Posted via RSDN NNTP Server 1.7 beta