По правам доступа

[Ols]

Подскажите, пожалуйста, возможно ли сделать следующее (при такой организации документа):

в документе есть таблица, содержащая 21*7 полей. Собственно права необходимо распределить для полей по столбцам.
Причем так, чтоб, например, поля первого столбца - после ввода данных и сохранения документа молгли видеть все пользователи, кроме некого субъекта, а координатор проекта (тоже пользователь) мог видеть и редактировать все, и при проверке данных, если будет обнаружена им ошибка, то давать разрешение на редактирование (по кнопке что-ли) пользователю, что вносил эти данные в первый столбец.

Поле можно скрыть по роли, но как управлять к нему доступом на чтение-редактирование?

 

[Constantin A Chervonenko]

Не получится. Защитить часть полей от редактирования - можно. А скрыть - только интерфейсными бантиками, которые обходятся одним кликом мыши.
Данные с разным доступом разноси по разным документам, защищенным полями READERS. А при отображении - собирай коллекцию того, что разрешено данному юзеру

 

[GROMILA]

Замечание №1
Все завит от крутизны требований к защите.

Если требования к защите от разработчика не столь критичны
Если на вашем предприятии фурычит примерное разделение:
1. Пользователи задачи
2. Разработчики
3. Администратор Domino
то от разработчиков и администратора толком не защитишь.

А вот между пользователями спокойно применяй на форме соткрытие полей по условию, причем
парами: Редактирумое + Для отображения
Пример:
Пусть есть поле CellField
На форме должна быть соответствующая пара полей:
CellField - редактируемое поле
CellField_view - поле для просмотра Computed for display = CellField

Если пользователь обладает определенными правами, то настраиваешь на них соответствующие формулы сокрытия/открытия нужных полей пары:
- CellField (открыть) а CellField_view (скрыть) - если права Просмотр+Редактиование
- CellField (скрыть) а CellField_view (открыть) - если права Только просмотр
- CellField (скрыть) а CellField_view (скрыть) - если нет прав на просмотр

Замечание №2
Частенько программеры сразу создают туеву хучу ролей на каждый чих и используют их в формулах сокрытия. Только вот потом их настраивать приходится администратору, а в окошке ACL это делать крайне неюзабельно.
ИМХО, так делать плохо.
Частенько настройкой прав занимается ответственный чувак в отделе, который является менеджером на уровне данной задачи (не базы лотус!!!), или требуется делегировать полномочия по настройке прав кому-то на время, да и видеть в табличном виде кому какие полномочия в данной задаче выставлены.
ИМХО, лучше вести свой справочник ролей.

Вот и получается, что данное требование ЮЗАБИЛИТИ назначения полномочий автоматом затрудняет использование стандартных механизмов Readers-Authors (метод разнесения по докуентам), что влечет за собой снижение степени защиты.

 

[Constantin A Chervonenko]

Не путай мягкое с тёплым.
По условию задачи поля надо защищать не только от редактирования (тут сокрытие от НЕпрограммиста поможет), но и от чтения. У меня так уже все юзера знают, что у мышки есть правая кнопка. Скрыть выборочно отдельное поле можно только шифрованием.
Так что "только солкосерил, и ТОЛЬКО после ампутации" (с) Т.е. делить по документам. А уж их защищать или скрывать...

 

[Axel]

Для: Constantin A Chervonenko
Если закрыть дизайн, то способ скрытия полей в принципе пройдет.

 

[Constantin A Chervonenko]

Для: Constantin A Chervonenko
Если закрыть дизайн, то способ скрытия полей в принципе пройдет.

Плавали, знаем. Сильно осложняет сопровождение этой прикладухи. Вывод: с переменным успехом боремся с последствиями неправильного архитектурного решения

 

[GROMILA]

Плавали, знаем. Сильно осложняет сопровождение этой прикладухи. Вывод: с переменным успехом боремся с последствиями неправильного архитектурного решения

Думаю, что сопровождать сборку-разборку единого документа на реквизиты сопровождать гораздо сложнее.

по поводу свойств документа
1. Есть регламент обновления баз на рабочем сервере!!!
2. Есть роль [Admin] у базы, которая видит все поля прямо на форме и в удобном виде, для простоты скрытые в секцию, чтобы легче было хайдить от остальных

 

[Constantin A Chervonenko]

Думаю, что сопровождать сборку-разборку единого документа на реквизиты сопровождать гораздо сложнее.

Разрабатывать сложнее, сопровождать - проще

по поводу свойств документа
1. Есть регламент обновления баз на рабочем сервере!!!
2. Есть роль [Admin] у базы, которая видит все поля прямо на форме и в удобном виде, для простоты скрытые в секцию, чтобы легче было хайдить от остальных

Во-во. Разработать специальную админскую форму, что-б через неё смотреть все служебные поля (по мере их возникновения), SeqNumber-ы и временнЫе метки. Спасибо за наше счастливое детство!