yky

Суть задачи:
Есть документ обрабатываемый на сервере. Есть пользователь у которого есть ЛотусИмя. Необхимо проверить есть ли у данного пользователя доступ к документу. Доступ может быть предоставлен как напрямую, так и через роли и группы.?Так как у групп может быть большая вложенность и этих групп ну очень дофига, то просто равернуть все группы и посмотреть есть ли он там не представляется возможным в разумные сроки.

@otyk86

А Вам программно надо?
Если нет, то ACL -> Effective Access...

0

yky

Программно. На сервере.

@mvyush

Сие покажет права доступа к базе, не к документу.
Кстати, а никто не в курсе, есть ли апишная функция, возвращающая список групп/ролей выбранного пользователя (аналогично @UserNameList, но не для текущего, а для выбранного пользователя).

0

@otyk86

Но тут мы таки увидим и все роли пользователя и все группы, в которые он входит.

0

@dyvomkym

А почему вы решили, что си-апишная функция, если такая есть, будет сильно быстрее работать, чем скрипт, что вы напишите?
Тем более, что если вам нужно массово проверять права к документам, то вы можете закэшировать состав групп и раскрытый состав содержимого ACL.

0

yky

Потому что API-шная функция поидее должна взять документ, взять учетку юзера по ЛН имени и сделать проверку могу/не могу открыть (редактировать) и вернуть Да/Нет , а если я напишу скрипт, то это будет что-то вроде.

1. Смотирм доступ к базе
2. Бежим по всем полям собираем все поля типа Автор/Ридер. Делаем список имен
3. Вытаскиваем все роли и группы
4. разворачиваем роли Добавляем имена в список имен. Добавляем группы в список групп.
5. Берем полученные группы. Лезем в Names.nsf и смотрим всех юзеров которых они содержат. Добавляем в список.
6. Смотрим входит ли юзер в полученный гигантский список.
7. Возвращаем Да/нет

А кажется мне что этот механизм должен быть и должен работать быстро потмоу, что скажем в Ytria ScanEZ такой механизм есть и он работает быстро ( когда мы пытаемся получить документ по UNIDу к которому у нас нет прав он сразу пишет что недостаточно прав. Причем именно недостаточно прав, а не документ не найден. Если документа нет, то ошибка будет другая)

ps. прошу не комментировать данный алгоритм так как я его не продумывал, и надеюсь что не придеца, а просто набросал.

@mvyush

http://www.ibm.com/developerworks/lotus/documentation/capi/

0

@ToxoRot

странные вы люди однако :unsure:
на документ если убрать все условности есть только два вида доступа:
1) Могу видеть
2) Могу менять

вот от этого и пляшите, а то начинают тут роли, группы вспоминать ;)

0

yky

2 nvy. Спасибо. Я до того как напистаь этот пост внимателньо изучил Хелп по Lotus С API.
Увы нашел только Function W32_NSFNoteGetInfo Lib "nnotes.dll" которым можно проверить наличие доступа для текущего юзера. У меня же обработка на серваке.

2 ToxaRat. Проблема опять же в том что обработка на сервере, который точно может видеть и менять док, а мне надо проверить для юзера. Так что увы попробовать открыть/поменять док и потом обработать полученную ошибку не получица.

PS Для решения моей задачи мне собственно нужна проверка на наличие Ридерского доступа.

@ToxoRot

iki
попробуй через Doc.Lock(

0

Tyo

На виндовом серваке тоже есть nnotes.dll. Только в зависимости от ОС название может меняться.

Можно пытаться сохранить документ и ловить эксепшен. Но, как я понимаю, вы хотите до выполнения долгой операции выяснить удастся ли сохранить результат...

yky

2 Toxa. Увы по корпоративным стандартам в базах стоит IsDocumentLockingEnabled = False

2 Tia. Проблемма не в том что на серваке нет nnotes.dll. Проблемма в том что текущий юзер - Сервер, а функция проверяет наличие доступа для текущего юзера (получится что для сервера у которого точно есть доступ). Опять же ловить эксепшен не получица по той же причине.

Сама задача: есть документ который юзер должен обработать (какие-нить договора и прочая лабуда). к нему есть взаимосвязные документы (всякая инфа, опять же договораи проч.) к которым у юзера возможно нет доступа. Перед тем как отправить юзеру оповещение о необходимости обработать документ сервер должен проверить есль ли у юзера доступ ко всем взаимосвязям и если нет выполнить некоторые _сложные_ действия по предоставлению доступа к конкретным документам. Предоставлять всегда и ко всем - не вариант.

@Mydyvys

Может упростить эти _сложные_ действия, а не искать костыль?
Создай копии этих документов. Пусть их обрабатывает.

0

yky

В процесс предоставления доступа вовлечены специально обученные люди которые оценивают необходимость предоставления. Упростить не получится.

Про копии не понял

@Mydyvys

Если сложно предоставить доступ к самим документам, то может быть проще создать копии документов и предоставить доступ к ним? Пусть пользователь обрабатывает копии, а потом сервер перенесёт изменения в основные документы.

0

@dyvomkym

А как по вашему API-шная функция сможет "сделать проверку могу/не могу открыть (редактировать)"? Да примерно так же как вы написали с поправкой на кэширование списка групп в которые входит пользователь.
Что впрочем и вам советую делать.

То есть.
1. Получение всех групп, в которые входит пользователь. Получили список имен и групп, через которые пользователь получает доступ к базам.
2. Получение текущего доступа к текущей базе и всех ролей пользователя через QueryAccessPrivileges и QueryAccessRoles. Получили список всех имен, групп и ролей, через которые пользователь может получить доступ к документам в базе.
3. Получение списка людей, групп и ролей, имеющих доступ к документу
4. Ищем пересечение этих списка доступа к документу и списка имен, групп и ролей в базе данного пользователя.

Для быстроты сравнения имеет смысл отсортировать список имен, групп и ролей и хранить список доступа к документу тоже отсортированным. Тогда можно написать довольно быструю функцию сравнения двух отсортированных списков.
Если вас беспокоит большая вложенность групп, то можно предварительно агентом для каждого пользователя создать документ со списком группы, в которые он входит.

0