Организация Доступа К Документам По Должности А Не По Имени Сотрудника

arm

Member
06.03.2013
24
0
#1
Суть в том, что сейчас есть база документов для которых назначается список исполнителей и у каждого из юзеров есть вьюха которая как раз отображает документы в которых указан пользователь в специальном поле. И сейчас все это работает естественно по простому имени пользователя, а если переписать все на должности то в View Selection Formula нужно будет записать код, который определял бы должность текущего пользователя в зависимости от его юзера, например можно было бы через @NameLookUp получить встроеный в учетку "JobTitle" или через @DBLookUp найти связь через специальную вьюшку, но ни та, не другая не работает ни во View Selection не в колонках, кто его знает, где ещё это все не будет работать...
Если кто-то с таким сталкивался и реализовывал, поделитесь опытом пожалуйста, потому, как сейчас перебрано куча вариантов и все они не работают.
 

ToxaRat

Чёрный маг
Lotus team
06.11.2007
3 233
18
#2
а если переписать все на должности то в View Selection Formula нужно будет записать код
ужас

потому, как сейчас перебрано куча вариантов и все они не работают.
хоть это радует

Первое что нужно усвоить, - что нужно в итоге?

Не дать доступ на документы не соответствующие должностным обязанностям? - ридерс поля
 

savl

Lotus team
28.10.2011
2 136
105
#3
ToxaRat, сами же понимаете, что если там не LN имена будут, то ничего не даст, да и только хуже сделает.
куча пользователей на одной должности, всех писать в список Readers? А новые сотрудники как туда попадут? Синхронизация?
Мои 3 варианта.
Вариант 1:
Необходимо завести должностные профили, каждый профиль прикрепляется к пользователю в специальной карточке.
На профиль навешивается доступ к системе, роли, группы, при необходимости. Если в системах есть АРМы, то и их в карточку пользователя крепить.
В доступе к документу прописываются конкретные профили, при попытке открытия по LN ищется карточка пользователя, проверяется его профиль с профилями в доступе. Не совпадает - не дает открыть. Спрятать документы при таком подходе от пользователя нельзя, но можно запретить открыть. Гибкое изменение доступа пользователя сразу к куче систем. Этакая внешняя система контроля доступа.
Можно продумать еще нюансы.
Вариант 2:
Загнать пользователей в группы, в доступе документа прописывать группы. Можно скрыть документы от пользователя по Readers.
Тут можно столкнуться с ограничением количества групп в names.nsf
Вариант 3:
Прописывать должности пользователей в документ из вашего справочника должностей.
При открытии документа лезть в список пользователей, взять должность конкретного, проверить со списком внутри документа.
Нет должности в списке - не открывать. Опять же нельзя спрятать документы, только запретить открытие.
 

arm

Member
06.03.2013
24
0
#4
ToxaRat, сами же понимаете, что если там не LN имена будут, то ничего не даст, да и только хуже сделает.
куча пользователей на одной должности, всех писать в список Readers? А новые сотрудники как туда попадут? Синхронизация?
Мои 3 варианта.
Вариант 1:
Необходимо завести должностные профили, каждый профиль прикрепляется к пользователю в специальной карточке.
На профиль навешивается доступ к системе, роли, группы, при необходимости. Если в системах есть АРМы, то и их в карточку пользователя крепить.
В доступе к документу прописываются конкретные профили, при попытке открытия по LN ищется карточка пользователя, проверяется его профиль с профилями в доступе. Не совпадает - не дает открыть. Спрятать документы при таком подходе от пользователя нельзя, но можно запретить открыть. Гибкое изменение доступа пользователя сразу к куче систем. Этакая внешняя система контроля доступа.
Можно продумать еще нюансы.
Вариант 2:
Загнать пользователей в группы, в доступе документа прописывать группы. Можно скрыть документы от пользователя по Readers.
Тут можно столкнуться с ограничением количества групп в names.nsf
Вариант 3:
Прописывать должности пользователей в документ из вашего справочника должностей.
При открытии документа лезть в список пользователей, взять должность конкретного, проверить со списком внутри документа.
Нет должности в списке - не открывать. Опять же нельзя спрятать документы, только запретить открытие.
Вот в том то и дело, что нужно именно спрятать документы, думаю совсем отказаться, или ХЗ ВАЩЕ!
 

lmike

нет, пердело совершенство
Lotus team
27.08.2008
6 599
277
#5
Тут можно столкнуться с ограничением количества групп в names.nsf
а можно не столкнуться :rolleyes:(о чем речь?) http://www.geniisoft.com/showcase.nsf/DominoLimits
добавим сюда еще DA (а это + одна АК +ЛДАП)
-группы вводить надо если имен м.б. много (на один документ)
-вести справочник по должностям
-сделать агент по пересчету доков: при изменении содержимого справочника

ридерс - это нормальная практика, а вот интерфейсные ограничения очень чреваты трудноуловимыми ошибками и дырами
 

savl

Lotus team
28.10.2011
2 136
105
#6
lmike
Не спорю по ридерс, сам пользуюсь. Про ограничение да, видать с ACL перепутал, на прошлой работе было много групп, очень много.

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

ToxaRat

Чёрный маг
Lotus team
06.11.2007
3 233
18
#7
ToxaRat, сами же понимаете, что если там не LN имена будут, то ничего не даст, да и только хуже сделает.
куча пользователей на одной должности, всех писать в список Readers? А новые сотрудники как туда попадут? Синхронизация?
Мои 3 варианта.
Вариант 1:
Необходимо завести должностные профили, каждый профиль прикрепляется к пользователю в специальной карточке.
На профиль навешивается доступ к системе, роли, группы, при необходимости. Если в системах есть АРМы, то и их в карточку пользователя крепить.
В доступе к документу прописываются конкретные профили, при попытке открытия по LN ищется карточка пользователя, проверяется его профиль с профилями в доступе. Не совпадает - не дает открыть. Спрятать документы при таком подходе от пользователя нельзя, но можно запретить открыть. Гибкое изменение доступа пользователя сразу к куче систем. Этакая внешняя система контроля доступа.
Можно продумать еще нюансы.
Вариант 2:
Загнать пользователей в группы, в доступе документа прописывать группы. Можно скрыть документы от пользователя по Readers.
Тут можно столкнуться с ограничением количества групп в names.nsf
Вариант 3:
Прописывать должности пользователей в документ из вашего справочника должностей.
При открытии документа лезть в список пользователей, взять должность конкретного, проверить со списком внутри документа.
Нет должности в списке - не открывать. Опять же нельзя спрятать документы, только запретить открытие.
не всё так страшно как кажется, когда я делал СЭД и в ней работало под 3К пользователей одновременно и всех их я вносил в ридерс документа это не вылезло за лимиты аж никак - да, пришлось немного по хитрить:
1) вместо полноценного LN использовал лишь краткую форму
2) всегда пытался понять когда документ становится публичным для всех, дабы поставить только *

Да, тут нужно сделать хороший механизм прописывания ридерс/авторс в документ, но потом поверь сможешь привязаться и к ФИО и к И.О., отделу, департаменту, должности, возрасту и т.д.
и отрабатывать будет и по новым резолюциям и по новой карточке в справочнике организации, и посадить одного юзера на кучу должностей...

Зато всё под полным твоим контролем, было бы желание начать :)
 
30.05.2006
1 345
11
#8
Типичный (реализован НЕ в одном СЭД) подход:
"Должность" - это группа в АК (с не более чем одним Member-ом).
"+"
1.В readers/authors группы работают
2.При изменении должности юзера НЕ НАДО пересчитывать все readers/authors всех документов
3.Для SingleCategory шареных view и SELECTов частных можно использовать @UserNamesList
4.Легко получаются временные замещения

"-"
1.Нужен "робот" который автоматом будет эти группы поддерживать (их-же никак не меньше, чем юзеров)
2.Некоторые сложности в мультидоменной инфраструктуре (много АК)
 

arm

Member
06.03.2013
24
0
#9
Типичный (реализован НЕ в одном СЭД) подход:
"Должность" - это группа в АК (с не более чем одним Member-ом).
"+"
1.В readers/authors группы работают
2.При изменении должности юзера НЕ НАДО пересчитывать все readers/authors всех документов
3.Для SingleCategory шареных view и SELECTов частных можно использовать @UserNamesList
4.Легко получаются временные замещения

"-"
1.Нужен "робот" который автоматом будет эти группы поддерживать (их-же никак не меньше, чем юзеров)
2.Некоторые сложности в мультидоменной инфраструктуре (много АК)
Много думали над этим вопросом, похоже это единственный здравый вариант! Других просто не видно!
Но с другой стороны в настройках Access Control базы в Advanced под выбором Administration Server есть такой пункт, в котором можно выбрать следующее: Modify All Names fields, и делаться это должно автоматически при исполнении Administration Process на соответствующем сервере, получается база может сама обновлять все поля "Names" во всех документах, например при переименовании пользователей, кто проверял такую штуку?
 
30.05.2006
1 345
11
#10
.. в настройках Access Control базы в Advanced под выбором Administration Server есть такой пункт, в котором можно выбрать следующее: Modify All Names fields, и делаться это должно автоматически при исполнении Administration Process на соответствующем сервере, получается база может сама обновлять все поля "Names" во всех документах, например при переименовании пользователей
"Плавали, знаем.."(с)
1.Эта база - "names.nsf". Я сомневаюсь, что поля Names в ней обрабатываются AdminRequest-ером на общих основаниях (эти поля - источник данных для AdmReq, а не цель)
2.Доверять поля Names "обычной базы" AdminRequest-еру иногда чревато. При переименовании юзеров всё Ок.. А вот при удалении?? Неоднократно "налетал" на коллизию, когда после такой зачистки в Readers не оставалось никого и док-т "пропадал" либо открывался на распашку (в зависимости от наличия дополнительных Readers). Это не баг, но учитывать надо..
 

arm

Member
06.03.2013
24
0
#11
"Плавали, знаем.."(с)
1.Эта база - "names.nsf". Я сомневаюсь, что поля Names в ней обрабатываются AdminRequest-ером на общих основаниях (эти поля - источник данных для AdmReq, а не цель)
2.Доверять поля Names "обычной базы" AdminRequest-еру иногда чревато. При переименовании юзеров всё Ок.. А вот при удалении?? Неоднократно "налетал" на коллизию, когда после такой зачистки в Readers не оставалось никого и док-т "пропадал" либо открывался на распашку (в зависимости от наличия дополнительных Readers). Это не баг, но учитывать надо..
Ну тогда придется делать суперагента, и интерфейс к нему для переделки соответствующих полей к новому имени
 

rinsk

Lotus team
12.11.2009
904
44
#12
skip
1.Нужен "робот" который автоматом будет эти группы поддерживать (их-же никак не меньше, чем юзеров)
skip
Этот "робот" зовется штатный Auto-Populated Groups с твиком http://www.eknori.de/2008-06-10/tweak-the-...e-in-domino-85/
У каждого пользователя в АК есть туча полей, согласно которым можно регулировать членство в группах.
Например по OU: (&(objectclass=organizationalPerson)(FullName=*OU=Anesteziologiya_reanimasiya_
2*))

PS. толко в основной ак(
 

swyatogor

Lotus team
24.02.2014
479
10
#13
Вопрос такого плана.. кто делал подскажите..
Встал вопрос такой же затеи.. нужно сделать СЭД с шаблонами хождения документов по должности.
Из всех способов самый здравый (на мой взгляд) сделать структуру на базе групп, но возникает сразу несколько вопросов:
1. Если все группы в АК предприятия - то они будут захламлять базу - например при выборе адресата в новом письме - а как по другому?
2. Как сделать именно структуру, чтоб можно было понять кто начальник отдела, а кто в отделе работает??
 

ty3uk

Well-known member
31.03.2008
170
0
#14
у меня такое решается базой Оргструктуры. База формирует группу для каждой должности + спец группы для начальников отделов и т.д. Чтоб группы не мешались в списке, начинаем их название с знака "_", тогда, группы, уходят в самый низ списка, что не так мешает работе.
+ пока не пробовал, но, как вариант в свойствах группы, дополнительно, проставлять не "многоцелевая", а "Только управление доступом" (честно, пока не проверял, нотификации по данным группам ходить будут или нет, надо тупо сесть и один раз проверить, по идее обязаны ходить)
 

swyatogor

Lotus team
24.02.2014
479
10
#15
вид группы на показ ее в окне выбора адресата ни как (ну кромя иконки) не влияет.. в нём показываются все сервера, все люди (в двух вариантах) все группы (кроме deny), все ресурсы и помещения.. бяда(

Добавлено: ах да.. там еще и маил-ин все

Добавлено: хэх.. и даже deny тоже есть....

Добавлено: ежели не жалко,
у меня такое решается базой Оргструктуры
можно глянуть??
 

ty3uk

Well-known member
31.03.2008
170
0
#16
ещё раз, в название группы добавляем, первым символом, ставим "_" (знак подчёркивания). С таким знаком, все группы спускаются вниз, т.к. по правилам сортировки знак "_" идёт после русских и латинских букавак.

нет, нельзя, база идёт в комплекте с нашими базами ЭДО. Отдельно не распространяется :rolleyes: .
Я не знаю как дела обстоят в БР. Возможно там есть что-то подобное. Посмотрите там.
 

rinsk

Lotus team
12.11.2009
904
44
#17
Домино группы имеющие сущность ролей в целевой системе замечательно живут в доп АК, который подключен через ДА с галкой Group authorization+Use exclusively for group authorization or credential authentication.
Для многодоменной архитектуры и не только - использовать condensed directory catalog который скучкует из Оргструктуры(ов) нужные группы в конкретном домене. Тут же Readers LocalDomainServers+LocalDomainAdmins+кого надо на эти группы.
 

swyatogor

Lotus team
24.02.2014
479
10
#18
хм.. т.е. есть база структуры организации.. при работе в рабочей базы в реадерс поля мы прописываем нужные группы..
а агент на этой базе пастит их как нужно в доп АК (т.е. отдельная база на темплейте pubnames), которая в свою очередь прописана в ДА с указанными выше галками..
при этом эти данные не видать в списках общей АК..
так ??
 

rinsk

Lotus team
12.11.2009
904
44
#19
хм.. т.е. есть база структуры организации.. при работе в рабочей базы в реадерс поля мы прописываем нужные группы..
а агент на этой базе пастит их как нужно в доп АК (т.е. отдельная база на темплейте pubnames), которая в свою очередь прописана в ДА с указанными выше галками..
при этом эти данные не видать в списках общей АК..
так ??
со службой каталогер: эта служба сама запускается с необходимой периодичностью и согласно формуле пихает в конденсед каталог.
Можно и без службы. В структуре организации без редерсов агент копирует в доп АК уже с ридерсами. Да и саму структуру организации можно сделать в виде доп. АК. Там где то 4 служебных вида должны быть ну и поля соотв.
Подробнее - http://www-12.lotus.com/ldd/doc/domino_not...5f?OpenDocument

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

swyatogor

Lotus team
24.02.2014
479
10
#20
офтопик - последний пост только запутал мну..((

но пока не об этом.. вопрос может кто сталкивался..
Создал стороннюю NAB, подключил ее через DA..
при команде в консоли
Код:
show xdir
- вижу две книги, основная и дополнительная..
но мало того, что доступ не воркает.. так еще и при
Код:
load dircat da
выходит ошибка
Код:
[21C8:0002-0A84] 20.11.2014 11:04:21  Directory Cataloger finished processing da: Entry not found in index
в поиске нашел только вот это но без ответа(