Нет, не правильно. Вот пример. Я вам советую меньше вопросов задавать, и больше самому покопаться. А еще все топики вот в этом разделе прочитать, начиная с первого. Многое станет ясно.
Открываете пользователя для редактирования, переходите во вкладку Настройки, и там создаете эту настройку. ?
При вызове использую имя класса «TableNameUsers» (при запросах он делает FROM table_name_users AS TableNameUsers). Но правильно ли понимаю, в запросах, например в JOIN — придется все равно использоваться название table_name_users?
Вот в данном случае подходящий вариант. А где это в настройках пользователя запрятано? Не могу найти
Добрый день. Вы путаете названия классов и названия таблиц. Это разные вещи. На основании информации о запрошенном классе, формируется запрос к его таблице. Поищите и почитайте подробней о мап-файлах. Вот пример, на котором многое станет понятней.
Кстати, есть еще вариант: если предполагается, что контент-менеджер будет работать только с одним конкретным разделом, можно в настройках пользователя задать tree_root_id = id раздела. Тогда он в дереве будет видеть только этот раздел и его дочерние документы. Указать сразу несколько разделов не получится.
Если делать по тому мануалу, и по общей системе, как это заведено в MODX-е, то только определив документы в различные группы ресурсов. Да, это крайне не удобно по многим причинам, но только так. Другой же, более разумный в этом случае способ — это разруливание на уровне плагина в момент попытки открытия документа для редактирования. Вот пример такого плагина: <?php
switch($modx->event->name){
case 'OnManagerPageBeforeRender':
switch($scriptProperties['controller']->config['controller']){
/*
Проверяем права на редактирование документов
*/
case 'resource/update':
// Проверяем наличие настройки allow_to_update (задается в настройках пользователя)
// В ней мы перечисляем, какие документы пользователю можно редактировать
// Если настройка задана, но id документа отсутствует в перечисленных разрешенных,
// То возвращаем ошибку доступа
if($allow_to_update = $modx->getOption('allow_to_update')){
if(!is_array($allow_to_update)){
$allow_to_update = explode(",", $allow_to_update);
$allow_to_update = array_map('trim', $allow_to_update);
}
//
if(!in_array($scriptProperties['controller']->scriptProperties['id'], $allow_to_update)){
$scriptProperties['controller']->failure('Доступ запрещен');
return;
}
}
break;
}
//print_r($scriptProperties['controller']->config);
//print_r($scriptProperties['controller']->scriptProperties);
break;
} Но это, что называется, «защита от дурака», то есть этот метод позволяет на уровне интерфейся рулить что можно открывать, а что нельзя (для удобства менеджера), но ничто не мешает ему отправлять Ajax-запрос на редактирование с указанием произвольного id. То есть этот метод не до конца защищает. Защита же на уровне разделения по группам ресурсов более надежная, ибо работает на уровне самого объекта ресурса, где би и как бы его не получили, а не просто на уровне рендеринга страницы редактирования. Для вас этот плагин просто как пример. Там вам придется свои более сложные условия писать, типа перебрать всех родителей ресурса, и если это новость, то ее редактировать можно. А так же не забудьте таким манагерам отключить разрешение быстрого редактирования страниц, ибо этот плагин там не сработает.
Всего-то навсего нужно API внимательно изучить, чтобы знать как что вызывать и что вообще можно вызвать, а далее уже прикручиваем все что вздумается Все так! С учетом того, что в Smarty-шаблонах нам полностью доступен объект $modx, делать там можно все, что угодно. До разраба мне конечно дaлеко, да и не за этим я здесь, просто захотел себе да и знакомым сайт создать, будучи даже и близко не шаря в программировании. А вот это уже чуть сложнее. Дело в том, что наши технологии как раз больше рассчитаны на программистов, и требуют хоть каких-то навыков в программировании.