13 521
правка
Изменения
м
** Атрибут атрибута — в каком виде показывать список (если в коде/шаблонах не задано специального поведения).
У всех атрибутов тоже есть ссылка на контролирующую сущность, означающая, что атрибут показывается, только если его сущность ссылается на его контролирующую сущность * Файл (или одну из нихвложение).
Нет описания правки
* способ преобразования в строку
* ''Возможно, права доступа к сущности — привязка действий над сущностью (просмотр, правка, возможно, другие) к группам пользователей. Возможно, не нужно это сюда пихать.''
У каждого атрибута есть:
* Тип
* Значение по умолчанию
* Вид показа в интерфейсе
* Копируется ли значение атрибута при клонировании сущности
* Показывается ли атрибут в форме создания сущности
* Ссылка на контролирующий атрибут той же сущности, что и этот, и на его значения
*: Если выбрано, означает, что атрибут показывается, только если другой атрибут той же сущности, которой принадлежит этот, имеет одно из заданных значений
Типы атрибутов:
** {{ok}} существует в частичном виде — без выбора желаемой сущности
* Multi-Select → ссылка на несколько сущностей одного типа (то есть «многие ко многим»)
** Вариант мультиселекта — «список подчинённых» (то есть 1 ко многим). Например, список аттачментов бага, список комментов к багу.
** {{ok}} существует в частичном виде — без выбора желаемой сущности
Поля багов перечислены ниже. Жирное «да» в колонке «можно отключить» означает, что отключать можно уже сейчас (скорее всего, через параметры типа usevotes и т. п.). Нежирное «да» в колонках «можно отключить» и «можно менять тип» означают, что чисто теоретически логика работы Bugzilla это позволяет.
bug_severity | single-select | да | нет |
priority | single-select | да | да | есть желание сделать decimal
assigned_to | single-select | нет | нет | показ в виде select’а или строки, есть функция валидации (угадывания юзера по некорректному имени)ссылка на пользователя. значение по умолчанию контролируется componentreporter | single-select | нет | нет | показ в виде select’а или строки, есть функция валидации (угадывания юзера по некорректному имени)ссылка на пользователяqa_contact | single-select | '''да''' | нет | показ в виде select’а или строки, есть функция валидации (угадывания юзера по некорректному имени)ссылка на пользователя. значение по умолчанию контролируется component
votes | decimal(,0) | '''да''' | нет |
cc | multi-select | да | нет | показ в виде combo-box’а, есть функция валидации (угадывания юзера по некорректному имени)ссылка на пользователей. значение по умолчанию контролируется componentdependson | multi-select | да | нет | ссылка на баги. показ в виде спискаblocked | multi-select | да | нет | ссылка на баги. показ в виде списка
target_milestone | single-select | да | да | контролируется product, если тип = single-select
see_also | multi-select | да | да | ссылка на баги. показ в виде списка (багов), если тип = single-select
alias | строка | '''да''' | да |
reporter_accessible | boolean | нет | нет |
flags | multi-select | да | нет | 1 ко многим
</tab>
Примечания:
* Все поля-ссылки на пользователей показываются в виде строки либо в виде combo-box’а, и у них есть функция валидации — она угадывает юзеров по некорректным именам.
Устаревшие поля / поля, которые ХЗ зачем нужны в таблице полей багов:
<tab sep=bar class=simpletable head=left>
submitter | single-select, показ в виде select’а или строки, есть функция валидации (угадывания юзера по некорректному имени)
description | single-select, показ в виде select’а или строки, есть функция валидации (угадывания юзера по некорректному имени)строка
filename | строка
mimetype | строка
thedata | потенциально строка, а вообще-то обычно NULL, так как данные хранятся в локальных файлах
</tab>
Поля компонентов:
<tab sep=bar class=simpletable head=top>
поле | тип | можно отключить? | можно менять тип? | примечания
name | строка | нет | нет |
initialowner | single-select | да | нет | ссылка на пользователя
initialqacontact| single-select | да | нет | ссылка на пользователя
initialcc | multi-select | да | нет | ссылка на пользователей
default_version | single-select | да | нет | ссылка на версию
description | строка | да | да |
product_id | single-select | нет | нет |
wiki_url | строка | да | нет |
is_active | boolean | да | нет |
</tab>
Что ушло бы в ORM?
* Custom Fields, то есть, управление полями багов.
* Отключение стандартных полей типа OS, Hardware.
* Изменение типов стандартных полей типа целочисленных приоритетов.
* Добавление спецполей в продукты, компоненты и т. д. — сейчас это делается в коде.
* Версионирование всех объектов. История бы хранилась унифицированно. Не было бы отдельно таблиц bugs_activity и longdescs, соответственно не было бы и тормозов при проверке «Only bugs changed between…»
* Простые интерфейсы типа CRUD (Create/Read/Update/Delete), сейчас созданные непонятно каким копипастом. В основном имеется ввиду админка.
* Права на редактирование объектов.
* Валидаторы и подсказки значений.
* Корректная валидация зависимостей полей друг от друга.
* Часть SQL-запросов, написанных ручками в коде.
* Создание новых объектов типа SCRUM карточек.
* Мохнатая логика автоматической постановки/обновления багов из обработки входящих e-mailов и Excel-импорта
* Можно было бы прикрутить статистику по любым объектам, причём с Time Machine, то есть просмотром статистики за любой прошедший момент времени. :)
Текущая логика страницы создания бага:
* выбор classification, если она включена
* classification выбрана → выбор product, если он не вообще один
* Submit по Ctrl-Enter
[[Категория:РазработкаBugzilla]]