Извлечь правила, которые отключают элемент управления

Question

Справочная информация

Еженедельно мы будем заставлять некоторых пользователей звать на помощь, почему вы не можете сделать X в форме Y. Из-за сложных бизнес-правил нам часто приходится самим просматривать код, чтобы понять, почемуэто конкретное действие не доступно в то время.Есть ли проверенные стратегии для борьбы с этим?

Как собрать всю информацию из графического интерфейса пользователя, бизнес-правил и / или безопасности, которая приводит к отключению кнопки?

Пример

пользователь не может удалить измерение из формы обзора измерений, потому что

GUI

• в форме не выбрано измерение.
• в форме выбрано несколько измерений.

Бизнес-правила

• выбранное измерение было использовано в расчете.
• с каким выбранным измерением связано (чтомы называем) productfiche.

Безопасность

• текущий пользователь не является членом группы аналитиков, ответственных за это конкретное измерение.
• текущий пользователь не является аналитиком.

Редактировать

Относительно действительных комментариев о том, что мы уже сделали расчет, чтобы решить,контроль должен быть отключен.

Мы используем ACL для домашнего приготовления для обеспечения безопасности.Это шаги, чтобы решить, должен ли элемент управления быть отключен

• Глобальный ACL извлекается (в настоящее время из базы данных).Если в ACL для свойства измерения присутствует Write ACE, это означает, что текущий пользователь имеет право изменить измерение.
• Измерительный бизнес-объект получает копию этого глобального ACL-списка.Бизнес-объект помещает свои бизнес-правила поверх извлеченного ACL.Если бизнес-правила предписывают, что измерение не должно быть доступно для записи, оно добавляет Deny Write ACE в ACL.
  Обратите внимание, что бизнес-объект может только сделать безопасность более ограничительной.Если глобальная безопасность требует, чтобы это не было сделано, это не может быть сделано.
• Связь с ACL бизнес-объекта и GUI осуществляется через то, что мы называем нашим объектом GuiMap.Этот объект извлекает копию ACL из бизнес-объекта и позволяет разработчику добавлять к нему указатели функций, возвращающие логические значения, для добавления Gui rules поверх списка ACL бизнес-объектов.

Теперь, чтобы определить,кнопка должна быть включена, GuiMap оценивает каждую переданную ей функцию в сочетании с безопасностью, определенной ACL бизнес-объекта, и в крайнем случае с безопасностью пользователя.

• Если у пользователя нет прав, результат всегда отключается.
• В противном случае, если бизнес-правила говорят, что он должен быть отключен, он отключается.
• elseесли какое-либо из правил Gui говорит, что оно должно быть отключено, оно отключено.

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

Прелесть, если вам нравится, заключается в следующем: по мере того, как ACL раздает копии, копии прикрепляются к мастеру и получают уведомление, когда их основной ACL get обновляется.Это позволяет нам

• позволять обновлять каждый элемент управления, если пользователь выходит из системы на любом экране.
• разрешать обновлять каждый элемент управления при изменении бизнес-объекта.

Это работает довольно хорошо для нас, за исключением того, что трудно понять, почему что-то отключено.

Answer 1

Если я вас правильно понимаю, у вас есть две отдельные проблемы:

1) Проверки в каждом слое просто возвращают логическое значение, указывающее, включено / отключено, и не возвращают причину.

Вы должны изменить это так, чтобы каждая проверка также возвращала причину; например вы можете вернуть кортеж (enabled, reason), где access - это логическое значение, имеющееся у вас сейчас, и указать описание причины его отключения (например, в виде строки).

В зависимости от среды, в которой вы работаете, изменение типа возврата всех проверок доступа может оказаться невозможным; если вы хотите избежать этого, вы можете сообщить причину «вне группы», например, спрятать его в глобальную (точнее локальную) переменную, например errno в UNIX или GetLastError в Windows. Это не так уж и элегантно, и многие, конечно, будут осуждены: - (

В качестве альтернативы, вы можете изменить свои проверки, чтобы выдавать исключения (с описательным сообщением) вместо возврата логического значения. Опять же, это будет неодобрительно во многих средах ...

2) Ваш бизнес-уровень добавляет записи в списки контроля доступа объекта. Когда вы позже проверяете доступ, вы знаете, какой записи отказано в доступе, но вы больше не знаете, почему эта запись была добавлена.

Решив это, вы можете добавить поле reason к ACE. Когда бизнес-уровень добавляет ACE, он устанавливает причину для описания причины, по которой в доступе было отказано. Затем проверка контроля доступа считывает причину и передает ее на уровень графического интерфейса, как описано выше.

Answer 2

Ливен, я бы лично порекомендовал вам решение, данное oefe .

.

Однако, так как вы не удовлетворены, я добавляю другой подход ниже. Это будет работать только в том случае, если ваш процесс рендеринга экрана с графическим интерфейсом идемпотентен (то есть не изменит состояния системы и может быть вызван несколько раз без воздействия на систему).

1. Использование шаблона декоратора Создание правила обёртки, которые могут вложить ваши оригинальные бизнес-правила. обертка Правило выполнит оригинальное правило как а также добавить причину, если доступ отказано.
2. Используйте шаблон стратегии , чтобы получить экземпляр правил. В зависимости от параметра, Стратегия должна заключаться в использовании оригинальной бизнес-правила или завернутый бизнес править.
3. На экране клиента при отключении элемент управления нажат, асинхронно вызвать тот же процесс, который был использован для Первоначально построить экран. Однако на этот раз добавьте параметры, т.е. идентификатор элемента управления и индикатор причины , который вы хотите знать причина, почему соответствующий контроль отключено.
4. Когда параметр индикатора причины настоящее время, используйте стратегию, которая использует оберток . Это обертки добавить причины на туз. В конце концов, для данного контролировать, выяснить причину требуемый контрольный идентификатор и верните его.
5. Когда клиент получает причину как асинхронную ответ, отобразите его.

Недостатки:

• Инициирование экрана должно быть идемпотентная
• Больше работы по созданию обёрток для правил
• Больше работы над правилами экземпляр (использование стратегии) ​​
• Если правила не идемпотентны или не могут использовать в обертке, вы будете требуется создать параллельную иерархию правил.

Преимущества:

• Причины не заполняются по умолчанию
• Когда пользователь запрашивает причину, только затем выполняется дополнительная обработка.

.

Обновление:

В качестве альтернативы для грубого, но более упрощенного подхода вы можете постепенно добавлять один модуль за раз, реорганизовывать существующие правила и делать их чувствительными к параметру индикатора id и индикатора причины. Если параметр индикатора причины присутствует, то правила сами должны заполнить причину.

Answer 3

Если это не объяснено в документации и неясно в графическом интерфейсе, я не вижу альтернативы необходимости изучать код. Я делал это тысячу раз, поэтому я действительно заинтересован в любой альтернативе, размещенной здесь:)

Может быть, мы могли бы написать причину в журналы каждый раз, когда кнопка отключена / включена. Например:

• Отключена кнопка A, потому что пользователь делает не имеет привилегии безопасности ABC
• Включена кнопка B, потому что все требуется информация теперь доступна

Answer 4

Я бы всегда визуально отключал элемент управления и давал пользователю знать причину либо по подсказке при наведении курсора, либо по диалоговому окну при нажатии (если ваш графический интерфейс позволяет прослушивать события на отключенных элементах управления).