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

Версия 23:59, 18 марта 2012

В Bugzilla половина кода в шаблонах, половина на основе полу-ORM’а Bugzilla::Object. Большая часть — говнокод. С одной стороны — ORM бы туда, было бы классно, НО! ORM мало, и нужен не он! Почти все существующие ORM-движки (кроме разве что Django Models) — это просто объектный интерфейс к базе данных. А нужно некое объектное ядро, которое бы позволяло создавать свои объекты, с полями различных типов, в том числе и ссылающимися на другие объекты, с возможностью приписывания специальных особенностей полям, с общими механизмами хранения истории, рассылки уведомлений, системой прав и с автоматическим базовым CRUD-интерфейсом.

Идеи по созданию объектного ядра

Объекты в Bugzilla

баг
классификация, продукт, компонент
тег (ключевое слово / keyword), milestone, версия, статус бага, agreement (пример кастомного поля)
вложение, комментарий, флаг, тип флага
пользователь, группа
если таки будет ядро — ещё появляется метакласс сущности, объекты которого описывают типы сущностей

Причём, понятное дело, если баг принадлежит к некоторому продукту (через компонент), то и его версия, milestone, agreement должны принадлежать к тому же продукту. Сейчас в Bugzilla это реализуется так — для каждой сущности, связанной с багом, в баге есть «поле», а для ограничения значений полей поля делаются «зависимыми» от других полей. Из-за этого там куча костылей и, по сути, повесить зависимость на отличное от поля «продукт» поле невозможно.

Минусы текущей реализации

Чем плоха текущая багзильная реализация этого «добра»?

Значения кастом полей в таблице багов хранятся не ссылками по ID, а по именам, что создаёт геморрой для зависимых полей, так как чтобы точно идентифицировать значение, приходится брать ещё и значение поля, от которого оно зависит.
«Поле» (селект и мультиселект) совмещено с объектом, соответственно, не добавишь дополнительных атрибутов объекту.
Для выпадающих списков есть как «контроль значений», так и «контроль видимости поля», что в корне неверно! Ибо что за бред — поле скрыто, но при этом есть варианты, которые можно выбрать? Или наоборот — поле доступно, но из вариантов — только пустое значение.
По факту, ни от чего, кроме продукта, зависимым значение не сделаешь.
История хранится только для багов, но не для остальных объектов.
Код полей не генерится автоматически, а ручками вписываются в шаблоны.
На всё это навёрнута туча неструктурированного кода, определяющего поведение «встроенных» полей.

Проект супер-объектного-ядра

Что предлагается сделать:

Есть объекты. У объектов есть поля (разных типов). В том числе, есть типы «multi-select» и «single-select», ссылающиеся на другие объекты.
Зависимости полей могут прописываться дополнительно, в виде ограничений вида: «баг.компонент.продукт == баг.продукт». Могут и не прописываться. Теоретически, могут прописываться несколько ограничений на одно поле, например, чтобы какой-нибудь атрибут зависел и от продукта, и от, скажем, операционной системы. Такое устройство наиболее гибкое и в частности позволяет багу иметь несколько полей, ссылающихся на один тип объектов.
Поля могут скрываться в зависимости от значений других полей. Селект-поля скрываются, если в них по зависимостям нечего выбирать. На поля остальных типов можно вешать «настройку видимости», подобную текущей багзильной реализации — просто тупо «поле = одно из значений…».
HTML-код полей должен генерироваться автоматически. Также желательна возможность задавать группировку полей в интерфейсе — например, опционально раскрываемые «Advanced Fields» (только общим fieldset’ом, а не как сейчас — просто скрытие полей в разных местах формы).
На поля можно назначить дополнительные обработчики, задающие более хитрое поведение. Сами обработчики пишутся в коде, по возможности — максимально абстрагированно от конкретного поля. Назначаться они при этом должны не из кода, а из интерфейса конфигурации модели. На этих дополнительных обработчиках должно работать всё! Примеры:
- Платформа, ОС: функции угадывания значения по умолчанию на основе заголовков запроса.
- Статус: есть ограничения переходов из состояния в состояние (workflow). Возможно, его нужно попытаться вынести в базовые настройки модели.
- CC: специальное поведение при клонировании, смене Assignee и QA (старые добавляются в CC), специальное «значение по умолчанию», зависящее от компонента. Возможно, зависимые значения по умолчанию стоит как-то протащить в общее ядро, но это чуть более тонкий момент, чем всё остальное.
- Keywords/теги: автосоздание новых значений.
История хранится централизованно для всех объектов.
Общий механизм рассылки изменений по почте для всех объектов каким-либо образом «связанным» пользователям. Настройки уведомлений на уровнях: событие (изменено значение поля, добавлена сущность) и отношение (собственно связь).
Поиск: адаптировать сильно прокачанный движок поиска из Bugzilla4Intranet. Адаптировать долго не придётся, потому что с точки зрения read-only все типы полей останутся, по сути, те же самые.
Права доступа: Нужна опять-таки общая схема для всех объектов, с одной стороны, простая для вычисления системой, а с другой стороны, дающая достаточную гибкость разных настроек. По всей видимости, нужны с одной стороны опять-таки «связанные» пользователи, а с другой стороны — роли. Причём, пользователи могут быть «связанные» через какое-то поле — например, человек может быть связан с багом, потому что прописан как Global Watcher для продукта этого бага. Роли могут набираться из действий над полями различных объектов и права на просмотр объектов. Возможно, нужно давать возможность разграничивать доступ на просмотр к разным полям — например, в Bugzilla только группа time-tracker’ов может посмотреть информацию о рабочем времени.

Таким образом наш трекер превратится, по сути, в модульное приложение, построенное вокруг очень прокачанного автоинтерфейса полей и объектов. Естественно, это уже не Bugzilla ни разу, но зато чем-то похоже на Roundup — «конструктор трекеров». Однако и с ним различий много — roundup не умеет зависимых селект-полей, модель задаётся в коде, права доступа слабые, поиск слабый.

Модель

Получается, что ядро модели состоит из следующих таблиц:

Типы объектов
- Название типа
- Дополнительное поведение типа
Поля
- Ссылка на объект
- ID поля
- Название поля
- Тип поля
- Поле этого же объекта, контролирующее видимость данного (для не-select полей)
- Связи поля (для select-полей)
- Дополнительное поведение поля
Контроль видимости полей
- Ссылка на поле
- ID объекта, для которого оно видно
Транзакции (группы изменений)
- Момент времени
- Изменивший пользователь
История изменений
- Ссылка на транзакцию
- Тип объекта
- Ссылка на объект
- Ссылка на поле (кроме добавления объекта)
- Старое значение
- Новое значение
Один неудаляемый тип — пользователи (их поля, тем не менее, можно менять)
Связи объектов с пользователями
- ID связи
- Название связи
- Ссылка на объект
- Цепочка свойств, заканчивающаяся объектом «пользователь»
Пользовательские настройки оповещений
- Ссылка на пользователя (либо пустая для настроек по умолчанию)
- Ссылка на связь
- Тип события: добавление/удаление/изменение
- Ссылка на поле объекта (может быть пустая)
Роли (или группы, что примерно то же самое)
- Включаемые роли
- Включаемые разрешения
Разрешения (из которых состоят роли)
- Ссылка на связь
- Тип разрешения: просмотр/создание/удаление/изменение
- Ссылка на поле объекта (пустая = весь объект)
- Ссылка на значение поля (пустая = любое)

Текущее состояние

Базовые поля (то, чего не быть логически не может):

Объект, баг, пользователь, группа, комментарий к багу.
Продукт имеет специальный смысл — разграничение прав. Поэтому он тоже обязателен.

У каждого поля есть:

Тип
Значение по умолчанию
Вид показа в интерфейсе (по умолчанию?)
Копируется ли значение атрибута при клонировании
Показывается ли атрибут в форме создания
Ссылка на контролирующий атрибут того же объекта, что и этот, и на его значения
Если выбрано, означает, что атрибут показывается, только если другой атрибут той же сущности, которой принадлежит этот, имеет одно из заданных значений

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

Строка
Boolean
Десятичное число
Дата
Время
Дата+время
Файл (вложение)
Single-Select → ссылка на сущность (то есть «многие к 1»)
Multi-Select → ссылка на несколько сущностей одного типа (то есть «многие ко многим»)
- Два способа показа — поле со списком (комбобокс), или мультиселект
Список тегов, с автодобавлением значений

Существующие поля

Поля багов

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

поле	тип	можно отключить?	можно менять тип?	примечания
short_desc	строка	нет	нет
classification	single-select	да	нет
product	single-select	да	нет	контролируется classification (или никем), у поля есть привязка к правам пользователя
component	single-select	да	нет	контролируется product
version	single-select	да	да	контролируется product, если тип = single-select. значение по умолчанию контролируется component
rep_platform	single-select	да	да	специальная функция «угадывания» дефолтного значения
bug_file_loc	строка	да	да
op_sys	single-select	да	да	специальная функция «угадывания» дефолтного значения
bug_status	single-select	нет	нет	есть функция валидации (Bug Status Workflow)
resolution	single-select	да	нет	у атрибута есть контролирующая видимость сущность (показывается только при bug_status.closed=1)
status_whiteboard	строка	да	да
keywords	multi-select	да	да	показ в виде списка
bug_severity	single-select	да	нет
priority	single-select	да	да	есть желание сделать decimal
assigned_to	single-select	нет	нет	ссылка на пользователя. значение по умолчанию контролируется component
reporter	single-select	нет	нет	ссылка на пользователя
qa_contact	single-select	да	нет	ссылка на пользователя. значение по умолчанию контролируется component
votes	decimal(,0)	да	нет
cc	multi-select	да	нет	ссылка на пользователей. значение по умолчанию контролируется component
dependson	multi-select	да	нет	ссылка на баги. показ в виде списка
blocked	multi-select	да	нет	ссылка на баги. показ в виде списка
target_milestone	single-select	да	да	контролируется product, если тип = single-select
see_also	multi-select	да	да	ссылка на баги. показ в виде списка (багов), если тип = single-select
alias	строка	да	да
reporter_accessible	boolean	нет	нет
cclist_accessible	boolean	нет	нет
estimated_time	время	да	нет
remaining_time	время	да	нет
deadline	дата	да	нет
creation_ts	дата+время	нет	нет
delta_ts	дата+время	нет	нет
cf_agreement	single-select	да	да	контролируется product
* нет в fielddescs *
lastdiffed	дата+время	нет	нет	скрыто в интерфейсе
attachments	multi-select	нет	нет	1 ко многим
longdescs	multi-select	нет	нет	1 ко многим
flags	multi-select	да	нет	1 ко многим

Примечания:

Все поля-ссылки на пользователей показываются в виде строки либо в виде combo-box’а, и у них есть функция валидации — она угадывает юзеров по некорректным именам.

Логически минимальный набор полей

Совершенно точно, никогда и ни при каких условиях у бага не могут отсутствовать поля:

ID
Заголовок
История => reporter, время создания (creation_ts), время изменения (delta_ts), время оповещения по почте (lastdiffed)
Комментарии

Без этого никакой «баг» смысла не имеет ни в одном баг-трекере.

Устаревшие поля

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

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

Вычисляемые поля

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

work_time	Сумма work_time от связанных longdescs
percentage_complete	(Сумма work_time от dependson)/(Сумма estimated_time от dependson)
owner_idle_time	Текущая дата минус MAX(дата последнего коммента от Assignee, дата последней активности от Assignee)
days_elapsed	Текущая дата минус delta_ts
everconfirmed	Менялся ли статус хоть раз на != UNCONFIRMED

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

submitter	single-select, показ в виде select’а или строки, есть функция валидации (угадывания юзера по некорректному имени)
description	строка
filename	строка
mimetype	строка
ispatch	boolean
isobsolete	boolean
isprivate	boolean
isurl	boolean
thedata	потенциально строка, а вообще-то обычно NULL, так как данные хранятся в локальных файлах

Поля компонентов

поле	тип	можно отключить?	можно менять тип?	примечания
name	строка	нет	нет
initialowner	single-select	да	нет	ссылка на пользователя
initialqacontact	single-select	да	нет	ссылка на пользователя
initialcc	multi-select	да	нет	ссылка на пользователей
default_version	single-select	да	нет	ссылка на версию
description	строка	да	да
product_id	single-select	нет	нет
wiki_url	строка	да	нет
is_active	boolean	да	нет

Из чего состоит багзилла?

С внешней точки зрения

Крупные блоки функционала в Bugzilla с точки зрения пользователя:

Создание, просмотр, изменение багов, история по багу
- Форматирование комментариев
Создание, просмотр, изменение вложений
Поиск багов, форма поиска
Графики одни, графики другие, Summarize Time
Исходящая почта
Входящая почта
Запросы флагов
Напоминания (whining)
Регистрация, изменение, раздача групп пользователям
Пользовательские настройки
XML-импорт (в полудохлом виде)
Web-сервисы (XML-RPC, JSON-RPC)
Sanity Check
Графы и деревья зависимостей
Голосование за баги

Наши крупные фичи

SCRUM-карточки
RSS-лента активности
XML-Simple Web-сервисы
Проверки корректности
Excel-импорт
Информер
Глобальная авторизация
Today Worktime, Super Worktime

Плюс вагон и маленькая тележка мелочи.

Страница создания бага (enter_bug.cgi)

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

выбор 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
Submit по Ctrl-Enter

Обработчик создания бага (post_bug.cgi)

Редирект на enter_bug.cgi если форма не заполнена
Проверка, не был ли уже использован этот token для постановки другого бага?
Вывод страницы с URL-шаблоном постановки бага, если попросили
Заполнение описания по шаблону, если использовался спецвид формы (например create_guided)
Отправка куки VERSION
Начало/конец транзакции в БД
Постановка собственно бага (Bug::create)
Постановка вложения сразу при создании бага
Постановка флагов на вложение
Постановка флагов на баг
Рассылка почты по багу, по его зависимостям
Вывод сообщения о том, что баг поставлен, о том, что CC-список обрезан по группе

Обработчик изменения бага (process_bug.cgi)

Начало/конец транзакции в БД
SELECT FOR UPDATE багов
Удаление значений полей, равных dontchange (используется в групповом редактировании)
Угадывание юзеров по части логина/имени
Проверка коллизии по delta_ts, вывод только действительно изменённых полей в форму подтверждения
Проверка token формы
Загрузка следующего бага из списка ДО обновления текущего (O_O)
Проверка прав редактирования по всем багам
Установка значения продукта до всех остальных полей
Установка новых групп до остальных изменений, когда включён strict_isolation
Установка/изменение флагов
Установка зависимостей бага
Установка ключевых слов
Установка остальных полей
Установка некоторых значений только для обновлений отдельных багов (alias, cclist_accessible, reporter_accessible, isprivate на комментах)
БОльшая часть логики обновления поля CC
Вызов функции проверки strict_isolation
Перемещение багов (MOVE) — полуживое, хз как работает
И после всего этого — ещё изменения, status, resolution, dup_id
Теперь всё это ещё незакоммичено, вызов реальных обновлений из Bug.pm
Отправка почты по зависимостям, если статус поменялся с открытого на закрытый
Обрезание CC-списка по группе (наше)
Сообщение, если очищено remaining_time
Удаление голосов за баг, если переместили в другой продукт, и проверка голосо-подтвеждённости бага
Отправка почты CC, Assignee, Reporter’у, QA, старым Assignee, QA и CC
Отправка почты по багу, дубликатом которого был помечен данный
Добавление нескольких вложений (наше)
Отправка почты по флагам, через отдельный механизм сбоку
Редирект (наше) или показ следующего/того же/никакого бага
Не показывает ничего, если USAGE_MODE_EMAIL

Список/поиск багов (buglist.cgi)

SuperWorkTime (наше доработко)
Редирект на форму поиска для пустого запроса
Редирект на форму поиска с добавленными пустыми полями, если на форме поиска жмут Add/Remove поле без JS
Редирект с POST’енного запроса на GET
Быстрый поиск
Посыл на хрен, если content пуст при включённом параметре specific_search_allow_empty_words
Обратная совместимость: format=rdf -> ctype=rdf, ctype=rss -> ctype=atom
ctype=js слать в хрен
Поддержка server-push
regetlastlist — открытие последнего просмотренного списка багов (берётся из куки)
Удаление колонки relevance из списка колонок, если юзер не просит полнотекстовый поиск
В buglist.cgi почему-то тусуются функции InsertNamedQuery, LookupSeries, GetQuip, GetGroups
Генерация имени файла, если попросили список не в html-формате
Выполнение запросов поиска
Сохранение и удаление сохранённых запросов из БД
Запуск series
Если сохранённый запрос не говорил нам свой формат, решаем что advanced
Вкуривание списка колонок (длинное, тварь)
Определение порядка сортировки
Подсчёт сумм значений полей таймтрекинга
Проверка доступа к багам и установка значения в implied или manual (х.з зачем нужно)
Массовое редактирование багов, в частности сборка пересечений доступных значений полей
Кодировка CSV (наше доработко)

Система прав

Какие в Bugzilla есть права / ограничения доступа?

Права доступа к продуктам
- MANDATORY / SHOWN / DEFAULT / NA
- Entry
- Canedit
- Editcomponents
- Canconfirm
- Editbugs
Private комментарии — видны только инсайдер-группе
Информация о таймтрекинге — видна только группе, списывающей время
reporter_accessible, cclist_accessible на отдельных багах
Опциональные группы на отдельных багах
Права на правку отдельных групп
Права editclassifications, editcomponents, editfields, editkeywords, editusers

Что не так?

Что в Bugzilla не так? Что нужно поменять, чтобы она перестала быть говном?

Да, я знаю, что почти всё, но дело не в этом — дело в том, что создавать систему «от противного» — есть хороший тон, ведущий к прогрессу.

Ядро

Самое жирное «не так» в Bugzilla — это слабость ядра. Если бы ядро было прокачанным, как в начале статьи, оно бы заменило:

Custom Fields, то есть, управление полями багов.
Отключение стандартных полей типа OS, Hardware.
Добавление спецполей в продукты, компоненты и т. д. — сейчас это делается в коде.
Версионирование всех объектов. История бы хранилась унифицированно. Не было бы отдельно таблиц bugs_activity и longdescs, соответственно не было бы и тормозов при проверке «Only bugs changed between…» либо комментарии бы дублировались в bugs_activity (логичнее)
Отправка почты, которая сейчас отправляется через 2 разных места.
Простые интерфейсы типа CRUD (Create/Read/Update/Delete), сейчас созданные непонятно каким копипастом. В основном имеется ввиду админка.
Система прав стала бы и проще (по сравнению с хрен-пойми-системой Mandatory/Default/Shown/NA), и имела бы больше возможностей.
Валидаторы и подсказки значений.
Корректная валидация зависимостей полей друг от друга.
Часть SQL-запросов, написанных ручками в коде.
Вся логика постановки/обновления багов из process_bug и post_bug, дублированная сейчас в обработке входящих e-mailов и Excel-импорте
Даже Excel- и XML-импорт, причём импортировать можно было бы вообще всё что угодно.

Появились бы дополнительные возможности:

Создание новых объектов типа SCRUM карточек.
Изменение типов стандартных полей типа целочисленных приоритетов.
Можно было бы прикрутить статистику по любым объектам, причём с Time Machine, то есть просмотром статистики за любой прошедший момент времени. :)

Внешности

Большая часть интерфейсов нуждается в полной переделке. Например:
- На форме бага «Show Advanced Fields» должно быть сделано отдельной группкой полей (fieldset), а не скрытием полей прямо посреди формы в разных местах (пугает).
- Страница настройки прав продукта — мегастрёмная. Таблица с группами там на хрен не нужна никому вообще.
- Частично относится к ядру, но — интерфейс редактирования «контроля значений» кастом-полей это сейчас полная жесть — например, нельзя посмотреть список значений кастом поля для конкретного продукта (от которого зависят наборы значений).
Историю изменений бага показывать вперемешку с комментариями к багу (а-ля Trac). Туда же можно заинтегрировать и замешать коммиты из системы контроля версий.
Добавить ленту обновлений по багам, поиск «последних багов», что-то типа форум-функциональности.
Возможно, добавить Grid View с возможностью массовых обновлений в поиске.
Отрефакторить кучу действий, связанных с поиском, расположенных под списком багов.
Keywords переделать в «теги», то есть, сделать, чтобы они сами заводились новые.
~~Заменить YUI на jQuery~~ в Bugzilla4Intranet уже, форму поиска сгруппировать (но не так, как в 4.0), сделать почти все фильтры добавляемыми, добавляемыми через JS, чтобы не перезагружалась страница каждый раз
Документацию «насытить» в вики, POD-документацию по коду туда же.

Кишки, кроме ядра

Добавить глобальный объект статуса, в который сохранять почту, которую нужно отправить, и сообщения, которые сейчас руками сохраняются в сессию.
Использовать не CGI, а хеши параметров запроса, это улучшает и производительность, и переносимость, и спасает от кучи глюков, так как например, $cgi->param может вернуть как список, так и скаляр
Использовать не кучу CGI-скриптов, а несколько (мало) точек входа и классы, всю мохнатую логику перенести в них. Не использовать модуль CGI.pm вообще (!), потому что он прости господи даже без use strict написан и порождает некоторые глюки сам по себе. В крайней форме точки доступа — это один index.cgi, позволяющий работать через CGI, один server.fcgi (FastCGI), один модуль для апача, и м.б. один для HTTP::Server::Simple. Ибо по сути, интерфейс «запроса» тривиален и не требует никакого бешеного CGI.
Убрать ВСЕ строки (terms и т. п.) и описания ошибок из шаблонов и «длинного if’а», добавить отдельный уровень «локализации» / «таблицы строк», и переместить всё это в него. Потенциально также переместить туда же вообще все строки/тексты из шаблонов, для лёгкой локализации.
Обязательно оставить совместимость с PostgreSQL, но генерилка запросов не должна на это рассчитывать и должна работать оптимальнее, чем сейчас, например, в смысле дурацких подзапросов assigned_to=(select id from profiles where login_name=?) и т. п.
Желательно заменить Template::Toolkit на что-нибудь, хотя бы даже на моё поделие VMX::Template, чтобы не общаться с этим тормозом. Но как МИНИМУМ, даже если не заменять — убрать ВСЮ обратную связь с БД из шаблонов, ибо именно она убивает производительность в первую очередь! Ну ладно, не в первую, а во вторую, после дурацкого движка поиска. Хотя это и будет уже не MVC, а MVP :)

@@ Строка 102: / Строка 102: @@
 ** Ссылка на поле объекта (может быть пустая)
 * Роли (или группы, что примерно то же самое)
+** Включаемые роли
+** Включаемые разрешения
 * Разрешения (из которых состоят роли)
+** Ссылка на связь
+** Тип разрешения: просмотр/создание/удаление/изменение
+** Ссылка на поле объекта (пустая = весь объект)
+** Ссылка на значение поля (пустая = любое)
 == Текущее состояние ==