Классы Users and Privilege

Классы Users and Privilege образуют пару и имеют свойства 'Список привилегий' и 'Назначенные пользователи'. Добавив к этим отчетам одну колонку Связать (combo) можно просто управлять привилегиями через эти отчеты, а не просто глазеть :) Предлагаю модифицировать.

Forums: 

Не понял, как эти очеты будут

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

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

Изображение пользователя ipanshin.

речь идет о дополн

речь идет о дополнении или удалении из списка, то комбо не нужен,

Твоя точка зрения тоже правомерна. Я это не отрицаю. Можно и так и так. Комбо я вставил для подтверждения изменений. Просто иногда надо срочно чтото изменить и путь пользователь-связь-привилегия-скомпилировать есть долгий. Вот и все.

Я настраиваю полномочия <a hre

Я настраиваю полномочия таким образом.
Достаточно удобно и быстро.

Согласен, что механизм назначения привилегии пользователю через меню пользователя нужен, но в системах где пользователй больше 5, все же надо работать через роли и группы .
А так же еще раз повторю, что вижу трудности (преодолимые) в грамотном отзыве привилегии у пользователя, т.к. в любом случае в результате должна работать цепочка: изменили список полномочий пользователя -> отразили их в документе Связь -> откомпилировали приилегии.

Изображение пользователя ipanshin.

У меня проблема вовсе не в нас

У меня проблема вовсе не в настройках полномочий, а в том, чтобы найти правильные механизмы связывания классов и их объектов между собой.
Например
Users-Privileges это пара или диполь
Далее Code-Doc - тоже пара ,...
Далее Code-ToolBox - пара,...

Далее можно связать Code-ToolBox c Doc. Это уже триада. Получается некая такая 'классовая' молекула. :) ... Можно и дальше говорить, но это видимо для всех скучно.

Изображение пользователя ipanshin.

И вторая особенность. Когда ме

И вторая особенность. Когда меню свойств становятся динамические, т.е. веером раздаются свойства и так же веером отбираются, то статика привилегий не успевает. Тут нужен автоматический механизм раздачи привилегий и их отбора в зависимости от ситуации или состояния.

Тут нужен <b>автом

Тут нужен автоматический механизм раздачи привилегий и их отбора в зависимости от ситуации или состояния.

Такие механизмы надо закладывать на уровне обработчика _getp_. Сделай дополнительный _getp_ для класса Doc, который будет управлять динамическими свойствами.

Вопрос про пара/диполь не понял. Пара - это комбинаторика, диполь - физика (химия).
Для меня User-Privilege - отношение классов, которые описано отдельным классом.

За <b>автоматическую</b> разда

За автоматическую раздачу привилегий люди типа Верещагина (фин директор ННШ, очень трепетно относящийся к security, прим. перев.) сразу повесят за одно место в подвале :)

Изображение пользователя ipanshin.

типа Верещагин просто не поним

типа Верещагин просто не понимает о чем речь. Я думаю и Вы не очень понимете. Постараюсь прислать по почте (если получится :) )

IMHO, ИП имел ввиду динамическ

IMHO, ИП имел ввиду динамическое формирование контекстного меню в зависимости от условий. Например, если накладная отгружена, то свойства Отгрузить уже не показывается, зато появляется пункт меню Отменить отгрузку.
А привилегии, ессено, должны раздоваться Министром-Администратором