Буду очень благодарна, если кто то предложит какоето решение или совет по следующей проблемме.

Поле ридерс переполнилось и не дает пересохранить документ, если я пытаюсь изменить поле ( добавить или удалить из списка).
Например юзер выбирает в поле из списка всех 1000 людей, когда потом я с этого списка хочу кого то убрать, то лотус не дает это сделать.
Выдает сообщение 32 K limit.

 

А зачем пользователь выбирает 1000 людей?
Почему у него нет возможности сказать, что документ виден всем, или указать конкретную группу?

 

neznayka43
использовать иной подход
или же светить в виде документы "обманки" которые перенаправляют на реальные документы

 

Если не хотите работать с группами, то создайте несколько readers полей в форме.
Делайте проверку на item.ValueLength>32000, если переполнено, то записывайте в другое реадерс поле)

 

Если не хотите работать с группами, то создайте несколько readers полей в форме.

к сожалению, это помогает не на долго, т.к. два больших поля плюс остальные в документе приведут к переполнению общего размера summary-полей в 64К и все пойдет... на форум ))

или же светить в виде документы "обманки" которые перенаправляют на реальные документы

ну, а реальному доку тогда как быть? всем виден должен быть?

тут уж действительно лучше использовать группы или псевдогруппы (*/OU/Org/C), либо создавать копии документа для определенного набора человек, но последний способ сложнее в управлении

 

Если не хотите работать с группами, то создайте несколько readers полей в форме.
Делайте проверку на item.ValueLength>32000, если переполнено, то записывайте в другое реадерс поле)

Так будут проблемы с отображением документа в представлениях. Те, кто за границей 32к не будут видеть документ в представлениях.
NIF рассчитывает, что суммарный объём реадерс и авторс-полей не превышает 32к.

neznayka43
Если у вас более одного реадерс-поля, и значения в них могут повторяться, то оставить одно реадерс-поле куда по уникальности поместить значения из всех старых полей. В противном случае, поможет только переход на группы. Хоть даже по одному сотруднику на группу. За счёт того, что имя группы будет короче полного notes-имени пользователя, вы сможете предоставить доступ бОльшему числу пользователей.

 

Akupaka

ну, а реальному доку тогда как быть? всем виден должен быть?

а реальный док в виде невиден вообще никак - по селекту не проходит, он только кодом открывается и вообще может в отдельной базе лежать

 

а реальный док в виде невиден вообще никак - по селекту не проходит, он только кодом открывается и вообще может в отдельной базе лежать

в любом случае надо мутить с доступом, что не очень-то полезно

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

 

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

таймаут на группу до 15 минут никто не отменял

 

таймаут на группу до 15 минут никто не отменял

а подробнее?..

 

Количество групп, в которые входит человек, ограничено. Обычно с этим ограничением не сталкиваются, но если создавать группу на каждый чих, то вы быстро к нему придете.
И я думаю, чем в больше количество групп входит человек, тем дольше у него открываются вьюшки. Ведь, чтобы определить имеет ли человек доступа к документу, нужно найти пересечение двух списков: всех имен юзера и ACL документа.

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

 

нет, нет, не на каждый чих, а только в случая переполнения и т.п., ну, в общем, интеллектуально...

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

поддерживаю!
и хорошо бы, если бы пользователи знали что такое группа и как с ними работать.

 

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

правильно гришь

Akupaka

а подробнее?

а что поподробнее, неужели вы думаете что как только создадите группу, наполните её юзерами сервер сразу по ней начнет работать?
неее
сервер умный, он кеширует списку пользоватаел, у него для этого спец таблица есть, в которой он держит права пользователей и отношение к группам
неужто никогда не сталкивались, что добавили нового пользователя в группу, а он туда ну никак вломиться не может?

 

неужто никогда не сталкивались

об указанном я знаю, но по предыдущему твоему посту этого не угадал. не считаю это критическим.

 

об указанном я знаю, но по предыдущему твоему посту этого не угадал. не считаю это критическим.

тогда из критического - количество записей в ACL базы - весьма ограничено

 

тогда из критического - количество записей в ACL базы - весьма ограничено

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

 

тогда из критического - количество записей в ACL базы - весьма ограничено

А можно поподробнее? Сколько записей может быть в ACL, есть ли ограничения на число ролей?

 

Для 7ки:

Имён в ACL - 32kб, 950шт.
Ролей - 75шт.

Групп, в которые входит пользователь - 4096шт.
Вложенность групп - 20 уровней
Список всех имён пользователя - 64кб.

 

TIA

Спасибо большое! На ограничения пока не натыкался, но инфа весьма полезная.

 

TIA

Спасибо большое! На ограничения пока не натыкался, но инфа весьма полезная.

Полный список тут: http://www-01.ibm.com/support/docview.wss?...uid=swg21222807