BugzillaORM — различия между версиями

Версия 18:37, 4 августа 2010

В Bugzilla (например, 3.6) половина кода в шаблонах, половина на основе полу-ORM’а, а большая часть не пойми как. А ORM бы туда, было бы классно, что-то в духе:

Есть сущности:

• баг
• классификация, продукт, компонент
• ключевое слово, milestone, версия, статус бага, agreement (кастомное поле!)
• вложение, комментарий, флаг, тип флага
• пользователь, группа
• как ни странно, «сущность» — «метакласс» (класс сущности)

У сущностей есть:

• ID — первичный ключ
• атрибуты
• ссылка на контролирующую сущность (тип + ID)
  то есть если другая сущность ссылается на эту, другим полем она должна ссылаться и на контролирующую
• способ преобразования в строку
• Возможно, права доступа к сущности — привязка действий над сущностью (просмотр, правка, возможно, другие) к группам пользователей. Возможно, не нужно это сюда пихать.

Типы атрибутов:

• Строка
• Boolean
• Decimal
• Дата
• Время
• Дата+время
• Single-Select → ссылка на сущность (то есть «многие к 1»)
  • Необязательный вариант синглселекта — «1 к 1».
  • существует в частичном виде — без выбора желаемой сущности
• Multi-Select → ссылка на несколько сущностей одного типа (то есть «многие ко многим»)
  • Атрибут атрибута — в каком виде показывать список (если в коде/шаблонах не задано специального поведения).
  • Вариант мультиселекта — «список подчинённых» (то есть 1 ко многим). Например, список аттачментов бага, список комментов к багу.
  • существует в частичном виде — без выбора желаемой сущности

У всех атрибутов тоже есть ссылка на контролирующую сущность, означающая, что атрибут показывается, только если его сущность ссылается на его контролирующую сущность (или одну из них).

Поля багов перечислены ниже. Жирное «да» в колонке «можно отключить» означает, что отключать можно уже сейчас (скорее всего, через параметры типа usevotes и т. п.). Нежирное «да» в колонках «можно отключить» и «можно менять тип» означают, что чисто теоретически логика работы Bugzilla это позволяет.

Устаревшие поля / поля, которые ХЗ зачем нужны в таблице полей багов:

• assignee_accessible
• qacontact_accessible
• longdesc
• commenter
• longdescs.isprivate
• content
• bug_group
• flagtypes.name
• requestees.login_name
• setters.login_name

Вычисляемые поля багов:

Поля вложений:

Текущая логика страницы создания бага:

• выбор classification, если она включена
• classification выбрана → выбор product, если он не вообще один
• тот же выбор продукта/классификации при клонировании багов
• продукт выбран → форма создания бага
• показ корректных списков возможных значений полей:
  • типы флагов в зависимости от компонента
  • cf_agreement в зависимости от продукта
  • списки пользователей, относящихся к багу в combo-box’ы
  • опциональный запрет на ввод приоритета на основе конфигурации (letsubmitterchoosepriority)
  • список флажков — ограничителей доступа группами
• значения полей по умолчанию:
  • которые совсем по умолчанию
  • угадывание op_sys и rep_platform на основе заголовков запроса
  • версия, qa_contact, assigned_to, cc по умолчанию для компонента
  • хитрая логика для изменения списков cc при выборе компонентов
  • assigned_to=ты при выборе статуса ASSIGNED
  • показ поля resolution при выборе закрытого статуса
  • версия из cookies
  • загруженные из шаблона ввода бага
  • загруженные из клонированного бага
    • ссылка на старый аттач в описании нового клонированного бага
    • хитрая логика для CC при клонировании багов
• напоминания о вводе времени
• предпросмотр комментариев
• постановка вложения сразу при создании бага
• переключатель Show Expert Fields