13 521
правка
Изменения
м
→Идеи по созданию объектного ядра
; Несколько ссылок на один тип: Всё это ведь не означает, что баг должен иметь только одну ссылку, скажем, на версию. Он вполне может иметь две ссылки — например, версия, в которой нашли и версия, в которой зафиксили. Последняя — это, по сути, target milestone, но ведь это не значит, что мы не можем захотеть ссылаться на сущность того же типа «версия». Или другой пример: двухуровневая техподдержка, ссылка на связанный внешний баг и ссылка на связанный внешний продукт из продукта. В конечном итоге, это можно решить присвоением «имени» ссылке, по умолчанию равному названию типа сущности, на которую ссылаемся. Это, кстати, снова становится похоже на схему с зависимыми полями :)
; Права: Сейчас в Bugzilla они рулятся на уровне продукта. TODO
; Скрытие/показ полей бага в зависимости друг от друга: Вот тут пока не додумал :)Сейчас в Bugzilla это реализовано отдельно от функционала контроля значений — по сути, скрываться выпадающее поле может в зависимости от одного поля, а набор значений может при этом меняться в зависимости от другого. А на самом деле '''''это неправильно'''''! Что за бред — поле скрыто, но при этом есть варианты, которые можно выбрать? Или наоборот — поле доступно, но из вариантов — только пустое значение. Не подходит. Соответственно, контроль показа поля в том виде, в котором он есть в Bugzilla сейчас, актуален только для полей других типов — строковых и так далее. TODO
; Email-уведомления об изменениях: С ними более-менее всё понятно. По сути, они всегда привязываются к какому-либо полю какого-либо объекта общей структуры, ссылающемуся на пользователя/пользователей (например, Assignee и CC бага) — это со стороны ссылок на пользователей. Вторая сторона — событие, но единственно возможные события — изменение поля или создание новой сущности.
