![[MC-04 logo]](/mc-04/chrome/site/logo.png){kind=logo}
Opened 13 months ago
Last modified 10 months ago
#1239 reopened улучшение
Хаос в истории изделия в интерфейсе "Тестирование"
| Reported by: | alx | Owned by: | Denis_N |
|---|---|---|---|
| Priority: | major | Component: | БД изделий АДС |
| Keywords: | Cc: |
Description (last modified by )
В r325/base в интерфейсе "Тестирование" после пары неудачных тестирований и устранений неисправностей в истории изделия отображается какой-то хаос:
Во-первых, при неуспешном результате тестирования в историю изделия заносится не одна, а две записи: одна запись типа "несоответствие", и одна запись типа "тестирование", хотя в действительности я выполнил одну операцию. Обратите внимание, что записи имеют одно и то же время с совпадением до секунды. При этом запись о несоответствии имеет комментарий, который я ввел в веб-интерфейсе при завершении тестирования, а запись о тестировании имеет пустой комментарий.
Во-вторых, из записи об устранении несоответствия никак нельзя понять, какое именно несоответствие было устранено. Получается, что перекрестные ссылки между записями о несоответствии и его устранении, которые были не так давно реализованы, не работают...
Мне кажется, что причина первой проблемы кроется в неудачном выборе способа типизации записей истории - когда одна запись имеет один фиксированный тип (в данном случае "тестирование" или "несоответствие"). Такая логика не очень точно соответствует реальной действительности, где результатом тестирования может быть обнаружение несоответствия, то есть сам факт неудачного тестирования уже означает, что имеет место несоответствие.
Учитывая сказанное, предлагаю изменить логику и схему записей истории таким образом, чтобы одна запись могла совмещать в себе информацию о неудачном тестировании и о несоответствии. Например трактовать тип записи не как единственное значение, а как поле флагов, в котором может быть установлено более одного флага одновременно. Это позволит истории изделия точнее отражать реально происходившие с изделием события, и избавит пользователей от лицезрения "лишних" записей.
По второй проблеме предлагаю изменить отображение истории изделия в интерфейсе "Тестирование" таким образом, чтобы пользователи могли понять, какие записи относятся к одному и тому же несоответствию, а какие - к разным. Как один из возможных вариантов решения могу предложить группировать записи, относящиеся к одному и тому же несоответствию, в одну общую запись:
Несоответствие:
Обнаружено: Иван Напримеров, 12 января 2022 в 15:54:23: Нет линка у интерфейсе eth5.
Ремонт: Петр Степанов, 15 января 2022 в 11:24:54 - Неуспешно: Грелась D4. Заменил, но не помогло.
Ремонт: Петр Степанов, 15 января 2022 в 12:11:27 - Успешно: Заменил еще и D7.
Также было бы полезно раскрашивать группы с неустраненными несоответствиями красным, устраненные - или зеленым, или нейтральным - чтобы сразу было видно, остались ли у изделия не устраненные несоответствия или нет...
Attachments (1)
Change History (23)
by , 13 months ago
comment:1 by , 13 months ago
| Description: | modified (diff) |
|---|
comment:2 by , 13 months ago
follow-up: 4 comment:3 by , 11 months ago
Мне нравится твое предложение полностью, Алексей.
Считаю, что его реализация упростит восприятие пользователем истории изделия и логики работы интерфейса.
Хотел только спросить, как ты видишь реализацию этого поля флагов в бд?
Replying to alx:
Учитывая сказанное, предлагаю изменить логику и схему записей истории таким образом, чтобы одна запись могла совмещать в себе информацию о неудачном тестировании и о несоответствии. Например трактовать тип записи не как единственное значение, а как поле флагов, в котором может быть установлено более одного флага одновременно. Это позволит истории изделия точнее отражать реально происходившие с изделием события, и избавит пользователей от лицезрения "лишних" записей.
follow-up: 6 comment:4 by , 11 months ago
Replying to Denis_N:
Хотел только спросить, как ты видишь реализацию этого поля флагов в бд?
Я вижу примерно так. Поле type_write имеет тип BIT вместо ENUM. Существующим типам записей (record, testimg, mismatch и т.п.) ставятся в соотетствие биты этого поля (b'0001', b'0010', b'0100' и т.д.). В результате появляется возможность комбинировать типы в одной записи:
b'0010' - testing,
b'0100' - mismatch,
b'0110' - testing и mismatch одновременно.
Проверки значения поля type_write на равенство конкретному значению меняются на проверки установки какого-либо бита: WHERE type_write & 1...
follow-up: 7 comment:6 by , 11 months ago
Replying to alx:
Я вижу примерно так. Поле
type_writeимеет тип BIT вместо ENUM.
Мне кажется битовый тип не очень нагляден(человекочитаем) и выборку из базы по битовому полю делать сложнее.
На мой взгляд вместо битового типа было бы удобнее использовать отдельные поля ENUM для каждого действия, которые будут содержать признак типа записи (NULL или нет) и сразу конкретное значение, т.е. предлагаю вообще убрать тип записи. Выглядеть запись в истории будет как-то так:
| record==NULL | testing==NULL | mistmatch==yes | otk==fail |
что будет соответствовать типу записи b'0101' в твоём примере и означать - плата не прошла ОТК т.к. обнаружено несоответствие
comment:7 by , 11 months ago
Replying to san:
На мой взгляд вместо битового типа было бы удобнее использовать отдельные поля ENUM для каждого действия, которые будут содержать признак типа записи (NULL или нет)
ENUM с единственным значением? Оригинально... :) Принципиальных возражений нет.
follow-up: 9 comment:8 by , 11 months ago
ENUM с единственным значением? Оригинально... :) Принципиальных возражений нет.
Ну не обязательно единственным, хотя в вырожденном случаем может быть и так.
testing и отк могут принимать значения NULL, ok или fail.
mistmatch - может быть, например: [Null, "обнаружено", "комментарий", "устранено"].
comment:9 by , 11 months ago
Replying to san:
testing и отк могут принимать значения NULL, ok или fail.
Могут, конечно, но это будет избыточно, так как успешность тестирования и контроля ОТК уже есть в поле status.
mistmatch - может быть, например: [Null, "обнаружено", "комментарий", "устранено"].
Безусловно, можно придумать и сделать можно много всяких значений вместо одного бита. Непонятно только, зачем... :)
follow-up: 11 comment:10 by , 11 months ago
много всяких значений вместо одного бита. Непонятно только, зачем... :)
По всяким не битовым значениям проще и наглядней делать запрос в базу, например условие where otk='fail' мне нравится больше чем что-то типа where type_write & b’0001′ AND status='fail' (с синтаксисом я наверняка наврал, но суть должна быть понятна)
follow-up: 12 comment:11 by , 11 months ago
Replying to san:
По всяким не битовым значениям проще и наглядней делать запрос в базу, например условие
where otk='fail'мне нравится больше чем что-то типаwhere type_write & b’0001′ AND status='fail'(с синтаксисом я наверняка наврал, но суть должна быть понятна)
Во-первых, я в comment:7 написал, что принципиальных возражений против использования типа ENUM у меня нет.
Во-вторых, с утверждением о том, что при нескольких значениях EMUM вместо одного запрос получается нагляднее, я согласиться не могу. Ведь придется писать что-то типа WHERE mismatch = 'обнаружено' OR mismatch = 'устранено' вместо WHERE NOT ISNULL(mismatch) или WHERE mismatch = 'yes'.
comment:12 by , 11 months ago
Replying to alx:
Replying to san:
По всяким не битовым значениям проще и наглядней делать запрос в базу, например условие
where otk='fail'мне нравится больше чем что-то типаwhere type_write & b’0001′ AND status='fail'(с синтаксисом я наверняка наврал, но суть должна быть понятна)
Во-первых, я в comment:7 написал, что принципиальных возражений против использования типа ENUM у меня нет.
Во-вторых, с утверждением о том, что при нескольких значениях EMUM вместо одного запрос получается нагляднее, я согласиться не могу. Ведь придется писать что-то типа
WHERE mismatch = 'обнаружено' OR mismatch = 'устранено'вместоWHERE NOT ISNULL(mismatch)илиWHERE mismatch = 'yes'.
follow-up: 14 comment:13 by , 11 months ago
Алексей, а что ты думаешь насчет типа SET? Подошел бы он для реализации данного тикета? В чем его плюсы и минусы в сравнении с BIT-овым вариантом реализации, на твой взгляд?
follow-up: 15 comment:14 by , 11 months ago
Replying to Denis_N:
Алексей, а что ты думаешь насчет типа
SET?
Нормальный вроде бы тип... Ничего особенного не думаю. :)
Подошел бы он для реализации данного тикета?
Думаю, вполне бы подошел.
В чем его плюсы и минусы в сравнении с
BIT-овым вариантом реализации, на твой взгляд?
Это фактически один и тот же тип - 64-битное число. Плюс в том, что кроме числового значения каждый бит представляется определенной строкой, что может сделать запросы более наглядными (понятными). Минусов, честно говоря, не вижу...
follow-up: 21 comment:20 by , 10 months ago
| Resolution: | → готово |
|---|---|
| Status: | new → closed |
comment:21 by , 10 months ago
| Resolution: | готово |
|---|---|
| Status: | closed → reopened |
В r342/base сделал несколько записей о несоотетветствиях изделия, а также о неудачном тестировании. После этого сделал записи об устранении неисправностей. В результате я вижу, что при тестировании, действительно, в историю добавилась только одна запись. Однако никакой группировки отображаемых в истории записей я не обнаружил - как и раньше, отображается "хаос" из расположенных вразнобой записей об обнаружении и устранении несоответствий, и понять, какая именно запись об устранении несоответствия какие именно несоответствие устраненяет, по-прежнему нельзя (если об этом не написано в тексте комментария).
Дополню немного. Довольно типичная ситуация в жизненном цикле изделия:
Я считаю, что в веб-интерфейсе должна быть возможность "открыть конкретное несоответствие" (подобно тому как есть возможность "открыть историю конкретного изделия"): при клике чего-то (например записи о несоответствии) должна открываться страница с отображением всех записей (и только их), связанных с данным конкретным несоответствием. На этой странице должна быть возможность не только добавить запись об устранении несоответствия, но и добавлять любые комментарии к данному конкретному несоответствию.