Выбрать всё в CRM: страницу или все записи по фильтру

Менеджер отфильтровал клиентов, нажал галочку в заголовке таблицы и запустил действие. Он ожидал изменить двадцать видимых строк, а система обработала все сто двадцать найденных записей. Возможна обратная ситуация: сотрудник думал, что выбрал весь фильтр, но изменил только первую страницу. Проблема начинается с неясного значения «всё», а не с цвета общего переключателя.

Ниже — модель приёмки таблицы в собственной CRM или внутреннем сервисе. Примеры используют вымышленные записи и безопасное тестовое действие. Они не описывают возможности конкретного продукта Левицкий Концепт. Для рабочей системы область массового изменения, права и порядок подтверждения нужно определить отдельно до реализации.

У общего выбора должна быть понятная область

Разделите три возможных набора: явно отмеченные строки, все строки текущей страницы и все записи, соответствующие фильтру. Первые два набора могут совпасть в отдельном состоянии, но это не делает их одинаковыми правилами. При переходе на следующую страницу разница станет видна. До разработки запишите, какой смысл имеет каждый элемент управления.

В учебной таблице фильтр нашёл 120 записей, на странице показано 20. Команда «выбрать страницу» выделяет эти двадцать. Для перехода ко всем найденным можно предусмотреть отдельное явное действие с подписью «выбрать все 120 по фильтру». Это предложенный способ объяснения области, а не обязательная единственная компоновка интерфейса.

Рядом с массовым действием показывайте не только число, но и основание: «20 на этой странице» или «120 по текущему фильтру». Одинаковый счётчик без пояснения не сообщает, где находятся остальные строки. Пользователь не должен изучать техническую документацию, чтобы понять, какие клиентские записи он собирается изменить.

Проверьте состав на небольших числах

Начните с трёх учебных действий. Выбрать всю первую страницу — получить 20 записей. Выбрать весь фильтр — 120. Затем исключить две определённые записи из полного набора — получить 118. В последнем случае программа должна помнить, что это весь набор с исключениями, либо сохранить конкретный состав другим согласованным способом.

Важно не спутать исключение и смену режима. Если после снятия одной галочки система незаметно возвращается к выбору только страницы, число изменится не на единицу. Пользователь должен видеть, какое правило действует после каждого шага. Сохранённое внутреннее состояние и текст перед запуском обязаны описывать один набор.

Если количество неизвестно или результат фильтра ещё загружается, интерфейс не должен выдавать вымышленный точный счётчик. Можно показать предусмотренное состояние ожидания. Нельзя оставить кнопку с прежним числом и применить действие к уже изменённому набору, не объяснив переход. Точность подписи здесь является частью безопасной работы таблицы.

Частичная галочка не объясняет выбор сама по себе

В паттерне Checkbox W3C APG описано дополнительное состояние частичного выбора группы. Оно помогает показать, что отмечена только часть элементов. Но сам по себе такой значок не устанавливает, какой группой управляет заголовок таблицы. Эту область определяет приложение и объясняет пользователю понятной подписью.

Проверьте состояние для нуля выбранных строк, части страницы и всей страницы. Затем отдельно проверьте режим полного фильтра с исключениями. Не требуйте, чтобы один маленький символ сообщал всю структуру сразу. Счётчик, подпись области и возможность посмотреть исключения могут дополнять его. Отдельно нужно убедиться, что управление понятно с клавиатуры и вспомогательными средствами в заявленном объёме поддержки.

В тестовой версии полезно показать выбранные идентификаторы доступным проверяющему способом. В обычном интерфейсе достаточно понятного списка или предпросмотра. Главное — возможность доказать, что исключённый клиент действительно не входит в действие. Правильная сумма 118 не подтверждает это: программа могла исключить две другие записи и всё равно показать то же число.

Фильтр изменился — прежний выбор требует решения

Менеджер выбрал клиентов одного города, а затем сменил фильтр на другой. Должен ли выбор сохраниться? Возможны разные процессы: сброс с предупреждением, сохранение явно выбранных строк с объяснением или отдельное подтверждение новой области. Нельзя незаметно расширять правило «все по фильтру» вслед за редактированием условий, если человек уже подтвердил иной набор.

В учебной первой версии смена условий сбрасывает массовый выбор и показывает понятную отметку. Это выбранное ограничение, не универсальная норма всех CRM. Оно упрощает проверку: новый фильтр требует нового осознанного выбора. При другом решении нужно описать, относятся ли ранее исключённые строки к новому набору и что показывает счётчик.

Сортировка и смена страницы также проверяются отдельно. Если человек отметил конкретные идентификаторы, перестановка строк не должна подменить их записями на прежних позициях. Галочка относится к записи, а не к пятому месту экрана. При обновлении данных этот принцип помогает избежать действий над случайно оказавшимся рядом клиентом.

Определите момент фиксации полного набора

Между выбором и запуском фильтру могут начать соответствовать новые записи. Владелец должен решить, включает ли действие их автоматически. Набор на момент выбора и набор на момент выполнения являются разными условиями. Оба требуют понятного описания; исходная цифра 120 не подтверждает, что через минуту состав останется прежним.

Для проверяемого действия можно предусмотреть подготовку конкретного набора и его подтверждение. Если подготовленный состав успел измениться, программа показывает это по принятому процессу. Это не означает, что интерфейс обязан сохранять все данные клиента в браузере. Способ фиксации и проверки выбирает разработчик, а требование формулируется через ожидаемое множество записей.

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

Массовое действие может закончиться частично

Из 118 выбранных записей часть может перестать удовлетворять условиям операции. Например, тестовый статус уже изменён другой задачей или у текущего пользователя больше нет предусмотренного разрешения. Программа должна проверить применимость на стороне сервиса, а не только доверять ранее показанной кнопке. Причины отказов сохраняются в пределах согласованного безопасного журнала.

Не называйте запуск задания успешным завершением всех изменений. В результате полезно разделить обработанные, пропущенные и требующие проверки записи. Числа должны согласовываться с определённым составом операции. Если действие выполнено только для 110 из 118, общий зелёный баннер «готово» без пояснения скрывает восемь незавершённых случаев.

В учебном результате 110 обработано, 5 пропущено по известному условию и 3 завершились ошибкой. Вместе это 118. Для продолжения нужен понятный список этих восьми записей и предусмотренные действия. Повтор не должен автоматически означать повторное применение ко всем 110 уже обработанным, если результат операции от этого меняется.

Сохраните результат независимо от открытой страницы

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

Для продолжительной обработки предусмотрите собственный идентификатор задания и понятные состояния. Это проектное требование, а не обещание автоматически фонового режима у любой системы. Если первая версия выполняет только небольшой синхронный набор, обозначьте его пределы и поведение при разрыве связи. Отсутствие уведомления не доказывает, что действие не произошло.

Вопрос повторного запроса разобран в статье о повторе операции после обрыва сети. Для таблицы сначала нужно правильно определить сам набор. Надёжная обработка неправильных идентификаторов не исправит исходную ошибку выбора. Поэтому приёмка начинается с области и исключений, а не с количества успешно изменённых строк.

Что включить в демонстрацию перед выпуском

Подготовьте 120 вымышленных записей, страницу на 20 строк и две заранее известные записи для исключения. Проверьте четыре строки таблицы, затем смените страницу, сортировку и фильтр. Отдельно добавьте подходящую запись после выбора и разберите ожидаемое поведение по моменту фиксации. Каждый тест должен иметь известный состав, а не только ожидаемый счётчик.

Наконец, покажите частичный результат и продолжение после закрытия экрана. Владелец должен суметь объяснить, что было выбрано, что обработано и что осталось. На этом заканчивается первая проверяемая версия массового выбора: понятная область, правильные записи и сохраняемый результат. С такой основой таблица помогает работать с большим списком, не превращая слово «всё» в опасную неоднозначность.