13 521
правка
Изменения
м
На самом деле, выше описан почти что [http://roundup.sourceforge.net/ Roundup], за теми исключениями, что он не умеет зависимые селекты (раз) и :)
Связь «многие ко многим» багов с ключевыми словами можно разбить на две «один ко многим» (тег → тег бага ← баг).
А подумав и посмотрев на красивую картинку выше, можно прийти к другой идее: сущности, связи между ними и идея непротиворечивого состояния (если всё это «замкнуть»). Но во-первых, это только часть картины, ибо на это ещё навёрнуты:; Несколько ссылок на один тип: Всё это ведь не означает, что баг должен иметь только одну ссылку, скажем, на версию. Он вполне может иметь две ссылки — например, версия, в которой нашли и версия, в которой зафиксили. Последняя — это, по сути, target milestone, но ведь это не значит, что мы не можем захотеть ссылаться на сущность того же типа «версия». Или другой пример: двухуровневая техподдержка, ссылка на связанный внешний баг и ссылка на связанный внешний продукт из продукта. В конечном итоге, это можно решить присвоением «имени» ссылке, по умолчанию равному названию типа сущности, на которую ссылаемся. Это, кстати, снова становится похоже на схему с зависимыми полями :); Права: Сейчас в Bugzilla они рулятся на уровне продукта. TODO; Скрытие/показ полей бага в зависимости друг от друга: Сейчас в Bugzilla это реализовано отдельно от функционала контроля значений — по сути, скрываться выпадающее поле может в зависимости от одного поля, а набор значений может при этом меняться в зависимости от другого. А на самом деле '''''это неправильно'''''! Что за бред — поле скрыто, но при этом есть варианты, которые можно выбрать? Или наоборот — поле доступно, но из вариантов — только пустое значение. Не подходит. Соответственно, контроль показа поля в том виде, в котором он есть в Bugzilla сейчас, актуален только для полей других типов — строковых и так далее.; Email-уведомления об изменениях: С ними более-менее всё понятно. По сути, они всегда привязываются к какому-либо полю какого-либо объекта общей структуры, ссылающемуся на пользователя/пользователей (например, Assignee и CC бага) — это со стороны ссылок на пользователей. Вторая сторона — событие, но единственно возможные события — изменение поля или создание новой сущности. А во-вторых — если не хранить поле (например, продукт), от которого зависит другое поле (например, компонент), в самом баге, тоже полезут костыли (только другие). Соответственно, нужно понять, чем вообще схема, реализованная в самой багзилле сейчас, Чем плохатекущая багзильная реализация этого «добра»? А вот чем:
Возможно, так даже получится Что предлагается сделать зависимость :* Есть объекты. У объектов есть поля (разных типов). В том числе, есть типы «multi-select» и «single-select».* Зависимости полей могут прописываться дополнительно, в виде ограничений вида: баг.компонент.продукт == баг.продукт. Могут и не прописываться. Теоретически, могут прописываться несколько ограничений на одно поле, например, чтобы какой-нибудь атрибут зависел и от двух продукта, и от, скажем, операционной системы. Такое устройство наиболее гибкое и в частности позволяет багу иметь несколько полей, ссылающихся на один тип объектов.* Поля могут скрываться в зависимости от значений другихполей. Селект-поля скрываются, если в них по зависимостям нечего выбирать. На поля остальных типов можно вешать «настройку видимости», подобную текущей багзильной реализации — просто тупо «поле = одно из значений…».* HTML-код полей должен генерироваться автоматически. Также желательна возможность задавать группировку полей в интерфейсе — например, опционально раскрываемые «Advanced Fields» (только общим fieldset’ом, а не как сейчас — просто скрытие полей в разных местах формы).* На поля можно назначить дополнительные обработчики, задающие более хитрое поведение. Сами обработчики пишутся в коде, по возможности — максимально абстрагированно от конкретного поля. Назначаться они при этом должны не из кода, а из интерфейса конфигурации модели. На этих дополнительных обработчиках должно работать всё!Примеры:** Платформа, ОС: функции угадывания значения по умолчанию на основе заголовков запроса.** Статус: есть ограничения переходов из состояния в состояние (workflow). Возможно, его нужно попытаться вынести в базовые настройки модели.** CC: специальное поведение при клонировании, смене Assignee и QA (старые добавляются в CC), специальное «значение по умолчанию», зависящее от компонента.* История хранится централизованно для всех объектов.* Общий механизм рассылки изменений по почте для всех объектов каким-либо образом «связанным» пользователям. Настройки уведомлений на уровнях: событие (изменено значение поля, добавлена сущность) и отношение (собственно связь).* Поиск: адаптировать сильно прокачанный движок поиска из [http://wiki.4intra.net/Bugzilla4Intranet Bugzilla4Intranet]. Адаптировать долго не придётся, потому что с точки зрения read-only все типы полей останутся, по сути, те же самые.* Права доступа: Нужна опять-таки общая схема для всех объектов, с одной стороны, простая для вычисления системой, а с другой стороны, дающая достаточную гибкость разных настроек. По всей видимости, нужны с одной стороны опять-таки «связанные» пользователи, а с другой стороны — роли. Причём, пользователи могут быть «связанные» через какое-то поле — например, человек может быть связан с багом, потому что прописан как Global Watcher для продукта этого бага. Роли могут набираться из действий над полями различных объектов и права на просмотр объектов. Возможно, нужно давать возможность разграничивать доступ на просмотр к разным полям — например, в Bugzilla только группа time-tracker’ов может посмотреть информацию о рабочем времени.
А видимость То есть, наш трекер превратится, по сути, в модульное приложение, построенное вокруг очень прокачанного автоинтерфейса полей других типов — напримери объектов. Естественно, строковых — пусть контролируется так жеэто уже не Bugzilla ни разу, как но зато чем-то похоже на [http://roundup.sourceforge.net/ Roundup] — «конструктор трекеров». Однако и сейчасс ним различий много — roundup не умеет зависимых селект-полей, модель задаётся в коде, права доступа слабые, поиск слабый.
Нет описания правки
В Bugzilla половина кода в шаблонах, половина на основе полу-ORM’а Bugzilla::Object. Большая часть — говнокод. С одной стороны — ORM бы туда, было бы классно, НО! ORM мало, и нужен не он! Все (существующие) ORM-движки — это просто объектный интерфейс к базе данных. А нужно некое объектное ядро, которое бы позволяло создавать свои объекты, с полями различных типов, в том числе и ссылающимися на другие такие же объекты, с возможностью приписывания специальных особенностей полю, с общим механизмом хранения истории и с автоматическим базовым CRUD-интерфейсом.
== Идеи по созданию объектного ядра ==
}
</graph>
Причём, понятное дело, если баг принадлежит к некоторому продукту (через компонент), то и его версия, milestone, agreement должны принадлежать к тому же продукту. Сейчас в Bugzilla это реализуется так — для каждой сущности, связанной с багом, в баге есть «поле», а для ограничения значений полей поля делаются «зависимыми» от других полей. Из-за этого там куча костылей и, по сути, повесить зависимость на отличное от поля «продукт» поле невозможно.
* Значения кастом полей в таблице багов хранятся не ссылками по ID, а по именам, что создаёт геморрой для зависимых полей, так как чтобы точно идентифицировать значение, приходится брать ещё и значение поля, от которого оно зависит.
* «Поле» (селект и мультиселект) совмещено с объектом, соответственно, не добавишь дополнительных атрибутов объекту.
* Для выпадающих списков есть как «контроль значений», так и «контроль видимости поля», что в корне '''''неверно (см. выше)'''''! Ибо что за бред — поле скрыто, но при этом есть варианты, которые можно выбрать? Или наоборот — поле доступно, но из вариантов — только пустое значение.
* По факту, ни от чего, кроме продукта, зависимым значение не сделаешь.
* История хранится только для багов, но не для остальных объектов.
* Поля Код полей не генерятся генерится автоматически, а ручками вписываются в шаблоны. Учитывая, что * На всё равно нужно вычислять «непротиворечивость» зависимостей полей, появляется следующая мысль:* Разделяем «поля» и «объекты».* Объекты могут содержат ссылки на другие (компонент ← продукт).* Поле содержит ссылку на другое поле, в которое должна попадать ссылка на объект, на который ссылается объект, на который ссылается поле +)) Но тут появляется следующий вопрос: это чтонавёрнута туча неструктурированного кода, всегда во все объекты тащить все связи объектов, с которыми они связаны («замыкать»)? No way! Соответственно, окончательная идея — «зависимости» между полями связанных объектов навешиваются в виде чего-то типа «внешних ключей». Например:* Объект «баг», поля «продукт» и «компонент», ссылающиеся на объекты «продукт» и «компонент»* У объекта «компонент» есть поле «продукт», ссылающееся на объект «продукт»* На баг навешено дополнительное ограничение: баг.компонент.продукт == баг.продуктопределяющего поведение «встроенных» полей.
== Текущее состояние ==
