Не работает фильтр "Прием/возврат"

[alx]

В r275/base делаю следующие действия:

• Открываю главную страницу.
• Кликаю "Показать фильтры".
• В строке "Комбинирование таблиц" кликаю "Выбрать столбцы для отображения".
• В открывшейся панели ставлю отметки столбца "Тип записи" и других нужных мне столбцов.
• Кликаю "Добавить фильтр по истории".
• В появившейся панели выбираю "Прим/возврат".
• Нажимаю ENTER.

В результате получаю ПОЧТИ ВСЕ записи истории:

Ожидалось, что будут выведены только записи о приемке.

После этого снова кликаю "Показать фильтры" и в открывшейся панели фильтров отсутствует фильтр "Приме/возврат". Ожидалось, что фильтр будет присутствовать.

В описанном эксперименте количество найденных записей (40888) точно такое же, как и без применения фильтра "Прием/возврат". Это позволяет предположить, что данный фильтр просто не применяется (что объясняет его последующее отсутствие в панели фильтров).

---

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

MariaDB [adcproducts]> SELECT COUNT(*) FROM history;
+----------+
| COUNT(*) |
+----------+
|    40999 |
+----------+
1 row in set (0.000 sec)

А где еще 111 записей?

[alx]

Блин, почему опечатки становятся видны только после того, как текст отправлен? :) Вычитывал ведь текст перед отправкой, ничего не заметил... Магия какая-то... :)

[Denis_N]

Проверил.

Причина была в старом динамическом конструкторе фильтров Главной страницы.

В r275/base пункт "Прием/Возврат" создавал блок фильтра для type_write='record', но сам факт выбора этого пункта не сохранялся как отдельное значение фильтра. Если внутри созданного блока не были выбраны дополнительные параметры, в POST не попадало данных, по которым backend мог построить условие history.type_write='record'. Поэтому итоговый запрос выполнялся фактически без этого ограничения, результат был почти таким же, как без фильтра, а при повторном открытии панели фильтр не восстанавливался.

Сейчас этот механизм уже не используется. Главная страница была переработана в r402/base, а в r498/base появился новый фильтр записей о перемещении с отдельной backend-логикой. В текущей версии записи приемки/возврата учитываются через фильтр перемещений: backend явно ищет записи журнала с type_write, содержащим 'change_location' или 'record', и с непустым location.

Расхождение между COUNT(*) FROM history и количеством строк на старой Главной, вероятно, связано с тем, что сравнивались разные выборки. COUNT(*) FROM history считал все записи истории, а старая Главная выводила историю через связь history -> products -> list_of_products, поэтому показывала только записи, которые удалось привязать к существующему изделию и имени изделия в справочнике.

Закрываю как исправленное переработкой Главной страницы.

[alx]

Replying to Denis_N:

Расхождение между COUNT(*) FROM history и количеством строк на старой Главной, вероятно, связано с тем, что сравнивались разные выборки. COUNT(*) FROM history считал все записи истории, а старая Главная выводила историю через связь history -> products -> list_of_products, поэтому показывала только записи, которые удалось привязать к существующему изделию и имени изделия в справочнике.

Хм... А почему 111 записей не удается, как ты выразился, "привязать к существующему изделию и имени изделия в справочнике"?

[Denis_N]

Да, сформулирован ответ слишком предположительно.

Старая Главная в r275/base сравнивалась не напрямую с COUNT(*) FROM history, а с выборкой через INNER JOIN history -> products -> list_of_products. Поэтому разница в 111 строк предполагает, что эти записи history не проходили один из JOIN-ов: либо для history.UID не находилось строки в products, либо для products.name не находилось соответствующего имени в list_of_products.

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