Роли и поле Type Readers

[olegber]

lotus 5
Есть две роли r1 и r2
создаём и добавляем их в поле type Readers

[codebox]dim arr(1 to 2) as string
arr(1)="[r1]"
arr(2)="[r2]"
Set ItemR=New NotesItem(doc, "aReaders", arr, READERS)
call doc.Save
[/codebox]

Получаем: пользователь может видеть документы, если
у него есть роль [r1] ИЛИ роль [r2].

Можно ли сделать так , чтобы пользователь видел документы, если
у него есть роль [r1] И роль [r2]
(Документ не должен отображаться ни во вьюверах, ни в форме)

 

[morpheus]

создать 3ю роль

 

[olegber]

Это понятно.)
но вообще то всё немного сложнее)

15 типов документов
В каждом документе есть одинаковое поле (общее), по значению которого документы относятся к определённому отделу.
Количество отделов - 10.

Каждый человек должен видеть документы только определённого типа и причём только своего отдела.

150 ролей.(если я правильно понял)
может есть другой выход?

 

[Medevic]

Нафиг роли.
Обычно это делается через установку прав для каждого отдела и каждого типа документов.

 

[Akupaka]

150 ролей.(если я правильно понял)

ты хочешь убиться об ТУД?..

первое, что мне пришло в голову, создать набор правил доступа, т.е. документ в котором указано:
- тип, список ползователей, которые могут его читать; т.е. будет 15 документов;

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

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

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

правда, если нужно обновить списки имен в параметре-типе и параметре-подразделении, то придется решить, что делать со старыми документами:
- изменять в них список читателей в соотв. с изменениями в списке сотрудников;
- новым именам будут доступны только новые документы;

сложно, но по другому пока не представляется...

 

[olegber]

Как

Обычно это делается через задания прав для каждого отдела и каждого типа документов.

как понять через задания прав ?

 

[Medevic]

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

 

[olegber]

Что копируем? (Имя пользователя или роль?)
Куда копируем?

 

[Medevic]

Я же написал, что про роли забываем.
Копируем имена пользователей и групп из настроечных документов в поля типа Readers и Authors созданного документа.

 

[Akupaka]

Что копируем? (Имя пользователя или роль?)
Куда копируем?

см выше мой пост

Medevic, я думал я прямолинейно думаю )

 

[olegber]

Я же написал, что про роли забываем.
Копируем имена пользователей и групп из настроечных документов в поля типа Readers и Authors созданного документа.

Интересный подход.)
У нас так же сделано, только данные в профильном документе и по ролям.
Довольно сложная система управления доступом(если ещё учитывать и поле Authors).

Спасибо за совет

 

[Medevic]

Профильные документы я бы не стал использовать. Это недавно обсуждалось.
Роли здесь абсолютно не нужны. Не считая, конечно, роли Admin . Может ещё какую-нибудь для начальства.
А система наоборот простая. Это с ролями была бы сложная. Особенно если будешь использовать группы.

Akupaka
Ну здесь типичный случай. Вряд ли что-то другое можно придумать.

 

[Constantin A Chervonenko]

Корни проблемы в том, что READERS/AUTHORS-поля это НЕ маленький локальный ACL.
В ACL-е можно как разрешить, так и запретить доступ кому-то; в READERS/AUTHORS - только разрешить

ЗЫ: в словарях (там, где устанавливается соответствие между назвой департамента и юзерами, допущенными к соотв.телу) вместо явных списков юзеров удобно использовать группы
"+" не придётся модифицировать документы при изменении списка личного состава департамента
"-" сложно поддерживать синхронность групп с нескольких АК

 

[Akupaka]

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