Правка строк прямо в списке админки - режим, сохранение, файлы
Включаем правку записей прямо в списке административной части: режим редактирования, обработка изменённых полей, файлы и проверка значений.
Что нужно знать заранее
Правка прямо в списке экономит сотрудникам десятки переходов в карточку. Она уместна там, где меняют одно-два поля у многих записей: сортировку, активность, цену или срок.
Список сам ничего не сохраняет: он только собирает изменённые сотрудником значения. Сохранение пишет разработчик, и там же живут проверки значений и права на конкретное действие.
Загруженные файлы приходят отдельно от обычных текстовых полей формы. Их переносят в набор изменённых полей отдельным вызовом до начала обработки, иначе файлы просто теряются при сохранении.
Шаги
- Пометить в описании списка те колонки, которые сотрудник может править прямо в строке.
- Поймать режим правки в коде страницы и получить полный набор изменённых строк.
- Перенести загруженные файлы в изменённые поля ещё до начала цикла обработки.
- Проверить значения каждой строки и сохранить их своим кодом с проверкой прав.
- Показать ошибки построчно, чтобы сотрудник сразу видел, какая запись не сохранилась.
Решение
Разрешаем правку нужных колонок:
$list->AddHeaders([ ['id' => 'ID', 'content' => 'ID', 'sort' => 'ID', 'default' => true], ['id' => 'SORT', 'content' => 'Сортировка', 'sort' => 'SORT', 'default' => true, 'editable' => true], // эту колонку можно править в строке ['id' => 'ACTIVE', 'content' => 'Активность', 'default' => true, 'editable' => true],]);Редактируемыми делают только те колонки, которые действительно правят пачками. Список из двадцати редактируемых полей превращается в форму, работать с которой неудобно и опасно.
Ловим режим правки и изменённые строки:
if ($list->EditAction()) { // сотрудник нажал сохранение в списке $list->convertFilesToEditFields(); // файлы переносим до цикла обработки foreach ($list->GetEditFields() as $id => $fields) { saveRow((int)$id, $fields); // сохранение пишем сами }}Перенос файлов делают строго до цикла обработки строк. Это самая частая ошибка в таких списках: поля сохраняются, а картинка или документ исчезают без единого сообщения.
Проверяем значения и сообщаем об ошибке:
foreach ($list->GetEditFields() as $id => $fields) { if (!is_numeric($fields['SORT'])) { $list->AddUpdateError('Сортировка должна быть числом', $id); // ошибка по строке continue; } VendorTable::update((int)$id, ['SORT' => (int)$fields['SORT']]);}Ошибку привязывают к конкретной строке, а не к списку целиком. Сотрудник правил двадцать записей, и сообщение «что-то пошло не так» не поможет ему найти строку с неверным значением.
Проверяем права до сохранения:
if ($APPLICATION->GetGroupRight('vendor.shop') < 'W') { $list->AddUpdateError('Недостаточно прав на изменение', 0); return; // права проверяем до любой записи}Возвращаем сотрудника на список после сохранения:
$list->ActionRedirect(); // возврат на список с сохранённым фильтром и страницей// без этого сотрудник теряет фильтр и начинает искать записи зановоВозврат с сохранённым фильтром - мелочь, которая экономит время каждый день. Без неё после каждого сохранения сотрудник заново выставляет отбор и листает до нужной страницы списка.
Типичные проблемы
Файл, загруженный в строке списка, не сохранился.
Не вызван перенос загруженных файлов в набор изменённых полей до начала цикла. Вызов ставят сразу после проверки режима правки, до начала обработки строк.
Сообщение об ошибке не показывает, где проблема.
Ошибка добавлена ко всему списку вместо конкретной строки с записью. Ошибку привязывают к идентификатору строки, и тогда сотрудник видит нужную запись.
Сотрудник со справочным доступом меняет данные.
Права проверяются только при выводе списка, но совсем не при сохранении строк. Проверку прав ставят в самом обработчике сохранения строк списка.
После сохранения сбрасывается фильтр списка.
В конце обработки не вызван штатный возврат на список в административной части. Возврат делают штатным методом: он помнит отбор и текущую страницу.
Правка в списке ломает данные редкими значениями.
Значения сохраняются без всякой проверки типа и границ допустимых значений. Каждую строку проверяют перед записью так же, как и в обычной форме.
Частые вопросы
Когда правка в списке лучше карточки?
Когда меняют одно-два поля у многих записей подряд: сортировку, активность, цену. Для сложной записи с проверками карточка остаётся удобнее.
Можно ли править так пользовательские поля?
Да, если они выведены колонками и помечены как редактируемые. Сложные типы полей при этом лучше оставить для карточки записи.
Как показать подсказку по формату значения?
В заголовке колонки или в подсказке рядом с ним. Сотрудник видит формат до правки, а не после сообщения об ошибке.
Что делать с очень длинными списками?
Ограничивать число записей на странице и опираться на фильтр. Правка сотни строк за один заход почти всегда означает, что нужна групповая операция.
Работает ли такая правка в своём модуле?
Да, механизм общий для всех списков административной части. Сохранение и права при этом пишет разработчик модуля.
Смежное
- Страницы в админке - оглавление подтемы
- Своя страница в админке: список, форма, пункт меню - как собирают сам список
- Групповые действия и выгрузка в своём списке админки - операции над отмеченными строками
- Форма в админке: вкладки, проверка значений, тулбар - карточка записи и её проверки
- Права в своём модуле: уровни, проверка, интерфейс настроек - права на изменение данных
- Своя таблица на ORM: сущность, запросы, изменение структуры - данные под таким списком
- Административный интерфейс - устройство интерфейса целиком