НАЧАЛО >> Оглавление >> Общее описание >> История изменений >> Что нового в проекте I128 >> Версия 2026.2.6 >> [I128-2776] Отчет АРМ Подписка по потребностям использует данные текущей подписки📄 Скачать в DOCX
| Тип | Версия | Статус | Приоритет | Исполнитель |
|---|---|---|---|---|
| ⚙️ Исправление ошибок | 2026.2.6 | 🔘 Завершено |
Средний | Ilya Mikhaylenko |
Компоненты: ИРБИС 128. Модуль Periodicals - АРМ Подписка
Завершено: 24.08.2026 15:11
Проблема
В АРМ Подписка действие Periodicals/GetSubDivisionRequest формирует CSV/Excel-отчет по заявленным изданиям подразделения, но берет данные из текущей подписки.
Сценарий воспроизведения
Periodicals/GetSubDivisionRequest.Ожидаемый результат
Отчет должен выводить текущие потребности адресата профиля: данные поля 139, включая число комплектов и VIP-абонента из повторений потребности.
Причина
В modules/Periodicals/Actions/GetSubDivisionRequest.inc действие сейчас перебирает повторения поля 39 (Текущая подписка) и использует индекс AP. Для отчета по потребностям нужен источник поля 139: адресат в подполе B, число комплектов в D, VIP-абонент в @.
Решение
Перевести Periodicals/GetSubDivisionRequest на данные текущих потребностей: искать/фильтровать записи по адресату потребности и суммировать подполе D поля 139; VIP-абонента брать из подполя @ поля 139. Использовать существующий паттерн из GetPendingNeeds/SaveCloseSubscriptionPrizn: сначала быстрый поиск AP=<адресат>, а если он не нашел потребности, выполнить fallback-поиск по журналам VD=J и при необходимости по базе с фильтрацией повторений 139^B. При необходимости обновить справку по отчету.
Риски
Нужно не сломать существующую CSV-кодировку Windows-1251, защиту от CSV-инъекций, Content-Length и поведение при пустом адресате профиля. Важно не полагаться только на AP, если индекс не включает поле 139, и не смешать текущие потребности с архивом потребностей.
Связь с IBK Проблема обнаружена при разборе IBK-455. Эта задача закрывает upstream-проблему U1.
I128-2776 для release/2026.2: исправляет CSV/Excel-отчет АРМ Подписка по заявленным изданиям подразделения. PR переводит Periodicals/GetSubDivisionRequest с данных текущей подписки на текущие потребности адресата профиля и обновляет Help по отчету.
Куда смотреть:
?id=Periodicals, профиль АРМ Подписка с заполненным destination -> пользовательская кнопка с action Periodicals/GetSubDivisionRequest -> скачивание result.csv. Chrome: не подтверждено, потому что в текущем локальном контексте не зафиксированы настроенный профиль и тестовые записи с активными потребностями 139. Было: строки отчета собирались из текущей подписки поля 39, поэтому число комплектов и VIP-абонент могли не совпадать с заявленными потребностями. Стало: строки отчета собираются из активных потребностей поля 139 для адресата профиля.destination; в целевой БД должны быть записи периодики с активными повторениями 139, где 139^B совпадает с адресатом, 139^D содержит положительное число комплектов, а 139^@ при необходимости содержит VIP-абонента.Periodicals/GetSubDivisionRequest. Если быстрый индекс AP= не содержит поле 139, action сам выполняет fallback по журналам и затем по ограниченному набору записей базы.?id=Help/Show&m=Periodicals/UserGuide/Subscriptions; раздел отчета теперь указывает поле 139 как источник числа комплектов и VIP-абонента.release/2026.2; merged-зависимости отсутствуют.Изменения по файлам:
modules/Periodicals/Actions/GetSubDivisionRequest.inc
Start() нормализует адресат профиля, сохраняет его в результате long-task и оставляет быстрый стартовый поиск по AP=.DoWork() больше не читает поле 39; строки отчета собираются по активным повторениям поля 139, где 139^B совпадает с адресатом профиля, 139^- пустое, 139^D суммируется как число комплектов, а 139^@ попадает в колонку VIP-абонента.Content-Length и имя result.csv сохранены.End() добавляет fallback по паттерну соседних Periodicals action: если быстрый AP= не дал строк отчета, выполняется поиск по VD=J, затем по "$" с лимитом 1000 записей.modules/Periodicals/Help/UserGuide/Subscriptions.md
Periodicals/GetSubDivisionRequest обновлено: источником числа комплектов и VIP-абонента указано поле 139, а не текущая подписка 39.AP= и fallback, когда потребности не найдены через индекс.Разрешение текущих конфликтов подготовлено в PR #1359 (merge/release-2026.2-to-develop-pr1358 -> develop, commit 169484ec3bf1bde29110dd8cd22cf7f5b3fae057). Обе исходные ветки защищены от прямого push; отдельный PR сохраняет направление переноса release → develop. После принятия #1359 следует повторно проверить этот PR на новые изменения релизной ветки.
Перенос всех изменений из release/2026.2, которые ещё не входят в develop.
PR создан после merge #1353: I128-2785: SocketProxy отправляет внутренние HTTPS-запросы на порт 80.
Пока этот PR открыт, последующие изменения release/2026.2 входят в него автоматически. Перед merge требуется проверить полный diff и пройти обычное review.
Перенос накопленных исправлений release/2026.2 в develop с разрешением конфликтов PR #1358.
Обе исходные ветки защищены от прямого push. Отдельная ветка содержит merge текущего release/2026.2 (e402d81e4d2a59c87254ea3bd62fbd805d6bd332) в текущий develop (df8b1a8ee2d35e0cc0c5e776d64cb71f115013e4). Новые функции develop не переносятся обратно в релизную линию. Для принятия изменений используется обычное review; PR #1358 пока остается открытым.
Разрешение конфликтов:
^, в том числе после редактирования повторений через F3. Отложенная синхронизация отменяется перед сохранением.modules/he3/tests/editor_commands_smoke.js. Существующий тест журнала статистики сохраняет путь tools/PagesStatJournalSelfTest.php.Проверки:
await Irbis.he3.testEditorCommands(). Серверное сохранение подменено; пользовательские БД не изменялись.При принятии сохранить merge-коммит и родителя release/2026.2 в истории develop (merge commit или fast-forward).
После принятия этого PR нужно повторно проверить #1358: если в release не появились новые изменения, его перенос будет полностью выполнен. Автоматизация последующих переносов release → develop не изменялась.