id	summary	reporter	owner	description	type	status	priority	component	resolution	keywords	cc
1501	Нормализовать старые дублирующиеся записи history.type_write='record'	Denis_N	Denis_N	"При разборе #1403 обнаружено, что в таблице history есть старые дублирующиеся записи type_write='record'. Это не только ошибка отображения интерфейса: в БД действительно присутствуют соседние одинаковые записи истории для одного и того же изделия.

Предварительный анализ локальной копии БД показал:

- найдено 831 строгих соседних дублей type_write='record';
- затронуто 780 изделий;
- под строгим дублем понимается запись, которая идёт сразу после предыдущей записи того же UID по N, при этом у обеих записей type_write='record' и полностью совпадают смысловые поля:
  worker, order_from, whom_order, location, number_order, status, comment, bond, shelfdrawer;
- date и N при сравнении не учитываются, так как они различаются у самих дублей.

Основная масса дублей имеет вид:

- order_from='АДС', whom_order='АДС', location='work', без комментария;
- order_from='Склад', whom_order='АДС', location='work', без комментария.

Также есть редкие случаи с location=develop/stock/fk/isolator/nelikvid, несколько записей с комментариями и одна пара с пустыми order_from/whom_order/location.

Предлагается:

1. Сформировать отчёт по найденным группам дублей в виде «первая запись / дубль».
2. Для каждой группы оставлять первую запись по N.
3. Последующие записи считать кандидатами на удаление или архивную нормализацию.
4. Автоматически обрабатывать только безопасные случаи: соседние строгие дубли без комментария, без номера заказа, без bond, без shelfdrawer.
5. Случаи с комментариями, нестандартными location или большим разрывом по времени вынести на ручную проверку.
6. Перед изменением данных обязательно сделать резервную копию таблицы history.

Цель: убрать или нормализовать старые технические дубли в истории изделий, не меняя смысловую историю реальных операций."	дефект	assigned	minor	Разное и всякое			alx san