Если у вас возникли какие либо вопросы которые вы не смогли решить по нашим публикациям самостоятельно,
то ждем ваше обращение в нашей службе тех поддержки.
Когда я столкнулся с такой задачей, я полез прежде всего в ядро, что советую делать всегда. Полез в main.interface.grid, и узнал, откуда она берет все настройки списка:
GRID_ID постоянен (для конкретного списка), первое и так константа, осталось как-то заменить этот метод на свой. Но сначала посмотрим внутренности этого метода.
Там я увидел кеш:
Что это значит? А то, что мы можем переопределить его до вызова грида, тем самым указав любые данные, какие только захотим. Этим методом я кстати когда-то пользовался .
Проверим - как хранится self::$cache. Нам свезло! Это protected.
То есть, достаточно из дочернего класса переопределить эту переменную. Что мы и делаем, быстренько накидывая такой метод в дочернем классе:
Суть кода проста - перетираем текущий кеш-массив пользователя на массив супер-юзера (естественно только для конкретной категории и имени переменной).
Теперь нам надо понять - какие значения у $category и $name. Если отмотаете в начало поста, то узнаете, что $cateogory это константа main.interface.grid, а $name это некий $arParams["GRID_ID"], который ставится извне. В моем случае внешний компонент, подключающий грид, это список сделок, поэтому я полез туда (в crm.deal.list).
Простой поиск по ctrl+f дает результат:
Отбрасывая ненужное нам, получаем, что GRID_ID равен CRM_DEAL_LIST_V12.
Вызываем наш единственный метод, который переопределит нужные переменные для данного пользователя:
Второй переменной идет ID пользователя, с которого надо взять все настройки.
Смотрим результат под любым пользователем - видим, что и колонки изначально стоят нужные, и изменить их порядок или добавить новые - невозможно. Что и требовалось сделать.
Резюмирую! Если вы хотите заморозить грид, порядок действий:
1. Создаете класс с методом выше. Менять его даже и не требуется, если только не захотите более удобно оформить порядок переменных.
2. Узнаете GRID_ID.
3. Вызываете метод перед вызовом непосредственно грида. Это может быть на самой странице компонента в публичной части (хотя в случае КП я бы не стал доверять даже публичке, она может меняться с обновлениями). Поэтому, лучше вызывать его в каком-то обработчике - например, OnBeforeProlog.
4. PS: По идее неким похожим способом можно легко и просто заморозить списки и формы в админке, но мне пока этого не требовалось.
Я не зря все подробно расписал - как шел, как искал. Чтобы обратить внимание новичков - что решения прежде всего стоит искать в самих интерфейсах и пользовательских инструментах. А если этого нет - сразу лезть в код. Какого-то промежуточного звена в нашем деле нет.
Назад в раздел
то ждем ваше обращение в нашей службе тех поддержки.
Делаем предустановленный и неменяемый грид для любого пользователя
Допустим, таблица сделок, или лидов, или любой другой список, основанный на гридах (в CRM таких данных чуть менее, чем полностью). И допустим, что эта таблица должна выглядеть так, как установил админ, или другой супер-юзер. Решение под катом.Когда я столкнулся с такой задачей, я полез прежде всего в ядро, что советую делать всегда. Полез в main.interface.grid, и узнал, откуда она берет все настройки списка:
$aOptions = CUserOptions::GetOption("main.interface.grid", $arParams["GRID_ID"], array()); |
GRID_ID постоянен (для конкретного списка), первое и так константа, осталось как-то заменить этот метод на свой. Но сначала посмотрим внутренности этого метода.
Там я увидел кеш:
Что это значит? А то, что мы можем переопределить его до вызова грида, тем самым указав любые данные, какие только захотим. Этим методом я кстати когда-то пользовался .
Проверим - как хранится self::$cache. Нам свезло! Это protected.
То есть, достаточно из дочернего класса переопределить эту переменную. Что мы и делаем, быстренько накидывая такой метод в дочернем классе:
class CUserOptionsOver extends CUserOptions {
public static function SetBaseUserCache($user_id, $base_user_id, $category, $name, $default_value = false) {
if ($base_user_id == $user_id) {
return;
}
if (!isset(parent::$cache[$user_id])) {
parent::$cache[$user_id] = array();
}
if (!isset(parent::$cache[$user_id][$category])) {
parent::$cache[$user_id][$category] = array();
}
parent::$cache[$user_id][$category][$name] = parent::GetOption($category, $name, $default_value, $base_user_id);
}
} |
Теперь нам надо понять - какие значения у $category и $name. Если отмотаете в начало поста, то узнаете, что $cateogory это константа main.interface.grid, а $name это некий $arParams["GRID_ID"], который ставится извне. В моем случае внешний компонент, подключающий грид, это список сделок, поэтому я полез туда (в crm.deal.list).
Простой поиск по ctrl+f дает результат:
$arResult['GRID_ID'] = 'CRM_DEAL_LIST_V12'.($bInternal && !empty($arParams['GRID_ID_SUFFIX']) ? '_'.$arParams['GRID_ID_SUFFIX'] : ''); |
Вызываем наш единственный метод, который переопределит нужные переменные для данного пользователя:
CUserOptionsOver::SetBaseUserCache($USER->GetID(), 1, 'main.interface.grid', 'CRM_DEAL_LIST_V12'); |
Второй переменной идет ID пользователя, с которого надо взять все настройки.
Смотрим результат под любым пользователем - видим, что и колонки изначально стоят нужные, и изменить их порядок или добавить новые - невозможно. Что и требовалось сделать.
Резюмирую! Если вы хотите заморозить грид, порядок действий:
1. Создаете класс с методом выше. Менять его даже и не требуется, если только не захотите более удобно оформить порядок переменных.
2. Узнаете GRID_ID.
3. Вызываете метод перед вызовом непосредственно грида. Это может быть на самой странице компонента в публичной части (хотя в случае КП я бы не стал доверять даже публичке, она может меняться с обновлениями). Поэтому, лучше вызывать его в каком-то обработчике - например, OnBeforeProlog.
4. PS: По идее неким похожим способом можно легко и просто заморозить списки и формы в админке, но мне пока этого не требовалось.
Я не зря все подробно расписал - как шел, как искал. Чтобы обратить внимание новичков - что решения прежде всего стоит искать в самих интерфейсах и пользовательских инструментах. А если этого нет - сразу лезть в код. Какого-то промежуточного звена в нашем деле нет.
Назад в раздел
Подписаться на новые материалы раздела:
