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

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

Важно

The LaunchPad bug tracker automatically proposes bugs that look similar to your bug title when you attempt to report a new one. This is important to avoid reporting several times the same bug. Be careful to double-check the proposed bugs, so you avoid creating duplicates. However do not forget to proceed further should none of the existing bugs match yours.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Bug Management Process

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

  • Invalid: the bug cannot be reproduced at all or is incorrect, for example because the poster has misunderstood OpenERP's features or is misusing the system. Bugs in this state are considered closed. Note: If this looks like it could become a Frequently Asked Question, don't hesitate to Convert to a question before answering (link is on top-right of bug page). This will mark the bug Invalid automatically, and then you can provide the answer on the linked Question. (Note: converting to a question sometimes fails at the moment due to a Launchpad bug)

  • Won't Fix: bugs or wishlists that we can't or don't want to fix/implement them. Bugs in this state are considered closed.

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

  • Fix Released: if you know the bug was valid bug has been fixed since it was reported, it may of course be marked directly as such (you may also set the appropriate mileston if you know it)

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

Assessing the importance of a bug is a difficult and often subjective task. In order to have common criterions, we propose the following definition for the severity levels on Launchpad bugs

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

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

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

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

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

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

Чтобы в действительности исправляться, ошибки должны быть назначены команде 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

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

  • via Launchpad (no guaranteed response time)

  • via the Publisher's Warranty channel for Customers (guaranteed response time according to the contract)

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

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

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

As of november 2010, OpenERP has started to enforce a stricter policy, which means that you may be surprised to see that more Launchpad bugs are closed with status Invalid or Won't Fix. The goal being pursued is to really improve the stability of the stable versions.

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

  • The main trouble with past stable versions was that developers did too much changes on the stable branch and introduced regressions (because the Support/Maintenance team was fixing a maximum of requests on stable branch reported by the community). This was too risky for a stable version.

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

  • Most of these requests (evaluated to 65% of bugs according to a recent bug qualification sprint) were feature improvements, not bugs.

  • The distinction was not clear between bugs fixed through the Publisher's Warranty contract with a guaranteed response time, and those fixed for free on Launchpad. The Support team did its best to fix both.

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

  • The OpenERP Launchpad team is dedicated to processing all bugs reported via Launchpad, qualifying them as quickly as possible, and getting them solved by the R&D teams. They must not touch the stable branches directly, and any important issue reported on a stable branch will be passed on to the OpenERP Publisher's Warranty team.

  • The OpenERP Publisher's Warranty team is in charge of receiving issues reported directly by customers via the OpenERP Publisher's Warranty, providing high-level expertise within short response times, including workarounds and patches when available. They carefully select the fixes to apply to the stable branches, to be published every month.

This way the responsabilities of the teams are clear, and we can appropriately implement continuous improvement, with distinct goals!

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

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 Publisher's Warranty contract so any bug they report via their dedicated Support/Maintenance channel will be handled accordingly.

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

It is the responsibility of OpenERP Publisher's Warranty team to maintain the maximum stability of the stable branches, and this implies being very strict on what can be considered important enough to be worth the application of a patch on a stable branch.

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

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 легко расширяется и настраивается под заказчика, так что вы можете реализовывать свои потребности с помощью модулей. И если они качественно созданы и востребованны — мы включим их в перечень официальных дополнений)