This is the documentation for older versions of Odoo (formerly OpenERP).

See the new Odoo user documentation.

See the new Odoo technical documentation.

Отчёты об ошибках и работа с ними

Отслеживание ошибок

Как описано в разделе Launchpad, основа сообщества, OpenERP использует Launchpad в качестве системы отслеживания ошибок.

Каждый может сообщать о новых ошибках или предоставить отклик на уже существующие в системе отслеживания ошибок Launchpad. Единственное требование — завести учётную запись на Launchpad и присоединиться к команде Сообщество OpenERP, для чего требуется лишь несколько щелчков мыши.

Примечание

Членство в дополнительных группах может потребоваться для выполнения отдельных заданий, что поясняется далее в разделе Обработка ошибок.

Любая замеченная неисправность или проблема, замеченная в OpenERP, должна быть описана в соответствующем проекте на Launchpad. Ссылка на создание нового отчёта об ошибке может быть обнаружена в верхней правой части страницы проекта на Launchpad. Вот краткий перечень прямых ссылок на создание отчётов об ошибках в каждом из проектов OpenERP.

Проект

Интерфейс отчётов об ошибках

OpenERP Addons

http://bugs.launchpad.net/openobject-addons

OpenERP Server

http://bugs.launchpad.net/openobject-server

OpenERP GTK Client

http://bugs.launchpad.net/openobject-client

OpenERP Web Client (6.0)

http://bugs.launchpad.net/openobject-client-web

OpenERP Web (6.1)

http://bugs.launchpad.net/openerp-web

Важно

Система отслеживания ошибок Launchpad автоматически предлагает ошибки, похожие на вашу заголовком, когда вы пытаетесь создать новый отчёт. Это важно и позволяет избежать создания нескольких отчётов об одной и той же ошибке. Будьте осторожны и дважды проверьте предлагаемые ошибки, чтобы избежать дублирования. Однако не забудьте продолжить, если ни одна из ошибок не совпала с вашей.

Определение ошибки

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

Ошибкой обычно считается:

  • Любая системная ошибка с полным остановом или возникновением трассировки

  • Любое ненормальное поведение системы, следующее из ошибки в коде OpenERP, без изменения оригинального функционала или спецификаций

  • Любая брешь в безопасности в коде программы

  • Несоответствие закону для любой существующей функции в сертифицированном модуле бухгалтерского учёта

Обычно не считается ошибкой:

  • Несовместимость со специфичными требованиями заказчика

  • Ненормальное поведение системы из-за неверной установки или настройки

  • Брешь в безопасности, последовавшая за неверной установкой или настройкой

  • Любое использование программы, которое не будет совместимо с некоторыми страндартами отрасли

Всё остальное — или относится к пожеланиям или должно быть оформлено в виде спецификации на изменение/улучшение.

Обработка ошибок

Следующий рисунок отражает общий процесс исправления ошибок, используемый в OpenERP, в частности над ветвью trunk, также известной как версия для разработчиков (смотрите также раздел Политика управления ошибками)

Bug Management Process

Обработка ошибок разделена на несколько основных этапов:

  1. Входящие отчёты об ошибках поступают Launchpad, наприсанные всем сообществом OpenERP

  2. Исследование новых ошибок производится выделенной командой внутри OpenERP SA, сопровождаемая Командой руководителей, группой опытных участников сообщества.

  3. Исправление ошибки по-настоящему осуществляется одной из команд иследования OpenERP, если только на этапе Исследования не случилось исправить ошибку напрямую, например, благодаря заплатке, поступившей одновременно с отчётом об ошибке.

  4. Последний этап перед выпуском исправления ошибки в официальной ветви — функциональный и технический анализ и рецензирование исправления Лидером команды и/или Командой качества.

Исследование ошибок

Чтобы правильно квалифицировать каждую ошибку, должны быть установлены следующие аттрибуты:

  • ветвь(-и), в которых он проявляется должны быть указаны верно

  • повторяемость ошибки должна быть проверена, также как и возможное дублирование (если это дубликат — пометьте его таковым и прекратите обработку)

  • состояние должно быть установлено верно, согласно пояснениям из следующего раздела

  • важность должна быть установлена верно, согласно пояснениям из следующего раздела

  • если ошибка действительна и должна быть исправлена (сейчас или в будущем), она должна быть назначена соответствующей Команде R&D

  • если ошибка ещё не исправлена, этап должен быть не установлен, если только этого не сделала соответствующая команда R&D, чтобы обозначить сроки выхода исправления

Оставлять ошибки в статусах Новая или Подтверждённая, не назначая команду R&D — это неправильно.

Состояние изученной ошибки

Во время изучения ошибки, ей должно быть назначено одно из следующих состояний:

  • Подтверждена: это означает, что ошибка воспроизводится, считается действительной и была принята. Ошибки в этом состоянии считаются открытыми. Также может быть установлен для Пожеланий, которые мы планируем реализовать в будущем.

  • Неполная: описание ошибки не содержит достаточного количества информации чтобы должным образом с ней поступить, что мешает её воспроизвести (например, не указана версия, не описан путь воспроизведения или упущена другая важная информация). Помните, что ошибки в этом состоянии могут быть обновлены путём дополнения их ответом. (На Launchpad они могут быть найдены по фильтру Неполная с ответом или Неполная без ответа). Поскольку мы используем авто-устаревание ошибок, такие ошибки будут помечены как Устарела автоматически через 60 дней неактивности и отсутствия ответов. Ошибки в этом состоянии считаются открытыми, пока не помечены как устаревшие.

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

  • Не будет исправлена: ошибки или пожелания, которые мы не можем или не хотим исправлять/ реализовывать. Ошибки в этом состоянии считаются закрытыми.

  • Изучена: это состояние означает, что изучавший ошибку до сих пор не уверен, должна она быть подтверждена или отклонена. Установите это состояние и назначьте команду, чтобы сообщить её лидеру о необходимости принятия/отклонения ошибки до начала работы над ней. Ошибки в этом состоянии считаются открытыми.

  • Выпущено исправление: если вам известно, что эта ошибка, будучи верной, была исправлена, ей может быть сразу назначено такое состояние. Также можно указать этап, на котором она была исправлена, если он вам известен.

Важность изученной ошибки

Назначение важности ошибке — трудная и зачастую субъективная задача. Чтобы иметь общие критерии оценки, мы предлагаем следующее определение уровней важности ошибок на Launchpad

  • Критический: проблема безопасности (т.е. система скомпрометирована, или возможно выполнение стороннего кода), или система неработоспособна для большинства пользователей. Любой вид повреждения данных.

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

  • Средний: меньшая часть приложения работает неправильно (работа не блокируется), или важная функция не работает у некоторых пользователей, возможно в конкретной конфигурации.

  • Низкий: оставшиеся ошибки, в основном связанные с удобством использования (т.е. ошибки отображения/поведения), которые не мешают использованию никакой из функций.

  • Пожелание: хорошо бы реализовать функционал/заплатку. Предложения улучшить/ изменить текущую логику приложения.

Назначение изученных ошибок

Чтобы в действительности исправляться, ошибки должны быть назначены команде R&D, ответственной за эту часть OpenERP. Каждая команда назначает этапы, чтобы показать, когда они планируют выпустить исправление ошибки для каждой из ошибок. Основные команды R&D и их зоны ответственности в настоящий момент таковы:

  • Addons Team 1 отвечает за модули CRM, Project, Plugins, Knowledge, Tools

  • Addons Team 2 отвечает за модули MRP, Stock, Purchase, Procurement, Marketing

  • Addons Team 3 отвечает за модули Account, Sales, Point of sale, Association, HR

  • Framework Team отвечает за Сервер/Рабочую среду

  • GTK Team отвечает за GTK-клиент

  • Web Team отвечает за веб-интерфейс

Назначение этапа

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

Политика управления ошибками

OpenERP Bug Policy

Официальная политика OpenERP в области ошибок зависит от версии или ветви, в которой проявляется ошибка. Ошибки, найденные в ветвях trunk или development обрабатываются согласно описанию в разделе Обработка ошибок. Ошибки, найденные в ветви stable исследуются более строго, чтобы снизить риски регрессии в запущенных в производство экземплярах.

trunk

Все ошибки и пожелания должны быть указаны на Launchpad, и будут рассмотрены соответствующей командой OpenERP. Правильно оформленные ошибки будут подтверждены и их исправление будет запланировано в соответствии с их важностью. Пожелания будут приняты в зависимости от стратегии отдела R&D и запланированы в списке задач R&D на усмотрение команды.

stable

Ошибки в стабильных выпусках могут быть поданы:

  • через Launchpad (без гарантированного времени на ответ)

  • по каналу Гарантии издателя клиентам (гарантированное время ответа согласно договору)

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

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

Обоснование политики в области ошибок

Начиная с ноября 2010, OpenERP стала ужесточать политику, что означает, что вас может удивить количество ошибок, закрытых со статусом Invalid или Won't Fix. Цель этого — увеличить стабильность стабильной версии.

Раньше разработчикам приходилось работать над всеми представленными на Launchpad ошибками, несмотря на выпуски OpenERP, которых касались ошибки и без чёткого понимания того, что является ошибкой, а что — нет. Несколько лет работы такого рода показали нам, что это не эффективно, поскольку приводит к длительному времени обработки некоторых ошибок и слишком часто влечёт за собой регрессию в стабильной ветви:

  • Основной проблемой с последними стабильными версиями было то, что разработчики вносили в них слишком много изменений, что приводило к регрессиям (в силу того, что команда поддержки и обслуживания старалась обслужить максимальное число запросов по стабильной ветви, поданных сообществом). Это было слишком рискованно для стабильной версии.

  • Лишь некоторое количество изменений действительно касалось заказчиков; изменения в стабильнойветви, используемой заказчиками — всегда риск. И этот риск надо уменьшать.

  • Большая часть этих запросов (приближающаяся к 65% ошибок, судя по последнему этапу исследования ошибок) была на самом деле запросами на улучшение, а не ошибками.

  • Не было ясной границы между ошибками, исправляемыми по договору Гарантии издателя с конечным временем реакции и ошибками, исправляемыми бесплатно на Launchpad. Команда поддержки делала всё возможное, чтобы исправлять и то и другое.

Чтобы исправить ситуацию, OpenERP разделила команды, ответственные за исправление ошибок и соответствующие процессы, разделив тем самым управление отчётами об ошибках общего назначения, поступающими от сообщества (улучшение продукта в будущем) и управление каждодневными проблемами, обнаруживаемыми в системах, работающих в производстве, гарантируя стабильность в самом консервативном её понимании:

  • Команда OpenERP Launchpad team выделена для обработки ошибок, поданных через Launchpad, и занимается их исследованием так быстро, как только возможно. Исправлением занимаются команды R&D. Они не касаются стабильных ветвей напрямую, и все важные проблемы, влияющие на стабильную ветвь, передаются Команде OPW.

  • Команда OPW отвечает за получение отчётов об ошибках, отправленных заказчиками напрямую по договору о Гарантии издателя, и предоставляет высокоуровневую поддержку предприятий с конечным временем реакции, включая "костыли" и исправления по мере доступности. Они тщательно отбирают исправления, которые будут включены в стабильную ветвь и опубликованы по итогам месяца.

Таким образом, зоны ответственности команд указаны чётко и мы можем соответствующим образом реализовать продолжающееся улучшение продукта, имея конечные цели!

ЧаВо по управлению ошибками

1. What is the policy regarding bugs encountered by users of the OpenERP Online Offer?

Customers of OpenERP's Online Offer are automatically subscribed to an OpenERP Enterprise contract so any bug they report via their dedicated Support/Maintenance channel will be handled accordingly.

2. My Launchpad bug report was refused for the stable release I reported! How can I get it fixed for my important projects/customers?

Поддержание стабильности в стабильных ветвях — задача команды OPW. И это требует особой строгости во всём, что касается исправления достаточно серьёзных ошибок в стабильной ветви.

Заметьте, что если ошибка влияет и на trunk-версию, вы можете попытаться просто совершить обратное портирование исправления, которое будет сделано для trunk-версии. Остальные участники сообщества могут предоставить исправления для стабильной ветви даже если ошибка была отклонена.

3. My Launchpad bug report/feature request was closed as Invalid or Won't Fix, but I can prove that it really is valid! How can I get it fixed/implemented for my important projects/customers?

Такое могло произойти не обязательно по ошибке. OpenERP не может покрыть все возможные варианты использования системы и не хочет этого делать. Основная идея в том, чтобы поддерживать самые важные и общие функции и избегать путей развития когда система будет слишком сложной. Однако OpenERP легко расширяется и настраивается под заказчика, так что вы можете реализовывать свои потребности с помощью модулей. И если они качественно созданы и востребованны — мы включим их в перечень официальных дополнений)

4. What's the matter with OpenERP Web Client bugs being all closed as Won't Fix?

As you certainly noticed, bugs reported against the 6.0 web client series had not been receiving a lot of attention lately on Launchpad.

The reason is that the OpenERP Web Client from the 6.0 series will not be developed further in the future, as it was becoming too hard to maintain, due to its aging architecture. For the 6.1 series, a new web frontend is under development, rewritten from scratch with a clean (HTML5/Javascript) state-of-the-art architecture. This will make future improvements and maintenance much easier.

The OpenERP Bug Management Policy explains that R&D developers solve bugs reported on Launchpad in the trunk development branch, in order to improve the product for the future, for everyone. As this project will no longer be used in 6.1, these R&D efforts would now be wasted.

Concerning the correction of bugs in the stable series, this is the responsibility of the OpenERP Enterprise (OPW) maintenance team, for all the reasons explained above, and they will of course continue to do it as long as the 6.0 LTS series is supported.

The R&D Web Team can therefore dedicate all its efforts to finishing the new OpenERP 6.1 client, and making it very robust, stable, easy to improve and maintain.