Крепление файлов и ....

[Guest]

Столкнулся с проблемой.

Как организовать крепление файлов и организацию доступа к ним.

Могу поместить в RichEdit. Вот как сделать, чтобы файл не могли удалить следующие редакторы документа.

Загружать файл на сервак и открыватьего или новый RichEdit (вычисляемый) подключать.

В общем хочу узнать как это делается. И как правильней это делать.

Если поможете с кодом - буду благодарен

 

[Andre]

А если использовать разграничение доступа следующее:
всем доступ авторский, а вот людям которые могут удалять файлы - editor.
В дизайнере в свойствах rich text поля ставим must have at least editor access to use.
Хотя по условиям задачи такое решение может и не подходить. Попробуй

 

[Guest]

Другого способа нет что ли? Это не совсем подходит.

Может из скрытого РичЕдита кнопкой открывать файл? Вот только как это делается...

 

[Andre]

Что еще можно придумать.
Раз необходимо, чтобы было разграничение доступа к вложению, то можно организовать его при помощи хранения вложений в отдельном специальном документе со своим разграничением доступа к редактированию и чтению документов.
Что в этом решении плохо: создается отдельный документ с хранением в нем вложения. Необходимо реализовать способ отображения имеющихся вложений (например при помощи embedded view. При большом количестве вложений в документ появится некоторое неудобство в плане прокрутки списка имеющихся значений.). Введение разграничения доступа authors и readers поля(как вариант)или можно поиграться с невозможностью редактировать документ при отсутствии у человека определенной роли, наличия его имени в специальном поле ... - события QueryOpen и QueryModeChange документа.
Что хорошо - Все решается при помощи разграничения доступа (authors и readers поля) или возможности редактирования документа. Если есть права на редактирование документа, значит могу и вложения удалять. Прав на редактирование нет - только просмотр вложений

Второй вариант - это хранение вложений в двух rich text полях. Первое поля - editable, второе поле - computed. Computed поле заполняется скриптом в зависимости от наличия вложений в editable поле. Видимость полей определяется например возможностями добавления \ удаления вложений.
Что плохо: дублирование вложений. Заморочки с программной работой с rich text (но решаемо).
Что хорошо: вся логика сосредоточена в одном месте, не нужно заморачиваться с разграничением доступа (authors и readers fields)(все решается при помощи hide when формулы полей)

P.S. Применительно к релизу 5. Насчет релиза 6 - возможно есть еще варианты . Но работаю в нем совсем мало. Тут может кто еще что подскажет

 

[Guest]

Интересные вещи пишите.
Тогда прошу совета как лучше поступить в конкретном случае.

Это основная задача.
Файл вкладывается на стадии создания документа. После этого вложенный файл все сотрудники могут открывать только для чтения (без права его удаления).

Второстепенная задача.
Возможно, что в будущем потребуется разрешить редактирование документа соответствующим сотрудникам. Можно не затрагивать этот вопрос сейчас.....

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

Благодарствую....

 

[Andre]

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

 

[Guest]

<!--QuoteBegin-Andre+19:10:2004, 13:53 -->
<span class="vbquote">(Andre @ 19:10:2004, 13:53 )</span><!--QuoteEBegin-->А что с документом в которм файл вложен ?
Если документ в общем случае не редактируется сотрудниками - т.е. они никакие поля в нем не изменяют (не должны изменять, нет такой необходимости ...), то все довольно просто.
Сразу не продумал такую вероятность. Каюсь[/quote]
Изменяют. Еще как изменяют... Наверное я не так выразился
Документ почти всегда доступен к редактированию, хотя бы кому-нибудь.

 

[Andre]

Тогда остаются только предложенные выше варианты. Не факт что единственные и правильные

Да еще появилась мысль о том, что можно попробовать избежать недостатков способа №2 с хранением вложений в editable и computed полях - а именно дублирование вложений.
Замутить можно например как нить так.
2 rich text поля (editable и computed) остаются. Вводится роль, флаг ... определяющая права пользователя на добавление\удаление вложений. Если права есть то доступно editable поле, иначе только computed.
Если права на добавление вложений есть - отрабатывать например событие QueryClose в котором делать следующее - копировать содержимое editable richtext поля в computed, editable поле удалять и создавать заново пустое, без вложений. таким образом вложения находятся в computed поле и в общем случае для изменений и удалений не доступны

Отрабатывать событие QueryOpen документа и проверять на то, что документ не новый и на наличие у открывающего пользователя роли, флага ... позволяющей добавлять и удалять вложение
--- Если такой роли, флага нет - просто открываем документ - вложения изменить и удалить возможности нет ибо они находятся в computed поле
--- Если такая роль есть - то отменяем открытие документа. Запоминаем его UNID где нить в переменной и делаем такой фокус:
содержимое computed richtext поля копируем в editable. computed rich text поле удаляем и создаем заново пустое. Документ сохраняем, находим его в базе по UNID и открываем на экране

Что в этом способе может быть плохо - заморочек с richtext становится еще больше (но имхо в принципе побороть можно), вероятность возникновения конфликтов увеличивается, поскольку документ при открытии пользователем имеющим права на добавление \ удаление вложений пересохраняется КАЖДЫЙ раз.

Что хорошо - количество вложений не дублируется.

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

В общем решение за тобой.
Если что - спрашивай. Постараюсь помочь чем смогу

 

[Andre]

А вот еще один вариант, простой как грабли :huh: Таки хорошая мысля приходит ..., но иногда не сразу

Значит в дизайнере делаешь свою форму. Например назовем ее RTRead. Поле RichText в нем computed. Добавляем на форму еще одно computed поле <Form>, тип text, значение "RTRead"
Копируем дизайн созданной формы. изменяем значение тип поля richtext с computed на editable. Форму называем
например RTEdit. Запрещаем создавать документы по этой форме из меню Create

В acl базы добавляем роль Attach, которая определяет возможность добавления, удаления вложений

Далее во всех view доступных пользователям, в которых отображаются документы RTRead (а именно документы с такой формой и будут (должны) находиться в базе) в QueryOpenDocument вешаем например такой код

Dim res As Variant
Dim coll As NotesDocumentCollection
Dim doc As NotesDocument
Dim ws As New NotesUIWorkspace

Set coll = source.Documents
Set doc = coll.GetFirstDocument

res = Evaluate(|@If(@isMember("

 

[nor]

Andre
странник
все не то, controlled access section - и все что тут нужно

конечно вещи интересные ты понапридумывал, Andre... но зачем все это?
странник, в эту секцию помещаешь нужные тебе поля, указываешь для нее: 1) формулу доступа для редактирования, 2) формулу скрытия (если нужно)

 

[Guest]

nor
В Упор не вижу подобного.... Может не та версия?

 

[Guest]

nor

А... дошло

Сейчас попробую. Что то раньше руки до секции этой не доходили.

А без секции как сделать? Только так как Andre говорит? Или по другому еще можно?

 

[Domino6]

Странник

Секция с доступом как раз и решит проблему + поставь подписывать и если файл подменят через код то подпись снимится и будет видно вмешательство