13 521
правка
Изменения
м
* «Поле» (селект и мультиселект) совмещено с объектом, соответственно, не добавишь дополнительных атрибутов объекту.* Для выпадающих списков есть как «контроль значений», так и «контроль видимости поля», что в корне '''''неверно'''''! Ибо что за бред — Типа поле скрыто, но при этом есть варианты, которые можно выбрать? Бред! Или наоборот — поле доступно, но из вариантов — только пустое значение.
* История хранится только для багов, но не для остальных объектов.
→Обновление модели
Чем плоха текущая багзильная реализация этого «добра»?
Очень просто: '''почти ни хрена не настраивается''' - нельзя ни добавить свои возможности, ни отрубить ненужные встроенные. Ибо всё жёстко и криво (хардкод). А ещё:
* История хранится только для багов, но не для остальных объектов.
* Шаблоны переусложнены.
* Нет "объектов", есть «значения полей», соответсвенно, им не добавишь атрибутов и не навесишь логики.
* Значения кастом полей в таблице багов хранятся не ссылками по ID, а по именам, что создаёт геморрой для зависимых полей, так как чтобы точно идентифицировать значение, приходится брать ещё и значение поля, от которого оно зависит.
* По факту, ни от чего, кроме продукта, зависимым значение не сделаешь.
* Код полей не генерится автоматически, а ручками вписываются в шаблоны.
* На всё это навёрнута туча неструктурированного кода, определяющего поведение «встроенных» полей.
* История хранится централизованно для всех объектов.
* Общий механизм рассылки изменений по почте для всех объектов каким-либо образом «связанным» пользователям. Настройки уведомлений на уровнях: событие (изменено значение поля, добавлена сущность) и отношение (собственно связь).
* Поиск: адаптировать сильно прокачанный движок поиска из [http://wiki.4intra.net/Bugzilla4Intranet Bugzilla4Intranet]. Адаптировать долго не придётся, потому что с точки зрения read-only все типы полей останутся, по сути, те же самые.С другой стороны, его нужно обобщить, так что кое-что сделать всё-таки будет нужно. Но зато в итоге получится супер-инструмент — система выборок, которая отлично хавает большие базы, сложные ''и произвольные'' структуры запросов и не давится :) (доказано Bugzilla4Intranet)
* Права доступа: Нужна опять-таки общая схема для всех объектов, с одной стороны, простая для вычисления системой, а с другой стороны, дающая достаточную гибкость разных настроек. По всей видимости, нужны с одной стороны опять-таки «связанные» пользователи, а с другой стороны — роли. Причём, пользователи могут быть «связанные» через какое-то поле — например, человек может быть связан с багом, потому что прописан как Global Watcher для продукта этого бага. Роли могут набираться из действий над полями различных объектов и права на просмотр объектов. Возможно, нужно давать возможность разграничивать доступ на просмотр к разным полям — например, в Bugzilla только группа time-tracker’ов может посмотреть информацию о рабочем времени.
Таким образом наш трекер превратится, по сути, в модульное приложение, построенное вокруг очень прокачанного автоинтерфейса полей и объектов. Естественно, это уже не Bugzilla ни разу, но зато чем-то похоже на [http://roundup.sourceforge.net/ Roundup] — «конструктор трекеров». Однако и с ним различий много — много — roundup не умеет зависимых селект-полей, модель задаётся в коде, права доступа слабые, поиск слабый.
=== Обновление модели === Обновление базы багзильское (тупая последовательность операций):* (+) Очевидный порядок обновлений, нет проблем с их зависимостями друг от друга (новые просто дописываются в конец, порядок всегда правильный)* (-) Не проверяется, корректна ли схема БД после обновлений* (-) Обновления задаются именно для SQL БД, а не для метамодели* (-) Не очень красивая портянка в функции обновления БД Обновление базы наше:* AddType -> RenameFields -> AddFields -> ChangeFields -> DropFields* ChangeFields с помощью функций обновления* (???) Самый интересный вопрос - как сделать функции обновления не на SQL, в условиях когда модель в неконсистентном и вообще не знает, в каком состоянии?* После каждого шага запуск хука* Переименования задаются декларативно* Возможность Dry Run, просмотра и проверки последовательности обновлений* Зависимости обновлений в рамках каждого шага можно задать декларативно (хотя ситуация редкая)*: А может, просто стоит задавать их в ассоциативном массиве по порядку* Ещё может быть, что обновление одного типа зависит от обновления другого (причём это уже более частая ситуация) === Модель === Получается, что ядро модели состоит из следующих таблиц:
* Типы объектов
** Название типа
** Дополнительное поведение типа
* Поля
** Ссылка на объект
** ID поля
** Название поля
** Тип поля
** Nullable? Т.е. разрешено ли пустое значение
** Поле этого же объекта, контролирующее видимость данного (для не-select полей)
** Связи поля (для select-полей)
** Дополнительное поведение поля
* Контроль видимости полей
** Ссылка на поле
** ID объекта, для которого оно видно
* Транзакции (группы изменений)
** Момент времени
** Изменивший пользователь
* История изменений
** Ссылка на транзакцию** Тип объекта** Ссылка на объект** Ссылка на поле (кроме добавления объекта)** Старое значение** Новое значение* Один неудаляемый тип - — пользователи(их поля, тем не менее, можно менять)
* Связи объектов с пользователями
* Правила * ID связи** Название связи** Ссылка на объект** Цепочка свойств, заканчивающаяся объектом «пользователь»* Пользовательские настройки оповещений** Ссылка на пользователя (либо пустая для настроек по умолчанию)** Ссылка на связь** Тип события: добавление/удаление/изменение** Ссылка на поле объекта (может быть пустая)
* Роли (или группы, что примерно то же самое)
** Включаемые роли
** Включаемые разрешения
* Разрешения (из которых состоят роли)
** Ссылка на связь
** Тип разрешения: просмотр/создание/удаление/изменение
** Ссылка на поле объекта (пустая = весь объект)
** Ссылка на значение поля (пустая = любое)
=== Типы полей ===
<tab sep="bar" class="wikitable" head="top">
Тип | Параметры | Представления
Строка | Длина | Input, textarea, rich edit
Логический | | Флажок
Числовой | Точность (M.N) | Input
Дата и/или время | Дата? Время? | Поле со всплывающим календарём, просто календарь, просто поле
Файл | | Поле загрузки файла
Single-select | Тип объекта | Радиобатон, HTML-селект
Multi-select | Тип объекта | HTML-мультиселект, флажки, комбо-бокс
</tab>
== Текущее состояние ==
** Canconfirm
** Editbugs
* Private комментарии — комментарии — видны только инсайдер-группе* Информация о таймтрекинге — таймтрекинге — видна только группе, списывающей время
* reporter_accessible, cclist_accessible на отдельных багах
* Опциональные группы на отдельных багах
* Права на правку отдельных групп
* Права editclassifications, editcomponents, editfields, editkeywords, editusers
=== Настройки оповещений о багах ===
Отношения:
* Assignee, QA, Reporter, CC
* Requestee или Setter флага (реально в Bugzilla прикручено сильно сбоку)
* По идее — также создатель аттачмента, коммента (если разрешать править)
* Watcher указанного выше
* Global Watcher
События:
* Добавлен/удалён из указанного выше
* Изменено одно из полей бага (м.б отдельные настройки, м.б вместе)
* Баг / блокирующий баг меняет статус с закрытого на открытый или обратно
* «Но кроме» UNCONFIRMED
* «Но кроме» своих изменений
== Что не так? ==