FLY-DIRECTUM: часть 5. И верить в то, что не было измен (с)
Всё чаще на форуме (и на проектах внедрения, что уж греха таить) поднимается вопрос о жёстком ограничении возможности редактирования документов, участвующих в типовых маршрутах, теми или иными участниками на тех или иных этапах. В довесок озвучивается необходимость разрешения редактирования только путём создания новых версий документа.
Требование само по себе достаточно неоднозначно. Казалось бы, ситуация в первую очередь должна решаться административно – маловероятно, что до внедрения системы сотрудники позволяли себе подменять документы в процессе их согласования, так почему после внедрения установленный порядок работы и деловой этики должен измениться? Но, раз потребность есть, давайте посмотрим – что с этим можно сделать?
Начнём со штатных средств. Новинки версии 4.9.1 позволяют всё меньшему кругу участников типового маршрута выдавать права выше просмотра. Так, если раньше для подписания документов электронной подписью требовались права типа «Изменение» и выше, то сейчас достаточно для конкретного вида документа установить минимальные права на подписание типа «Просмотр». Вторая новинка – передача прав на документы – позволяет не только существенно сократить круг лиц с полными правами на документы, но и снизить количество запросов к этим лицам на выдачу прав. Более того, если привлечь разработчика и немного пошаманить, то ту же передачу прав можно использовать только на конкретных вложенных документах, а так же только на конкретных блоках: при формировании заданий по блоку разрешать передачу прав, при выполнении – снимать разрешение. Все эти манипуляции позволяют на максимальном количестве блоков типового маршрута выдавать права на вложения всем участникам только на просмотр.
Оборотная сторона медали заключается в двух важных нюансах. Во-первых, рецензенты смогут вносить свои замечания только в текст переписки по задаче, а это далеко не всех и не всегда устраивает. Во-вторых, автор документа продолжает обладать полными правами на документ, что позволяет ему редактировать документ на любой стадии жизненного цикла, в том числе и после согласования (опустим этическую сторону вопроса). Безусловно, электронная подпись максимально защищает документ от внеплановых изменений, но по тем или иным причинам её использование может быть не актуально для компании. Как поступить?
В теме Изменение прав доступа на документ моя коллега разработчик Юлия Литвинюк даёт подробные рекомендации о том, как разработать новое свойство блока «Расширенное задание», позволяющее выдавать и изымать у исполнителя блока требуемые права на вложенные документы. Пользуясь этими рекомендациями можно программно изменять права автора документа, разрешая редактирование вложений на определённых этапах маршрута – например только при необходимости доработки. При использовании этого способа необходимо помнить, что для документа в любом случае должен быть указан хотя бы один пользователь с типом прав «Полный», поэтому, снимая права с автора документа, необходимо будет выдать их администратору или любому другому служебному пользователю.
Схожим образом решается задача разрешения редактирования документа только созданием новых версий. Для этого можно разработать новое свойство блока «Расширенное задание», устанавливающее блокировку на все версии вложенных документов. Таким образом даже наличие полных прав на документ не позволит редактировать его иначе, чем созданием новой версии, которая, в свою очередь, так же будет заблокирована от последующих изменений. Именно этот вариант можно использовать для работы рецензентов, предпочитающих вносить исправления непосредственно в текст документа. При использовании этого способа необходимо учитывать, что блокировки с версий сможет снимать только администратор системы и пользователь, от имени которого блокировка будет установлена, причём это может быть как исполнитель задания, так и служебный пользователь.
Дополнительно, во избежание нежелательного роста количества версий документа, а также в целях исключения несогласованных изменений, можно осуществлять контроль за созданием версий документа. В этом нам также поможет разработка нового свойства блока "Расширенное задание". При настройке свойства будет проверяться создание новой версии документа и либо полностью запрещаться дальнейшее движение по типовому маршруту, либо разрешаться отправка только на доработку инициатору, чтобы ввести его в курс изменений и осуществить повторное согласование изменённого документа. Подробная реализация описана Юлией Литвинюк в теме Контроль за созданием версий ЭД в блоке "Расширенное задание".
Отдельной строкой хочу упомянуть о том, что в редакторе MS Word есть возможность установки парольной защиты на изменение документа кроме записи исправлений или вставки примечаний. Можно обязать автора после создания документа защищать его в том числе и таким образом, либо устанавливать защиту программно, пользуясь разработкой, предложенной Татьяной Дозморовой в материале Оформление замечаний с помощью примечаний.
Все перечисленные способы можно использовать как совместно, так и в различных комбинациях: например при установке блокировок нет нужды изымать права у автора документа, а в случае использования защиты средствами MS Word не нужны блокировки – достаточно изъять права у автора и выдавать их только при необходимости доработки.
Разрабатываем сейчас процедуру согласования многостраничных документов (с большим и жестко не определенным сроком для согласующих).
Согласование проходит в 2 этапа: Рассмотрение и согласование.
На этапе рассмотрения ставим блокировки на все версии в вычислениях маршрута.
На этапе согласования снимаем блокировку с последней версии (что бы её можно было подписать) и участники согласования должны наложить на эту версию свои подписи.
Проблемным участком остаётся только период, когда блокировка с версии снята, но ЭЦП ещё ни одним из участников не наложена... В это время (у нас ещё 4.8) инициатор или согласующие могут изменить текст документа. И хотя вероятность этого не велика, к законам Мерфи надо прислушиваться...
Пока у нас модуль в разработке, по этой причине и прецедентов ещё нет. Как будет позже, покажет время...
Михаил, правильно ли я понимаю, что все участники процесса как минимум дважды работают с одним и тем же документом? Не затягивает ли это процесс - наверняка участники перед подписанием повторно вычитывают документ?
Что касается проблемного участка, могу предложить в тот же момент, когда снимается блокировка с версии, подписывать эту версию электронной подписью от имени служебного пользователя - так Вы оставите Мерфи с носом =)
По поводу системной подписи, думали над этим вариантом. Не хочется пока идти по этому варианту. Подпись - всё таки инструмент пользователя, а не разработчика. Но возможно мы к нему ещё придем...
По поводу работы с документом дважды. Как правило документы в формате doc, docx, что позволяет не проводить полное вчитывание, а с помощью инструментария офиса провести сравнение 2х документов. Кроме того в момент рассмотрения система записывает, какая версия документа в данный момент последняя в отдельном справочнике согласования для текущего согласующего.
Посмотрев в этот справочник на этапе согласования, согласующий сможет узнать, какую версию он рассматривал последний раз и какая сейчас актуальная. Если есть версия, появившаяся позже, то он обязан перед подписанием ознакомится с изменениями в новой версии. Возможно именно эти изменения могут его не устраивать...
А так же автоматически (на основе текстов переписки) ведётся отдельный документ с перечнем замечаний, которые выставлены тем или иным согласующим.
Тогда могу предложить два других варианта:
Спасибо за подсказку, Анатолий, сейчас включу эту информацию в текст материала.
Насколько я помню, такая защита при желании не очень сложно снимается. По крайней мере, однажды я ее снимал...
Иван, если ставить её без использования пароля (с пустым паролем), то конечно снимается она простым нажатием кнопки "Снять защиту". Но если использовать пароль, то без его знания защиту снять не получится.
Существует полно всякого софта, который умеет снимать парольную защиту с офисных документов. Причем работает этот софт довольно таки шустро и всегда со 100% результатом. Если посидеть и немного подумать над этой проблемой, то наверняка можно что-нибудь "замутить", чтобы можно было просматривать и редактировать запороленные офисные документы прямо в DIRECTUM.
Дмитрий, это безусловно. А ещё можно не ходить далеко за софтом и взламывать сразу саму базу - тут даже ЭП не помеха. Против лома нет приёма, если нет другого лома.
Материал преследовал иные цели.
В материал добавлена информация о реализации контроля за созданием версий документа.
Файлы Word и Excel начиная с версии 2007 - zip-архивы, внутри метаданные хранятся в виде xml-файлов. Наличие защиты и хэш пароля как раз в одной из xml находится, так что чистится вручную максимум за 10 минут (если уже знать, что конкретно менять). Потом только импортировать измененный документ останется. Одна из первых ссылок в гугле: http://www.nextofwindows.com/how-to-remove-password-from-protected-word-file-in-word-2007-and-2010/
Иван, предлагаю оформить сразу материалом, что-нибудь вроде "Обход запретов, накрученных разработчиками DIRECTUM, для чайников"
Можно обойтись простенькой процедурой настройки прав на вложения, но до версии 5.0 были проблемы с возвратом прав при прерывании процессов.
Максим, разверните свой комментарий пожалуйста, я не совсем поняла - что вы хотели сказать.
Была задача исключить доступ к документам более чем на Просмотр Инициатору чтобы он не мог ничего сделать с документами пока они ходят по маршруту. Да и исполнителям заданий тоже лишние права не нужны после выполнения. Для этого была составлена функция:
Сама функция:
//Убираем права Attachments = Task.GetAttachments(TRUE) if VarIsClear(Attachments) Exit endif if Attachments.Count <= 0 Exit endif AdministratorsGroup = ServiceFactory.GetGroupByName('Administrators') Administrators = ServiceFactory.GetGroupMembers(AdministratorsGroup) Administrator = ServiceFactory.GetUserByName('Administrator') foreach Attachment in Attachments AttachmentInfo = Attachment.ObjectInfo if AttachmentInfo.ComponentType = ctEDocument EDocument = AttachmentInfo.Document EDocument.Requisites('ISBDelegateRights').Value = 'Да' EDocument.Save //Проверяем есть ли права у Администратора if not EDocument.AccessRights.Managers.Find(Administrator) EDocument.AccessRights.Managers.Add(Administrator) EDocument.Save endif foreach User in EDocument.AccessRights.Managers if (User.Name <<>> 'Administrator') EDocument.AccessRights.Managers.Delete(User) EDocument.Save EDocument.AccessRights.Readers.Add(User) EDocument.Save endif endforeach foreach User in EDocument.AccessRights.Writers if (User.Name <<>> 'Administrator') EDocument.AccessRights.Writers.Delete(User) EDocument.Save EDocument.AccessRights.Readers.Add(User) EDocument.Save endif endforeach endif endforeachВызов это функции вставляется везде где нужно отобрать права после выполнения задания. Выдача прав, в том числе на этапе "Доработка" выполняется настройками блока Задание или Расширенное задание.
Но до версии 5.0 не было события позволяющего обработать прерывание маршрута Инициатором. Из-за этого приходилось восстанавливать доступ руками по звонку. В 5.0. событие появилось, в нём можно проанализировать на каком этапе прерывается маршрут и в зависимости от этого раздать необходимые права на вложения. Например, если маршрут не прошёл всех согласующих, то прерывание означает необходимость серьёзно доработать документы, а возможно и поменять параметры маршрута, следовательно можно вернуть Инициатору полные права.
Примерно так. Решение не сильно универсальное и кроме документов ничего не обрабатывает, но нам было достаточно.
Спасибо за подробности, Максим
В качестве замечания-примечания, вот это foreach не нужен:
foreach User in EDocument.AccessRights.Managers if (User.Name <<>> 'Administrator') EDocument.AccessRights.Managers.Delete(User) EDocument.Save EDocument.AccessRights.Readers.Add(User) EDocument.Save endif endforeachЕсли его убрать, код будет работать абсолютно так же, как раньше. И непонятно, зачем постоянно делать Save у документа - это совершенно лишнее. Достаточно один раз сохранить после всего кода.
Почему не нужен? Список пользователей с полным доступом и список пользователей с доступом на изменение разные вещи. Или API уже поменялось? А сохранение уже не помню почему вставил, но что-то без него не работало. Функция делалась ещё для 4.7.
Да, разные списки, но те, кто имеет полный доступ, имеют и права на изменение (ну и на чтение, конечно). Поэтому при удалении из списка на изменение, пользователи удаляются и из списка полных прав доступа (если они там были).
О как! А в справке об этом нюансе ни слова.
Если верить справочной системе, у IAccessRights свойства Managers, Readers и Writers возвращают IUserList - объект для управления списком пользователей. Откуда он знает, что надо заглянуть в другие IUserList?
Так запрограммирована платформа.
Авторизуйтесь, чтобы написать комментарий