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

Тема в разделе "Lotus - Программирование", создана пользователем arm, 26 мар 2013.

  1. arm

    arm Active Member

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

    ToxaRat Чёрный маг
    Lotus team

    Регистрация:
    6 ноя 2007
    Сообщения:
    3.046
    Симпатии:
    18
    ужас

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

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

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

    savl Lotus team
    Lotus team

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

    arm Active Member

    Регистрация:
    6 мар 2013
    Сообщения:
    25
    Симпатии:
    0
    Вот в том то и дело, что нужно именно спрятать документы, думаю совсем отказаться, или ХЗ ВАЩЕ!
     
  5. lmike

    lmike нет, пердело совершенство
    Команда форума Lotus team

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

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

    savl Lotus team
    Lotus team

    Регистрация:
    28 окт 2011
    Сообщения:
    2.051
    Симпатии:
    146
    lmike
    Не спорю по ридерс, сам пользуюсь. Про ограничение да, видать с ACL перепутал, на прошлой работе было много групп, очень много.

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

    ToxaRat Чёрный маг
    Lotus team

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

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

    Зато всё под полным твоим контролем, было бы желание начать :)
     
  8. Constantin A Chervonenko

    Constantin A Chervonenko Well-Known Member

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

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

    arm Active Member

    Регистрация:
    6 мар 2013
    Сообщения:
    25
    Симпатии:
    0
    Много думали над этим вопросом, похоже это единственный здравый вариант! Других просто не видно!
    Но с другой стороны в настройках Access Control базы в Advanced под выбором Administration Server есть такой пункт, в котором можно выбрать следующее: Modify All Names fields, и делаться это должно автоматически при исполнении Administration Process на соответствующем сервере, получается база может сама обновлять все поля "Names" во всех документах, например при переименовании пользователей, кто проверял такую штуку?
     
  10. Constantin A Chervonenko

    Constantin A Chervonenko Well-Known Member

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

    arm Active Member

    Регистрация:
    6 мар 2013
    Сообщения:
    25
    Симпатии:
    0
    Ну тогда придется делать суперагента, и интерфейс к нему для переделки соответствующих полей к новому имени
     
  12. rinsk

    rinsk Lotus team
    Lotus team

    Регистрация:
    12 ноя 2009
    Сообщения:
    795
    Симпатии:
    78
    Этот "робот" зовется штатный 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. толко в основной ак(
     
  13. swyatogor

    swyatogor Lotus team
    Lotus team

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

    ty3uk Well-Known Member

    Регистрация:
    31 мар 2008
    Сообщения:
    169
    Симпатии:
    0
    у меня такое решается базой Оргструктуры. База формирует группу для каждой должности + спец группы для начальников отделов и т.д. Чтоб группы не мешались в списке, начинаем их название с знака "_", тогда, группы, уходят в самый низ списка, что не так мешает работе.
    + пока не пробовал, но, как вариант в свойствах группы, дополнительно, проставлять не "многоцелевая", а "Только управление доступом" (честно, пока не проверял, нотификации по данным группам ходить будут или нет, надо тупо сесть и один раз проверить, по идее обязаны ходить)
     
  15. swyatogor

    swyatogor Lotus team
    Lotus team

    Регистрация:
    24 фев 2014
    Сообщения:
    429
    Симпатии:
    10
    вид группы на показ ее в окне выбора адресата ни как (ну кромя иконки) не влияет.. в нём показываются все сервера, все люди (в двух вариантах) все группы (кроме deny), все ресурсы и помещения.. бяда(

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

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

    Добавлено: ежели не жалко,
    можно глянуть??
     
  16. ty3uk

    ty3uk Well-Known Member

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

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

    rinsk Lotus team
    Lotus team

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

    swyatogor Lotus team
    Lotus team

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

    rinsk Lotus team
    Lotus team

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

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

    swyatogor Lotus team
    Lotus team

    Регистрация:
    24 фев 2014
    Сообщения:
    429
    Симпатии:
    10
    офтопик - последний пост только запутал мну..((

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

Поделиться этой страницей