Разработчики продолжают раскрывать подробности о возможных направлениях развития платформы 1С:Предприятие 8.5.5. В новых публикациях описаны планируемые изменения в работе с ролями и правами, обслуживании PostgreSQL, автоматизированном тестировании и Системе взаимодействия.
Ранее мы уже рассказывали о предварительных планах по развитию платформы 1С:Предприятие 8.5.5 . Среди них упоминались поддержка gRPC, анализ покрытия прикладного кода тестами, развитие интеграционных механизмов и инструменты для определения минимально необходимых прав пользователя.
Теперь появились дополнительные сведения еще о четырех направлениях:
- упрощении работы с ролями в Конфигураторе;
- автоматизации отдельных операций обслуживания PostgreSQL;
- получении расшифровок и краткого содержания видеозвонков;
- расширении возможностей автоматизированного тестирования интерфейса.
Важно учитывать, что речь идет именно о планах развития платформы. Состав версии, сроки реализации, названия методов, ограничения и порядок использования функций могут измениться.
Какие направления развития заявлены для 1С:Предприятия 8.5.5
| Направление | Что рассматривают разработчики | Для кого это может быть полезно |
|---|---|---|
| Роли и права | Поиск и фильтрация ролей и объектов в редакторах Конфигуратора | Разработчики, аналитики и специалисты сопровождения |
| PostgreSQL | Платформенный сервис для периодического обслуживания базы данных | Администраторы 1С и ИТ-инфраструктуры |
| Видеозвонки | Получение текстовой расшифровки и краткого содержания записи | Проектные команды, консультанты и руководители |
| Автоматизированное тестирование | Дополнительные методы для проверки меню, сообщений, окон и командного интерфейса | Разработчики и специалисты по тестированию |
| Контроль обновлений | Совместное применение автотестов и анализа покрытия кода | Компании с крупными и доработанными системами 1С |
Рассмотрим подробнее, как могут работать заявленные механизмы, если они войдут в итоговый релиз.
В Конфигураторе могут упростить работу с большим количеством ролей
Одна из опубликованных инициатив касается работы с ролями и правами доступа.
В небольших информационных базах количество ролей обычно ограничено. Однако в крупных конфигурациях, особенно в 1С:ERP, 1С:Комплексной автоматизации, 1С:Документообороте и отраслевых решениях, ролевая модель может включать десятки или сотни элементов.
Отдельные роли могут создаваться для:
- бухгалтеров;
- кадровых специалистов;
- руководителей;
- менеджеров;
- кладовщиков;
- производственных сотрудников;
- операторов;
- администраторов;
- специалистов отдельных подразделений.
Ситуация становится сложнее, если в конфигурации присутствуют собственные объекты, расширения, дополнительные подсистемы и доработанные механизмы разграничения доступа.
В таком случае разработчику приходится работать с длинными перечнями ролей и большими деревьями метаданных. Поиск роли, связанной с определенным документом, справочником или регистром, может занимать значительное время.
Для версии 8.5.5 рассматривается несколько изменений, которые должны упростить эту работу.
Поиск ролей в настройках прав объекта
В правах объекта метаданных планируется добавить фильтрующий поиск по ролям.
Также рассматривается возможность отбора ролей в зависимости от того, имеют ли они права на выбранный объект.
Например, специалист сможет открыть определенный документ, справочник или регистр и получить более компактный список ролей, связанных с этим объектом. В конфигурациях с большим количеством ролей такой фильтр может сократить объем ручного поиска.
Фильтрация объектов в редакторе роли
Изменения также планируются в редакторе отдельной роли. Разработчики описывают возможность:
- искать объекты в дереве метаданных;
- отображать только те объекты, на которые выбранная роль имеет права.
Вместо просмотра всей структуры конфигурации специалист сможет сосредоточиться на объектах, связанных с конкретной ролью.
Это может быть полезно при:
- аудите прав пользователей;
- изменении полномочий сотрудников;
- расследовании ошибок доступа;
- подготовке новой роли;
- проверке последствий обновления;
- анализе ранее выполненных доработок.
Изменения в редакторе «Все роли»
Наиболее заметная доработка рассматривается для редактора «Все роли».
В опубликованных материалах упоминаются следующие возможности:
- поиск по дереву метаданных;
- фильтрация списка ролей;
- отображение ролей, имеющих права на выбранный объект;
- отображение объектов, доступных выбранным ролям;
- визуальное выделение объектов и ветвей дерева, связанных с отобранными ролями;
- расчет общей колонки прав только по выбранным ролям.
Если механизм войдет в релиз, специалист сможет выбрать несколько ролей и анализировать только связанную с ними часть конфигурации. Это потенциально упростит сравнение прав и поиск пересечений между ролями.
Новые фильтры не заменят проектирование системы доступа
Планируемые изменения следует рассматривать как инструменты навигации и анализа. Они не будут самостоятельно определять, какие полномочия необходимо предоставить конкретному сотруднику.
Даже при наличии удобных фильтров потребуется определить:
- какие данные должен видеть пользователь;
- какие документы он может создавать;
- какие операции ему разрешено выполнять;
- должен ли он иметь доступ к данным других организаций;
- может ли он изменять финансовую информацию;
- какие действия требуют дополнительного согласования.
Новые механизмы могут облегчить техническую работу с ролями, но ответственность за проектирование системы доступа останется за организацией и специалистами, сопровождающими информационную базу.
Работу с фильтрами ролей также не следует путать с другим заявленным направлением развития платформы — определением минимального набора прав, необходимого для выполнения определенного пользовательского сценария.
Эти механизмы могут дополнять друг друга:
- фильтрация помогает исследовать уже существующую ролевую модель;
- анализ минимальных прав может помочь определить разрешения, необходимые для конкретной операции.
Окончательный состав обоих механизмов станет понятен после публикации документации.
Для записанных видеозвонков рассматривают расшифровку и конспект
Еще одно направление развития связано с Системой взаимодействия 1С.
Сейчас она позволяет пользователям обмениваться сообщениями, проводить видеозвонки и использовать инструменты совместной работы внутри прикладного решения.
В версии 8.5.5 разработчики рассматривают возможность обработки записанного видеозвонка средствами встроенного языка.
В опубликованном описании упоминаются два возможных результата:
- полная текстовая расшифровка разговора;
- краткое содержание или конспект записи.
Предполагается, что полученный текст можно будет использовать в прикладном решении: показать пользователю, сохранить или передать на дальнейшую обработку.
Однако это пока не означает появления готовой функции автоматического протоколирования всех рабочих встреч.
Разработчики описывают платформенную возможность. Конкретные сценарии использования должны будут реализовываться на уровне конфигурации или отдельной доработки.
Как расшифровка может применяться в проектах
Если заявленный механизм войдет в платформу, на его основе можно будет рассматривать несколько прикладных сценариев.
Подготовка материалов по итогам встречи
Расшифровка может стать дополнительным источником информации при составлении:
- протокола совещания;
- отчета о встрече;
- постановки задачи;
- описания требований;
- внутренней инструкции;
- проектной документации.
При этом автоматически сформированный текст необходимо будет проверять. Он не должен без контроля заменять утвержденный протокол или техническое задание.
Ознакомление с пропущенными звонками
Сотрудник, который не участвовал во встрече, потенциально сможет ознакомиться с кратким содержанием вместо просмотра всей видеозаписи.
Это может быть полезно при длительных проектных обсуждениях, демонстрациях и согласовании требований.
Сохранение истории решений
Во время внедрения и сопровождения 1С значительная часть вопросов обсуждается на онлайн-встречах.
Через некоторое время участникам может быть сложно восстановить:
- какую логику согласовали;
- какие ограничения были выявлены;
- почему выбрали определенный вариант;
- кто должен был предоставить информацию;
- какие действия планировали выполнить дальше.
Текстовая расшифровка может использоваться как дополнительный источник для восстановления контекста. Однако юридическая и управленческая значимость такого текста будет зависеть от внутренних регламентов организации.
Что пока неизвестно о расшифровке видеозвонков
Опубликованная информация пока не дает ответов на ряд практических вопросов:
- какие языки будут поддерживаться;
- где будет обрабатываться запись;
- потребуется ли дополнительный сервис;
- будут ли действовать ограничения по длительности звонка;
- как будет разграничиваться доступ к расшифровке;
- можно ли будет повторно формировать краткое содержание;
- как будет храниться результат;
- какие версии Системы взаимодействия будут поддерживаться;
- потребуются ли отдельные лицензии или настройки.
Эти детали могут существенно повлиять на возможность применения механизма в корпоративных системах.
Организациям также потребуется учитывать правила работы с персональными данными, конфиденциальной информацией и записями переговоров.
Для PostgreSQL планируют платформенный сервис обслуживания
Отдельный материал посвящен обслуживанию информационных баз, работающих на PostgreSQL.
В настоящее время многие операции с СУБД выполняются администраторами с использованием отдельных инструментов, сценариев и регламентов.
При этом число систем 1С на PostgreSQL увеличивается. Для части компаний эта СУБД становится альтернативой коммерческим решениям, в том числе в рамках импортозамещения инфраструктуры.
Разработчики рассматривают создание компонента «Сервис обслуживания баз данных», или DBMaintenanceService.
Согласно опубликованному описанию, сервис должен выполнять настроенные операции обслуживания PostgreSQL в заданные периоды.
Как может настраиваться сервис обслуживания PostgreSQL
Настройки планируют разместить в функции технического специалиста «Управление серверами».
Предполагается, что соответствующий раздел будет доступен при использовании PostgreSQL.
Администратор сможет задавать:
- перечень выполняемых операций;
- периодичность;
- дополнительные параметры;
- разрешенные интервалы выполнения;
- интенсивность обслуживания;
- разные расписания для будних и выходных дней.
Одна из особенностей заявленного подхода состоит в использовании окон обслуживания.
Администратор сможет определить не только конкретное время запуска, но и период, в течение которого сервису разрешено выполнять определенные действия.
Например, можно будет предусмотреть:
- короткое ночное окно в рабочие дни;
- более продолжительный интервал в выходные;
- отдельный режим для периода минимальной нагрузки;
- различную интенсивность в зависимости от дня недели.
Если такой механизм будет реализован, он может упростить организацию регулярных операций в компаниях, где нет отдельного администратора PostgreSQL.
Также заявлена возможная доработка консоли администрирования серверов 1С и предоставление части функций во встроенном языке.
Почему обслуживание СУБД имеет значение
Производительность системы 1С зависит не только от прикладного кода и конфигурации, но и от состояния базы данных.
По мере эксплуатации могут увеличиваться:
- объемы таблиц;
- размеры индексов;
- количество записей в регистрах;
- продолжительность запросов;
- нагрузка на дисковую подсистему;
- время выполнения регламентных операций.
В крупных информационных системах это может влиять на:
- проведение документов;
- закрытие месяца;
- расчет себестоимости;
- формирование отчетов;
- выполнение обменов;
- массовую обработку данных;
- расчет начислений;
- работу фоновых заданий.
Регулярное обслуживание помогает поддерживать стабильность базы данных. Однако выполнять его необходимо с учетом пользовательской нагрузки.
Ресурсоемкая операция, запущенная в рабочее время, может замедлить работу сотрудников. Поэтому возможность задавать окна и интенсивность обслуживания может оказаться полезной.
Новый сервис не заменит полноценное администрирование PostgreSQL
Даже если компонент войдет в релиз 8.5.5, он не сделает базу данных полностью автономной.
Администраторам по-прежнему потребуется:
- контролировать свободное место;
- проверять резервное копирование;
- выполнять тестовое восстановление;
- анализировать медленные запросы;
- отслеживать блокировки;
- контролировать состояние оборудования;
- проверять журналы ошибок;
- планировать обновление СУБД;
- настраивать отказоустойчивость;
- анализировать рост информационной базы.
Платформенный сервис может автоматизировать только часть периодических операций.
Точный перечень поддерживаемых задач, требования к правам и совместимые версии PostgreSQL станут известны после выхода технической документации.
Продолжается развитие автоматизированного тестирования
Еще одна группа планов относится к механизму автоматизированного тестирования.
Он позволяет воспроизводить действия пользователя в интерфейсе 1С и проверять результат программными средствами.
Тест может:
- открывать формы;
- заполнять поля;
- нажимать команды;
- переходить между разделами;
- записывать документы;
- сравнивать полученные данные с ожидаемыми.
Для версии 8.5.5 разработчики описали несколько дополнительных методов, которые могут расширить возможности проверки интерфейса.
Названия, параметры и порядок применения методов до выпуска версии могут быть изменены.
Возможные новые методы тестируемой формы
Для объекта ТестируемаяФорма рассматриваются три дополнительных метода.
ПолучитьПредставлениеМеню
Метод планируется использовать для получения представлений пунктов открытого меню в виде массива строк.
Если он войдет в релиз, автоматический тест сможет проверять:
- открылось ли нужное меню;
- присутствует ли определенная команда;
- соответствует ли состав меню ожидаемому;
- не исчез ли пункт после обновления;
- доступна ли команда пользователю с определенными правами.
ОтображаетсяСообщениеПользователю
Метод должен определять, отображается ли пользователю сообщение, связанное с проверкой заполнения формы.
Предполагается, что результат будет возвращаться в виде логического значения.
ПолучитьТекстСообщенияПользователю
С помощью этого метода планируется получать текст показанного сообщения.
Вместе эти механизмы могут использоваться для проверки реакции системы на ошибочные действия пользователя.
Например, тест сможет оставить обязательное поле незаполненным и проверить:
- появилось ли сообщение;
- соответствует ли его текст ожидаемому;
- не позволила ли система продолжить операцию.
Это может повысить качество проверки форм и прикладных ограничений.
Планируется расширить проверку командного интерфейса
В опубликованном описании также упоминается добавление программно доступных имен для элементов командного интерфейса.
Тесты потенциально смогут обращаться к таким областям, как:
- панель разделов;
- избранное;
- история;
- панель открытых окон;
- функции текущего раздела;
- панель действий;
- панель навигации;
- меню функций.
Это может быть полезно при проверке интерфейса для разных ролей.
Например, после изменения прав автоматический сценарий сможет проверить, что пользователь:
- видит предусмотренные разделы;
- может открыть необходимые функции;
- не имеет доступа к запрещенным подсистемам;
- сохраняет рабочие команды после обновления.
Может появиться механизм определения блокирующего окна
Для объекта ТестируемоеОкноКлиентскогоПриложения рассматривается метод ПолучитьБлокирующееОкно.
Он должен позволить определить, открыто ли поверх текущего окна другое окно, которое препятствует дальнейшему выполнению теста.
Такая ситуация может возникнуть, если во время сценария появляется:
- предупреждение;
- подтверждение операции;
- сообщение об ошибке;
- диалог выбора;
- дополнительная форма;
- запрос на продолжение действия.
Сейчас неожиданное окно может привести к остановке сценария. Новый метод потенциально позволит тесту обнаружить его, проверить содержание и выполнить предусмотренное действие.
Как это связано с анализом покрытия кода
Ранее среди планов по платформе 8.5.5 также упоминался анализ покрытия прикладного кода тестами.
Автоматизированное тестирование и анализ покрытия решают разные задачи.
Автотест проверяет, удалось ли выполнить пользовательский сценарий и получить ожидаемый результат.
Анализ покрытия должен показывать, какие участки прикладного кода фактически выполнялись во время теста.
Например, тест может успешно провести документ. Однако это не означает, что были проверены все возможные условия:
- возврат;
- скидка;
- особый вид операции;
- отсутствие необходимых данных;
- альтернативный вариант расчета;
- работа пользователя с другой ролью.
Если оба механизма войдут в релиз, их совместное применение может помочь точнее оценивать качество проверки.
Наибольшую пользу это может принести при:
- обновлении нетиповых конфигураций;
- разработке расширений;
- изменении расчетных алгоритмов;
- доработке прав;
- исправлении ошибок;
- подготовке крупных релизов;
- изменении интеграций;
- переносе функциональности.
Что планы по версии 8.5.5 могут означать для пользователей
Большинство описанных изменений ориентировано на разработчиков и администраторов. Однако косвенно они могут повлиять и на работу бизнеса.
Проверка обновлений может стать подробнее
Дополнительные методы тестирования позволят охватывать больше элементов интерфейса и пользовательских сценариев.
Это может снизить риск того, что после обновления останется незамеченной ошибка в меню, форме, правах или обработке блокирующего окна.
Анализ прав может занимать меньше времени
Фильтры в редакторах ролей потенциально упростят поиск источника доступа и сравнение полномочий.
Обслуживание PostgreSQL может стать более централизованным
Платформенный сервис может сократить количество отдельных инструментов и ручных операций. Реальный эффект будет зависеть от состава поддерживаемых задач.
Результаты видеозвонков можно будет использовать в прикладных процессах
Расшифровка и краткое содержание могут стать основой для протоколов, отчетов и проектной документации. Однако для этого потребуется дополнительная реализация и контроль результата.
Нужно ли уже готовиться к версии 8.5.5
Обновлять рабочую систему только на основании предварительных анонсов преждевременно.
Однако крупным организациям уже сейчас можно оценить потенциальную применимость заявленных механизмов:
- проанализировать количество ролей и сложность системы доступа;
- проверить действующий регламент обслуживания PostgreSQL;
- составить перечень критичных пользовательских сценариев;
- определить, какие операции необходимо тестировать после обновлений;
- оценить текущее использование Системы взаимодействия;
- подготовить отдельный тестовый контур;
- зафиксировать состав расширений, интеграций и внешних обработок;
- определить порядок проверки новых версий платформы.
После выхода релиза потребуется изучить:
- официальное описание изменений;
- техническую документацию;
- системные требования;
- совместимость используемой конфигурации;
- ограничения новых функций;
- требования к PostgreSQL;
- работу расширений;
- выполнение регламентных заданий;
- права пользователей;
- критичные операции на тестовой копии базы.
Если эти механизмы войдут в итоговый релиз, они могут упростить сопровождение крупных и доработанных информационных систем. При этом пока речь идет только о предварительно заявленных возможностях. Их окончательный состав, ограничения и порядок применения могут измениться.
Компаниям, которые планируют переход на 1С:Предприятие 8.5.5, следует дождаться официального релиза, проверить совместимость используемой конфигурации и протестировать обновление на отдельной копии информационной базы.
