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

[arm]

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

 

[ToxaRat]

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

ужас

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

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

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

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

 

[savl]

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

 

[arm]

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

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

 

[lmike]

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

а можно не столкнуться (о чем речь?)

Ссылка скрыта от гостей

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

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

 

[savl]

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

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

 

[ToxaRat]

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

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

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

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

 

[Constantin A Chervonenko]

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

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

 

[arm]

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

 

[Constantin A Chervonenko]

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

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

 

[arm]

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

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

 

[rinsk]

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

Этот "робот" зовется штатный Auto-Populated Groups с твиком

Ссылка скрыта от гостей

У каждого пользователя в АК есть туча полей, согласно которым можно регулировать членство в группах.
Например по OU: (&(objectclass=organizationalPerson)(FullName=*OU=Anesteziologiya_reanimasiya_
2*))

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

 

[swyatogor]

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

 

[ty3uk]

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

 

[swyatogor]

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

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

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

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

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

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

 

[ty3uk]

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

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

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

 

[rinsk]

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

 

[swyatogor]

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

 

[rinsk]

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

со службой каталогер: эта служба сама запускается с необходимой периодичностью и согласно формуле пихает в конденсед каталог.
Можно и без службы. В структуре организации без редерсов агент копирует в доп АК уже с ридерсами. Да и саму структуру организации можно сделать в виде доп. АК. Там где то 4 служебных вида должны быть ну и поля соотв.
Подробнее -

Ссылка скрыта от гостей

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

 

[swyatogor]

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

но пока не об этом.. вопрос может кто сталкивался..
Создал стороннюю 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

в поиске нашел только

Ссылка скрыта от гостей