gifts2017

Журнал регистрации изменений во внешней информационной базе 1С (управляемые и обычные формы, демо-сервер)

Опубликовал Виталий Барилко (Diversus) в раздел Администрирование - Журнал регистрации

Давно известно, что стандартный журнал регистрации фирмой 1С достаточно плохо продуман и реализован. Допустим, он предоставляет информацию об идентификаторе транзакции, но не предоставляет сведения о том какой реквизит был изменен, что, по моему мнению, более важно. Далее самый больной вопрос, как быть, если пользователей работает много, изменений производится тоже достаточно много и Вы пытаетесь, в стандартном журнале найти, кто изменил документ? Как это не печально, но подобная, в общем случае, тривиальная задача займет у Вас очень много времени, т.к. открывается и ищется все чудовищно долго. Простой отбор по какому-нибудь документу может занимать 5-10 минут, а время, как известно, деньги… Так же в стандартном журнале нельзя увидеть, что было изменено в объекте. Т.е. на вопрос, какой конкретно реквизит или строчка в табличной части были изменены, ответа мы не получим. Зачастую нерадивые сотрудники этим пользуются, аргументируя, что они просто открыли документ и вместо кнопки «Закрыть» нажали «OK» ничего не изменив. Не получится настроить встроенный журнал, чтобы из открытого документа или справочника можно было бы нажатием одной кнопки увидеть всю историю изменений. А это очень удобно!

ТОП-продаж! ТОП-5 продаж разработок Инфостарта! Мы регулярно добавляем новые возможности!

Основные возможности

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

1) Подсистема работает в конфигурациях 8.2 и 8.3 в толстом, тонком и WEB-клиенте (обычные и управляемые формы). Сейчас сложилась парадоксальная ситуация. Есть конфигурации, которые используют обычные формы, есть которые работают на управляемых формах, а так же есть те, которые работают и так и так. Наша подсистема позволяет работать в любом режиме, причем если будет запущена в толстом клиенте, то будет интерфейс и формы толстого клиента, если в тонком или WEB, то на управляемых формах. При этом практически не будет никакой разницы с точки зрения функциональности. Вот как выглядит журнал регистрации в толстом и тонком клиенте:

2) Регистрируются изменения для следующих видов объектов: константы, справочники, документы, планы видов характеристик, планы счетов, планы обменов, планы видов расчета, бизнес-процессы, задачи и регистры сведений.

3) Для хранения истории изменений объектов используется внешняя информационная база 1C. Был выбран именно этот механизм хранения, т.к. он не влияет на размер основной информационной базы 1C (Хранитель журнала регистрации), а работа напрямую с внешней базой харнителя позволяет быстро производить чтение и запись событий.

4) При помещении во внешнюю информационную базу история изменений объектов «сжимается». Что это значит? Приведем пример. Допустим пользователь «А» создал документ, заполнил его и провел. Затем пользователь «Б» его открыл и изменил в нем один реквизит, после чего также провел. При этом наша подсистема позволит Вам увидеть, только то, что пользователь «Б» изменил без показа всех реквизитов. Это позволяет точно сказать, что было изменено.

5) Есть возможность настроить список объектов, по которым не нужно отслеживать изменения. Скажем больше: такая возможность просто необходима! Так как в типовых конфигурациях есть, например, справочники «Сохраненные настройки» или «Рабочие места», по которым нет необходимости вести историю изменений т.к. эти справочники служебные. Так же можно ограничить запись не только объектов, но и конкретных реквизитов!

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

7) Возможность записи событий входа и выхода пользователей в информационную базу (при желании можно отключить).

8) Гибкая система отборов: по пользователю, компьютеру, типу метаданных, объекту, представлению, событию за период. Все отборы устанавливаются на фантастической скорости! Это не десятки минут ожидания работы типового механизма. Все просто и быстро.

9) Минимальное влияние на производительность. Вы практически не почувствуете разницу при работе с нашей подсистемой и без нее. При разработке подсистемы мы руководствовались тем, что перенос событий во внешнюю ИБ 1С не будет оказывать никакого влияния на размер основной информационной базы.

10) Для типовых конфигураций разработаны внешние печатные формы, которые позволят просматривать истории изменений объектов при печати. Т.е. для любых объектов типовых конфигураций (БП, ЗУП, УПП, УТ, КА, БГУ, УНФ) можно за пару щелчков мыши, нажав на кнопку «Печать» и выбрав пункт «Просмотр изменений» открыть изменения данного объекта.

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

12) "Откат" изменений объектов в конфигурации на предыдущие версии по данным журнала регистрации.

13) Один журнал регистрации для нескольких информационных баз 1С.

14) Поддержка ведении истории в распределенных информационных базах (РИБ) с двумя способами ведения истории.

Как это выглядит на примере?

Возможности - это хорошо, но как это выглядит в реальной жизни? Вот вопрос, который беспокоит всех. Мы постарались сделать работу с журналом в максимально простом и понятном виде. Рассмотрим несколько примеров.

Пример 1.

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

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

Пример 2.

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

Открываем событие:

Видим, что в искомом документе пользователь "Абдулов" изменил в 1-ой строке табличной части "Товары", реквизит "Количество" с 300 на 100. При изменении количества поменялись так же и суммы.
Все достаточно просто и понятно.

Это всего лишь примеры, но именно они показывают всю мощь подсистемы.

Вопрос-ответ

Вопрос: Сложно ли интегрировать подсистему в конфигурацию?
Ответ: Абсолютно ничего сложного. В руководстве для пользователей установка описана до мелочей. Ее сможет установить человек, который никогда прежде ничего подобного не делал.

Вопрос: А код подсистемы открыт?
Ответ: Да. Подсистема полностью открыта.

Вопрос: Будет ли система и дальше развиваться и обновляться?
Ответ: Конечно! Подсистема постоянно развивается и обрастает новым функционалом. После покупки в качестве бонуса первые полгода обновления предоставляются бесплатно. После окончания бесплатной поддержки и получения обновлений, Вы можете их продлить: 1 год - 7800 руб, 2 года - 11800 руб. В новых версиях мы улучшаем подсистему, добавляем новые возможности, а так же адаптируем подсистему к изменениям в платформе 1С.

Вопрос: Подсистема работает и на обычных формах и на управляемых? На каких конфигурациях?
Ответ: Функционал и для обычных и для управляемых форм одинаковый, соответственно подсистема работает как на обычных формах, так и на управляемых. По скриншотам из публикации это видно. Кроме того, подсистема одинаково успешно будет работать в ЛЮБОЙ конфигурации, как типовой, так и не типовой.

Вопрос: Если в организации несколько баз, для каждой надо приобретать отдельно, или достаточной одной лицензии?
Ответ: В пределах одной организации достаточно одной лицензии, причем подсистему можно использовать во ВСЕХ конфигурациях организации. Если же в одной информационной базе ведется учет сразу нескольких организаций, то так же достаточно только одной лицензии.

Если остались еще вопросы, добро пожаловать в демо-версию!

Последние обновления

[+] - новый функционал, [*] - изменение, [!] - исправление ошибки

03.08.16 Версия подсистемы 3.0.7.5

[+] Добавлена возможность выполнять перенос кэша с помощью запуска рабочей ИБ из командной строки под специальным именем пользователя "РегламентныеЗадания".
[!] Исправлена ошибка при выполнении регламентного задания по контролю активности пользователей.
[!] Исправлена ошибка подключения к информационной базе с журналом из внешнего соединения.
[!] Убрана регистрация входов пользователей из внешнего соединения.
[!] При выключенной регистрации входов/выходов пользователей настройка игнорировалась и выходы фиксировались.

17.07.16 Версия подсистемы 3.0.7.2

[+] В форму события добавлена возможность открывать отчет по изменения по объекту из текущего события, отчет покажет все версии объекта и цветовым оформлением выделит добавление/изменение/удаление реквизитов и строк табличных частей.
[+] Добавлена настройка (размер порции данных, в настройках, закладка "Дополнительно"), которая позволяет переносить только определенное количество записей за один раз при выполнении регламентного задания по переносу событий из кэша в "Хранитель". По умолчанию она устанавливается в 10000 записей за одно регламентное задание.
[+] В связи с тем, что в версии 1С 8.3.8 запрещены серверные методы при отключенном режиме совместимости, теперь фиксирование выходов пользователей делается добавленным регламентным заданием "(ВН)Контроль активности пользователей"(сравнивается текущий список активных пользователей и список пользователей при прошлом запуске регламентного задания). Такие ухищрения добавлены из-за нововведений в платформу и невозможности использования серверных вызовов при закрытии приложения.
[*] В форме кэша в регистре сведений очистка регистра теперь осуществляется с предварительным вопросом к пользователю.
[*] Изменен механизм построения отчета по изменениям объектов. Значительно увеличена скорость работы отчета. Особенно хорошо заметна разница на больших информационных базах. Добавлена настройка, которая позволяет не раскрашивать отчет, что в некоторых случаях так же влияет на скорость формирования отчета. Наша команда выражает благодарность Старченко Роману за оказанную помощь в изменении отчета.
[*] В форме печати события снят флаг "Защита" в обычной форме. Теперь печатную форму можно сохранить в файл.
[*] В версии 8.3.8 при отключенном режиме совместимости теперь не регистрируются события выхода пользователей в связи с ограничениями, который были введены в платформу.
[*] Полностью изменен механизм обновления и первоначального заполнения подсистемы. Если по какой-то причине обновление невозможно, то подсистема скажет об этом.
[*] Проведены работы по отказу открытия событий журнала при недоступности объектов источников по RLS. Т.е. нельзя открыть события по объектам, которые недоступны пользователям.
[*] При открытии настроек и журнала регистрации добавлена проверка прав.
[*] При выводе дерева метаданных в настройках, теперь метаданные сортируются по представлению. Если же в конфигурации нет целой ветки метаданных, например, бизнес-процессов, то она не отображается. Увеличена скорость отображения дерева метаданных при открытии.
[!] Если подсистема не имела соединения с "Хранителем журнала регистрации", то не выполнялись некоторые отборы по доступным записям из кэша в журнале (пользователи, метаданные, ссылки метаданных, события).
[!] Если журнал был открыт и в момент между обновлением журнала и открытием события с открываемым событием произошло какое-то действие, например, перенос из кэша в хранитель, или в хранителе определены изменения, то данная ситуация теперь обрабатывается подсистемой корректно и событие открывается.
[!] При включенном технологическом журнале ранее появлялись записи при работе фонового задания связанные с работой параметров сеанса. На самом деле ошибки не возникали, события просто фиксировались в технологическом журнале. Данный недостаток устранен.
[!] При восстановлении объекта из истории и открытии формы в толстом клиенте, реализовано открытие формы с признаком модифицированности.
[!] В версии 8.3.8 при отключенном режиме совместимости и завершении работы исправлена ошибка "Серверные вызовы при завершении работы запрещены".
[!] Исправлена ошибка, когда при применении настроек не запоминались галочки в дереве регистрируемых объектов, при выбранном методе регистрации "Фиксировать только то, что выбрано, новые объекты не фиксировать".

14.04.16 Версия подсистемы 3.0.6.1

[+] Реализована проверка прав доступа текущего пользователя к просмотру содержимого событий журнала. События по объектам, к которым нет доступа у пользователя теперь приводят к предупреждению "Нарушение прав доступа!". Ранее могла быть такая ситуация, когда в ИБ включен RLS или недоступны какие-то метаданные для чтения, и пользователь, имея доступ к журналу, не мог видеть объекты, которые созданы, но мог открыть событие в журнале регистрации и посмотреть изменения объекта со всеми значениями реквизитов. Данная коллизия устранена.
[+] Добавлена возможность определять регистрировать или нет добавленные в конфигурацию после настройки подсистемы объекты (FS#436). При добавлении нового объекта метаданных, ранее объекты фиксировались в любом случае. Теперь эта настройка опциональна, на закладке ""Регистрируемые объекты"" появился реквизит, который может принимать значения:
- Фиксировать то, что выбрано и новые (добавляемые) объекты (так работало ранее)
- Фиксировать только то, что выбрано, новые объекты не фиксировать (добавлено)
[+] Подробнее о новом виде можно прочесть в обновленной документации к конфигурации.
Доработана проверка параметров уникальности информационной базы с учетом особенности строки подключения отказоустойчивого кластера. Теперь в качестве разделителя при перечислении серверов можно использовать еще один символ. Символ вертикального слеша "|" (использовать без кавычек) и отделять варианты именования серверов данным разделителем.
[*] Изменена длина реквизита НомерЗаписи в регистре сведений "(ВН) Кэш журнала регистрации".
[*] При очистке кэша из формы регистра кэша, если открыт журнал, то список с событиями обновится после очистки.
[*] В форме просмотра строки в событии изменен просмотр длиной строки, теперь просмотр представлен в виде удобном для чтения. Строка открывается в отдельном окне при двойном клике по значению реквизита.
[!] Важно! Исправлена ошибка, которая иногда приводила к блокировкам в информационной базе при высоких нагрузках.
[!] В отборе по значениям, которые встречаются в изменениях исправлена ошибка отбора записей в кэше.

Конфигурация "Хранитель журнала регистрации"
[+] В настройки добавлена возможность фиксировать только изменения событий. Т.е. можно настроить, чтобы значения реквизитов, которые не были изменены не сохранялись в "Хранителе". Эта возможность позволит существенно снизить объем информационной базы, но при этом может пострадать наглядность информационной составляющей события.
[+] В форму списка событий добавлена подсказка о количестве обработанных и не обработанных событий, а так же комментарий с общей оценкой обработки данных.
[+] Изменен механизм переноса данных из информационных баз в "Хранитель". Повышена производительность. На тестовых данных скорость переноса увеличена в несколько раз.
[+] Изменен механизм обработки событий и определения изменений в событиях (что было/что стало). Повышена производительность, в особенности для регистров сведений. Теперь для каждого уникального сочетания измерений не создается отдельная записи создается отдельное событие, а происходит запись набора данных как одного события. Это существенно увеличило скорость обработки данных для регистров сведений.
[+] В настройках добавлена возможность удалить события с определенным типом метаданных. Возможность пригодиться при не верной первоначальной настройке списка объектов (добавили лишнее). Для того, чтобы удалить лишние события, щелкните правой кнопкой в дереве настроек метаданных и выберите пункт "Удалить данные".
[+] В регистр сведений "Образы объектов" добавлен реквизит "Изменение", ссылающееся на последнее изменение на которое в будущем позволит при удалении родительского события очищать сведения по устаревшим образам объектов.
[*] У регистра сведений "внИзменения" убрано индексирование по реквизиту "Изменено" как избыточное. Добавлен реквизит "ИдентификаторЗаписи" для быстрой работы событиями по регистрам сведений.
[*] Добавлена возможность запускать обработку событий хранителя из командной строки. Для этого необходимо создать пользователя "РегламентныеЗадания" (без кавычек) и настроить запуск конфигурации из под этого пользователя.
[*] В справочнике "Реквизиты объектов" у реквизитов ИмяТЧ и ИмяРеквизита для оптимизации изменена длина строки.
[*] Изменена форма "Настройки хранения и обработки событий" в нее добавлены дополнительные настройки и возможности. Форма переименована на "Настройки" .
[!] В разделе "Настройки и администрирование" убраны не актвиные для нажатия гиперссылки.
[!] В форме "Настройки" при изменении срока хранения событий не устанавливался номер регламентного задания. Ошибка исправлена. (FS#432).

11.02.16 Версия подсистемы 3.0.5.0

[+] Теперь при переносе данных в ИБ "Хранитель" данные передаются пакетами (N-ое количество записей кэша). В настройки подсистемы добавлен реквизит "Размер пакета переноса данных". Данный параметр указывает на количество передаваемых записей в пакете. Чем он больше, тем меньше обращений к COM-соединению при передаче данных в "Хранитель", тем быстрее будет осуществляться перенос. Не стоит устанавливать большие значения, оптимальное значение 100 элементов в пакете. Использование данного механизма позволяет существенно увеличить скорость перемещения кэша в "Хранитель журнала регистрации".
[+] Для справочников и документов существенно увеличена скорость записи изменений в кэш.
[+] У справочника внКэшЖурналаРегистрации убран флаг "Использовать стандартные команды", данный справочник отмечен к удалению в будущих версиях. Роль кэширующего объекта для журнала занял регистр сведений "внКэшЖурналаРегистрации".
[+] Добавлена возможность (кнопка) в настройках подсистемы на закладке "Регистрируемые объекты" исключить реквизиты с типом "ХранилищеЗначения" из регистрируемых. Это позволит сократить объем хранимых данных (FS#431). Рекомендуется не фиксировать изменения в данных реквизитах.
[+] В форму события журнала добавлена кнопка "Печать", которая открывает печатную форму по событию из журнала. Форма предназначена для демонстрации изменений пользователя в удобном виде и для осуществления при необходимости печати данных события на бумажном носителе.
[+] При переносе кэша в хранитель реализовано пере подключение в случае, если COM-соединение было потеряно. Так же если соединение пропадает по какой-то причине, то подсистема пытается снова подключиться к хранителю.
[*] Добавлена запись в стандартный журнал регистрации при невозможности подключения к внешней базе "Хранитель журнала регистрации".
[*] В форме события добавлена возможность для открытия значений реквизитов с типом "Строка" для просмотра в диалоговом окне. При двойном щелчке, в открытом событии журнала на значении реквизита открывается диалоговое окно с данным значением. Ранее открывались только объекты ссылочных типов. Возможность добавлена так как, для длинных строк, не видно полностью, какое значение было ранее (FS#346).
[*] Убрана настройка для определения способа представления (при регистрации/в регламентном задании). Подсистема теперь определяет представление только в регламентном задании.
[*] Модифицирован отчет "(ВН) История изменений объектов", теперь отчет более точно показывает изменения, так же дополнительно отображаются цветовое оформление события "Удаление".
[*] При открытии формы отбора теперь отображаются все пользователи, в том числе и те, которые еще не были перенесены из кэша в "Хранитель". Отбор по таким пользователям осуществляется только по записям из кэша.
[*] У роли "внАдминистраторЖурналаРегистрации" убран флаг "Администрирование" для конфигурации в целом. В новых конфигурациях на основе БСП это приводило к ошибке.
[*] В отчете "(ВН) История изменений объектов" организован вывод с учетом сортировки по строкам табличной части.
[*] В управляемом приложении оптимизирован вывод данных из ИБ "Хранитель".
[*] В подсистеме изменен термин "сжатие" на "обработано".
[*] В форме журнала кнопка "Вернуться к предыдущей версии", теперь становиться не доступной, если текущая событие не подразумевает восстановление объекта.
[!] Исправлена ошибка отображения изменений для не ссылочных объектов метаданных (регистры сведений, константы и т.д.) (FS#430).
[!] При открытии объектов, в которых хранились в качестве реквизитов значения с типами УникальныйИдентификатор, или ХранилищеЗначения иногда могла появляться ошибка формата потока. Ошибка исправлена.
[!] При создании первоначального образа и отказа после создания перенести события из кэша в ИБ хранителя, ошибочно выдавалось сообщение об успешности переноса кэша в хранитель.
[!] Исправлена ошибка в отчете "(ВН) История изменений объектов", когда при изменении данных в клиентском приложении и в результате изменения данные из web-сервиса по-разному получалось представление значения булевого типа.
[!] При обновлении в форме журнала регистрации в подсистеме в некоторых случаях фокус не устанавливался на строку до обновления, например, для входов и выходов.
[!] В обычных формах некорректно работало восстановление периода по умолчанию после отключения отбора по одному объекту (FS#463).
[!] Исправлена неточность при отображении событий в которых есть изменения. Ранее туда не попадали события, которые перенесены в "Хранитель", но не сделана обработка этих записей.
[!] Исправлена ошибка при восстановлении объектов на предыдущие версии на основании данных журнала.
[!] В обычных формах при отключенной галочке "Вести историю изменений" были доступны некоторые реквизиты.

Конфигурации "Хранитель журнала регистрации" 1.0.3.7

[+] В настройки добавлена возможность фиксировать только изменения событий. Т.е. можно настроить, чтобы значения реквизитов, которые не были изменены не сохранялись в "Хранителе". Эта возможность позволит существенно снизить объем информационной базы, но при этом может пострадать наглядность информационной составляющей события.
[+] В форму списка событий добавлена подсказка о количестве обработанных и не обработанных событий, а так же комментарий с общей оценкой обработки данных.
[+] Изменен механизм переноса данных из информационных баз в "Хранитель". Повышена производительность. На тестовых данных скорость переноса увеличена в несколько раз.
[+] Изменен механизм обработки событий и определения изменений в событиях (что было/что стало). Повышена производительность, в особенности для регистров сведений. Теперь для каждого уникального сочетания измерений не создается отдельная записи создается отдельное событие, а происходит запись набора данных как одного события. Это существенно увеличило скорость обработки данных для регистров сведений.
[+] В настройках добавлена возможность удалить события с определенным типом метаданных. Возможность пригодиться при не верной первоначальной настройке списка объектов (добавили лишнее). Для того, чтобы удалить лишние события, щелкните правой кнопкой в дереве настроек метаданных и выберите пункт "Удалить данные".
[+] В регистр сведений "Образы объектов" добавлен реквизит "Изменение", ссылающееся на последнее изменение на которое в будущем позволит при удалении родительского события очищать сведения по устаревшим образам объектов.
[*] У регистра сведений "внИзменения" убрано индексирование по реквизиту "Изменено" как избыточное. Добавлен реквизит "ИдентификаторЗаписи" для быстрой работы событиями по регистрам сведений.
[*] Изменена форма "Настройки хранения и обработки событий" в нее добавлены дополнительные настройки и возможности. Форма переименована на "Настройки" .
[!] Добавлена возможность запускать обработку событий хранителя из командной строки. Для этого необходимо создать пользователя "РегламентныеЗадания" (без кавычек) и настроить запуск конфигурации из под этого пользователя.
[!] В справочнике "Реквизиты объектов" у реквизитов ИмяТЧ и ИмяРеквизита для оптимизации изменена длина строки.
[!] В разделе "Настройки и администрирование" убраны не актвиные для нажатия гиперссылки.
[!] В форме "Настройки" при изменении срока хранения событий не устанавливался номер регламентного задания. Ошибка исправлена. (FS#432).

30.09.15 Версия подсистемы 3.0.2.3

[+] Добавлена возможность запуска ИБ "Хранитель журнала регистрации" из настроек подсистемы.
[+] Добавлен функционал, позволяющий существенно увеличить скорость работы в высоконагруженных ИБ. Узким местом в фиксировании события является механизм определения представления объектов ссылочных типов, для увеличения скорости предусмотрена настройка на вкладке "Дополнительно" в настройках, которая позволяет для каждого из объектов определять представление объектов ссылочных типов в фоновом задании при переносе кэша в информационную базу "Хранитель".
[+] Добавлена роль "(ВН) Не фиксировать события журнала регистрации", которая позволяет отключать регистрацию изменений для конкретных пользователей. Настройка для текущего пользователя вступает в силу после перезапуска конфигурации в режиме предприятия.
[*] Удалена подписка на события "внЖурналРегистрацииПередУдалениемКэша", как не обязательная.
[*] Добавлено индексирование по измерениям в регистре "внИзменения".
[*] Реализована более оптимальная запись изменений по регистрам сведений. Причем улучшена как запись изменений в кэш, так и перенос в ИБ "Хранитель журнала регистрации".
[*] Добавлены формы просмотра элементов кэша в управляемом и обычном приложении.
[*] Добавлена дополнительная проверка при переносе кэша в ИБ хранителя, которая при одновременном выполнении из двух мест выполнялось только первый раз. Т.е. когда запущено параллельно и фоновое задание переноса кэша в хранитель и выполняется перенос вручную из формы настройки.
[*] Добавлено обновление данных в открытом журнале регистрации, при ручном переносе из кэша в информационную базу "Хранитель журнала регистрации" на закладке "Мониторинг" в настройках.
[!] Для некоторых регистров, в особых случаях, могла возникать коллизия записи в журнал. Это могло привести к тому, что данные по изменениям не записывались.
[!] Исправлена ошибка открытия объекта по двойному щелчку на ячейке в форме события.
[!] Исправлена ошибка, при которой для пользователей без ролей "вн..." на журнал регистрации, иногда могла отображаться ошибка "Нарушение прав доступа" при запуске конфигурации (обычные формы, клиент-серверный вариант).
[!] В отчете "(ВН) История изменений объектов" исправлена ошибка, которая возникала если по исследуемому объекту некоторые данные содержатся в кэше.

Конфигурации "Хранитель журнала регистрации" 1.0.2.3

[*] Удалены подписки на события "внПередУдалениемСобытияЖурналаРегистрации", "внПередУдалениемИдентификатораОбъекта" как не обязательные.
[!] В некоторых случаях не выполнялся запрос из журнала ИБ в настройках мониторинга по количеству объектов из подсистемы конфигурации по COM-соединению.
[!] Исправлена ошибка выполнения по регламентному заданию вместо очистки, обработка.

28.08.15 Версия подсистемы 3.0.1.1, версия 

[+] Добавлены два события открытие и закрытие форм. Эти события можно использовать для фиксирования открытия и закрытия обычных и управляемых форм в конфигурации. Подробнее как внедрить этот функционал см. в документации.
[+] Для типовых конфигураций на управляемых формах (которые используют БСП), реализована внешняя печатная форма "История изменений объекта по журналу регистрации", которая открывает для объектов из формы элемента/объекта и списка историю изменений основываясь на данных журнала.
[+] Добавлена возможность обработки данных в информационной базе "Хранителя" из рабочей информационной базы (в настройках закладка "Мониторинг").

[*] Добавлен реквизит "ПропускатьОбработку" в справочнике кэша "внЖурналРегистрации", который указывает необходимо ли определять образ объекта для обработки перед обработкой определения реквизитов.
[*] Увеличена скорость открытия событий из внешней информационной базы хранителя.
[*] Увеличена скорость получения данных по мониторингу из хранителя.
[*] Изменения данных производимые фоновыми заданиями теперь регистрируется под пользователем "Фоновое задание" (для платформы 1С 8.3).
[*] Добавлен общий модуль "внЖурналРегистрацииСервер" в который были перемещены методы записи в кэш, а также перенос кэша в информационную базу "Хранителя". Произведен рефакторинг кода.

[!] В клиент-серверном варианте при использовании толстых форм, у пользователей без полных прав, или у тех, пользователей у которых не было ролей просмотра или администрирования журнала регистрации была ошибка с правами на добавление объектов в журнал.

Конфигурации "Хранитель журнала регистрации" 1.0.1.1

[+] Добавлены два события открытие и закрытие формы. Эти события можно использовать для фиксирования открытия и закрытия форм в конфигурации. Подробнее как внедрить этот функционал см. в документации.

[*] Добавлен реквизит "ПропускатьОбработку" в справочнике хранения "внЖурналРегистрации", который указывает необходимо ли опредлелять образ объекта для обработки перед обработкой определения реквизитов.

[!]Исправлена ошибка, которая появлялась в форме настройки хранителя при нажатии на флаг "Автоматически удалять устаревшие события".

05.08.15 Версия 3.0.0.0

[+] Полностью изменен механизм хранения внешнего журнала регистрации. Теперь внешняя база MS SQL заменена на внешнюю информационную базу 1С (Хранитель журнала регистрации), что позволит хранить и обрабатывать журнал более гибко.
[+] Теперь регламентные операции с журналом происходят в ИБ "Хранителя журнала регистрации", в рабочей информационной базе не производится определения изменений, данные событий полностью перегружаются в ИБ хранителя, а уже там происходит анализ по изменениям.
[+] Во внешней ИБ "Хранитель журнала регистрации" теперь не происходит операции "сжатия". Каждое событие записывается полностью, а вместо сжатия происходит анализ на изменения и помечаются те реквизиты, которые были изменены.
[+] При открытии события в журнале регистрации появилась возможность как просмотра изменений, так и образа объекта в целом.
[+] Данные кэша из ИБ источника не обрабатываются, а переносятся в ИБ хранителя, где в дальнейшем обрабатываются.
[+] Изменены настройки журнала, удалена вкладка "Сжатие и очистка", появилась вкладка "Мониторинг журнала", которая позволяет посмотреть на состояние "Хранителя журнала регистрации" и локального кэша журнала, а так же перенести локальный кэш во внешнюю ИБ вручную.
[+] Реализован механизм кэширования внешнего соединения к ИБ "Хранитель журнала регистрации".
[+] Добавлен механизм проверки обновлений. Теперь один раз в неделю при открытии журнала происходит проверка обновления подсистемы.
[+] Добавлено новое событие "Начало сеанса (роли изменены)". Которое будет означать, что у пользователя были изменены роли. Работает только если включен механизм фиксирования входов и выходов пользователей. Событие строится на основе данных при входе пользователя проверяются доступные роли, а когда данное событие переносится в ИБ хранителя определяется были ли изменения ролей или нет.
[*] Удалены многие объекты из старой редакции, т.к. часть функционала была перемещена на сторону ИБ хранителя.
[*] Изменен отчет "Активность работы пользователей", добавлены варианты отчетов (Основной, По метаданным, Диаграмма пользователей).
[*] Удалена роль "(ВН) Пользователь журнала регистрации", она с текущей версии уже не нужна. Теперь для всех пользовтелей по умолчанию включена регистрация изменений.
[*] Изменены наименования модулей подсистемы.
[*] Теперь запись изменений делается не в табличную часть справочника кэша, а в отдельный регистр "внИзменения". При этом основное событие всегда одно, а не разбивается на части когда количество строк изменений более 99999.
[*] В управляемой форме журнала два реквизита "Дата начала с" и "по" (период выбора событий) заменены одним единственным реквизитом "Период".
[*] Удален механизм подписок на события для изменений. Подобный механизм со временем будет перенесен и функционально расширен (оповещение на e-mail и sms информирование об изменениях) в ИБ хранителя журнала регистрации.
[*] Появился переопределяемый модуль "внЖурналРегистрацииПереопределяемый", которые позволит существенно расширить механизм добавления своих событий.
[!] Исправлена ошибка дублирования удаляемых данных из регистров сведений с ведущем измерением "ЛюбаяСсылка" или "СправочникСсылка". Если для этого регистра включена регистрация изменений, это приводит к невозможности определения изменений (удаление записи из кэша вызывает запись набора записей регистра, при этом создается новая запись кэша) (FS#329).
[!] Исправлен внешняя печатная форма для типовых конфигураций на обычных формах: УТ 10.3, ЗУП 2.5, УПП 1.3 и т.д. Печатная форма не отображала корректно изменения по текущему объекту.

19.02.15 Версия 2.0.3.6

[!] Исправлена ошибка, которая могла возникать при сжатии кэша журнала регистрации на больших объемах данных. Изменен механизм получения данных при сжатии.

20.01.15 Версия 2.0.3.5

[+] Оптимизирована структура базы данных MS SQL. Реквизиты "имя табличной части" (nametp) и "имя реквизита" (namerec) вынесены в отдельную таблицу "props", что должно существенно уменьшить размер базы данных внешнего журнала. Запрос выполненный перед обновлением подсистемы должен изменить структуру базы данных.
[+] В настройках добавлен флаг "Фиксировать перепроведение документа". Если флажок установлен и происходит перепроведение документов, без изменения реквизитов, то фиксируется событие "Проведение" (FS#283).

[*] При первоначальном заполнении теперь происходит сжатие, а не прямая запись в MS SQL, как было ранее, без анализа, есть ли еще версии этого объекта или нет. Сжатие было добавлено в связи с тем, что для больших компаний, первоначальное заполнение выполнялось долго и поэтому принималось решение о том, чтобы они могли работать параллельно первоначальному заполнению. В связи с этим могла появится проблема когда объект был изменен, а потом повторно был создан первоначальный образ и сразу записан в MS SQL (FS#233). Причем сжатие после первоначального заполнения стало опциональным, его можно провести как вручную после создания первоначального образа, так и не запускать и его позже запустит регламентное задание.
[*] В обычных формах в некоторых конфигурациях форма настроек журнала отображалась не корректно (FS#266).
[*] Изменено имя табличной части "Изменения" на "внИзменения" справочника "внКэшЖурналаРегистрации" в связи с тем, что такое же имя используется для таблицы изменений в планах обмена - это могло приводить к ошибкам (FS#281).
[*] В обычных формах в событии изменены цвета чередования строк.
[*] В регламентных заданиях таймаут выполнения запроса теперь равен нулю, т.е. больше нет ограничений по времени выполнения.

[!] При попытке подключения к базе с помощью внешнего соединения возникала ошибка FS#280 в версии для платформы 8.3.
[!] Исправлена ошибка создания базы данных, которая начинается с цифры (FS#270).
[!] Исправлена ошибка "Vardecimal Storage Format is not supported" при первоначальном создании БД на некоторых редакциях MS SQL (FS#316).
[!] В обычных формах при изменении в журнале даты начала или даты окончания отбора, не происходило автоматическое обновление формы списка журнала.
[!] Функция "РазложитьСтрокуВМассивПодстрок" заменена на "внРазложитьСтрокуВМассивПодстрок" в связи с тем, что в некоторых старых конфигурациях одноименная функция находилась в глобальном модуле (FS#265).
[!] Исправлена ошибка, когда физическое представление ссылки одного и того же объекта ссылочного типа, но в разных базах РИБ могло не совпадать. Соответственно при полном обмене в головную ИБ попадали записи, которые представляли одни и те же ссылки, но с точки зрения подсистемы были различными (FS#289).
[!] Исправлена ошибка при первоначальном заполнении в регистрах сведений (FS#296).
[!] Исправлена ошибка при удалении записи из регистра сведений, когда событие удаления не всегда фиксировалось в журнале.
[!] Перед записью регистра сведений изменен механизм формирования запроса к текущему набору записей регистра до изменения. В старом варианте работы могла происходить ошибка, если присутствовало измерение "Набор".
[!] Исправлена ошибка "Incorrect syntax near ‘,’", которая возникает в некоторых случаях при сжатии журнала FS#324

03.10.14 Версия 2.0.2.3

Важно!
Принято решение разделить подсистему на две ветви - для платформы 8.2 и для 8.3, так как все больше организаций переходит на 8.3. Так же это связано с тем, что ряд типовых конфигураций все больше использует режим отказа от модальности, что не поддерживается в 8.2. Отказа от поддержки подсистемы для платформы 8.2 на данные момент не планируется. Будут развиваться обе версии. В обновлении будет две папки, в одной обновление для платформы 8.2, в другой для 8.3. Используйте обновление в зависимости от той версии платформы, которая у Вас установлена.

[+] Добавлена возможность дополнительного отбора не только по объектам, которые изменялись, но и по тем объектам, которые встречались в изменениях (FS#231).
[+] Данную возможность хорошо иллюстрирует пример. Например, необходимо найти все документы, в которых за установленный период была изменена конкретная номенклатура (за сентябрь 2014 года найти все созданные и измененные документы "Реализация товаров и услуг", в которых встречалась номенклатура "Кофе "Чибо").
В отборе появилось два поля на закладке "Данные", вместо одного:
- "Данные, которые изменялись" - старый отбор, который был ранее. Выбирает события-изменения по конкретному объекту.
- "Данные, которые встречались в изменениях" - добавленный реквизит, который позволяет выбрать события, в которых встречался данный объект ссылочного типа, причем это могут быть как изменения этого объекта, так и изменения других объектов, где данный объект добавлен как реквизит или входит в табличные части измененного объекта.

[*] Добавлена возможность при первоначальном заполнении ИБ установить флаги заполнения только для тех объектов, по которым ведется учет изменений (в настройке "Начальное заполнение" кнопка "По регистрируемым").
[*] Добавлена запись в стандартный журнал регистрации при возникновении исключительной ситуации фиксирования записи изменения объекта журналом.
[*] Полностью изменен механизм проверки уникальности. Вместо строки уникальности, теперь используется два параметра:
1) Список серверов, который можно задать через символ ";"
2) Имя информационной базы.
Проверка уникальности происходит по совпадению параметров одного из серверов настройки с определенным для текущей базы сервером, а так же при совпадении имени информационной базы.
Для файловых баз проверка осуществляется только для реквизита имени информационной базы, которая содержит путь к конфигурации.
По умолчанию эти два параметра заполняются по данным текущей базы. Эта возможность необходима для того, что бы обеспечить работу в случаях, когда сервер в сети может быть определен по разному, например: server, server.local или server:1541.
[*] При окончания фонового задания сжатия в стандартный журнал регистрации пишется количество сжатых объектов кэша.
[*] При создании новой базы с журналом регистрации для поля версии (ver) таблицы изменений (journ) изменен тип с smallint до int. В скрипте изменено максимальное количество объектов метаданных, сменен тип с smallint на int. Для уже созданных баз журнала данные параметры не изменятся.

[!] Убрана проверка на доступность роли администратора журнала при открытии настроек. В конфигурациях на основе БСП, данная проверка приводила к невозможности работы с настройками у пользователя с полными правами (FS#228).
[!] Версия изменения объектов могла определяться в некоторых случаях неверно. Ошибка исправлена.
[!] Исправлена ошибка определения имени компьютера, который произвел изменение в клиент-серверных конфигурациях, которые работают на управляемых формах, ранее определялся компьютер сервера, а не клиента, на котором было изменение (FS#236).
[!] Исправлена ошибка при которой не запускалось сжатие из фонового задания.
[!] Исправлена ошибка с доступом на объекты подсистемы для пользователей у которых не установлены роли для работы с журналом (FS#229).

12.08.14 Версия 2.0.1.6

[+] Добавлена поддержка РИБ. Теперь журнал регистрации может вестись в распределенных базах, при этом в дочерних узлах РИБ сжатия не происходит, доступ к журналу есть только в центральной базе. См. документацию как использовать журнал в РИБ. В связи с этим исчезла возможность отключения регистрации при обмене данными.
[+] Добавлена поддержка одного журнала MS SQL для нескольких информационных баз 1С. Теперь достаточно одного журнала для всех информационных баз предприятия. Для информационной базы появился в настройках специальный идентификатор, который закрепляется за информационной базой 1С. Идентификатор информационной базы — это строка, которая должна быть уникальной для каждой базы журнала. В настройках появился этот идентификатор.
[+] Добавлен механизм подписок на события для пользователей. Т.е. появилась возможность добавить подписки, которые будут срабатывать при изменении выбранных объектов или реквизитов и оповещать ответственных пользователей. Т.е., например, если кассир отвечает за кассовые документы, и кто-то отличный от кассира поменял реквизит сумма в документе, то подсистему можно настроить так, что кассир будет оповещен о том, что объект или реквизит документа изменил другой пользователь. События подписок (оповещения) создаются при сжатии объектов из кэша, при этом пользователь получает уведомление только при изменении другим пользователем, собственные изменения не вызывают оповещений.
[+] Добавлена возможность "отката" изменений объектов в конфигурации на предыдущие версии по данным журнала регистрации (FS#48). В журнале появилась дополнительная кнопка.
[+] Добавлена возможность при первоначальном заполнении журнала регистрации ограничивать выборку объектов по периоду. Т.е. документы, бизнес-процессы, задачи и регистры сведений, где есть привязка к периоду могут быть заполнены только для объектов старшей определенной даты (FS#82).
[+] Добавлена возможность не только фиксировать объект целиком, но и управлять фиксированием отдельных реквизитов и табличных частей объекта. Для этого в настройках на вкладке "Регистрируемые объекты" разверните объект и снимите галочки с тех объектов, которые регистрировать не нужно..

[*] Изменена длина строк реквизитов: "Компьютер" со 100 до 80, "МетаданныеОбъекта" с 500 до 300, "Пользователь" с 100 до 80 символов в справочнике "(ВН) Кэш журнала регистрации изменений". Так же из табличной части удалены два реквизита. Это на немного уменьшит физический размер данных кэша подсистемы.
[*] При сжатии уменьшено количество обращений к внешнему журналу регистрации.
[*] В отчете по активности пользователей ниже диаграммы раньше выводилась таблица активности в строку, теперь для удобства она выводится в столбец.
[*] В отборах улучшена работа с деревом метаданных, появился отбор по базе РИБ.
[*] При первоначальном заполнении добавлена возможность регистрировались первоначальное состояние планов счетов, планов обмена, регистров сведений.
[*] Запрещено интерактивное открытие системных объектов подсистемы.

[!] Найдена и исправлена утечка памяти при работе с внешней базой данных MS SQL.
[!] Для иерархических справочников и планов видов характеристик исправлена ошибка, при которой для групп, выводились реквизиты элементов, а для элементов - реквизиты групп.
[!] При первоначальном заполнении журнала регистрации исправлена ошибка, при которой, в некоторых случаях, не выполнялась регистрации планов обмена и планов видов характеристик.

26.06.14 Версия 2.0.0.3

[*] Проверка уникальности информационной базы объединена с проверкой необходимости ведения истории.
[!] Исправлена ошибка чтения наличия пользователей в конфигурации.

23.06.14 Версия 2.0.0.0

[+] Появилась возможность автоматической очистки журнала регистрации от старых данных по расписанию, которая по умолчанию выполняется один раз в день. Добавлены реквизиты, которые позволяют назначить автоматический интервал очистки в днях.
[+] Добавлена возможность отключения проверки уникальности информационных баз.
[+] Добавлена возможность просмотра истории разработки журнала регистрации из формы настроек.
[+] Добавлена проверка на то, что в информационной базе нет пользователей. Журнал регистрации в таком случае вестись не будет.
[+] Улучшена работа с деревьями в настройках. Теперь строки не сворачиваются при щелчке. Так же добавлено три состояния галочки: Включена, Выключена и Частично включена (видна для родительских, когда часть дочерних строк включена, а часть выключена). Реализовано как в обычном приложении, так и в управляемом.
[+] Добавлена возможность запуска регламентного сжатия и очистки журнала регистрации из командной строки. Для этого необходимо создать пользователя "АвтоматическоеСжатие" (без кавычек) и с помощью командной строки запускать конфигурацию в режиме платформы. При старте под этим пользователем, сжатие будет запущено автоматически и конфигурация будет закрыта после сжатия. Для автоматической очистки все аналогично, только для пользователя "АвтоматическаяОчистка". Более подробно смотрите справку на нашем сайте.
[+] Появилась возможность устанавливать в настройках таймаут соединение с MS SQL в секундах. Значение по умолчанию 180 секунд (3 минуты), при установки в ноль таймаут не устанавливается и запросы ожидают отклика бесконечно долго, пока не получат ответ.
[+] Добавлен модуль "внОбщийМодульПовтИсп" и удален параметр сеанса "внПараметрыЖурналаРегистрации". Теперь настройки подсистемы получаются из общего модуля с признаком повторного использования возвращаемых значений, а не из параметров сеанса. По замерам это привело к существенному увеличению производительности.

[*] Увеличена скорость добавления и удаления элементов в/из кэш(а), при этом будет выполняться минимум проверок в дополнительных подписках на события.
[*] В толстом клиенте при сжатии вручную из настроек журнала выводиться прогресс сжатия, а так же время до окончания сжатия.
[*] Для конфигураций на основе БСП при встраивании и обновлении подсистемы добавлен автоматический запуск обновления справочника "Идентификаторы объектов метаданных".

[!] Исправлено неверное определение изменений при сжатии объектов, которое возникало если изменения одного и того же объекта выполнялись в одно и тоже время.
[!] Исправлена ошибка выполнения отчета по активности работы пользователей. Ошибка появлялась только при использовании MS SQL 2005 и ниже.
[!] Для отчета "(ВН) История изменений объектов" установлена и обычная и управляемая форма.
[!] Убрана неверно формируемая расшифровка для отчета "(ВН) История изменений объектов"
[!] Исправлены найденные ошибки при очистке журнала регистрации.
[!] Увеличена общая производительность работы журнала.

[!] Изменено лицензионное соглашение. С этой редакции начинаем глобальное расширение функционала (поддержка РИБ, один журнал на несколько баз, откат изменений и т.д.).


19.03.14 Версия 1.0.5.5

[+] Добавлен отчет "История изменения объектов", который показывает изменения в объектах ссылочного типа в удобном для просмотра виде, в таблице.
[+] Добавлена возможность при создании БД из настроек получить запрос SQL, который создает БД с журналом, для запуска этого скрипта вручную на сервере MS SQL. 
[*] Из ролей подсистемы удалена возможность просмотра всех функций и роль с правами запуска конфигураций.
[*] При входе и выходе пользователя добавлена Попытка/Исключение. 
[*] При фиксировании события удаления объекта, в кэше все добавляется в транзакции.
[!] Исправлена ошибка регистрации событий планов обмена.

10.01.14 Версия 1.0.4.1

[+] Переработаны принципы записи при изменениях регистров сведений, а так же добавлена возможность определения изменений.
[+] При записи регистра сведений в представление события теперь добавляется установленный отбор, который использовался при записи, это улучшит наглядность.
[+] Добавлен реквизит в события журнала регистрации, который отображает статус сжатия события в кэше (сжат/не сжат).
[+] Добавлена настройка в параметры журнала регистрации, которая позволяет на усмотрение пользователей фиксировать изменения при обмене данными в журнале регистрации. Данная настройка находится на закладке Дополнительно.
[+] Добавлена возможность обработки и отображения своих событий (см. документацию к подсистеме).
[*] Теперь при записи регистра автоматически определяется тип записи ""Изменение"" и ""Физические удаление"" (при очистке).
[*] Изменен механизм при отборе в журнале по текущему элементу. Для регистров сведений отбор происходит по измерениям и стандартным реквизитам: регистратор, период (если они есть), для ссылочных объектов по ссылке, для входа и выхода по типу объекта.
[*] При открытии формы настроек теперь настройки не загружаются все сразу, а только по мере их использования.
[*] При создании первой версии объекта в журнале теперь фиксируется тип события ""Создание"", а не ""Изменение"".
[*] Установлен флаг с возможностью использования модуля ""внОбщийМодуль"" во внешнем соединении.
[*] В журнале регистрации кнопке обновления журнала назначена горячая клавиша ""F5"".
[*] В управляемом режиме для событий, которые не показывают изменений на форме (входы, выходы, изменения констант и т.д.) кнопка показа изменений на форме скрывается при открытии. Для режима на обычных формах данная возможность была доступна ранее.
[!] Исправлена ошибка, определения изменений для констант.
[!] Исправлена ошибка, при которой в конфигурации не фиксировались изменения общих реквизитов объектов.
[!] Исправлена ошибка, которая могла возникать при сжатии объектов и подключении к MS SQL с ошибкой.
[!] Устранена ошибка, при которой при отключении истории изменений, входы и выходы пользователей все равно фиксировались в журнале регистрации.
[!] Исправлена ошибка определения параметров уникальности информационных базы в домене, значения, определяемые в регламентном задании и в сеансе пользователя могли отличаться (ошибка платформы 1С), в связи с чем могло не работать регламентное задание.

12.09.13 Версия 1.0.3.1

[+] Добавлен вывод в настройках журнала регистрации версии подсистемы в заголовок формы настройки.
[!] Исправлена ошибка, которая возникала при записи объектов с большими табличными частями в кэш.

09.07.13 Версия 1.0.2.7

[!] Исправлена ошибка при сжатии объектов и переносе из кэша в БД MS SQL Server, которая могла возникнуть при определенных обстоятельствах.

11.06.13 Версия 1.0.2.5

[+] Для увеличения скорости и стабильности работы полностью изменена схема работы журнала регистрации. Добавлен справочник "(ВН) Кэш журнала регистрации изменений". При изменении данных, данные попадают сначала в этот справочник, а затем переносятся из него в базу данных MS SQL регламентным заданием. Это позволяет существенно увеличить скорость работы подсистемы и избавиться от ошибок соединения с БД MS SQL обычным пользователям.
[+] В событиях добавлена возможность раскрывать/сворачивать реквизиты и табличные части одной кнопкой.
[!] Исправлена ошибка в отчете по анализу работы пользователей в толстом клиенте, при которой дата завершения периода была равна дате начала.
[!] Исправлена ошибка при сжатии данных. Изменения не попадали в журнал, если удалялись строки из табличных частей объектов.
[*] Добавлена обработка событий при проведении/отмене проведения, пометке/снятии пометки удаления. Теперь данные виды операций отмечаются отдельными значками в журнале

09.04.13 Версия 1.0.0.2

[*] Исправлена ошибка конвертации даты, если в MS SQL Server формат даты отличается от '01.01.2013 00:00:00' (например для серверных ОС, у которых в языковых настройках стоит формат '2013/01/01 00:00:00' и т.д.).
[*] Формат даты унифицирован и теперь не зависит от языковых настроек.

Важно! Обновления размещены по дате "сверху-вниз" (последние изменения вверху, первые внизу).

 Сделайте свою жизнь проще! Пусть работа будет приносить только удовольствие!

Лицензии

Наименование Файл Версия Размер Кол. Скачив.
Руководство пользователя, редакция 3.0
.pdf 4,56Mb
19.07.16
542
.pdf 3.0.7.5 4,56Mb 542 Бесплатно
Журнал регистрации изменений во внешней информационной базе 1С
16.08.2016
3.0.7.5 12000 руб.

Моментальная
доставка

Поддержка и получение обновлений подсистемы "Журнал регистрации изменений во внешней ИБ 1С" сроком на 12 месяцев СТАНДАРТ
16.11.2016
7800 руб.
Поддержка и получение обновлений подсистемы "Журнал регистрации изменений во внешней ИБ 1С" сроком на 24 месяца СТАНДАРТ
16.11.2016
11800 руб.

См. также

Подписаться Добавить вознаграждение

Комментарии

1. Князев Евгений Юрьевич (noblekey) 04.02.13 15:30
а чем ваша разработка отличается от http://infostart.ru/public/71458/?
2. Виталий Барилко (Diversus) 04.02.13 15:35
(1) Отличается очень многим.

1) Работа с журналом регистрации в базе MS SQL Server быстрее чем в базе 1С через сom-соединение.
2) Есть запись данных регистров сведений, чего нет вообще нигде
3) Пытались сделать интерфейс как можно более приближенный к типовому журналу регистрации
4) Ну и дешевле)))
3. Инна Дмитриева (InnaD) 04.02.13 17:49
4. andrey dyak (dyak84) 04.02.13 18:59
Здраствуйте скажете пожалуйста как нащет производительности у меня база 150 гб пользователи не будуть подвисать????????
5. Виталий Барилко (Diversus) 04.02.13 21:22
(3) На PostgreSQL не работает и пока не планируется делать для этой СУБД. Все делалось исключительно для MS SQL Server. Но даже если у Вас его нет, никто не мешает использовать версию Express, которая бесплатна.
(4) При правильной настройке хранимой базы с журналом регистрации и нашей подсистемы ничего не должно подвисать. У нас сделано кэширование соединения к SQL Server и используемых данных, которое в разы повышает производительность. Например, соединение с базой данных журнала регистрации, создается только один раз при записи первого объекта и работает весь сеанс не создаваясь вновь. Так же сделаны в отличие от типового журнала многие улучшения, который благоприятным образом отразились на производительности. Например, у нас не записывается постоянно в базу данных имя пользователя, имя компьютера и метаданные. Для них заведены отдельные таблицы, а в сам журнал записывается только ID этих данных. Это позволило существенно сократить размеры записываемых данных, а так же быстро выводить в отборах данные объекты.
migulja; Zircool; kirillbul; +3 Ответить
6. Павел Данилкович (pashoid) 06.02.13 01:44
Эх, если можно былоб отключить штатный журнал. Вот это песня былаб.
7. 1С-у.к.и. 1С-у.к.и. (1cyku) 06.02.13 08:06
Что произойдет с программой, если оборвется соединение с SQL сервером? Как обрабатывается, например, ошибка по таймауту?
8. Виталий Барилко (Diversus) 06.02.13 11:03
(6) Штатный журнал регистрации можно отключить (или изменить список регистрируемых изменений). Для этого необходимо зайти в режиме конфигуратора и в меню выбрать Администрирование>Настройки журнала регистрации...
Далее выбрать список событий, который необходимо регистрировать. Если ничего не хотите видеть выберите пункт "Не регистрировать".
9. Виталий Барилко (Diversus) 06.02.13 11:10
(7) Если оборвется соединение с SQL сервером, то:
1) Будет осуществлена попытка создать соединение повторно, если этот шаг исправит ситуацию, то продолжаем работать в штатном режиме
2) Если соединение с сервером будет потеряно, и повторное переподключение не даст результатов (например, что то случилось с машиной на которой установлен экземпляр SQL сервера), то события перестанут фиксироваться для данного пользователя, но работать с информационной базой 1С он продолжит без каких либо ошибок. Т.к. подсистема, подсистемой, но она не должна ни в коей мере влиять на основную работу.
10. KV1s (KroVladS) 22.02.13 12:53
(9) Diversus,
Т.к. подсистема, подсистемой, но она не должна ни в коей мере влиять на основную работу.

лучше вынесите в настройки, может для кого то как раз принципиально чтобы не было ни одного действия без лога.
11. Виталий Барилко (Diversus) 22.02.13 13:11
(10) Все и вынесено в настройки
12. Виктор Лебедев (eeeio) 12.03.13 08:46
выглядит отлично. жаль нам не нужно.
stas1kbob; +1 Ответить
18. Азбука Морзе 04.04.13 11:32
У нас более 20 филиалов, на каждом как минимум типовая бухгалтерия и не типовая торговля. В связи с этим вопрос: на каждую базу требуется отдельная лицензия или достаточно одной для всех.
19. Виталий Барилко (Diversus) 04.04.13 11:40
(18) Достаточно одной лицензии на неограниченное число информационных баз для каждого юридического лица.
20. Виталий Барилко (Diversus) 09.04.13 13:35
Обновление подсистемы "Журнал регистрации изменений во внешней БД MS SQL Server", версия 1.0.0.2 от 09.04.13

[*] Исправлена ошибка конвертации даты, если в MS SQL Server формат даты отличается от '01.01.2013 00:00:00' (например для серверных ОС, у которых в языковых настройках стоит формат '2013/01/01 00:00:00' и т.д.).
Формат даты унифицирован и теперь не зависит от языковых настроек.
21. Александр Тарасюк (Aletar) 26.06.13 06:44
Скажите, а если возможность использования одной базы журнала изменений для нескольких информационных баз?
22. Виталий Барилко (Diversus) 26.06.13 10:15
(21) Нет. Такой возможности нет. Для одной информационной базы - одна база данных MS SQL для журнала регистрации.
24. Виталий Васькович (mr_best_23rus) 28.10.13 06:38
Здравствуйте! Купил вашу подсистему, при создании базы 1С наглухо зависает. Настраивал по инструкции. Что можно сделать?
25. Виталий Барилко (Diversus) 28.10.13 10:30
(24) Подобное поведение возможно при блокировании прямого доступа к серверу MS SQL, например, антивирусом. Напишите мне личное сообщение решим проблему.
26. Виталий Жуланов (VZhulanov) 06.11.13 19:09
Подробно изучил инструкцию и все комментарии к вашей подсистеме и к подсистеме http://infostart.ru/public/71458/
У конкурентов понравилась возможность восстановления физически удаленных записей и возможность отката изменений. Но очень не понравилось хранение данных в базе 1С, так как есть собственный опыт подобного хранения истории изменений - база быстро достигает своих пределом по размерам, а у моих клиентов лицензии только на файловые 1Ски.

Вопросы по вашей подсистеме:
1. Планируется ли возможность отката изменений ? - не самое важное.
2. Планируется ли хранение самого первого состояния объекта, при его создании? У пользователей есть права на физическое удаление объектов, но иногда им злоупотребляют, и тогда данные можно было бы поднять из истории изменений, а не из бэкапа, как сейчас делаю.
3. Планируется ли регистрация изменений в распределенных базах ? Ибо некоторые объекты меняются в разных перифериях, а в центре хотелось бы видеть консолидированную информацию по всем изменениям объекта. Это очень важный пункт, так как периферий много, и отслеживать изменения довольно таки трудно.
4. Планируется ли возможность вести изменения нескольких 1С баз в одной внешней SQL ?
5. Через что идет работа с SQL сервером, будет ли подсистема работать под линуксом ?
27. Виталий Жуланов (VZhulanov) 07.11.13 10:21
Идея по отслеживанию изменений для распеределлынх баз:

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

Настраиваем эту саму репликацию на уровне SQL сервера и имеем одинаковые базы истории в центральном и периферийном объекте.
Главное чтобы идентификаторы, которые используются внутри SQL базы (если такие есть конечно) были уникальными.

Останется в процедурах загрузки обмена тоже добавить контроль на изменения объектов и сохранять их с признаком "изменение при обмене".

Опять же не в курсе есть ли такая возможность на бесплатных Express базах.
Если нет, то это еще один повод расширить универсальность подсистемы и научить ее работать с Postgress, тем более что структура таблиц и запросы будут не сильно друг от друга отличаться, а для распространения подсистемы это даст хороший толчок.
28. Dmitry Grabarev (dmitry-gr) 15.11.13 10:58
Подскажите, что будет происходить если в процессе эксплуатации сервер хранения логов станет недоступным?
Как это скажется на производительности?
Что произойдет когда он снова включится?

29. Виталий Барилко (Diversus) 15.11.13 11:31
(28) При отключении по какой то причине сервера с журналом будет произведена попытка подключиться к журналу снова, если вторая попытка не удачная, то больше подсистема в данном сеансе не будет предпринимать попытки подключиться. После перезапуска сеанса все повторяется.
30. Dmitry Grabarev (dmitry-gr) 15.11.13 11:53
(29) Diversus, не могли бы пояснить механизм кеширования соединения с базой. Что с ним будет если сеанс "переехал" на другой процесс или другой сервер?
31. Виталий Барилко (Diversus) 15.11.13 12:32
(26) Извините за не оперативный ответ (был на Infostart Event).

>> 1. Планируется ли возможность отката изменений ? - не самое важное.

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

>> 2. Планируется ли хранение самого первого состояния объекта, при его создании? У пользователей есть права на физическое удаление объектов, но иногда им злоупотребляют, и тогда данные можно было бы поднять из истории изменений, а не из бэкапа, как сейчас делаю.

Это есть. Хранятся все версии изменений.

>> 3. Планируется ли регистрация изменений в распределенных базах ? Ибо некоторые объекты меняются в разных перифериях, а в центре хотелось бы видеть консолидированную информацию по всем изменениям объекта. Это очень важный пункт, так как периферий много, и отслеживать изменения довольно таки трудно.

Да хотим сделать. Но тут сложность в том, что необходим механизм переноса данных из MS SQL из филиалов в центр. В MS SQL есть репликация данных (но в Expres если не путаю, этого нет). Либо какая нибудь выгрузка, либо еще что-то... Надо думать.

>> 4. Планируется ли возможность вести изменения нескольких 1С баз в одной внешней SQL?
Возможно в будущем. Т.к. по сути доработки для данного функционала минимальны.

Думали над этим, но в конце пришли вот к чему. Простой вопрос: а зачем? Проще, когда явно есть соответствие журнал бухгалтерии <-> бухгалтерия. Проще с переносом. Вдруг будет физический переезд одной базы на другой сервер. Когда журнал будет в одной базе, здесь будут сложности. Да и сжатие истории будет быстрее, если базы журналов физически различные.

>> 5. Через что идет работа с SQL сервером, будет ли подсистема работать под линуксом?

Через ADO. Под линуксом не могу сказать, не пробывал. Наверняка есть что нибудь, что заставит ADO работать из под линукса.
32. Виталий Барилко (Diversus) 15.11.13 12:42
(30) dmitry-gr, лучше расскажу про схему записи.

1) В конфигурации делается запись изменения объекта. Подписка на событие это изменение фиксирует и помещает его в кэш (специальный справочник в конфигурации) записывая полный образ объекта.
2) Фоновое задание обходит кэш и переносит все изменения объектов в журнал регистрации - БД MS SQL попутно "сжимая" изменения, находит какие реквизиты были изменены и переносит только их в журнал.
3) Из кэша удаляются обработанные записи.

Таким образом пользователь не имеет соединения с БД MS SQL. Это делает за него фоновое задание.
При запросе просмотре истории данные изменений получает так же сервер и возвращает на клиента таблицу с изменениями.
33. sanek sanek_gk (sanek_gk) 22.11.13 12:31
Добрый день. Просветите пожалуйста. Чем ваша подсистема отличается по быстродействию от стандартной если стандартное версионирование хранит образы объектов в регистре сведений а вы свой кэш в справочнике. Чем обоснован выбор хранения кэша в справочнике?
34. Виталий Барилко (Diversus) 22.11.13 12:46
(33) sanek_gk, выбор справочника в качестве кэша обусловлен удобством дальнейшей обработки данных. По сути, на физическом уровне запись полного образа объекта занимает примерно одно и тоже время, что в справочник, что в регистр сведений.
35. helgi 19.12.13 18:44
(34) Diversus,
В справочник быстрее, имхо, можно добиться, если в нем снести код/наименование, т.к. останется только кластерный индекс по ссылке, по которому дописываются данные в конец таблицы (не могут вставляться в середину). В регистре надо будет искусственный идентификатор, который сделать так, чтобы записи дописывались в конец без блокировки всей таблицы, невозможно.
36. Виталий Барилко (Diversus) 19.12.13 18:51
(35) helgi, если речь идет о постоянно очищаемом регистре и справочнике, где данные есть только до следующего регламентного задания, то скорость будет примерно одинаковая. Та разница о которой Вы говорите, для маленьких наборов данных не принципиальна.
37. helgi 19.12.13 19:07
(36) Diversus,
да, согласен, не подумал, что у объем маленький.
38. Александр Кирилюк (ArtfulCrom) 15.01.14 06:31
Я правильно понял, что каждое событие пишеться с клиента, а не с сервера?
Т.е. если клиенты не имеют доступа к одному скл серверу, то реализовать ваш журнал не возможно?

Например, в облаке?
39. Александр Кирилюк (ArtfulCrom) 15.01.14 06:35
(38) извин-те, нашел ответ выше в каментах )))
40. Вячеслав (Borunmeert) 24.01.14 10:34
Устанавливал все по инструкции, все норм кроме одного. Регламентное задание похоже не выполняется. База в три раза распухла, в логах стандартного журнала про фоновое задание это: {ОбщийМодуль.внОбщийМодуль.Модуль(853)}: Невозможно обработать параметр "ВестиИсториюИзменений" для получения значения. Что забыл сделать?
41. Виталий Барилко (Diversus) 24.01.14 10:50
42. Сергей Иванов (xten) 24.01.14 16:42
Скажите, пожалуйста, купив Вашу программу Журнал Регистрации, к какому количеству баз (клиент-сервер) я могу ее подсоединить? Спасибо
43. Виталий Барилко (Diversus) 24.01.14 16:57
(42) В подсистеме нет проверки на количество подключаемых баз данных, поэтому, столько сколько захотите, но только в Вашей организации.
44. vik123 vik (vik123) 30.01.14 12:00
Добрый день.
Планируется ли выпуск отчета по сравнению версий, аналогичного
отчету в разработке http://infostart.ru/public/71458/?
45. Виталий Барилко (Diversus) 30.01.14 12:25
(44) В планах, подобный отчет запланирован.
46. vik123 vik (vik123) 30.01.14 12:41
(45) Diversus,
надо было сразу спросить))
а когда ожидать?
и еще вопрос, как отслеживаются изменения в табличных частях?
Допустим в доке удалили строку из середины тч.
Это будет регистрироваться как изменение всех последующих строк(сдвинулись на 1 вверх) или
как удаление конкретной строки?
47. Arikite (ArikiteSun) 25.02.14 12:02
Можете дать доступ к демо версии?
48. Виталий Барилко (Diversus) 25.02.14 12:15
49. Сергей Иванов (xten) 19.03.14 13:46
Скажите, пожалуйста, хотя бы примерно, на сколько процентов увеличивается скорость работы стандартной БП 2.0 ,15-20 одновременных пользователей (обычное приложение, MS SQL 2008)при использовании ЖурРег во внешней БД ?
Спасибо
50. Виталий Барилко (Diversus) 19.03.14 14:08
(49) Специальных замеров не делали, но при работе влияние не заметно. Пользователи ничего не почувствуют.
51. Вадим Окунев (Upiterus) 23.03.14 16:45
Спасибо за журнал! Очень полезная вещь, всем рекомендую!:)

Единственное неудобство, с которым столкнулся при первичной настройке, - почему-то отсутствует в последнем релизе УТ 11.1.4.14 кнопка обновления справочника идентификаторов объектов метаданных. Танцы с изменением номера релиза и попыткой запустить стандартную обработку обновления ИБ ни к чему не привели:( Пришлось для этого выцарапывать из БСП обработку ИнструментыРазработчикаОбновлениеВспомогательныхДанных и используемые в БСП общие модули. Было бы неплохо для удобства пользователей добавить в обработку настройки журнала кнопу обновления идентификаторов.
52. Виталий Барилко (Diversus) 24.03.14 10:00
(51) Спасибо за отзыв, очень рад, что Вам понравилась наша разработка!
Насчет кнопочки для вызова БСП, сделал на сайте тикет для включения данного функционала в подсистему. Так что, ждите в следующем релизе.
53. Анна Зверева (Dirol-ka) 26.03.14 11:38
добрый день.

есть ли демо версия?
54. Виталий Барилко (Diversus) 26.03.14 11:42
(53) Есть демо-сервер. В правом верхнем углу публикации кнопка "Показать демо".
55. pepe (pepe) 04.06.14 15:59
Видел я этот продукт, очень сырой продукт и много не достатков в нем. Не рекомендую его использовать.
1) Не фиксировалась объекты у которых не изменялись реквизиты.
2) Чтобы регистрация велась нужно, чтобы у пользователя обязательно была установлена специальная роль
3) Возрастает нагрузка на сервер при сравнении, за счет этого система начала тормозить
4) Перенес базу на другой сервер, нужно помнить про настройки этого журнала
5) Если журнал изменений отключили, а у пользователя стоят роли журнала, то дальше выполняется большой кусок кода который не нужен.
6) Сам код написания очень запутанный и не всегда понятный.
Это только, что было на поверхности. Дальше не копал в нем.

56. Vit Red (lakra) 04.06.14 16:26
используем на базе, в которой одновременно работает ~200 пользователей.
эксплуатируем 11 месяцев, проблем нет, тормозов нет, все довольны ибо каждый чих наглядно виден.
размер базы внешнего журнала регистрации ~950гигабайт.
57. Виталий Барилко (Diversus) 04.06.14 17:12
(55) pepe, зачем Вы пишите эту ерунду?
Подсистема на Инфостарте уже больше чем 1.5 года, имеет очень много клиентов, положительных отзывов.
Но я попытаюсь ответить на Ваше сообщение.
1) Не фиксировалась объекты у которых не изменялись реквизиты.

Как бы логично :) Зачем в журнале изменения, которые не изменялись? Т.е. открываем справочник нажимаем на кнопку ОК ничего не изменяя. Зачем в истории нам знать, что справочник не изменялся, а просто был перезаписан? Если нет изменений в объекте нет и записи в журнале. Как раз таки это позволяет убрать много не нужного хлама из журнала, чтобы вести действительно изменения по объектам, а не все подряд как в типовом журнале. Все логично.
2) Чтобы регистрация велась нужно, чтобы у пользователя обязательно была установлена специальная роль

Абсолютно верно. Дело в том, что для того, что бы пользоваться функциональностью подсистемы в системе 1С:Предприятия предусмотрено разграничение по правам, соответственно, если прав нет, то и функционал подсистемы использовать не получится. Далее есть два пути, добавлять роли для чтения и записи в уже существующие роли, либо добавить свои роли, который разрешат доступ к объектам. При первом подходе, если конфигурация типовая и будет обновлена в следующий раз, нам заново придется изменять права на наши объекты, поэтому логически верным и оправданным является введения собственных ролей, которые назначаются пользователям. При этом в подсистеме есть возможность в настройках установить права ВСЕМ быстро, щелчком одной кнопки. Без ролей ничего работать не будет и не только в нашей подсистеме. Вы даже константу добавите в конфигурацию, для пользователей без полных прав, она будет недоступной ни для чтения, ни для записи, а тут целая подсистема...
3) Возрастает нагрузка на сервер при сравнении, за счет этого система начала тормозить

"Навешивание" дополнительного функционала при записи и удалении объектов безусловно ведет к увеличению нагрузки. Но мы приняли все возможное, чтобы уменьшить ее. Например, была переработано сжатие объектов, оно осуществляется в фоновом задании (на обычных пользователей не влияет). Есть справочник кэша журнала регистрации, куда записываются не сжатые объекты.
Т.е. реализована связь:
СОБЫТИЕ ИЗМЕНЕНИЯ -> КЭШ ЖУРНАЛА РЕГИСТРАЦИИ -> ВНЕШНЯЯ СУБД MS SQL SERVER (в фоновом задании)
Разработана даже техника кэшированного считывания настроек для каждого пользователя (т.е. настройки подсистемы из БД считываются всего один раз для сеанса пользователя). И это только малая часть озвученных оптимизаций.
Такой подход позволяет существенно снизить нагрузку подсистемы.
Более того, комментарий (56) пользователя lakra говорит о том, что Ваше утверждение про сильное падение производительности голословно. ~200 юзеров в информационной базе работающих одновременно лучшее тому подтверждение.
4) Перенес базу на другой сервер, нужно помнить про настройки этого журнала

Все верно. Я Вам больше скажу, если Вы перенесете базу 1С на другой сервер, Вам придется переносить и типовой журнал регистрации. Да и к тому же, база не так часто переносится, чтобы бы говорить об этом серьезно.
К тому же, хранение информационной базы 1С и журнала регистрации отдельно друг от друга, дает свои плюсы, которые существенно выше, чем перенос основной базы на другой сервер раз в год.
5) Если журнал изменений отключили, а у пользователя стоят роли журнала, то дальше выполняется большой кусок кода который не нужен.

Абсолютная ложь! Вот пример кода, отрабатываемого при изменении объектов:
// Процедура фиксирует текущее состояние объекта и записывает в кэш
Процедура РегистрацияИзмененияОбъекта(Объект, НачальноеЗаполнение =  Ложь)
	
	// Журнал регистрации ведется?
	Если НЕ глВНЗначениеПеременной("ВестиИсториюИзменений") Тогда
		Возврат;
	КонецЕсли;
//...
...Показать Скрыть

По вашему этот код избыточен? :)
6) Сам код написания очень запутанный и не всегда понятный.

Вы не думали над тем, что если Вы не можете разобраться в коде, то может дело не в коде? :)

Все, что Вы написали абсолютно не соответствует действительности...
Пожалуйста, не вводите людей в заблуждение.
58. pepe (pepe) 06.06.14 18:57
А теперь мои аргументы:
1) Документ не изменяли, а просто перепровели. Проводки по партиям изменились, а в журнале нам не показывает изменений, как то не очень хорошо.
2) На счет ролей понятно, но лучше чтобы была привязка к роли "Пользователей", при добавлении пользователей, очень часто не ставят данную роль.
3) Очень странно, что при 200 пользователях система работает стабильно. Фоновое задание памяти кушает не много, а вот процессор и время выполнения не радует.
По оптимизации:
Почему параметры работы не вынесены в модуль Повторного использования, для ускорения работы, как в типовых решениях. Это сильно увеличивает производительность. Также использование ХранилищеЗначения очень замедляет работу. Провел тестирование механизма: записывал 100 элементов справочника банковские счета. С включенным алгоритмом 8 с, без него и с версионирование 5 с. Для чистоты эксперимента запуска замер 10 раз, показатель средний.
4) Типовое Версионирование работает в любом случаи.
5) Код с подписки на событие при записи регистра сведений:
Если НЕ РольДоступна("внПользовательИсторииИзменений") И НЕ РольДоступна("внАдминистраторЖурналаРегистрации") И НЕ РольДоступна("внПросмотрЖурналаРегистрации") Тогда
Возврат;
КонецЕсли;


Если Источник.ОбменДанными.Загрузка И НЕ глВНЗначениеПеременной("ФиксироватьИзмененияПриОбменеДанными") Тогда
Возврат;
КонецЕсли;

// Добавляем дополнительные свойства
Если НЕ Отказ Тогда
ПолноеИмя = Источник.Метаданные().ПолноеИмя();
Запрос = Новый Запрос;
СписокПолейУсловияОтбораТекст = "";
Для каждого ЭлементОтбора Из Источник.Отбор Цикл
Если НЕ ЭлементОтбора.Использование Тогда
Продолжить;
КонецЕсли;
Если НЕ ПустаяСтрока(СписокПолейУсловияОтбораТекст) Тогда
СписокПолейУсловияОтбораТекст = СписокПолейУсловияОтбораТекст + " И ";
КонецЕсли;
СписокПолейУсловияОтбораТекст = СписокПолейУсловияОтбораТекст +" Набор." + ЭлементОтбора.Имя + " = &" + ЭлементОтбора.Имя;
Запрос.УстановитьПараметр(ЭлементОтбора.Имя, ЭлементОтбора.Значение);
КонецЦикла;

Если НЕ ПустаяСтрока(СписокПолейУсловияОтбораТекст) Тогда
СписокПолейУсловияОтбораТекст = " ГДЕ " + СписокПолейУсловияОтбораТекст;
КонецЕсли;

Запрос.Текст =
"ВЫБРАТЬ * ИЗ " + ПолноеИмя + " КАК Набор
| " + СписокПолейУсловияОтбораТекст;
ТЗРегистра = Запрос.Выполнить().Выгрузить();

Источник.ДополнительныеСвойства.Вставить("внРегистрСведенийЗаписью", ТЗРегистра);
КонецЕсли;

Я как то не вижу проверку глВНЗначениеПеременной("ВестиИсториюИзменений").
Возможно у меня конфигурация старая, но думаю это мало вероятно.
6) Каждый воспринимает по своему.
59. Виталий Барилко (Diversus) 06.06.14 19:29
(58) pepe,
1) Документ не изменяли, а просто перепровели. Проводки по партиям изменились, а в журнале нам не показывает изменений, как то не очень хорошо.

Подсистема показывает изменения. В документе по факту ничего не изменилось.
2) На счет ролей понятно, но лучше чтобы была привязка к роли "Пользователей", при добавлении пользователей, очень часто не ставят данную роль.

В типовых конфигурациях на УФ с использованием БСП, сейчас это все решается на уровне профилей прав. Создал один раз профиль внеся туда нашу роль, потом включаешь пользователям нужный профиль и все. С профилями настроил и забыл.
3) Очень странно, что при 200 пользователях система работает стабильно. Фоновое задание памяти кушает не много, а вот процессор и время выполнения не радует.
По оптимизации:
Почему параметры работы не вынесены в модуль Повторного использования, для ускорения работы, как в типовых решениях. Это сильно увеличивает производительность. Также использование ХранилищеЗначения очень замедляет работу. Провел тестирование механизма: записывал 100 элементов справочника банковские счета. С включенным алгоритмом 8 с, без него и с версионирование 5 с. Для чистоты эксперимента запуска замер 10 раз, показатель средний.

Прототип подсистемы родился еще в 8.1 и по идее все настройки хранятся в параметре сеанса и скорость должна быть сопоставима с использованием модуля с повторным использованием значений. Надо будет сделать замеры. Если окажется, что скорость на порядок выше, изменим, не проблема.
4) Типовое Версионирование работает в любом случаи.

Начали говорить про минусы нашей подсистемы, говорите и про минусы версионирования.
Минусы версионирования:
1) серьезное увеличение размеров БД, что влечет за собой замедление обновления и реструктуризации данных.
2) невозможность быстрой выгрузки и потом загрузки базы в тестовую, т.к. объемы неприлично большие.
3) информационная база 1С становится не транспорабельной, если в ней работает очень много пользователей. Только перенос средствами СУБД. Штатной выгрузкой будет работать очень долго.
Мы через все это проходили, поэтому остановились на отдельном хранении истории журнала вне информационной базы 1С.
5) Код с подписки на событие при записи регистра сведений: Возможно у меня конфигурация старая, но думаю это мало вероятно.

Да. Это старая версия подсистемы.

В целом, я позитивно оцениваю критику, но только конструктивную...
Если у пользователей подсистемы есть вопросы или предложения по улучшению функционала, они пишут о них нам в тикет-системе на нашем сайте, мы стараемся их решить и угодить всем. Вам, тоже надо было так сделать.
60. Андрей Старченко (dr.death) 25.06.14 06:30
Сплошной обман! Покупали версию 1.0.4.1 Установил. Косяков куча, вплоть до того что записи ЖР просто не переносились (архивировались) в SQl, т.е. срабатывало регламентное задание и висело!!! Потом вышло обновление 1.0.5.5 И ТОЖЕ САМОЕ + тормозить чуть чуть меньше стало. База росла примерно на 2 Gb в день!!! При этом наблюдалось заметное снижение производительность, планировал подключать к двум базам, в итоге пришлось отказаться от использования на первой. Об этом всё писал в тех поддержку, в итоге включили пару ошибок к исправлению в будущих версиях. В ИТОГЕ ВЫШЛА ВЕРСИЯ 2 И ОБНОВЛЕНИЯ НЕ МОГУ СКАЧАТЬ, ПИШУТ КУПИТЕ ЗА 3000 руб. Как понимать?!!!!! Если вы обновляете свои косяки ( обратите внимание что программа была до этого приобретена), то доводите их до логического завершения, а вы выпустили новую версию и просите денег. не хорошо... да и где гарантия что опять не опрокинете... вообщем впечатления резко негативные!
61. Виталий Барилко (Diversus) 25.06.14 12:51
(60) dr.death, согласно условиям лицензионного договора обновления предоставлялись бесплатно для версий 1.x.x.x. Сейчас вышла версия 2.0.0.0, начиная с этой версии обновления предоставляется по подписке. Поэтому мы никого не обманываем. Более того, для пользователей, которые приобрели подсистему после 01.04.14 мы предоставили бонус в виде бесплатной полугодовой подписки.
Теперь о проблемах.
База росла примерно на 2 Gb в день!!!

Почитайте инструкцию по работе с подсистемой, там есть такая тема: "Что делать если очень быстро растет база данных журнала в MS SQL". Там же рекомендации по настройке MS SQL, а так же по настройке самой подсистемы, чтобы и производительность и размер журнала были оптимальными.
При этом наблюдалось заметное снижение производительности

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

Теперь по поводу обращений в техподдержку. Проверили от Вас было зарегистрирован только один тикет, который не касался работы регламентного задания и который был решен.
Если действительно есть проблемы, на которые мы вовремя не отреагировали, напишите нам на почту, если это действительно наша вина и мы ее не решили, вопрос будет решен в вашу пользу.
62. Виталий Барилко (Diversus) 10.07.14 12:45
26.06.14 Версия 2.0.0.3

[*] Проверка уникальности информационной базы объединена с проверкой необходимости ведения истории.
[!] Исправлена ошибка чтения наличия пользователей в конфигурации.
63. Марина Семёнова (SemenovaMarinaV) 30.07.14 14:27
А не будет ли внешяя база по размеру в несколько раз больше основной?
64. Виталий Барилко (Diversus) 30.07.14 14:46
(63) SemenovaMarinaV, во внешней базе хранятся изменения объектов.
Если документ записали, его реквизиты, табличные части переносятся полностью, потом при изменении этого документа будут записываться только его ИЗМЕНЕНИЯ. Т.е. изменили один реквизит, будет записан только один реквизит и т.д.

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

Плюс, мы добавили в версии 2.0 функционал по очистке устаревших данных, а это позволит удалять старые и уже не нужные данные. Об этом подробнее, так же в документации.
65. pepe (pepe) 07.08.14 16:21
В новой обработке по описанию, уже улучшили некоторые механизмы на которые не нравились мне и идея хорошая с единым журналом для всех баз УРБД, осталось посмотреть на реализацию и работоспособность.
66. Виталий Барилко (Diversus) 11.08.14 09:22
(65) pepe,

В версии 2.0.1 добавляем поддержку распределенных баз данных. Реализовали 2 вида обмена:
1) Полный. Это когда правится план обмена и происходит помимо обмена основными данными, обмен данными журнала.
2) Упрощенный. Когда фиксируется при обмене только база-источник из которой грузятся изменения.
Каждый из типов имеет свои плюсы и минусы, которые будут отражены в справке.

Версия 2.0.1 выйдет в ближайшее время.
67. Юрий Липовский (Юрий ЛЛ) 19.08.14 11:48
поддержка и обновления платные на эту прогу?
68. Виталий Барилко (Diversus) 19.08.14 12:08
(67) После покупки первые полгода бесплатно, потом за отдельную плату (1 год - 3500 р.)
Обновления предоставляются по принципу ИТС.
69. Юрий Липовский (Юрий ЛЛ) 19.08.14 12:42
почему нигде не написано про это?(68) Diversus,
70. Виталий Барилко (Diversus) 19.08.14 12:55
(69) Юрий ЛЛ, написано в разделе "Вопрос-ответ":
Вопрос: Будет ли система и дальше развиваться и обновляться?
Ответ: Конечно! Подсистема постоянно развивается и обрастает новым функционалом. После покупки в качестве бонуса первые полгода обновления предоставляются бесплатно.
71. Юрий Липовский (Юрий ЛЛ) 19.08.14 15:18
(70) Diversus, Хорошо, есть Юрий ЛЛ, который уже сталкивался с твоими программами
и необъявленными(скрытыми) ценами на обновления.
Зато теперь ты можешь ссылаться на твой ответ мне, если кто-то задаст такой же вопрос как и я.
Так и напишешь - "Ну вот же я в комментариях писал цену..."
72. Виталий Барилко (Diversus) 19.08.14 21:20
(71) Юрий ЛЛ, спасибо! Обновил публикацию и ввел в разделе вопрос-ответ пункт, касаемо обновлений и поддержки, а так же их стоимости.
73. Алексей Роза (DoctorRoza) 10.11.14 08:15
Предложу своему директору! Разработка достойная! :)
74. Игорь Дзеса (Kamikadze) 26.11.14 16:11
Diversus, аргументы pepe серйозные. Зачем система, где не фиксируется проведение документа? Это же влияет на суть данных, которые хранятся в базе 1С. И то, что такой вариант не отслеживается - очень плохо. в основном из-за этих проблем и смотрят все в журнал регистрации от 1С-ки. Я вот думал приобрести, но.... это НО меня останавливает.
tramontana; +1 Ответить 2
75. Виталий Барилко (Diversus) 26.11.14 17:02
(74) Kamikadze, событие фиксируется если есть ХОТЯ бы одно изменение в объекте.
Если изменений в объекте нет, то объект не изменился, а так как нам важна именно фиксация изменений, то мы это не записываем.
Технически реализовать запись документа только при перепроведении не сложно, но нужно ли это?
Хотя мы такую возможно можем добавить опционально и исключительно для документов... Типа, если пользователь нажал на кнопку ОК в документе и при этом ничего не поменялось в документе, то фиксировать событие перепроведения документа.
76. Виталий Барилко (Diversus) 26.11.14 17:08
(74) Тут просто вся соль в том, что если пользователь открыл документ и просто нажал на кнопку ОК. То при анализе образа объекта получается, что как будто ничего не изменилось.
Хотя, конечно, простое перепроведение документа, особенно при партионном учете может навести "шороху" в информационной базе.
Мы, все таки наверное, подумаем над реализацией и добавим это опционально, фиксировать такие событие в истории или нет.
77. Вадим Мананников (manan) 26.11.14 20:46
Почему в качестве хранилища изменений не используется отдельная база 1с?
78. Виталий Барилко (Diversus) 26.11.14 21:38
(77) manan. Как говорится, так исторически сложилось :)
Но самое забавное, что в версии 2.0 мы заложили возможность расширения поддерживаемых СУБД для хранения журналов изменений и мысли добавить отдельную базу 1С для хранения журналов были.
79. Игорь Дзеса (Kamikadze) 27.11.14 12:07
(75) Diversus, я бы иначе сформулировал - если были изменения в регистрах при проведении, то это нужно фиксировать. Это пожелание, которое, как мне кажется, очень нужное в работе пользователя. Хотя ваш вариант более предпочтителен.

(76) Diversus, хорошо :)
80. Игорь Дзеса (Kamikadze) 27.11.14 12:08
(78) Diversus, есть ли задумка реализации хранения данных на не реляционной базе данных, где поиск будет существенно быстрее?
81. Вадим Мананников (manan) 09.12.14 10:27
Хочу приобрести на организацию, с возможностью дорабатывать. Код конфигурации полностью открыт?
82. Алекс Ю (AlexO) 10.12.14 11:22
(81) manan,
Код конфигурации полностью открыт?

С чего бы, если даже обновления - платные?
83. Виталий Барилко (Diversus) 10.12.14 12:15
(82) AlexO, код подсистемы полностью открыт.
Мы работаем над подсистемой и периодически выпускаем обновления к ней.
Появилась очередная хотелка, нашли ошибку, вышла 8.3 без использования режима модальности и т.д. мы доработали/исправили.
Дали скачать пользователям.
Если подписка заканчивается то, обновления не предоставляются, но тем не менее код полностью открыт.
Продлили поддержку - получили последнюю актуальную версию и никаких проблем.
84. tixis1c tixis1c (qwed557) 10.12.14 13:00
(56) lakra, за 11 месяцев 950 Гб??? Ну и аппетиты.
85. Виталий Барилко (Diversus) 10.12.14 13:49
(84) Ничего удивительного в таком размере нет.
Представьте, фиксируются ВСЕ изменения объектов. Т.е. зашли в документ заполнили, сохранили и провели. Потом открыли, изменили один реквизит, или пару, перепровели и т.д. Естественно в ИБ 1С объект как был один так и остался, а в журнал попадают сразу все изменения объекта, после каждой записи и неважно, что следующие шаги - только изменения объекта. Все равно много данных записывается. И это только для одного документа.
А когда в ИБ 1С 150 пользователей в онлайне и каждый что-то делает, то данные журнала растут.
Так что, повторюсь, ничего удивительного нет.
86. Алекс Ю (AlexO) 11.12.14 11:35
(85) предстаьте, вы б в 1С реализовали такое версионирование хранить...
Хотя все равно много - ну гигов 50-60 за 11 месяцев - нормально. Там что за формат хранения? Может, пустоты много "хранится"?
87. Вадим Мананников (manan) 11.12.14 14:24
Приобрел конфигурацию. При попытке сделать первоначальное заполнение (кстати, зачем оно вообще нужно) сразу ошибка:
{ОбщийМодуль.внОбщийМодуль.Модуль(1492)}: Ошибка при вызове метода контекста (Выполнить)
Результат = Запрос.Выполнить();
по причине:
{(4, 2)}: Таблица не найдена "РегистрСведений.РегистрСведенийСРегистратором"
<<?>>РегистрСведений.РегистрСведенийСРегистратором КАК Регистр

Впечатление испорчено. Как бороться с ошибкой, подскажете?
88. Виталий Барилко (Diversus) 11.12.14 14:28
(87) manan, пишите нам на почту, или в скайп, мы реагируем быстро.
Если что подключимся по TeamViewer поможем.
89. Виталий Барилко (Diversus) 11.12.14 14:41
90. Вадим Мананников (manan) 11.12.14 15:05
(88) Первоначальное заполнение не удалось выполнить, ошибка - "Недостаточно памяти". Как-то все печально. Если очевидно, что при первоначальном заполнении будет обрабатываться большое количество данных, логично было бы эту процедуру как-то более оптимально реализовать.
91. Павел Белан (webcisp) 18.01.15 03:32
У нас базы 1С "крутятся" на сервере PostgreSQL (Linux) - ваше решение будет с нашими базами работать ?
92. Виталий Барилко (Diversus) 18.01.15 22:14
(91) webcisp, к сожалению пока все работает только в связке Информационная база (ИБ) + Windows + MS SQL (для журнала). Но мы планируем в будущем добавить: ИБ + Windows + 1C (для журнала), возможно так же добавим и ИБ + Linux + 1C (для журнала).
93. Алекс Ю (AlexO) 19.01.15 10:33
(91) webcisp,
на сервере PostgreSQL (Linux) - ваше решение будет с нашими базами работать ?
Если фраза в названии темы "во внешней БД MS SQL Server" ни о чем не говорит, то вам лучше не подключать пока ничего вообще))
94. Зоя Сорокина (Soikalv) 22.01.15 12:20
Очень неудобно. что фиксируются именно любые изменения объекта. Журнал становится слишком громоздким. Нужна или нет информация. кто вообще открывал документ в текущем режиме - это вопрос. Мне кажется. было бы логичнее фиксировать в журнале только те события. которые привели к изменению каких-либо реквизитов объекта. Или настроить функцию вабора реквизитов, которые будут выводиться в журнале.
95. Виталий Барилко (Diversus) 22.01.15 12:24
(94) Soikalv, так журнал так и работает. Фиксируется только то, что изменилось у объектов. Открытия документов не фиксируются.
Есть так же возможность настройки фиксации изменений и указать те объекты и реквизиты, которые нужны в истории.
96. Namig Pirkuleiv (Namig) 22.01.15 18:47
можно ли похожее делать для 8'018'2? только с урезанными функциями.
97. Виталий Барилко (Diversus) 23.01.15 09:07
(96) Namig, подсистема работает в 1С версий 8.2 и 8.3, более ранние нет смысла поддерживать, т.к.
1) 95% пользователей 1C v8 работают именно на этих версиях
2) 8.0 и 8.1 - устаревшие версии и нет смысла делать, что-то для старых платформ ввиду сокращения пользователей.
98. Вадим Мананников (manan) 03.02.15 11:38
Итак, крайне неприятное наблюдение при работе с системой.
Зачем сделано назначение роли внПользовательИсторииИзменений юзерам опционально, если это не работает? Конечно, удобно было бы отключить например логирование администраторов, НО! Будем иметь неправильную информацию об изменениях.
Пример: есть пользователь Админ (которого не хотим логировать) без роли внПользовательИсторииИзменений и пользователь Юзер с ролью внПользовательИсторииИзменений.Включаем логирование реквизита "Руководитель" справочника "Сотрудники". Дальше:
1. Пользователь Юзер меняет руководителя какого-либо сотрудника с Иванов на Петров.
2. Пользователь Админ меняет руководителя того же сотрудника с Петров на Сидоров
3. Пользователь Юзер меняет руководителя того же сотрудника с Сидоров на Козлов.
Внимание, вопрос: что вы ожидаете увидеть в журнале регистрации для пункта 3? Лично я (логично) следующее: руководитель сотрудника был изменен пользователем Юзер с Сидоров на Козлов. НО! Разработчики конфигурации (нелогично) считают так: руководитель сотрудника был изменен пользователем Юзер с Петров на Козлов. Загадка, блин!
Надеюсь, авторы системы не будут отмалчиваться здесь, посылая таких вот добросовестных приобретателей их поделки как я в почту/скайп/личку, а заявят во всеуслышание, что да, имеются крупные косяки в нашей недешевой поделке, исправлять будем/не будем (нужное подчеркнуть).
99. Виталий Барилко (Diversus) 03.02.15 13:26
(98) manan,

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

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

Верно ли это с методологической точки зрения? Наверное все же нет... Так как, действительно, теряется правильная последовательность изменений в журнале, но мы сознательно пошли на это, чтобы это было именно опционально как описано выше. Нам прекрасно известно как работает блок:
УстановитьПривелегировнныйРежим(Истина);
//...
УстановитьПривелегировнныйРежим(Ложь);
И что привелегированным режимом можно было избавиться от этой лишней роли, для записи в тот же кэш изменений пользователем...

Теперь по поводу отписок в скайп/личку/team viewer и т.п. О чем Вы написали.
Я считаю хорошей практикой, когда с чем-то озадаченным пользователем, пытаются связаться на прямую и выяснить более подробнее об ошибке или пожелании. Мне кажется наоборот так пользователь получает обратный отклик и точно не останется один на один с проблемой, если она у него возникла. Вы неверно приняли заботу о конечном пользователе, попыткой скрыть ошибки в подсистеме. Ошибки есть везде и это, всем известный факт. Пишите на ящик поддержки, мы отвечаем и если действительно ошибка, мы включаем ее в баг-треккер и работаем по ней и к следующему релизу стараемся, чтобы все были довольны. Но то, что Вы указали выше - это не баг, это, сознательный шаг. Если все делать по инструкции и всем проставить роль, все будет работать как надо...

Спасибо.
100. Вадим Мананников (manan) 06.02.15 09:08
(99) Коллеги, ну реально уже не смешно. Я ожидал с помощью Вашей разработки решить конкретную проблему, а именно - выловить человека, который меняет руководителя сотрудника. Сначала выставил период журнала месяц, в итоге журнал даже не открылся - все повисло. Потом поставил - неделю, форма журнала открывается, но пустая и неактивная - видимо идет заполнение. С трудом форма все же заполнилась, но неактивна по-прежнему. В общем, тормоза еще круче, чем в штатном журнале регистрации от 1С. И это я включил только логирование одного реквизита одного справочника плюс еще регистрацию фактов перепроведения документов. Регламентное задание "Обработка журнала регистрации" вообще не успевает отработать за 10 минут. Есть возможность вернуть деньги через Инфостарт? Сильно жалею что приобрел. Наверное, версионирование из БСП лучше прикрутить.
101. Виталий Барилко (Diversus) 06.02.15 11:00
(100) Звонил на ваш номер, но вы не взяли трубку...
Связался с дирекцией Инфостарта, совместно решили вам сделать возврат и тут дело не в том, что разработка плохая, а в том, что автор поста (100) уже хорошо известен Инфостарту с не очень хорошей стороны, как проблемный и склочный человек... Так что для таких как вы, ей богу, сделать возврат проще, чем иметь такого клиента у себя.

Теперь по тексту.
Не знаю с какой целью, но Вы сознательно и не обоснованно вводите людей в заблуждение.
1) Если включена регистрация только одного справочника и одного реквизита в этом справочнике + перепроведения документов, то Вы явно лукавите. Не может быть столько изменений этого одного реквизита, чтобы журнал долго открывался и долго сжимался. Выше отписывались люди у которых все прекрасно отрабатывало и журнал был больше ~950 Гб и все нормально работает. А у Вас тут, понимаешь, один реквизит в одном справочнике регистрируется и журнал не открывается...
2) С тем, что версионирование из БСП лучше - это тоже лукавство, чистой воды. К нам обычно обращаются, как раз уже тогда, когда попробуют использовать версионирование и через неделю база распухает до невероятных размеров и они принимают решение не использовать этот механизм и ищут ему замену.

PS: Я очень ревностно отношусь к своим коммерческим решениям, за более чем 4 года успешного сотрудничества с Инфостартом (!) не было НИ ОДНОГО такого клиента с такими претензиями как вы! Доржи не даст соврать. Говорите о проблемах, но на прямую не обращаетесь с ними ко мне, мои просьбы связаться через skype и показать проблемы через Team Viewer игнорируете и при этом откровенно обманываете как в п.1. Так что не надо троллить и очернять ни меня ни разработку, я приложил максимум усилий и терпения!

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

Для остальных:
Вообще конечно, мое упущение, что я не сделал табличку с плюсами и минусами, замерами производительности типового журнала, версионирования и нашего журнала на MS SQL. Обещаю в ближайшее время постараюсь это сделать, чтобы все, что изложено выше уже не могло бы недобросовестными людьми использоваться как аргумент.
v.a.ryag; JesteR; rayastar; klinval; kalevra67; vadimlp77; denis_aka_wolf; Rokstedi; Uncore; tiniji; xMen; kuzyara; Alex George; support; +14 Ответить 1
103. Сергей Клабуков (klabuk0v) 12.02.15 09:07
А есть возможность взять систему на тестовый период? 30 дней например. Поставить систему, сделать замеры и только потом принять решение о покупке?
104. Виталий Барилко (Diversus) 12.02.15 09:08
(103) Как я обещал, выложу результаты тестирования системы в публикацию чуть позже, самостоятельно.
105. Виталий Барилко (Diversus) 25.02.15 17:51
Обновление от 19.02.15 Версия 2.0.3.6
[!] Исправлена ошибка, которая могла возникать при сжатии кэша журнала регистрации на больших объемах данных. Изменен механизм получения данных при сжатии.
106. Олег Познянский (olegpoz) 19.03.15 12:35
Добрый день!
Пока только знакомлюсь с вашим продуктом - очень похоже что он нам понравится)

Однако - почему нельзя было бы поменять логику с ролью "(ВН) Пользователь журнала регистрации" ?
Понятно что для НЕКТОРЫХ пользователей, иногда нужно отключать регистрацию.
Почему не сделать по-умолчанию - для всех регистрируем, а при включенной роли "(ВН) Не регистрировать..." - не регистрируем ??

Не пришлось бы для каждого новго юзера следить за этой ролью (а с БСП еще и за группой доступа)
Или я не прав?
Для написания сообщения необходимо авторизоваться
Прикрепить файл
Дополнительные параметры ответа