Практически каждый программист 1С сталкивался со следующей ситуацией: кто-то из пользователей случайно/намеренно помечает на удаление объект информационной базы. В зависимости от ситуации можно действовать по-разному:
- Ничего не искать и не выяснять, подойти к проблеме философски — заранее понять и простить виновника и просто снять пометку удаления. На мой взгляд, так и стоит поступить, если последствия незначительны, подобные случаи легко обнаруживаются пользователем и
вообще никого это не волнуетнет веской причины для выяснения обстоятельств; - Найти записи о пострадавшем объекте в журнале регистрации, установить виновника — пользователь установивший пометку удаления, совершил ли он это действие со своего компьютера или пытался кого-то подставить (скандалы, интриги, расследования) и действовать в соответствии с полученной информацией;
- Обнаружить, что по факту объект в информационной базе полностью отсутствует. В попытках восстановить хронологию событий в журнале регистрации осознать, что записи по нему не обнаружены, хотя у нас есть веские доказательства его существования. Для такого случая как раз и создана эта обработка.
Не смотря на то, что поиск элемента в журнале регистрации результата не выдает, в нем могут записи вида <Объект не найден>. Данная обработка выводит все подобные записи за указанный период:
Желательно не задавать большой период, особенно на базах с большим количеством пользователей и большим объемом данных.
Если вы начинающий программист, то обратите внимание, что в случае явного удаления объекта, в первую очередь нужно проверить всех пользователей на наличие права доступа "Непосредственное удаление", т.е. право удаления объектов без контроля ссылочной целостности. Также стоит проверить все внешние обработки и конфигурацию а использование метода "Удалить()", которые также действует без использования контроля ссылочной целостности.
С помощью материалов сайта https://helpf.pro/faq/view/483/html (огромное спасибо автору) с переделкой под управляемый формы была создана обработка для получения GUID из строки вида " <Объект не найден> (84:bf5600145e3710ab11dda4c605dbe824)". Далее, в копии информационной базы с помощью той же обработки по этому GUID были получены ссылки этих объектов и таким образом удалось отследить всю историю событий:
Отпуск под номером 42-кд был создан и проведен одним пользователем, снят с проведения и помечен другим и удален из базы данных фоновым заданием, т.е. обработкой "УдалениеПомеченныхОбъектов", вот это поворот.
Для удобства поиска и анализа в обработке есть возможность отфильтровать журнал по представлению данных, если есть его точные номер и дата документа, либо по метаданным.
Related Posts
Восстановление последовательности документов при закрытии месяца в Бухгалтерия 3.0 не завершается
Заполнение табличных частей
Формирование сводных актов выполненных работ
Ввод поступления в переработку на основании передачи сырья (между организациями)- Конспект по установке сервера 1С на linux
Получение имени компьютера и его IP локально и в терминале
Подобных решений на инфостарте очень много… А почему заранее не быть готовым к такому?
(1) Отличная разработка, упрощает жизнь пользователю и программисту. Надо бы тоже полистать БСП в поисках интересного)
Конечно, есть много подобных обработок, но в основном они направлены на получение GUID объекта. Данная же предназначена для получения конкретной информации о факте удаления объекта. Зачастую необходимо конкретно знать, кто из пользователей «косячит», делает он это со злым умыслом или нет. Можно сколько угодно восстанавливать объекты из версий, а можно один раз поговорить с человеком и это решит проблему (или нет, но он осознает, что за ним следят:) ) Превентивные меры это конечно хорошо, но решения пост-фактум тоже должны быть. Никому не навязываю свое мнение, мне данная разработка не раз пригождалась, поэтому решила ей поделиться)
(2)
Никто не мешает перед удалением записывать автора. Я же выдрал из БСП Версионирование, там как раз делается версия, автор, дата.
(3) Это все замечательно, но это также превентивные меры. Если ситуация уже произошла, к примеру кто-то удалил большой объем документов и это повлекло негативные последствия, руководство требует найти виновника. Если базы достаются по наследству, либо программист работает во франчайзи/фрилансе, не важно как было все организовано раньше, и как можно это сделать в будущем — нужен результат. А потом уже все что угодно, любые мероприятия по предотвращению.
(4)Хорошо вот стандартная ситуация.
Фирма без администратора и программиста в штате. Обслуживает ее кто то (не обязательно франч) с мелким ценником и таким же качеством обслуживания.
Бекапов нет(это всплыло когда уже что-то плохое произошло).
Журнал регистрации не ведется(экономия места).
У всех в базе полные права.
Ситуация произошла но тут и вы не поможете.
П.С. А фирм таких очень много…
(5) У описанной фирмы все очень плохо, я думаю ей кто-то в ней захочет навредить, то тут не поможете и Вы) Ну а если серьезно, я вроде как не отрицаю, что предусмотрительный контроль это хорошо или даже необходимо, но если есть возможность, то почему бы не разобраться в произошедшем, используя доступные на данный момент средства?
Насколько я знаю, многие не используют версионирование из-за увеличения объема базы данных и снижения производительности, если они отключили даже журнал регистрации для экономии места, не будут ли занимать еще больше места версии объектов? (это не ирония, я действительно хочу знать что оптимальнее)
(6)
Поэтому и планирую в будущем некое хранилище данных в которое будут стикать версии с различных баз по http, а потом может и ВИД сделаю. И лежать оно может где угодно хоть в облаке.
Вот что я считаю оптимальным. Но до этого хочу дорисовть другую подсистему.
(7) Получается, это что-то вроде резервной копии отдельных данных базы на внешнем источнике?
(8)Да. Копия удаленных объектов.
Пока только в текущей базе, потом будет некое центральное хранилище(отдельная конфигурация с http-сервисами, а потом и возможно некий скрипт для разворачивания на голой СУБД).
(2) А разве объекты не удаляются «по делу»? Например, зачем в базе дубликаты Контрагентов, Номенклатуры и т.п. Их вроде как можно и нужно удалять…
А если вместо рукоприкладства «Вредного Юзера» рухнет винт компьютера? И рабочая база «улетит в небытие»?
ПЕРВОЕ правило — делай резервную копию, что бы потом не было «Мучительно больно» восстанавливать данные!
(10) Вы читали описание публикации? Как это связано с объектами, который удаляются «по делу»?)
(11) Спасибо за проявленный интерес, но вы ничего не перепутали? Данная обработка позволяет исправить ситуацию де-факто, когда все уже свершилось. Где вы увидели, что я советую не делать резервные копии?) В публикации указано, что GUID удаленного неопознанного объекта мы распознаем как раз в резервной копии.
(13) Данное примечание не Вам, а прочим читателям. Просто акцентирую внимание на то, что восстановить можно из достаточно свежей резервной копии…
(12) Так в Журнале регистрации нет пометок о причине удаления… По делу или злонамеренно — не вычислишь!
Получается полный список, в котором неизвестным способом ищется один или несколько Объектов… Вероятно поиск происходит по Представлению… Методика поиска нужного документа не раскрыта.
Есть не совсем криминальный сценарий: Пользователь с целью внесения исправлений, делает копию документа, правит с проведением. А заодно удаляет неправильный источник.
P.S. Предпочтительнее перед загрузкой из копии, иметь возможность посмотреть реквизиты документа…
Кстати, а связанные документы как подгружаются (например, связка Реализация + СчетФактура)? Индивидуальным указанием каждого из них?