Роли и поле Type Readers

  • Автор темы olegber
  • Дата начала
O

olegber

#1
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]
(Документ не должен отображаться ни во вьюверах, ни в форме)
 
O

olegber

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

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

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

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

Medevic

Что это ? :)
Lotus team
10.12.2004
3 346
1
#4
Нафиг роли.
Обычно это делается через установку прав для каждого отдела и каждого типа документов.
 

Akupaka

А че я?.. О.о
04.10.2007
3 360
1
#5
150 ролей.(если я правильно понял)
ты хочешь убиться об ТУД?.. :rolleyes:

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

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

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

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

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

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

Medevic

Что это ? :)
Lotus team
10.12.2004
3 346
1
#7
Для каждого отдела и типа документа создается настроечный документ, где прописываются права(пользователи которые могут читать, редактировать и т.п.).
При создании документа копируем эти данные из настроечных документов в соответствующие поля.
Ну и, если надо, отслеживаем изменения в настроечных документах.
 
O

olegber

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

Medevic

Что это ? :)
Lotus team
10.12.2004
3 346
1
#9
Я же написал, что про роли забываем.
Копируем имена пользователей и групп из настроечных документов в поля типа Readers и Authors созданного документа.
 
O

olegber

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

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

Medevic

Что это ? :)
Lotus team
10.12.2004
3 346
1
#12
Профильные документы я бы не стал использовать. Это недавно обсуждалось.
Роли здесь абсолютно не нужны. Не считая, конечно, роли Admin :rolleyes:. Может ещё какую-нибудь для начальства.
А система наоборот простая. Это с ролями была бы сложная. Особенно если будешь использовать группы.

Akupaka
Ну здесь типичный случай. Вряд ли что-то другое можно придумать. :)
 
30.05.2006
1 345
11
#13
Корни проблемы в том, что READERS/AUTHORS-поля это НЕ маленький локальный ACL.
В ACL-е можно как разрешить, так и запретить доступ кому-то; в READERS/AUTHORS - только разрешить

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

Akupaka

А че я?.. О.о
04.10.2007
3 360
1
#14
еще из минусов групп - локальные реплики не всегда работают корректно с ними... правда, я не углублялся...