Настраиваем историю в DIRECTUM 5.4

Насколько пострадала производительность при добавлении расширенной истории?

По удалению не сделали отчета в коробке: руководство как правило очень интересует - а кто это такой шустрый что поудалял там всякое.. и показывать ему результаты запроса вместо простого и понятного отчета - ну как то не комильфо. Понятно что можно "сделайсам" допилить как обычно. Ну как обычно то все сам да сам..Ну сколько можно то...

Было бы хорошо видеть историю : в формате "было - стало"  в одной записи. а не в двух.и отображать только ИЗМЕНЕННЫЕ реквизиты. Мне не нужны в истории реквизиты если их значение не изменялось при сохранении. Зачем они там? Как то это можно через директиву always управлять? Например завести changed.

Тогда история выглядела бы так:
Например:
Подразделение: было: отдел обращения граждан, стало: канцеляция
Наша организация: было: Завод стало: не завод.

и все. И не нужно длинный список всех рекизитов выводить если они не изменялись при текущей операции редактироваия.Вуаля. Возросла читабельность. снизилась нагрузка на базу. Людям стало жить легче и при разборках в масштабе предприятия - тыкать в историю и говорить смотрите " иванов такой сякой - сумму и расчетный счет контрагента поменял в договоре, а после уехал на гаваи жить как то резко вдруг"

Было бы хорошо: Если я хочу журнализировать целиком справочник (не выбирая какие там поля важные, какие нет)  мне сейчас нужно прописывать каждый раз длинную XML ину... Допустим добавили новый реквизит и забыли добавить его в историю - новый реквизит не зажурнализируется при реализованном подходе "а опишите конкретно какие поля вы хотите видеть в истории..,"
А вот было бы здоровско если: "хочу журнализировать целиком справочник, не хочу описывать xml ину, хочу забыть про проблемы но в случае алярма и ахтунга - быстро найти "кто такой резкий все поменял в записи в т..ч и в недавно добавленном реквизите который туда впихнул коллега но почему то забыл указать что нужно его в xml ине диковинной вписать еще"

Было бы хорошо уйти от редактирования XML а сделать человеческие редактируемые таблицы со списком журналируемых полей в табличной части - пусть генерируют  xml для журналирования по факту сохранения записи в эту таблицу.

И да, присоединяюсь к вопросу выше прозвучавшему:
Пробовали ли разработчики стресс-тест провести - например в сценарии в цикле модифицировать 10 000 записей справочника ОРГ с влюченной ПОЛНОЙ историей изменения и без включенной?
Каковы результаты по времени выполнения?

Все вышенаписанное  - ИМХО.Просьба серьезно не воспринимать.

Вдогонку вопрос : сохраняется ли в таблицах при удалении - наименование удаленного объекта?
ИД собственно - это просто цифры и кто то "удалил объект с ИД 123456" - в отчете - ну как то слабый аргумент "для трибунала" а вот если там будет "удалил объект с наименованием "Очень важный договор на много много рублей НЕ УДАЛЯТЬ!!"  тогда другое дело.  Тогда - вот они неопровержимые доказательства.
А для этого надо чтобы какая то понятная человеку информация об удаленом объекте сохранялась  - не только его ИД.
 

сохраняется ли в таблицах при удалении - наименование удаленного объекта?

Эта информация сохранялась и ранее. В том же виде, что и сейчас дополнительные реквизиты, раньше сохранялись реквизиты "Код", "Наименование", "Состояние" и вроде бы "Наша организация".

Просто сейчас к этим реквизитам можно добавить ещё других.

Поэтому, достать инфу о том, как звался удаленный объект можно было и ранее.

Можно настроить, чтобы в историю попадали только измененные реквизиты и именно так как вы предложили. Подробности лучше смотреть в документации, после этого большая часть ваших вопросов должна отпасть.  Что касается было/стало - такое решение обсуждалось, но было отвергнуто по ряду причин (основная - дублирование информации в истории, бОльший объем данных в базе).

Согласен, было бы замечательно иметь удобный интерфейс настройки! К сожалению иногда бывает так, что выбор происходит не между вариантами "настройки истории в XML" и "история с удобной настройкой", а между "вообще нет настройки" и "настройки истории в XML".

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

...
<requisite name="наименование" when="changed" />
...

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

У реквизита всегда можно применить when="changed" независимо от того, в карточке он или в табличной части.

Игорь, какая-то странная ситуация (она не должна возникать часто). Возможно, у вас слишком многим даны права на удаление объектов в системе, и надо урезать доступные пользователям права доступа?

Дим, тут я думаю даже не вопрос того, как часто это делать, а вопрос юзабилити. В целом хотелось бы уйти от прямых запросов в базу. Поэтому и возникают такие  вопросы, чтобы была возможность это посмотреть прямо из DIRECTUM, а не лезть в базу.

Тезис моего сообщения выделю жирным. Прошу не обижаться, а принять к сведению.
Когда прочитал новость о том, что у нас будет логирование истории обрадовался.
Обновил я значит базу, захожу в ТКД и думаю "сейчас настрою логирование", а там БАЦ-БАЦ-БАЦи ничего не поменялось, захожу в справку, а там....
Реализация изменения реквизитов - это полный провал, после такого я бы уволил программиста который это написал, а точнее того, кто придумал как это будет реализовано.

1. зачем придумывать было новый справочник для этого? есть компонента "Типы справочников"/"ТКД", в табличную часть Реквизиты, нужно было добавить пару столбцов "Логировать - Да/Нет", "Когда логировать - изм/удал/созд", это бы сразу и решало вопрос, что добавив новый реквизит я не забуду его добавить в логирование.
2. Как можно было реализовать, чтобы в историю тупо каждый раз писалось значение реквизита, даже если он не менялся?(Я же в настройках указываю ЛОГИРОВАТЬ ИЗМЕНЕНИЕ РЕКВИЗИТА а оно тупо всегда логируется - это как? нормально?) Если в справочнике 100 реквизитов и меня интересует изменение всех, то будет не история а каша.
3. Если честно я не читал текстов идей и предложений по тому как это реализовать, но первое, что я заметил когда вошел в историю - это "а где предыдущее значение?". Реализовано должно быть как минимум "было/стало", а еще лучше, чтобы была возможность установить, нужно ли видеть предыдущие значение.
4, Настройка логирования это вообще какая-то наркомания.Как это можно было выпустить в релиз?  если Вы не знаете как сделать без этих xml, то нужно сделать чтобы они автоматом формировались.
p.s. Считаю это всё должно быть переделано на нормальный лад. Такая реализация это не уровень компании, которая специализируется на выпуске ПО.

Михаил Извеков, Вы написали:

"Что касается было/стало - такое решение обсуждалось, но было отвергнуто по ряду причин (основная - дублирование информации в истории, бОльший объем данных в базе)."
 

Дублирование информации - это то, что сейчас у Вас получилось.
Если реализовать было/стало и писать в историю только при реальном изменении, то данных было бы в десятки раз меньше.

Евгений, а when="changed" не работает как положено?

Александр, Да работает, сперва не увидел его, но информативности все равно никакой нет.
Немного непонятно зачем нужна секция Action? 

Настройку истории не стали помещать в "Типы справочников"/"ТКД", по нескольким причинам:

1. В этих компонентах хранится разработка, которая экспортируется/импортируется как руками, так и при конвертации на новые версии. Будь история там же - пришлось бы решать (в том числе и вручную, администраторам на местах) многочисленные конфликты с различающимися настройками. А настройки по умолчанию и настройки в конкретных базах точно будут отличатся. Так я знаю клиента-"параноика" (в хорошем смысле) с не очень большим количеством пользователей, но хорошим бюджетом на "паранойю" - они могут включить логирование вообще всего. С другой стороны есть клиент с >10к пользователями, для которого размер баз уже является важным показателем и тот будет логировать только самые важные места.

2. Соответствующих компонент нет для папок и задач. Ну хорошо, для задач есть ТМы, но тогда где настраивать для задач по свободному маршруту?

3. Права и разделение обязанностей. На справочник настроек можно отдельно выдать права тому, кому не стоит выдавать права на изменение разработки. В крупных компаниях бывают администраторы безопасности, которым недосуг разбираться с богатством возможностей Типов справочников, им просто нужно настроить готовую систему.

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

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

Михаил, 

1.  А в чем проблема при экспорте разработки? не делайте в чистой БД стандартного логирования и всё, тогда и проблемы в сравнении не будет.
2.  а зачем это логирование в истории свободных задач? там можно будет посмотреть кто и где вложил какой файл?
А для папок, что фиксировать? там итак в историю попадает изменение прав доступа. Или логировать еще что имя папки сменилось? (попробуй найди папку, если её имя кто-то сменил)
3. Опять же как я дам писать XML для людей которые совсем с этим не знакомы? поэтому данный пункт тоже не решен. А на вопрос в чем сложность автоматом формировать XML Вы так и не ответили...за пару часов начинающий программист напишет функцию, которая сделает подстановку и автозамену строк.

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

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

1. Всё равно будут возникать ситуации когда настройки истории будут не совпадать при импорте. Перенос между базами разработки и продуктива (это всё на стороне клиента), например. Нужно будет дорабатывать механизм импорта (по аналогии с "принимать настройки видов справочников"), но тогда будут проблемы, если настройку всё же надо перенести, возможно частично.

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

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

Для папок в историю попадает сам факт изменения прав, можно настроить, например, какие именно права были изменены.

3. Окей, я повторюсь:

Автоматом формировать XML на основе чего? Какие строки на какие будет менять начинающий программист?

3. Вот смотрите, захожу я в справочник "настройка истории". указываю что для ПИСЬМА ВХОДЯЩЕГО буду настраивать, когда жму кнопку "настроить" выпадает диалог со списком реквизитов ПИСЬМА ВХОДЯЩЕГО, где я просто ставлю галочки напротив нужных мне реквизитов. а при закрытии даилога автоматом формироуется XML и записывается куда нужно. Дел на 2-3 часа для начинающего программиста.

Я боюсь вы недооцениваете сложность разработки визуального редактора настроек истории. При сохранении текущего функционала конечно, а то ваше описание подходит только под функционал вида "всегда записывать вот эти реквизиты на любое изменение объекта в базе".

Не говоря уже о том, что это потом ещё протестировать и описать надо.

Михаил,
"но тогда будут проблемы, если настройку всё же надо перенести, возможно частично"

- они и сейчас есть. В любом случае придется ручками переносить, если надо частично. Так что не аргумент. Но вот то, что настройка идет отдельно от компоненты создает дополнительные проблемы. Надо ж каждый раз помнить, что надо перенести еще и записи справочников настройки.

"Некоторые настройки просто тяжело ложатся на доступ через реквизиты (как предлагаете вы), а не через событие (как сейчас)"

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

У нас 5 возможных событий - делаем 5 детальных разделов (по одному для каждого события) + 5 реквизитов When для каждого события (в целом для события).
В детальном разделе указываем реквизиты (или псевдо-реквизиты для прав доступа) и when для каждого реквизита. Для реквизитов детального раздела дополнительно надо добавить реквизит state (строка добавлена/удалена/изменена).

Где шаблон-то посмотреть, если у меня нет 5.4?

Автоматом формировать XML на основе чего?

- на основе заполнения реквизитов в схеме, что указана выше. Только в одну сторону: из реквизитов в xml. Небольшой for xml sql-запрос (или через MSXML.DomDocument, кому как удобнее) и всё.

Михаил Извеков, да какой визуальный редактор истории, Вам говорят о том, чтобы всё оставить как есть, только вместо ручной правки XML накидать псевдоформу из которой в момент закрытия формировать XML автоматом. 
Еще раз повторюсь - это никак не меняет того, что сделано сейчас, а всего лишь плюсом 2-3ч программирования.
Что там сложного? запросом из базы получить список реквизитов для компоненты закинуть их в таблицу, добавить столбцы с событиями(типа признак) и при сохранении этого всего сформировать XML по таблице. 

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

Александр, есть же Экспорт записей справочников.

По поводу плохого вписывания это я отвечал Евгению на его предложение добавить в табличную часть "Реквизиты" компоненты "Типы справочников" двух столбцов - "Логировать?" и "Когда логировать?". Вот пример XML, которая записывает в историю как именно изменились права на документ:

<?xml version="1.0" encoding="windows-1251"?>
<settings>

  <action name="laRights" when="always">
    <detail when="always">
      <requisite name="ISBEDocAccountID" when="always" />
      <requisite name="ISBEDocAccountName" when="always" />
      <requisite name="ISBEDocAccessType" when="always" />
    </detail>
    <detail state="changed" when="always">
      <requisite name="ISBEDocAccountID" when="always" />
      <requisite name="ISBEDocAccountName" when="always" />
      <requisite name="ISBEDocAccessType" when="changed" />
    </detail>
    <detail state="unmodified" when="never">
      <requisite when="never" />
    </detail>
  </action>
  
  <view><![CDATA[<?xml version="1.0" encoding="windows-1251"?>
  <xsl:stylesheet xmlns:xsl="http://www.w3.org/1999/XSL/Transform" version="1.0">
    <xsl:output method="text" />
    <xsl:template match="/H">
      <xsl:for-each select="./R">
        <xsl:value-of select="@LN" />: <xsl:value-of select="text()" /><xsl:if test="not(position() = last())">, </xsl:if>
      </xsl:for-each>
      <xsl:if test="count(/H/R) &gt; 0"><xsl:text>&#13;&#10;</xsl:text></xsl:if>
      <xsl:for-each select="./D[@I='1']">
        <xsl:for-each select="./TR">
          <xsl:if test="./R[@N='ISBEDocAccessType']">
            <xsl:value-of select="./R[@N='ISBEDocAccountName']"/>
            <xsl:text> - </xsl:text>
            <xsl:choose>
              <xsl:when test="@S='D'">
                <xsl:text>LoadString('ACCESS_RIGHTS_REVOKED_TEXT'; 'SYSRES_SYSCOMP')</xsl:text>
              </xsl:when>
              <xsl:otherwise>
                <xsl:value-of select="./R[@N='ISBEDocAccessType']"/>
              </xsl:otherwise>
            </xsl:choose>
            <xsl:if test="not(position() = last())"><xsl:text>, &#13;&#10;</xsl:text></xsl:if>
          </xsl:if>
        </xsl:for-each>
      </xsl:for-each>
    </xsl:template>
  </xsl:stylesheet>]]>
  </view>

</settings>

После чего, при изменении прав на документ, в истории можно увидеть примерно такой результат:

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

Евгений, я вас понял. То что вы называете "псевдоформой" я назвал "визуальным редактором". XML из примера выше так же не ложится в ваше последнее описание редактора.

И я тоже ещё раз повторюсь, вы недооцениваете сложность промышленной разработки этого функционала. 2-3 часов не хватит даже на лабу для студента сделанную тяп-ляп.

Александр Чугунов, да не обязательно обратно считывать из XML(если это так сложно) - достаточно где-то хранить предыдущие значения для каждой записи информацию, можно в таблице, или вообще в каком нибудь текстовом реквизите этой записи справочника.
Михаил Извеков, так вы начните копать с самого начала разработки Вами этих модулей. Вы сами себя загнали в тупик. Всё что нужно было это логирование изменения реквизитов справочников/документов. А логирование изменения прав доступа для документов и папок нужно реализовывать "по умолчанию", но с настройкой по каждому виду документов с типом "Да (простое логирование)/Да (детальное логирование)/Нет"   и добавить одну общую константу в системе "логировать изменение прав на папках" и всё.
Всё остальное логирование не имеет смысла и не несет никакой полезной информации для пользователей.

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

Михаил, не понял к чему тут про экспорт записей справочников. Я писал что вручную надо переносить только если надо частично перенести. И что при переносе разработки надо не забывать переносить настройки логирования этим тупым [медленным] экспортом/импортом записей справочников (для себя я его переписал, запускается мгновенно и экспортирует намного быстрее). Ваша "промышленная разработка" на ISBL частенько только и тянет что на "лабу" студента, которую никто не рецензирует. А публиковать эти непроработанные и не прорецензированные  "лабы" (раз и два) как материал, достойный внимания, - это вообще звиздец.

А теперь я еще немного Вас помучаю по XML, мне не очень понятен смысл некоторых вещей.
1) Опишите ситуация, когда нужно логировать не измененные записи детального раздела. Я про вот этот вот кусок (который, мне кажется, можно не писать):

<detail state="unmodified" when="never">
  <requisite when="never" />
</detail>

2) Без указания номера детального раздела настройка типа "логировать всё в детальных разделах за исключением вот этого и этого" выглядит сомнительно полезной. Не до конца гибкой получается настройка.

Моя идея заключается в том, чтобы преобразовать иерархию XML в плоские списки табличных частей. Это оставит гибкость настройки, но при этом сделает установку простых настроек более удобной, а чаще всего будут простые настройки типа "логировать вот этот, этот и этот реквизит", а не "логировать всё, кроме".
Судя по всему, эту часть плохо аналитики проконтролировали на юзабилити и разработчики сделали как лучше с технической точки зрения. Сам этим страдал раньше постоянно и сейчас с этим сложно, хоть и стараюсь думать и за пользователей: делал максимально технически правильное решение, а потом пользователям неудобно с этим работать, пользователям надо как проще (при этом возможность гибкой настройки для искушенных оставлять надо).

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

Обсуждения "лаб" по ссылкам предлагаю там и продолжать, к этому материалу они не имеют никакого отношения.

По XML

1. Этот кусок как раз и отключает логирование не измененных записей (при этом надо логировать удалённые и вставленные).

2. Настройка из примера гласит не "логировать всё в детальных разделах за исключением вот этого и этого", а "логировать определенные реквизиты для строк с определённым статусом в детальных разделах и не логировать всё остальное". Поскольку поместить реквизиты с одинаковым кодом в разные детальные разделы нельзя (правда тут есть исключения для нескольких системных реквизитов) - коды реквизитов однозначно указывают какие разделы нужно логировать.

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

Михаил, 

1. по поводу переноса: существует хорошая практика ,что с DEV на TEST настройки видов не переносят, для переноса на бой делают отдельный пакет с TEST на основе ISC. Настройки колонок, как и логирование  позиционируются как настройка, поэтому к DEV никакого отношения иметь не должны, а в TEST должны быть идентичны бою. Думаю, аналогично можно и с настройками логирования делать. К тому же, ничего не мешает сначала принять то, где надо принимать настройки логирования, а потом то, где не надо (можно же сделать сравнение какие настройки были и какие стали).
2. про лабы согласен, это просто эмоции. Вызваны они тем, .что Вы заявили, что "промышленная разработка" у вас это что-то СИЛЬНО более трудоемкое, чем просто разработка. Хотя результат не всегда соответствует. Элементарное рецензирование опытным разработчиком часто просто отсутствует.
3. по XML 
  3.1 я спросил зачем вообще может понадобиться логирование не измененных записей?
  3.2 я выразил мысль без привязки к конкретному примеру XML, а в целом. Наверно, мне следовало уточнить. И вопрос связан с возможностью не указывать имя реквизита (элемент requisite должен быть, да, но без указания имени) для detail, что означает "логировать всё в детальных разделах" (я так понял). Или так нельзя? 
4. В данном случае могла бы быть и гибкость и юзабилити. Как я уже сказал, в XML не хватает только возможности указания номера детальных разделов, а так вроде всё покрывается. Но сверху можно было бы сделать элементарный интерфейс для тех, кому нужны только простые настройки. Тот пример, что Вы привели, легко настраивается без редактирования XML схемой что я привел.

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

3.2 Можно, тогда действительно будет логироваться всё. 

Указание детального раздела для покрытия наших требований нигде не понадобилось, хватило имён реквизитов. Я не исключаю, что в будущем это может измениться и такое указание будет можно сделать. Например, если будут соответствующие пожелания с конретными примерами.

Не смог добиться логирования для табличного реквизита

Пример настройки табличного реквизита:
<action when="always">
<detail when="always">
<requisite name="НССОКонтОргЗначение" when="always"/>
</detail>
</action>

В историю пишется только действие без указания реквизита.

Где я ошибся? 

Может имя реквизита с ошибкой? Попробуйте вообще его убрать и посмотреть, какие реквизиты записались.

Тоже не вышло с таблицей. К стандартной настройке изменения добавила реквизит карточки Инициатор и реквизит детального раздела. Реквизит карточки записывается, реквизит таблицы - нет.

  <action name="laChange" when="always">
    <requisite name="Вид" when="always" />
    <requisite name="ИД" when="always" />
    <requisite name="Код" when="always" />
    <requisite name="Наименование" when="always" />
    <requisite name="Ведущая аналитика" when="always" />
    <requisite name="НашаОрг" when="always" />
    <requisite name="СтатУтв" when="always" />    
    <requisite name="Инициатор" when="always" />
    <detail when="always">
      <requisite 
        name="ОргТ"
        when="always" />
    </detail>    
  </action>

Появилась необходимость отслеживать изменения в справочнике РКК, т.е. создание, изменение и удаление документов, добавил в настройки истории компонент запись с указанием на компоненту ркк, попробовал создать и удалить РКК, но не смог найти где просматривать лог, в истории справочника РКК в типах справочников ничего не появляется, в конкретном справочнике, где я создавал (Внутренние РКК) тоже ничего, в журнале так же нет информации, что я делаю не так? Спасибо

Т.е. на данный момент я могу посмотреть изменения по определенной РКК, открыв её историю, но где я могу посмотреть общую историю, в том числе удаление РКК?

Приветствую. Собственно возник вопрос по ведению истории ссылок в папках. Возможно ли в историю вписывать наименование объекта, ссылка которого была помещена в папку?