Дублирование записей о добавлении изделия в БД

[alx]

Мной обнаружено, что у некоторых (изготовленных в последнее время) изделий запись о добавлении изделия в БД записывается в историю дважды. Вот пример:

Вот что у этого изделия в таблице history:

MariaDB [adcproducts]> select * from history where UID=1806;
+------+---------------------+---------------------+------------+------------+------------+----------+--------------+--------+---------+------+------+-------------+
| UID  | worker              | date                | type_write | order_from | whom_order | location | number_order | status | comment | N    | bond | shelfdrawer |
+------+---------------------+---------------------+------------+------------+------------+----------+--------------+--------+---------+------+------+-------------+
| 1806 | Епишин О.В.         | 2021-08-20 13:32:09 | record     | АДС        | АДС        | NULL     |         NULL | NULL   |         | 2940 | NULL | NULL        |
| 1806 | Епишин О.В.         | 2021-08-20 13:32:21 | record     |            | АДС        | NULL     |         NULL | NULL   |         | 2941 | NULL | NULL        |
+------+---------------------+---------------------+------------+------------+------------+----------+--------------+--------+---------+------+------+-------------+
2 rows in set (0.001 sec)

Ожидалось, что в историю изделия запись о добавлении изделия в БД ьудет заноситься только один раз, как это и было раньше.

[alx]

Забыл описать ожидаемое поведение.

[alx]

Дополнительная информация.
Обнаружилось, что целый ряд записей в истории изделия ошибочно отображается как событие "Добавлено в базу". Например как "Добавлено в базу" отображаются просто комментарии:

Я не добавлял изделие S/N H03938 в БД, я написал несколько комментариев.

Еще пример - изделие S/N F00851:

Здесь я дважды "переместил" изделие, но в истории записи о перемещении ошибочно отображаются как событие "Добавлено в базу".

[Denis_N]

Тикет разобран как две связанные, но разные проблемы.

1. Ошибочное отображение записей как «Добавлено в базу»

В старой Главной странице запись history.type_write='record' отображалась как событие «Добавлено в базу». Поэтому в r420/base и близких версиях как «Добавлено в базу» могли отображаться не только реальные записи первичного добавления изделия, но и старые записи другого смысла: комментарии, возвраты/перемещения, старые записи с order_from=, whom_order='АДС' и т.п.

Это исправлено в коде:

• r497/base: добавлена корректная обработка старых record-записей вида order_from=, whom_order='АДС', location=... как перемещения;
• r500/base: на Главной изменён вывод Журнала событий, событие стало отображаться по смыслу записи;
• r503/base: логика отображения истории вынесена в общий js/history_events.js для Главной и Универсальной панели. В ней record/change_location интерпретируются по комбинации type_write/order_from/whom_order/location/shelfdrawer, а не как безусловное «Добавлено в базу»;
• r523/base: отображение событий переведено на стабильные UI-иконки, без изменения смысла событий.

2. Новые записи перемещения/возврата

Часть старых record-записей создавалась не как первичное добавление изделия, а при изменении местоположения/возврате. Это также исправлялось отдельно:

• r480/base и r484/base: при смене местоположения в интерфейсе «Возврат» вместо type_write='record' стала создаваться запись type_write='change_location';
• r570/base: добавлена защита от повторного сохранения бессмысленного перемещения, если изделие уже находится в выбранном месте/полке;
• r572/base: аналогичная защита добавлена в Универсальной панели.

Таким образом, текущий интерфейс больше не должен показывать любые record-записи как «Добавлено в базу», а новые перемещения не должны записываться как record.

Отдельно при проверке подтвердилось, что в старых исторических данных действительно есть дублирующиеся соседние записи history.type_write='record'. Например, для UID=1806 это именно старые данные в history. Это уже не дефект текущего отображения интерфейса, а задача нормализации исторической БД. По предварительному анализу найдено 831 строгий соседний дубль record; для их разбора создан отдельный тикет по нормализации данных.

Текущий тикет закрываю: поведение интерфейса и запись новых перемещений исправлены в указанных ревизиях.

Оставшаяся чистка старых записей history будет выполняться отдельной задачей нормализации - See #1501