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

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

0

а если переписать все на должности то в View Selection Formula нужно будет записать код

ужас

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

хоть это радует

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

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

0

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

0

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

Вот в том то и дело, что нужно именно спрятать документы, думаю совсем отказаться, или ХЗ ВАЩЕ!

0

Тут можно столкнуться с ограничением количества групп в names.nsf

а можно не столкнуться (о чем речь?) http://www.geniisoft.com/showcase.nsf/DominoLimyts
добавим сюда еще DA (а это + одна АК +ЛДАП)
-группы вводить надо если имен м.б. много (на один документ)
-вести справочник по должностям
-сделать агент по пересчету доков: при изменении содержимого справочника

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

0

lmike
Не спорю по ридерс, сам пользуюсь. Про ограничение да, видать с ACL перепутал, на прошлой работе было много групп, очень много.

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

0

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

не всё так страшно как кажется, когда я делал СЭД и в ней работало под 3К пользователей одновременно и всех их я вносил в ридерс документа это не вылезло за лимиты аж никак - да, пришлось немного по хитрить:
1) вместо полноценного LN использовал лишь краткую форму
2) всегда пытался понять когда документ становится публичным для всех, дабы поставить только *

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

Зато всё под полным твоим контролем, было бы желание начать

0

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

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

0

Сообщение от Constantin A Chervonenko Типичный (реализован НЕ в одном СЭД) подход: "Должность" - это группа в АК (с не более чем одним 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" во всех документах, например при переименовании пользователей, кто проверял такую штуку?

0

Сообщение от arm .. в настройках Access Control базы в Advanced под выбором Administration Server есть такой пункт, в котором можно выбрать следующее: Modify All Names fields, и делаться это должно автоматически при исполнении Administration Process на соответствующем сервере, получается база может сама обновлять все поля "Names" во всех документах, например при переименовании пользователей

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

0

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

Ну тогда придется делать суперагента, и интерфейс к нему для переделки соответствующих полей к новому имени

0

Сообщение от Constantin A Chervonenko skip 1.Нужен "робот" который автоматом будет эти группы поддерживать (их-же никак не меньше, чем юзеров) skip

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

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

0

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

0

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

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

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

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

Добавлено: ежели не жалко,

у меня такое решается базой Оргструктуры

можно глянуть??

0

ещё раз, в название группы добавляем, первым символом, ставим "_" (знак подчёркивания). С таким знаком, все группы спускаются вниз, т.к. по правилам сортировки знак "_" идёт после русских и латинских букавак.

можно глянуть??

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

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

0

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

0

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

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

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

0

офтопик - последний пост только запутал мну..((

но пока не об этом.. вопрос может кто сталкивался..
Создал стороннюю NAB, подключил ее через DA..
при команде в консоли

- вижу две книги, основная и дополнительная..
но мало того, что доступ не воркает.. так еще и при

выходит ошибка

в поиске нашел только вот это но без ответа(

0