tndt-54 - Дашборд сначала показывает критические задачи

Проект

tndt - Task n Doc Tracker

Этап

Открыта

Тип

Задача

Приоритет

Обычный

Трудоемкость

Обычная

Создана

demius

Дата создания

4 года назад

Назначена

demius

Обновлена

8 месяцев назад

У нас есть критически важные задачи по другим проектам, но мы в них редко лазаем. Надо их выводить на дашборде и помечать. А то, система бекапов, важная и в tndt то же потеряна в проекте, в который мне лазить лень. а не хотелось бы потерять все, что мы тут понаписали

Вобще задача была бы не сложной, но другие приоритеты нам хотелось бы сортировать обычным образом, по updated, кроме того у каждого проекта свой набор приоритетов (или вобще приоритетов нет) а дашборд не находится в контексте проекта. Так что надо подумать что на странице дашборда считать высокоприоритетными задачами.

отдельный флаг у элемента справочника приоритет, что этот приоритет критический и должен выталкивать задачу, чтобы она мозолила глаза.
Система у всех проектов, к которых есть приоритет, выбирает самый верхний и считает его критическим. (правда могут быть проекты с приоритетами, но в целом мне не важные, и бещ критических приоритетов, с другой стороны и задач у них будет не много, а обычным порядком они не зафлудят дашборд)

Панель управления

Комментарии могут оставлять только авторизованные пользователи

demius 8 месяцев назад

Кажется тут нужен флаг в самой задаче, а справочник управляет этим флагом. Как сейас он управляет флагом is_closed

demius 3 года назад

В целом специальное поле подмешивающееся к сортировке, в норме имеющее какое-то значение не вмешивающееся в сортировку вполне имеет право на жизнь. Его дельтой могут разные системы изменять, кому нужно изменить важность. (правда в 95% случаев это будет таки приоритет), так что можно и sort_priority, а с появлением новой системы переименовтаь в custom_sort

demius 3 года назад

Второй вариант непонятно как реализовывать, сортировать сначала по приоритету, потом по дате? Так это испортит сортировку остальных. Кроме того у нас нет правила, что самый важный приоритет в конце или в начале, их id довольно спонтанны.

demius 4 года назад

Да, первый пункт правильнее, но по флагам в элементах справочника не посортируешь.

Добавить в задачу отдельный флаг sorted_priority, который система справочников будет заполнять по своим правилам, а репозиторий просто по нему сортировать. +быстро, -лишний денормализованный атрибут.
В репозиториях спросясь сервиса набирать n-е количество особых задач, и вручную подмешивать к выдаче. Чем равно n? Мы эти задачи последовательно спрашиваем у всех проектов, или у 5 самых новых? Это в любом случае куча подзапросов со странными выборками.

demius 4 года назад

Я пока склоняюсь к первому пункту, задачи с критическим приоритетом будут проявлять себя и в других частях системы