УТ 11.4.5.* рассчитана на работу с 8.3.10
Открываем в 8.3.12
Отключаем режим совместимости
Получаем проблему с невозможностью ввести адрес.
Добавляем расширение с расширением данных
Получаем проблему с невозможностью выполнить обновление на новые версии конфигурации.
Вы правильно сделали выбрав механизм расширений, но поймите, изменение режима совместимости — это изменение в основной конфигурации, которое не только сисадмину делать нельзя, любой понимающий что делает разработчик откажется его менять.
Профессионально поступить: это сказать, что ваше расширение требует режима совместимости не меньше 8.3.11, УТ с этим режимом ожидания в октябре.
Версия УТ 11.4.6, которая сейчас заявлена следующей, в списке проектов в анонсе было обновление БСП до версии 3.0.1, которое работает в режиме 8.3.12 с отключенным режимом совместимости. Чтобы использовать возможности платформы по максимуму надо дождаться выпуска 11.4.6.
Бухгалтерия, кстати, уже публичную бета выложила 3.0.65, в которой обновила БСП до 3.0.1 и перешла на 8.3.12. Наверное на неделе выпустятся.
Режим совместимости конфигурации в значение Не использовать будет в разных версиях конфигурации разный. Поставьте режим Не использовать в конфигураторе версии 8.3.10, а потом откройте эту же конфигурацию в конфигураторе версии 8.3.11. Что Вы увидите? Режим совместимости, который Вы поставили в Не использовать вдруг стал режимом совместимости 8.3.10.
А еще можно сделать выгрузку конфигурации в xml из версии 8.3.10 с включенным режимом Не использовать и посмотреть ноду в файле описания конфигурации, что будет в файле? Режим совместимости 8.3.10.
Это дурацкая неоднозначность платформы, которая многими не правильно понимается. Не использовать, это значи режим той версии, который сейчас запущен.
Вот сейчас платформа выпустила бета-версию 8.3.13, смотрите апдейт: http://downloads.v8.1c.ru/content//Platform/8_3_13_1472/1cv8upd_8_3_13_1472.htm
Особенно внимательно на фрагмент Изменения, влияющие на поведение системы. Если эти изменения платформы не отработать в типовой конфигурации, то она будет работать не ожидаемо. А отработаны они будут только тогда, когда будет выпущена официальная версия от 1С.
Что сделали Вы: у работающей и протестированной в определенном режиме работы интерпретатора конфигурации сменили версию интерпретатора, не доработав при этом конфигурацию. Это значит что конфигурация может вообще в произвольном месте развалиться, потому что авторы кода этой конфигурации ее тестировали в одном режиме работы, а Вы запускаете в другом.
Конкретно с Вашими доработками ничего страшного не случится, ведь Вы их, надеюсь, отладили в новом режиме, а весь остальной типовой код? У вас нет возможности перезапустить все тесты по всем подсистемам и гарантировать, что все работает точно так же. А если бы была возможность, Вы бы ужаснулись количиству проблем.
Например, появился в платформе нативный метод ПобитовоеИ и ПобитовоеИли, который отдельно был реализован в контактной информации БСП. При запуске в режиме совместимости 8.3.10 платформа все новшества отключает, а при снятии — отваливаются все формы на которые выведена контактная информация, потому что идет конфликт имен методов глобального контекста. И это только самый простой пример, коих тысячи.
Апресов Игорь (1С, Москва): Мы никогда не меняем режим совместимости просто так — это большой техпроект в котором анализируются изменения, дорабатывается конфигурация, пишется методика по переходу.
Я могу Вам посоветовать подождать выхода УТ на версии платформы 8.3.12, но уж точно предлагать пользователям ломать их информационные базы не следует.
Все можно заменить :)
СППР — Jira — Redmine — GitLab Issue
GitConverter можно вообще не использовать если разрабатываешь в формате EDT
Сценарное тестирование — Ванесса — xUnit
Тест-центр — Zabbix
Центр администрирования — Gitlab CI — Jenkins — Ansible — Kubernetes (все завсит от того любишь ты больше оркестрацию или развертку)
SonatQube — АПК
Так же в списке нет — отдельно юнит-тесты пишут с расширениями в роли моков.
А еще есть механики, которые проверить можно только SikuliX, например нажатие на кнопочку загрузки файла в веб-клиенте.
Плюс под все окружение нужны обертки снимающие журнал регистрации, технологический журнал и дампы в случае падения или зависания.
Сонар не содержит в себе всех проверок, а только расширяет базовые проверки.
Например для проверки python сонар использует выгрузку результата проверки pylint.
Окошко действительно красивое. Если платформа запущена под отладкой — то доступен стек и пепеход к дизайнеру, но если запущена в штатном режиме, то это окно как обычное предупреждение.
Если ничего не нужно делать в блоке исключений (как с отменой транзакции) то и попытка не нужна. Гасить исключения бесследно — плохой тон. Есть очень редкие случаи, когда исключение не приводит к проблемам и можно его заменить на запись в журнал регистрации типом предупреждение, но в общем исключение должно быть выброшено пользователю и при этом платформа сама его запишет в журнал как ошибку.
Не понимаю чем Сообщить лучше ВызватьИсключение.
Обработка вызова исключения корректно дойдет до пользователя и покажет ошибку.
Обрабатывать дополнительно ошибку отмены транзакции не нужно.
Имеет смысл код обработки ошибки отмены транзакции только в случае, когда результат кода должен дойти куда-нубудь вне инетрефейса 1С, например возвратов веб-сервиса или http-сервиса.
Но даже там проще обернуть в попытку исключение вызов бизнес-логики чтобы корректно сформировать код возврата вне зависимости от того ошибка это базы или бизнес-логики, потому что конечно потребителю это собственно все равно, ему главное получить код статуса ошибки.
sonarQube афигенен, жаль только что требуется лицензия на фичу открывающую проверку по нескольким бранчам, когда много версий на поддержке и когда хочешь тестировать до принятия мердж-реквета — это важно.
Понятное дело, но тут тоже можно поспорить :)
Есть база данных угроз ФСТЭКА, там есть замечательная угроза УБИ.165 https://bdu.fstec.ru/threat/ubi.165
Угроза включения в проект не достоверно испытанных компонентов
Переиспользование кода без испытаний влечет к понижению безопасности проекта, потому в любом случае надо делать аудит кода, и тогда уже принимать решение "байскаутить" или же пилить адаптер безопасного вызова.
Не идеальны. Но они проверены специалистами разных групп и разработчиками платформы и согласованы между собой.
Все ошибки и пожелания к стандартам рассматриваются и исправляются в рамках партнерской конференции БСП (https://partners.v8.1c.ru/forum/forum/186/topics).
Сколько раз видел, как методы БСП оборачивают в try-catch, не смотря на то, что эти методы были спроектированы так, чтобы никогда не выбрасывать исключений...
УТ 11.4.5.* рассчитана на работу с 8.3.10
Открываем в 8.3.12
Отключаем режим совместимости
Получаем проблему с невозможностью ввести адрес.
Добавляем расширение с расширением данных
Получаем проблему с невозможностью выполнить обновление на новые версии конфигурации.
Вы правильно сделали выбрав механизм расширений, но поймите, изменение режима совместимости — это изменение в основной конфигурации, которое не только сисадмину делать нельзя, любой понимающий что делает разработчик откажется его менять.
Профессионально поступить: это сказать, что ваше расширение требует режима совместимости не меньше 8.3.11, УТ с этим режимом ожидания в октябре.
Например так написал автор Gitter'а, который сделал расширение для СППР с расширением данных:
https://github.com/JohnyDeath/GitterExtForSPPR
Версия УТ 11.4.6, которая сейчас заявлена следующей, в списке проектов в анонсе было обновление БСП до версии 3.0.1, которое работает в режиме 8.3.12 с отключенным режимом совместимости. Чтобы использовать возможности платформы по максимуму надо дождаться выпуска 11.4.6.
Бухгалтерия, кстати, уже публичную бета выложила 3.0.65, в которой обновила БСП до 3.0.1 и перешла на 8.3.12. Наверное на неделе выпустятся.
Режим совместимости конфигурации в значение Не использовать будет в разных версиях конфигурации разный. Поставьте режим Не использовать в конфигураторе версии 8.3.10, а потом откройте эту же конфигурацию в конфигураторе версии 8.3.11. Что Вы увидите? Режим совместимости, который Вы поставили в Не использовать вдруг стал режимом совместимости 8.3.10.
А еще можно сделать выгрузку конфигурации в xml из версии 8.3.10 с включенным режимом Не использовать и посмотреть ноду в файле описания конфигурации, что будет в файле? Режим совместимости 8.3.10.
Это дурацкая неоднозначность платформы, которая многими не правильно понимается. Не использовать, это значи режим той версии, который сейчас запущен.
Вот сейчас платформа выпустила бета-версию 8.3.13, смотрите апдейт:
http://downloads.v8.1c.ru/content//Platform/8_3_13_1472/1cv8upd_8_3_13_1472.htm
Особенно внимательно на фрагмент Изменения, влияющие на поведение системы. Если эти изменения платформы не отработать в типовой конфигурации, то она будет работать не ожидаемо. А отработаны они будут только тогда, когда будет выпущена официальная версия от 1С.
Режим совместимости был задолго до появления расширений. Кстати, у расширений режим совместимости свой, в добавку к режиму совместимости конфигураций.
В режиме совместимости платформа меняет свое поведение. Смотрите документацию здесь
https://its.1c.ru/db/v8313doc#bookmark:dev:TI000001242: особенность%20режима%20совместимости
Каждую конфигурацию при смене режима требуется дорабатывать, смотрите методику отказа от режима совместимости:
https://its.1c.ru/db/metod8dev#content:5293:hdoc:_top: методика%20по%20переходу%208.2%20без%20режима
Что сделали Вы: у работающей и протестированной в определенном режиме работы интерпретатора конфигурации сменили версию интерпретатора, не доработав при этом конфигурацию. Это значит что конфигурация может вообще в произвольном месте развалиться, потому что авторы кода этой конфигурации ее тестировали в одном режиме работы, а Вы запускаете в другом.
Конкретно с Вашими доработками ничего страшного не случится, ведь Вы их, надеюсь, отладили в новом режиме, а весь остальной типовой код? У вас нет возможности перезапустить все тесты по всем подсистемам и гарантировать, что все работает точно так же. А если бы была возможность, Вы бы ужаснулись количиству проблем.
Например, появился в платформе нативный метод ПобитовоеИ и ПобитовоеИли, который отдельно был реализован в контактной информации БСП. При запуске в режиме совместимости 8.3.10 платформа все новшества отключает, а при снятии — отваливаются все формы на которые выведена контактная информация, потому что идет конфликт имен методов глобального контекста. И это только самый простой пример, коих тысячи.
Кажется такие фееричные идеи уже обсуждались на партнерском форуме в ветке БСП:
https://partners.v8.1c.ru/forum/t/1747505/m/1747619
Цитирую:
Я могу Вам посоветовать подождать выхода УТ на версии платформы 8.3.12, но уж точно предлагать пользователям ломать их информационные базы не следует.
Все можно заменить :)
СППР — Jira — Redmine — GitLab Issue
GitConverter можно вообще не использовать если разрабатываешь в формате EDT
Сценарное тестирование — Ванесса — xUnit
Тест-центр — Zabbix
Центр администрирования — Gitlab CI — Jenkins — Ansible — Kubernetes (все завсит от того любишь ты больше оркестрацию или развертку)
SonatQube — АПК
Так же в списке нет — отдельно юнит-тесты пишут с расширениями в роли моков.
А еще есть механики, которые проверить можно только SikuliX, например нажатие на кнопочку загрузки файла в веб-клиенте.
Плюс под все окружение нужны обертки снимающие журнал регистрации, технологический журнал и дампы в случае падения или зависания.
nlruslan alexey-lustin
На конкурс пойдет?
http://konkurs.1c.ru/diplom/
Как по тексту так и по комментариям, замечание всем:
Методология — это наука о методиках.
говорите правильно: Методика
Сонар не содержит в себе всех проверок, а только расширяет базовые проверки.
Например для проверки python сонар использует выгрузку результата проверки pylint.
Я не об этом. Я о том, что в зависимости от того разрешена ли отладка в текущем сеансе окно меняется.
Обработка:
Если включена:
Если отключена:
Окошко действительно красивое. Если платформа запущена под отладкой — то доступен стек и пепеход к дизайнеру, но если запущена в штатном режиме, то это окно как обычное предупреждение.
Если ничего не нужно делать в блоке исключений (как с отменой транзакции) то и попытка не нужна. Гасить исключения бесследно — плохой тон. Есть очень редкие случаи, когда исключение не приводит к проблемам и можно его заменить на запись в журнал регистрации типом предупреждение, но в общем исключение должно быть выброшено пользователю и при этом платформа сама его запишет в журнал как ошибку.
Не понимаю чем Сообщить лучше ВызватьИсключение.
Обработка вызова исключения корректно дойдет до пользователя и покажет ошибку.
Обрабатывать дополнительно ошибку отмены транзакции не нужно.
Имеет смысл код обработки ошибки отмены транзакции только в случае, когда результат кода должен дойти куда-нубудь вне инетрефейса 1С, например возвратов веб-сервиса или http-сервиса.
Но даже там проще обернуть в попытку исключение вызов бизнес-логики чтобы корректно сформировать код возврата вне зависимости от того ошибка это базы или бизнес-логики, потому что конечно потребителю это собственно все равно, ему главное получить код статуса ошибки.
Появилась Community версия для бранч плагина? 0_о
sonarQube афигенен, жаль только что требуется лицензия на фичу открывающую проверку по нескольким бранчам, когда много версий на поддержке и когда хочешь тестировать до принятия мердж-реквета — это важно.
Понятное дело, но тут тоже можно поспорить :)
Есть база данных угроз ФСТЭКА, там есть замечательная угроза УБИ.165
https://bdu.fstec.ru/threat/ubi.165
Угроза включения в проект не достоверно испытанных компонентов
Переиспользование кода без испытаний влечет к понижению безопасности проекта, потому в любом случае надо делать аудит кода, и тогда уже принимать решение "байскаутить" или же пилить адаптер безопасного вызова.
Не идеальны. Но они проверены специалистами разных групп и разработчиками платформы и согласованы между собой.
Все ошибки и пожелания к стандартам рассматриваются и исправляются в рамках партнерской конференции БСП (https://partners.v8.1c.ru/forum/forum/186/topics).
Мой перфекционизм требует приводить к стандарту вызываемый код. :)
Что верно то верно.
Но работаем с тем, что имеем.
Сколько раз видел, как методы БСП оборачивают в try-catch, не смотря на то, что эти методы были спроектированы так, чтобы никогда не выбрасывать исключений...
Как с этим бороться? Пока ответа нет.