<?php // Полная загрузка сервисных книжек, создан 2024-01-05 12:44:55
global $wpdb2;
global $failure;
global $file_hist;
///// echo '<H2><b>Старт загрузки</b></H2><br>';
$failure=FALSE;
//подключаемся к базе
$wpdb2 = include_once 'connection.php'; ; // подключаемся к MySQL
// если не удалось подключиться, и нужно оборвать PHP с сообщением об этой ошибке
if (!empty($wpdb2->error))
{
///// echo '<H2><b>Ошибка подключения к БД, завершение.</b></H2><br>';
$failure=TRUE;
wp_die( $wpdb2->error );
}
$m_size_file=0;
$m_mtime_file=0;
$m_comment='';
/////проверка существования файлов выгрузки из 1С
////файл выгрузки сервисных книжек
$file_hist = ABSPATH.'/_1c_alfa_exchange/AA_hist.csv';
if (!file_exists($file_hist))
{
///// echo '<H2><b>Файл обмена с сервисными книжками не существует.</b></H2><br>';
$m_comment='Файл обмена с сервисными книжками не существует';
$failure=TRUE;
}
/////инициируем таблицу лога
/////если не существует файла то возврат и ничего не делаем
if ($failure){
///включает защиту от SQL инъекций и данные можно передавать как есть, например: $_GET['foo']
///// echo '<H2><b>Попытка вставить запись в лог таблицу</b></H2><br>';
$insert_fail_zapros=$wpdb2->insert('vin_logs', array('time_stamp'=>time(),'last_mtime_upload'=>$m_mtime_file,'last_size_upload'=>$m_size_file,'comment'=>$m_comment));
wp_die();
///// echo '<H2><b>Возврат в начало.</b></H2><br>';
return $failure;
}
/////проверка лога загрузки, что бы не загружать тоже самое
$masiv_data_file=stat($file_hist); ////передаем в массив свойство файла
$m_size_file=$masiv_data_file[7]; ////получаем размер файла
$m_mtime_file=$masiv_data_file[9]; ////получаем дату модификации файла
////создаем запрос на получение последней удачной загрузки
////выбираем по штампу времени создания (редактирования) файла загрузки AA_hist.csv, $m_mtime_file
///// echo '<H2><b>Размер файла: '.$m_size_file.'</b></H2><br>';
///// echo '<H2><b>Штамп времени файла: '.$m_mtime_file.'</b></H2><br>';
///// echo '<H2><b>Формирование запроса на выборку из лога</b></H2><br>';
////препарируем запрос
$text_zaprosa=$wpdb2->prepare("SELECT * FROM `vin_logs` WHERE `last_mtime_upload` = %s", $m_mtime_file);
$results=$wpdb2->get_results($text_zaprosa);
if ($results)
{ foreach ( $results as $r)
{
////если штамп времени и размер файла совпадают, возврат
if (($r->last_mtime_upload==$m_mtime_file) && ($r->last_size_upload==$m_size_file))
{////echo '<H2><b>Возврат в начало, т.к. найдена запись в логе.</b></H2><br>';
$insert_fail_zapros=$wpdb2->insert('vin_logs', array('time_stamp'=>time(),'last_mtime_upload'=>$m_mtime_file,'last_size_upload'=>$m_size_file,'comment'=>'Загрузка отменена, новых данных нет, т.к. найдена запись в логе.'));
wp_die();
return $failure;
}
}
}
////если данные новые, пишем в лог запись о начале загрузки
/////echo '<H2><b>Попытка вставить запись о начале загрузки в лог таблицу</b></H2><br>';
$insert_fail_zapros=$wpdb2->insert('vin_logs', array('time_stamp'=>time(),'last_mtime_upload'=>0, 'last_size_upload'=>$m_size_file, 'comment'=>'Начало загрузки'));
////очищаем таблицу
$clear_tbl_zap=$wpdb2->prepare("TRUNCATE TABLE %s", 'vin_history');
$clear_tbl_zap_repl=str_replace("'","`",$clear_tbl_zap);
$results=$wpdb2->query($clear_tbl_zap_repl);
///// echo '<H2><b>Очистка таблицы сервисных книжек</b></H2><br>';
if (empty($results))
{
///// echo '<H2><b>Ошибка очистки таблицы книжек, завершение.</b></H2><br>';
//// если очистка не удалась, возврат
$failure=TRUE;
wp_die();
return $failure;
}
////загружаем данные
$table='vin_history'; // Имя таблицы для импорта
//$file_hist Имя CSV файла, откуда берется информация // (путь от корня web-сервера)
$delim=';'; // Разделитель полей в CSV файле
$enclosed='"'; // Кавычки для содержимого полей
$escaped='\
+ за описание последствий применения!
От себя добавлю:
1) Если предполагается использование конструкции с подзапросом, типа ТекущаяТаблица ГДЕ (ТекущаяТаблица.Ссылка В (Выбрать Ссылка ИЗ …. — выбираем необходимые данные), то лучше необходимые данные загрузить в параметр сеанса и использовать ТекущаяТаблица ГДЕ ТекущаяТаблица.Ссылка В (&НеобходимыеДанные). Т.е. необходимо по максимуму упрощать запрос и избавляться от всяческих подзапросов.
2) Внимательно использовать РАЗРЕШЕННЫЕ в подзапросах RLS, если такие все же имеются. Иначе может возникнуть ошибка из-за использования РАЗРЕШЕННЫЕ в основном запросе.
Только не начиная с платформы 8.0
RLS впервые появился только в 8.1
Плохо, написано для тех кому и так все поянтно. В итоге — кому этот материал предназначается?
.
лень расписать «на пальцах».. что например означает шаблон в рис.1? что значит таблица слева, а параметр справа?
(4) CheBurator, поддерживаю. Ссылки на материалы в ИТС тоже неплохо бы поместить.
(4), (5)
Ребята, статья не призвана заменить литературу из коробки и диски ИТС.
Che, в руководстве разработчика синтаксис описан (стр.177 и далее).
Если есть желающие дополнить материал, я не возражаю.
Да, было бы неплохо расширить написанной, «разжевать». Но, в целом статья хорошая, ставлю «+».
К механизмам RLS надо подходить акуратно, так как его использование может снижать производительность системы.
(6)
Чувствую себя обманутым.
захожу по заголовку, мол «ага щас узнаю как настроить RLS». в итоге тут вижу треп-междусобойчик профи.
для новичка единственная ценная информация — это расшифровка аббревиатуры RLS и понятно, что это и зачем.
и все. быстрый ответ на свой вопрос не получил.
за совет читать книги и другие источники, спасибо — и так их читаем.
зря потратил время.
Процитирую вопрос: «а для чего была написана эта статья?»
(9) В статье разобран простой пример использования механизма. Считаю, что его можно использовать как дополнение к материалу из книги Руководство разработчика. Также считаю, что статья пригодится тем, кто без книг самостоятельно пытался настроить ограничения, но возникали какие-то вопросы.
А какой вопрос был у тебя?
По мне дак данный механизм конечно хорош, но вот его реализация в платформе сыровата что ли. Скажем, чтобы передать в запрос параметр обязательно нужно заводить ПараметрСеанса, как то не очень прикольно.
Вот, кстати, , кое-что проясняет.
Вот реализация в ЗУПЕ типовых шаблонов типа «ОбщееУправлениеДоступом» или «ОрганизацияВШапкеФизЛицоВШапке» вообще не читабельно, если потратить время, то конечно можно разобраться, но когда первый раз видишь — убивает просто.
К сожалению статья не о чем.Тот кто сталкивался с данным механизмом наверное со мною согласятся.У меня был проект в котором активно использовался механизм ограничения доступа на уровне записи, Это 64 филиала в одном ЗУП.
На тот момент ЗУП была единственной конфигурацией в которой это было реализовано. Информационных материалов по теме очень мало.Была статья на ИТС, то ж не о чем.Сам разбирался по реализованным шаблонам в той же ЗУП.По ним вполне можно во все въехать и в общем то немного посмотрев как это там реализовано — можно разобраться.
Интересные комменты от Ediks (2) .Там действительно есть странности которые вроде как должны работать, но по факту почему то не работают.
Ну будем надеяться что автор или кто нибудь другой возьмутся за благородный труд написать и разжевать все подробности RLS
(11) sound, спасибо. ссылка полезная. Коротко и по делу.
(2) непонятно, о чем речь.
Если о подзапросах — они прекрасно работают в RLS.
А если о частном случае применения В (Выбрать Ссылка ИЗ …. ) — т.е. подзапрос после «В», то так и нужно писать.
Далее.
РАЗРЕШЕННЫЕ в языке запросов разрешены только в основном запросе.
Или в RLS это не отслеживается? Сам не проверял, т.к. вообще, РАЗРЕШЕННЫЕ ставятся в запросах в конфе, а не в RLS.
Собственно, это и задумывалось — RLS отсекает по указанному условию, а запрос берет только то, что разрешил RLS.
В случае не установки РАЗРЕШЕННЫЕ в запросах (в конфе) будут значения типа <Объект не найден>.
Т.е. РАЗРЕШЕННЫЕ и RLS работают именно таким образом и в такой связке, и безо всяких ошибок, а не как прикольно использовать :)))
(0) автор, на самом деле — или разжевывай все ПАРАМЕТРЫ, или разбери «обновленный» шаблон RLS из конф 8.2 на несколько страниц…
а так — ни новичку не понятно, ни бывалому неинтересно.
И исправь заголовок — хотя бы что-то «Использование простейшего RLS».
И что в 8.1., а не в 8.0 RLS появились, поправь наконец.
Елки, за что плюс-то ставить??
(11) sound,
я сам вручную шаблоны RLS отлаживал, до изменений 8.2 :))
Т.е. запрос + понимание работы шаблона.
Кстати, RLS по ссылке — не самый сложный, немного набив руку, потом такие сам пишешь влет.
А вот в 8.2 какая-то попа — править что-либо надо неделю…
(17)
1) О подзапросах — я разве упоминал что подзапросы нельзя использовать? Я написал, что все выборки необходимо делать заранее и помещать их в параметры сеанса. Это сделано исключительно ради быстродействия. Когда 1000 пользователей пытается прочитать документы с RLS, то их работа становится невозможной. Либо список открывается минут через 15, либо идут блокировки. С параметром сеанса ситуация изменилась кардинально — вообще никаких заметных задержек. Это не теоретические разглагольствования, а суровая реальность. Боевой опыт…
2) Если указать в подзапросе RLS РАЗРЕШЕННЫЕ, то обращение к объекту с RLS вызывает ошибку времени исполнения, Т.е. платформа это отслеживает, но отслеживает на момент исполнения. Это и понятно, платформа 1С по сути своей — интерпретатор. Я это проверял (ошибку, а не то, что это интерпретатор:)) и написал это просто для сведения. Рука привычно написала РАЗРЕШЕННЫЕ, а в результате — ошибка.
(20) вот теперь понятно 🙂
Т.е. не использовать РАЗРЕШЕННЫЕ в подзапросах для параметров сеанса (а не для подзапросов RLS, как однозначно указывает фраза из (2): «Внимательно использовать РАЗРЕШЕННЫЕ в подзапросах RLS», т.к. это все-таки запросы параметров, потом становящиеся волею судьбы «подзапросами» RLS), или использовать очень осторожно.
Вообще, если приложите пример RLS с вызовом параметра и запрос из самого параметра — будет прекрасно 🙂
Потому как обычно подзапросы идут по пользователям или группам — там на быстродействие не сказывается.
Т.е. нужен пример, когда реально оправдано использование результата запроса через параметры сеанса.
вставлю и я свои пять копеек…
думал, что то новое для себя узнаю, а ниче нового… на самом деле в ЖКК очень хорошо все описано, т.к. с ходу и не понятно…а в статье, если бы я попробывал по статье настроить хотя бы простое условие, то ничего бы у меня не получилось…
лушче бы упомянули про шаблоны, текущие таблицы, что означает в настройках роли ГДЕ Ложь (я уже сам знаю) :)))
я вот тут у себя немного собрал информации, когда писал для одной конторы ограничения…
а за шо 38 плюсов не понятно )
относительно использования в шаблонах RLS РАЗРЕШЕННЫЕ, мне даже в голову не приходило, т.к. в описании языка запросов популярно описано для чего это применяется… и логика подсказывает, а накой тогда использовать данную конструкцию в шаблоне RLS если она предназначена для использования шаблонов RLS )))
(21)
1) Да нет же, как раз в запросах при установке параметров сеанса можно и нужно использовать РАЗРЕШЕННЫЕ. Параметры сеанса в общем случае заполняются при старте системы — там нет никаких ограничений.
В RLS ошибку вызовет конструкция типа:
Выбрать Ссылка Из НекийОбъект //Основной запрос
Где Ссылка (Выбрать Разрешенные Из Чегототам //условие RLS
Вообще в подзапросах нельзя использовать Разрешенные. Вы это можете увидеть в обычном конструкторе запроса — при создании подзапроса на закладке «Дополнительно» отсутствует галочка «Разрешенные».
Так что можно усилить мое утверждение — в подзапросах RLS (как и в любых подзапросах) вообще нельзя использовать Разрешенные.
2) Пример готового запроса не хотелось бы выкладывать — конфига специфическая.
спасибо статья полезная, но хотелось бы по-подробнее
(24) 2) боитесь, что через подзапрос RLS залезем к вам в базу? 🙂
непонятно, что за тайна — убрали название организации и заменили названия на общепринятые.
(22) «В «ГДЕ Ложь» Ложь будет всегда, а значит пользователю доступ будет запрещен всегда.»
— вот честно, ерунду написали :))
«ГДЕ Ложь» — это условие, а не запрет на доступ 🙂
да шо вы такое говорите?
вы забыли про приоритеты… приоритетными всегда являются права с большим доступом… если у меня две роли, в одной наложен шаблон ограничения по правам на чтение на некий объект, во второй, на этот объект установлено чтение без ограничения, то шаблон работать не будет…
если же написать ГДЕ Ложь во второй роли, то шаблон будет работать т.к. будут выполняться определенные условия… читайте книжку
да и смысл писать ГДЕ Ложь, если достаточно снять галочку «Чтение». Тут явно просматривается логика )))
ГДЕ ЛОЖЬ используется, когда пользователю надо дать доступ на обращение к таблице, но сами данные читать запретить.
Если просто снять галку Чтение, то при обращении к таблице ВЫБРАТЬ РАЗРЕШЕННЫЕ ИЗ Таблица будет выдано исключение. Чтобы исключение не возникало, а запрос не возвращал данных используется такой финт.
Не о чем. Из разряда «А это RLS, тут можно потыкать мышкой. Если заинтересовало — почитайте мануал».
Комментарий также нИ о чем.
1. Читаем мануал.
2. Пробуем что-то сделать.
3. Читаем доп.статьи.
4. Пробуем что-то сделать.
(28) WKBAPKA,
вы забыли про приоритеты… приоритетными всегда являются права с большим доступом…
Причем тут приоритеты ролей друг над другом и RLS?
RLS никак не отменяет роли и не разрешает там, где роль запретила.
RLS никак не влияет на роль. Он ей подчинен, и выполняет свои, строго определенные функции — в рамках ограничений, наложенных ролью.
Не знаю, что вы за мануалы чиатете, — я их уже давно не читаю, окромя Большой
Советской ЭнциклопедииЖелто-белой Книжки, но если это 1с-мануалы, и там написано процитированное вами — то, как всегда, мануалы 1с такие мануалы… 🙂ГДЕ Ложь пишется не в Роли, а для вывода списка объекта. И не важно, какие роли — ГДЕ Ложь лишь разграничивает то, что запрещено или разрешено RLS. И к ролям это не имеет никакого отношения — если роль запретила, то RLS тут не поможет, потому как он сам привязан от роли как Подчиненный и Хозяин, если уж на то пошло, а не как вы написали «если роль запрещает…то RLS не покажет…». Тут нет вариантов.
это потому, что вы не знаете, для чего в RLS писать ГДЕ Ложь.
А сняв «чтение» в роли — вы запретите в принципе что-либо прочитать в данном объекте.
читайте умные книжки.
Даже я , который не претендует на замещение умных книжек, скажу вам — роли разграничивают общий доступ на объекты, а RLS — лишь разграничивает то, что разрешено ролью.
(32)
по RLS НЕТ МАНУАЛОВ.
есть частичная разрозненная информация.
(34) есть раздел в руководстве разработчика, вот я про него.
(35)
это где, на какой странице?
(36) начало на стр.177
(33) AlexO,
да шо вы такое говорите?
вы забыли про приоритеты… приоритетными всегда являются права с большим доступом…
Причем тут приоритеты ролей друг над другом и RLS?
RLS никак не отменяет роли и не разрешает там, где роль запретила.
Думаю, что WKBAPKA имел в виду следующее: если одна роль позволяет читать таблицу с ограничением
а другая роль читать с ограничением
то пользователь с такими ролями сможет таки прочитать данные, где он является ответственным.
(36) AlexO,
возьмите, откройте книжку, которую вы так часто любите читать, называется «Руководство разработчика», там RLS посвящен целый раздел.
Объясняю на пальцах. Имеем две роли: Роль Бухгалтера и роль Менеджер. Имеем справочник, например «Контрагенты». У роли бухгалтер к нему полный доступ, нет ограничений, а для роли менеджера заданы ограничения, какие нибудь.
Берем пользователя «Вася Пупкин», ставим эти две роли в надежде, что для него будут работать ограничения. Но т.к. для роли бухгалтера определен полный доступ, то при наложении ролей роль бухгалтера для данного справочника будет приоритетнее, а значит, Вася Пупкин получит полный доступ к этому справочнику, без ограничений.
Но если написать в роли бухгалтера
у Васи Пупкина появятся ограничения, т.к. больше прав ему уже будет давать роль менеджера. А у бухгалтера вообще не будет доступа к этому справочнику, если не назначить ему еще одну роль, с большими правами. Теперь понятно?
(38) sai_NT,
имеется ввиду, что для роли где написано
всегда будет запрет на чтение, а для второй роли будет разрешено чтение по разрешенным записям, соответственно она и будет давать возможность читать таблицу, но с наложенным ограничением
(34) AlexO,
Цитата
да шо вы такое говорите?
вы забыли про приоритеты… приоритетными всегда являются права с большим доступом…
Причем тут приоритеты ролей друг над другом и RLS?
RLS никак не отменяет роли и не разрешает там, где роль запретила.
RLS никак не влияет на роль. Он ей подчинен, и выполняет свои, строго определенные функции — в рамках ограничений, наложенных ролью.
Не знаю, что вы за мануалы чиатете, — я их уже давно не читаю, окромя Большой Советской Энциклопедии Желто-белой Книжки, но если это 1с-мануалы, и там написано процитированное вами — то, как всегда, мануалы 1с такие мануалы… 🙂
Цитата
если же написать ГДЕ Ложь во второй роли
ГДЕ Ложь пишется не в Роли, а для вывода списка объекта. И не важно, какие роли — ГДЕ Ложь лишь разграничивает то, что запрещено или разрешено RLS. И к ролям это не имеет никакого отношения — если роль запретила, то RLS тут не поможет, потому как он сам привязан от роли как Подчиненный и Хозяин, если уж на то пошло, а не как вы написали «если роль запрещает…то RLS не покажет…». Тут нет вариантов.
Цитата
да и смысл писать ГДЕ Ложь, если достаточно снять галочку «Чтение»
это потому, что вы не знаете, для чего в RLS писать ГДЕ Ложь.
А сняв «чтение» в роли — вы запретите в принципе что-либо прочитать в данном объекте.
Цитата
… читайте книжку
читайте умные книжки.
Даже я , который не претендует на замещение умных книжек, скажу вам — роли разграничивают общий доступ на объекты, а RLS — лишь разграничивает то, что разрешено ролью.
Показать
забористая у вас травка
текст ограничения RLS как раз прописывается в ролях… понятное дело, что если снять галочку на чтение, то смысла от ограничения не будет…
если стоит галочка Чтение и без ограничения — это означает ПОЛНЫЕ ПРАВА НА ЧТЕНИЕ ОБЪЕКТА… Если написать «Где ЛОЖЬ» — это тоже самое ЧТО СНЯТЬ ГАЛОЧКУ, т.к. ограничение всегда будет возвращать ЛОЖЬ. И пишется это для того, чтобы у пользователя не было полных прав на объект если у него две роли, в одной наложено ограничение, и вторую нужно ему назначить,а в ней полные права на этот объект
для наложения ограничения запрос должен вернуть либо ИСТИНА либо ЛОЖЬ!
всегда возвращает ЛОЖЬ
(39) Наверно я таки не то курю. Мне непонятно.
Зачем давать бухгалтеру полный доступ к справочнику контрагенты — если тут же ему его запретить?! Вот это проясните. Я как бы понял про приоритеты и про то что если будет роль у которой РЛС дает больше доступа чем ГДЕ ЛОЖЬ — то пользователь таки что-то увидит.
Не понял я только одного — сначала бухгалтеру даем все права — а потом забираем. Зачем тогда давать права?! Вот этого я не пойму.
ведь если назначить только роль «Бухгалтер» — то он не прочитает из справочника ровным счетом ничего.
Вот я так понимаю — если я хочу Менеджеру огрничить доступ к контрагентам — я ставлю галочку на «Чтение» и пишу ограничение доступа, зачем этот изврат с «Где ЛОЖЬ» у бухгалтера?!
Если я сниму просто галочку на чтение у бухгалтера и поставлю обе роли «менеджер» и «бухгалтер» — то Вася Пупкин получит доступ к Контрагентам или нет? Ведь у него есть разрешающее право? Значит получит?
[/IS-QUOTE]ГДЕ Ложь использовать имеет смысл в случае комбинации ролей… использовать или не использовать эту конструкцию, уже каждый сам для себя определяет…
Объясняю на пальцах. Имеем две роли: Роль Бухгалтера и роль Менеджер. Имеем справочник, например «Контрагенты». У роли бухгалтер к нему полный доступ, нет ограничений, а для роли менеджера заданы ограничения, какие нибудь.
Берем пользователя «Вася Пупкин», ставим эти две роли в надежде, что для него будут работать ограничения. Но т.к. для роли бухгалтера определен полный доступ, то при наложении ролей роль бухгалтера для данного справочника будет приоритетнее, а значит, Вася Пупкин получит полный доступ к этому справочнику, без ограничений.
Но если написать в роли бухгалтера
перечитайте еще раз внимательно, что я написал
смысл, в наложении ролей… когда менеджеру устанавливаем роль бухгалтера… зачем? это уже другой вопрос
(45) В том то и дело, что мне для понимания нужно разобраться, и именно Ваши посты, я внимательно перечитывал, (только в них я заметил попытку объяснить).
Еще раз объясню как понимаю Ваши высказывания я.
Есть роль «Бухгалтер» у которого есть полный доступ к справочнику контрагенты. Но в то же самое время, у нее (роли) этот доступ отобрали, поставив ограничение «ГДЕ ЛОЖЬ» в РЛС. Это я верно понимаю?
Так же есть роль «Менеджер» у которой доступ к справочнику контрагенты ограничечен только для текущегоПользователя.
Роль «Бухгалтер» (исходя из постановки задачи) — не может использоваться самостоятельно и предназначена для комбинирования с другими ролями.
Если у роли «Бухгалтер» снять галочку «Чтение», и объединить ее с ролью Менеджер — получится чтот же набор прав и ограничений? или не тот же?
Я, читал ЖКК, там написано что если у одной из ролей доступ разрешен — значит он разрешен для пользователя которому эти роли назначены. Т.е. если у «Бухатера» запрет на чтение, а у «Менеджера» разрешено на чтение, но есть РЛС «ТекущийПользователь» — то менеджер будет иметь доступ к контрагентам и только к тем которые разрешены его же РЛС. Я правильно понял? Или я гдето ошибся?
(39) WKBAPKA,
Если вам удобно самому себе ставить подножки и потом показывать, с каим трудом их преодолеваете — то играйтесь. RLS назначается на одну роль.
с какого перепугу у бухгалтера, у которого полный доступ к документу, и нет никаких других ограничений, пропадет доступ к этому документу?
AlexO, в сообщении под номером 39 я привел пример, что значит ГДЕ ЛОЖЬ. Я подчеркнул, что если у бухгалтера, кроме роли Бухгалтера, не будет назначена еще одна роль, у которой есть разрешение на чтение справочника Контрагенты, то бухгалтер не будет иметь доступ к этому справочнику.
С какого перепуга? да с самого простого, у него всегда на чтение будет установлено ЛОЖЬ, т.к. мы такой ему шаблон наложили.
Для mvgfirst
Если мы накладываем шаблон для менеджера по какому то условию, по которому менеджер должен видеть только тех контрагентов для которых данное условие истинно, и подключаем менеджеру роль бухгалтера, у которой для данного справочника ограничения не наложены, т.е. полный доступ, согласно правилу приоритета всегда, менеджер получит полные права на чтение и будет видеть все элементы. Если же написать ГДЕ Ложь, в этом случае мы как бы закрываем доступ на чтение программным образом и будет срабатывать условие в шаблоне.
Возможно, пример с ролью бухгалтера не совсем удачный. В типовых ГДЕ Ложь можно найти в роли Пользователь.
(48) WKBAPKA,
Упрощу вопрос:
Правильно ли я понимаю что РЛС на чтение «ГДЕ ЛОЖЬ» для «Прочие поля» без установки других РЛС на чтение для конкретных полей — равноценна и абсолютно тождественна запрету на чтение (снятой галочки с права на чтение)?
Если правильно — то зачем это писать — если гораздо нагляднее и понятнее для посторонних именно отсутствие «галочки» на праве «чтение».
Хотя вот пока писал предыдущий пост, кажись до меня дошло: сняв «галочку» с «чтения» — нельзя поставить галочку «добавление» и «удаление». Таким образом используюя РЛС «ГДЕ ЛОЖЬ» — есть возможность предоставить право «добавлять», «изменять» и «удалять» — не предоставляя право «читать»
Хотя я это и понимаю, но я (возможно ввиду каких то ограничений своего сознания) не могу представить реально-применимую ситуацию когда со справочником можно манипулировать не видя результатов.
Это мне напомнило древний анекдот «Чукча не читатель — Чукча писатель» — т.е. писать могу, а прочитать то что написал уже не смогу.
Прошу объяснить мне, на реальной ситуации, где такое можно применить. Может кто может поделится реальной практической ситуацией где это ему пригодилось. Глядишь и я должен этим пользоваться а по незнанию теряю ценный опыт.
Такая конструкция (<Прочие поля объекта> — Объект ГДЕ ЛОЖЬ), как я понял, используется только в RLS-запросе и только при назначении доступа на чтение.
Т.е. если на какой-то объект (документ) нет прав ни на что, а запрос в конфе просит данные, то по этому документу система контроля доступа прав 1С выдаст запросу <объект не найден> (т.к. никаких прав на документ не установлено, окромя далее рассматриваемого RLS-запроса), что и будет получено в ТЧ или списке.
Тогда, чтобы обойти это, придумали в RLS эту конструкцию.
Ставим её на закрытый документ на право «чтение», и теперь при запросе:
система контроля прав 1С дает вместо ссылки — «не найдено» по этой записи -> получили, что Документ = Ложь (нет его, не существует для данного пользователя) -> а строки, где ссылка Ложь, RLS теперь разрешает на чтение -> выводится пустая запись вместо <объект не найден>.
Ставим еще и РАЗРЕШЕННЫЕ в запрос — теперь все записи, для которых RLS дал ЛОЖЬ, будут отсеиваться, и выводиться только те, для которых RLS дал ИСТИНА.
(51) WKBAPKA, Как то путано получилось у Вас (по крайней мере мне так кажется), но я вроде-как разобрался
По вашему мнению если снять галку на чтение — то вместо объекта в журналах, списках и полях ввода — будет выводиться «<Объект не найден>», а если галочку поставить и установить «ГДЕ ЛОЖЬ» — то будет что?! «пустая строка», белое поле?
Я сейчас зашел в УТ 10.3, создал роль у которой разрешил доступ к документу «Заказ покупателя» и на справочник контрагентов поставил «Где ЛОЖЬ» — затем зашел в 1С предприятие и открыл журнал заказов, в итоге я вижу что в графе «Контрагент» все равно выводится «<Объект не найден>»
На мисте, кстати в теме про «ГДЕ ЛОЖЬ» — тоже писали что разницы в этом случае не будет.
Вот… поэтому все еще прошу разъяснений от тех кто уже постиг эту истину — зачем в типовых используют РЛС «ГДЕ ЛОЖЬ»
В другой ветке, кстати иницированной WKBAPKA, нашел следующее пояснение:
Подумал, что в предыдущем тестовом примере, я что-то упустил и поэтому не получил нужного эффекта. Поэтому решил провести эксперимент на чистой базе
1. Создал пустую базу (создал роль с полными правами иначе не пускало в базу)
2. Добавил справочник «Товар» без реквизитов
3. Добавил документ «Заказ» с одним реквизитом шапки «Товар» с типом «Справочник.Товар»
4. Создал роль «Урезаный» в которой дал доступ на документ Заказ — полный (все галочки поставил), на справочник Товар поставил галочку «чтение» и добавил РЛС
5. Создал роль «ГдеЛожь» в которой поставил доступ на «чтение» и установил РЛС «ГДЕ ЛОЖЬ» у справочника Товар, других прав в эту роль не добавлял
6. Создал роль «БезПраваНаТовар» в которой предоставил доступ к документу Заказ полный а к товару вообще доступа не предоставлял
Под полными правами зашел и создал два элемента справочника «Товар1» и «Товар2» а так же два заказа «Заказ 1» с товаром 1 и заказ 2 с товаром 2
Перепробовал все комбинации совмещения ролей — всегда получал одинаковый результат.
Если пользователь совмещал или имел только одну роль с РЛС по наименованию — то он видел товар с наименованием «Товар1» и на других полях видел «Объект не найден….»
если же пользователь получал роль или «БезПрав» или «ГдеЛожь» — получался всегда одинаковый эффект, пользователь всегда видел надпись «объект ненайден»
Независимо от того было ли право на чтение установлено или вообще небыло прав.
Проведя этот эксперимент, я остался в недоумении — какова цель использования конструкции «ГДЕ ЛОЖЬ» если снятием галочки «чтение» достигаем тех же результатов
Возможно эксперимент мой был недостаточно полным, и именно упущенная мною часть эксперимента раскрывает суть использования этой конструкции — тогда прошу указать что было упущено
Ответ получен самостоятельно!
Действительно цитата «выловленая» в соседней ветке — отражает истину. И только она. Более того все прочие рассуждения на тему «<Объект не найден…>» только вносят сумятицу в умы новобранцев и искажают истину.
Для практического осмысления действия этого механизма в выше приведенном тестовом примере нужно всего лишь добавить право «просмотр», и вот тогда появляются различия, которые можно осознать.
Т.е. установив РЛС «ГДЕ ЛОЖЬ» неважно будет ли совмещена эта роль с другими или нет, Вы таким образом имеете возможность установить право «Просмотр» на этот справочник (или любой другой объект). Т.е. при попытке просмотреть список объектов Вы увидите сам список но не увидите записей. Без этого РЛС а именно с отключенным правом «чтение» — право «Просмотр» установить невозможно, а значит невозможно будет и открыть список (будет выскакивать предупреждение «Нет прав»)
С другой стороны, использовать роль в которой есть такой РЛС — саму по себе — бессмыслено, разве что только — это может быть применено дабы не пугать пользователя надписями «НЕТ ПРАВ» и взамен их показывать ожидаемое окно списка но просто пустое.
Как говорится: «Слава Богу, до меня наконец дошло!»
ой, сорри, не туда ответила… как это сообщение удалить?
Описание RLS находится на странице 117 Руководства разработчика (83.002.05), глава 5.5.4.8
На ИТС диске в разделе «1С:Предприятие 8. Документация», в теме Разработчикам -> Платформа, механизмы и технологии -> Методические рекомендации по конфигурированию -> Ограничение доступа на уровне записей и полей.
статья хорошая, только коротковата. Автору плюс. Кто хочет узнать получше РЛС, про это есть блок в продвинутом курсе Гилева.
(57) stas1kbob, пошлите куда-нибудь поточнее 🙂
(54) mvgfirst, как всегда, комментарии полезней самой публикации 🙂
Ставим для документа так:
<Прочие поля> | ГДЕ Ложь
Ссылка, ВерсияДанных, Номер, Дата
Тогда в запросах мы имеем право обращаться к полям «Ссылка», «Дата», но при открытии получим «У пользователя недостаточно прав ..»
Т.е. таким способом мы можем дать доступ к некоторым реквизитам объекта, которые используются в запросах.
Это очень актуально для партионного учёта, когда менеджер проводит, то система должна знать дату партиобразуещего документа для списания партии в расходе, но менеджер не должен иметь прав на документ-партию.
(60) WWWolfy, добрый день! Нашел ветку по RLS, увидел комменты знающих людей, хотел уточнить один момент.
Обнаружил только сегодня. Конфигурация УТ 10.3, нетиповая.
При отключенном RLS, если у пользователя в ролях, разрешающих доступ к документу, в ограничении доступа стоит ГДЕ Ложь, тогда:
1. В журнале документы контрагентов этот вид документа видно, но зайти в него нельзя, и при попытке зайти 1С предлагает завершить работу или перезапуститься.
2. Список этого вида документов пуст.
3. В структуре подчиненности этот вид документа не виден.
Стираем ГДЕ Ложь, работает так, как ожидалось.
Получается, что ГДЕ Ложь работает вне зависимости от включения RLS, или я в чего-то не знаю?..
P.S. Это называется «Конец дня» или «туплю». RLS всегда работает, если введено ограничение доступа. Соответственно все так и есть, только надо дать доступ на ссылку. Спасибо за внимание)
(0) Автор, верни мне деньги за билет!
(60) WWWolfy, проводить надо под полными правами и дело не только в том, что можно чего-то не прочитать, а в том, что никому не нужны тормоза от пришитого к запросу хвоста из условий RLS.
RLS встроено, и просто отключению не подлежит — правильно. можно ли отключить RLS какой-либо галкой на всех шаблонах
нашел отключается на вкладке администрирование- настройки пользователей и прав
Очень полезная дискуссия о правах и РЛС.
Плюсую за дискуссию. В споре рождается истина…
Тоже набрел на эту тему в надежде решить свой вопрос, но к сожалению не нашел ответа.
Настраиваю РЛС по табличной части документа Платежное поручение исходящее. Во всех примерах (и в конфигурациях и на сайтах) используется условие, в котором есть соединения вида ТекущаяТаблица.Ссылка = ТабличнаяЧастьДокумента.Ссылка
Показать
Вопрос: откуда берется Ссылка при добавлении нового документа?
Знаю, что проверка РЛС происходит между процедурами ПередЗаписью и ПриЗаписи модуля объекта, то Ссылка может существовать, но транзакция еще не завершена. Поэтому ограничения на добавления срабатывают.
А вот как быть при исправлении существующего документа? Какая ссылка будет браться в этом случае? Из практики работы существующего ограничения почему то берется старая ссылка, а не ссылка с новыми данными. Т.е. получается, что запрет сработает при попытке отредактировать запрещенные старые данные. Но в то же время позволяет разрешенные документы исправить так, что потом они становятся запрещенными. Такая логика работы РЛС?
(9)Статья очень полезная, благодаря ей не тратили время на эксперименты которые произвел автор.
Картинки к статье не загружаются