• 🚨 29 мая стартует курс «Пентест Active Directory: от теории к практике» от Академии Кодебай

    🔍 Изучите реальные техники атак на инфраструктуру Active Directory: от первоначального доступа до полной компрометации.
    🛠️ Освойте инструменты, такие как BloodHound, Mimikatz, CrackMapExec и другие.
    🧪 Пройдите практические лабораторные работы, имитирующие реальные сценарии атак.
    🧠 Получите знания, которые помогут вам стать востребованным специалистом в области информационной безопасности.

    После старта курса запись открыта еще 10 дней Подробнее о курсе ...

  • Познакомьтесь с пентестом веб-приложений на практике в нашем новом бесплатном курсе

    «Анализ защищенности веб-приложений»

    🔥 Записаться бесплатно!

Как лучше сделать в форме историю ответных документов?

  • Автор темы Автор темы masyna
  • Дата начала Дата начала
M

masyna

Доброго всем вечера Господа!!!

Такая проблемка, хочу чтобы в одной из главных форм отображались в виде истории ответы на эту форму, которые можно отрыть тут же из формы!! Я думаю что это делается с помощью встроенной вью, но как это сделать не знаю!! Помогите решить задачку, желательно со всем листингом, если он вообще будет))))

И вот еще что хотелось бы у вас попросить, может кто скинуть пример базы с динамическим выбором документов, с помощью формы выбора??? Очень буду благодарен!!!

Да Я забыл сказать. Я в этом деле новичок, поэтому может вопрос покажется и глупым)))))
 
Я в этом деле новичок
судя по всему, в изучении справочной системы ты тоже новичек? ))

внедренный вид имеет свойство "Show single category" - это можно почитать в справке.
работает это свойство в паре с видом таким образом, что вид фильтруется по первой категоризированной колонке.

например, если по твоей задаче построить вид, который отбирает только дочерние документы к документам по заданной форме, то первая категоризированная колонка может быть сформированна по формуле:
Код:
@Text($REF)
а свойство внедренного вида "Show single category" на форме родительского документа может иметь значение:
Код:
@Text(@DocumentUniqueID)
 
Встроенная вью добавляется на форму через меню "Create\Embedded Element\View". В св-вах встроенной вьюшки на второй закладке есть галка "Show only current thread". Она означает, что должна отобразиться то дерево респонсных документов из указанного вью, в которой содержится текущий документ, открытый по данной форме. В качестве встроенной должны быть обычная вьюшка с отображением иерархии респонсов.
 
В св-вах встроенной вьюшки на второй закладке есть галка "Show only current thread"
ух ты! хороший вариант! я как-то его упустил в своей практике...

единственное, как я понял, в этом внедренном виде будет отображаться и головной документ, и от этого не уйти (?), но, если это не помеха, то очень хороший вариант!
 
Большое спасибо очень помогло, но вот возник еще один вопрос!!!!

Как сделать ответный документ сразу к нескольким основным документам одной формы???
Поясню Вообще делаю базу данных учета технических средств, в которой есть основная форма описывающая характеристики одного технического средства. Это основная форма в которой хочу сделать историю ответных документов (накладная, акт перевода в другую категорию, акт списания и т.д.). Так вот как можно сделать Ответный документ (НАКЛАДНАЯ) сразу для нескольких технических средств?????

Еще раз повторюсь, кому не жалко можно образец какой нибудь похожей базы данных!!!
 
Ответный документ может иметь только одного родителя (ссылка на родителя хранится в поле $REF в особом формате).
Можно сделать псевдо иерархию и хранить в накладной UNIDы техсредств в многозначном текстовом поле. В данном случае не будут работать штатные средства Лотуса по поддержке иерархии (doc.Responses, doc.ParentDocumentUNID), но это решаемо.

Может чем поможет элегантная функция от Egor A. Ivanov; InterTrust 13.03.2007 17:24
на входе псевдодочерний документ, имя поля заменяющего $REF и родительский UNID в строке.
Код:
Sub SetRRLItem (note As NotesDocument, itemName As String, itemValue As String)
Dim parent As New NotesDocument (note.ParentDatabase)
Dim response As New NotesDocument (note.ParentDatabase)
Let parent.UniversalID = itemValue
Call response.MakeResponse (parent)
Call response.GetFirstItem ("$REF").CopyItemToDocument (note, itemName)
End Sub

P.S. И не надо так кричать — люди здесь не глухие
 
nvy

а можно разъяснения получить по коду? в чем его суть?
я вижу, что в итоге мы получаем как минимум одно поле $REF в note-документе, но для этого достаточно было вызвать метод MakeResponse у соответстующего объекта напрямую, т.е. без этого замысловатого способа.
а если мы получим в note-документе два и более полей $REF, то чего этим добьемся?
 
а можно разъяснения получить по коду? в чем его суть?
я вижу, что в итоге мы получаем как минимум одно поле $REF в note-документе...
поле $ref в note не создается.
Call response.GetFirstItem ("$REF").CopyItemToDocument (note, itemName)
суть: не нарушая родной иерархии - выстроить альтернативную по другому полю. Тип поля - Response Reference List, т.о. по нему можно строить вьюхи как по $ref
 
а слона-то я и не заметил :rolleyes: спасибо
суть: не нарушая родной иерархии - выстроить альтернативную по другому полю
а для чего сохранять тип поля (Response Reference List)?
предполагается, что альтернативная иерархия в виде будет по Default строиться?
тогда разве нужен тип RRL?
 
nvy

а можно разъяснения получить по коду? в чем его суть?
я вижу, что в итоге мы получаем как минимум одно поле $REF в note-документе, но для этого достаточно было вызвать метод MakeResponse у соответстующего объекта напрямую, т.е. без этого замысловатого способа.
а если мы получим в note-документе два и более полей $REF, то чего этим добьемся?
Алгоритм следующий
- создаём временный родительский документ
- задаём ему unid актуального родительского документа
- создаём временный дочерний документ
- создаём в дочернем документе поле $REF к временному родительскому документу. Т.к. у временного родительского документа тот же unid, что и у настоящего, то после завершения кода и удаления временного родительского документа из памяти, данная ссылка будет указывать на настоящего родителя
- копируем поле $REF под нужным именем в настоящий дочерний документ.

Данная функция может использоваться для построения альтернативной иерархии. Если поля ссылок делать видимыми, они отображаются в виде ссылок на документы (как в рт-поле).
 
только для этого тип RRL сохраняется?

Если честно, сам я альтернативную иерархию пока нигде не использовал, нужды не было. Наткнулся на любопытный код, взял себе на заметку — может где пригодится. Возник вопрос по теме — я поделился (с указанием авторства). А уж использовать или нет — это каждый для себя сам решает.
 
Akupaka
Кажись, в формулу отбора надо добавить что-то типа Field $REF := MyREF;
 
Мы перед селектом вьюхи делали DEFAULT $Ref:=myParent;
Работало, так как в документах $Ref отсутствовало.
С вариантом Field $REF не экспериментировали :rolleyes:
 
дять, ну ты-то старый аксакал форума! :-) заюзай посик.
дык, не такой уж и старый :discard:
я юзал, и интертраст порыл, и даже по памяти вначале сам написал... но че-то не работает :)
хочется инструкцию :rolleyes:

и вот еще, как мне для одних доков этот дефолт заюзать, а для других нет? :)
бо дефолт оператором в @IF не фухрычит... или я туплю по полной

Добавлено: вопрос отпал. я все сделал правильно... но!
но TIA прав :)
тип поля обязательно RRL

и да! код предложеный nvy весьма полезен

к стати, вот, кому интересно очень хороший пример:

(ищите вложение внизу страницы)
 
Мы в соцсетях:

Обучение наступательной кибербезопасности в игровой форме. Начать игру!

Курс AD