gifts2017

Простой доступ только для чтения [Запрет редактирования документов/справочников/регистров сведений/... ]

Опубликовал Александр Че (chmod660) в раздел Администрирование - Системное

Нужно предоставить кому-либо доступ к базе в режиме только-просмотр. Новый сотрудник на испытательном сроке, или же аудиторы-проверщики. Легкий способ решить эту проблему изложен ниже, с приложенной подсистемой.
Основные плюсы:
-  минимум доработки;
-  не требуется сопровождение (работает после обновления основной конфигурации поставщика);
-  позволяет для любого набора прав включить запрет редактирования.

Чтобы пользователь не мог не только редактировать документы, но и портить сознательно/несознательно наши справочники, нужно:

  1. создать пустую роль, не дающую доступ ни к какому элементу данных;
  2. создать три подписки на события перед записью: для всех Документов, Справочников, Регистров сведений;
  3. в обработчиках подписок анализировать доступность этой роли, и возвращать отказ, если роль доступна.

 

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

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

В прилагаемом файлике набор - роль, подписки и модуль. Вы можете объединить их со своей конфигурацией и безбоязненно даваь доступ только на просмотр всяким аналитикам и контролёрам.

Картинка показывает содержимое cf-файла.

 

Сама идея достаточно проста, и возможно, даже слишком для публикации на этом сайте. Однако, я сам некоторое время ходил другими путями - например, дата запрета редактирования, которая разрешает менять справочники, либо спецроль с указанием доступа к данным (её нужно постоянно актуализировать, и править типовые элементы конфигурации).

Этот путь считаю простым, а главное - разовым. После добавления документов/справочников/регистров, они всё так дже останутся недоступными для редактирования.

Скачать файлы

Наименование Файл Версия Размер
Конфигурация "read-only" 384
.cf 9,89Kb
15.08.12
384
.cf 9,89Kb Скачать

См. также

PowerTools от 1 000
Вознаграждение за ответ
Сумма: 0 $m
Добавили:
Александр Че (chmod660) (160.00 $m), Татьяна Шулдикова (taasha25) (48.00 $m)
Подписаться Добавить вознаграждение

Лучшие комментарии

99. Zigfridish (Bassgood) 15.08.12 16:26
(97) AlexO, а вы считаете, что применение RLS никакой нагрузки не создает? вы измеряли производительность системы при использовании RLS и подписок для решения одной и той же задачи? если нет, тогда смысла спорить о том, что из этих двух меньше всего нагружает систему - нет.
От RLS всячески отказываются, если можно обойтись без их применения более простыми способами (RLS используется для ограничения доступа на уровне ЗАПИСЕЙ, о каком применении RLS для запрета записи тут может идти речь вообще).
149. taasha25 (taasha25) 17.06.13 16:52
Еще раз спасибо!

Для нового пользователя в БП (Россия)нужно также в процедуру запрета изменения справочников добавить исключение для справочника ПОЛЬЗОВАТЕЛИ.

Если ТипЗнч(Источник)=ТипЗнч(Справочники.Пользователи.СоздатьЭлемент()) Тогда
Возврат;
КонецЕсли;

Остальные комментарии

0. Александр Че (chmod660) 31.07.12 18:05
Нужно предоставить кому-либо доступ к базе в режиме только-просмотр. Новый сотрудник на испытательном сроке, или же аудиторы-проверщики. Легкий способ решить эту проблему изложен ниже, с приложенной подсистемой.
Основные плюсы:
- минимум доработки;
- не требуется сопровождение (работает после обновления основной конфигурации поставщика);
- позволяет для любого набора прав включить запрет редактирования.

Перейти к публикации

1. Yaroslav (maddy) 31.07.12 19:26
Если бороться за минимализм (а т.к. подписка на ВСЕ изменения то стоит) можно писать еще короче
Отказ = РольДоступна("ro_...
2. Александр Че (chmod660) 31.07.12 19:55
(1) maddy, соглашусь.
когда-то замечал информацию, что написание цикла в одну строку и впрямь влияет на быстродействие в лучшую сторону.
3. Алексей Константинов (alexk-is) 31.07.12 20:16
4. Алексей 1 (AlX0id) 31.07.12 22:38
Однако, я сам некоторое время ходил другими путями - например, дата запрета редактирования, которая разрешает менять справочники, либо спецроль с указанием доступа к данным (её нужно постоянно актуализировать, и править типовые элементы конфигурации).

Ну таки можно подумать, что к новым объектам сами собой права доступа появятся.. Запреты - да, права - нет. Так что от актуализации не избавляет, к сожалению.

З.Ы. Хотя, если вы говорите именно о типовых ролях, то избавит, пожалуй..
5. Александр Капустин (kapustinag) 31.07.12 22:57
Хорошая мысль, попробую применить.
Для нас вопрос очень актуальный, т.к. действительно очень много контролеров и аудиторов из головной компании "набегами" ходят-бродят по базам дочерних. Попробуй тут защитись от случайного или неслучайного изменения данных.

Насчет (цитата) "... Для полноты картины еще можно создать подписки для констант, планов счетов, планов видов характеристик ..." - не согласен. Я имею в виду, что если стоит цель запретить все изменения, то ПВХ, планы счетов и т.п. объекты нужно защищать вообще в первую очередь, а не для полноты картины.

И еще один момент: пользователи, которым выдана эта запрещающая роль, должны иметь возможность формировать отчеты, сохранять свои настройки (и настройки пользователя, и настройки отчетов). Поэтому кое-что придется разрешить менять.
6. Александр Че (chmod660) 31.07.12 23:05
7. Александр Че (chmod660) 31.07.12 23:08
(4) AlX0id, добавляя новые метаданные, они появляются в полных правах, (ну, там где есть соответствующий признак, вернее) и разработчик сам закидывает еще куда считает нужным. Плюс такого способа в том, что о роли "Запрет редактирования" не нужно помнить.
8. Александр Че (chmod660) 31.07.12 23:57
(5) kapustinag, спасибо за отклик.
про ПВХ и план счетов - цель была дать не рыбу, но удочку. Теперь можно идею развивать, быстродействие тестить.

Про настройки - вы совершенно правы, и в УПП, например, приходится разрешать регистр "СохраненныеНастройки", иначе вываливается исключение (в ЦФ-файле это есть, и на скриншоте видно). Настройки пользователя - уже дело личное. Могу дополнить публикацию перечнем допустимых к записи регистров, по вашему усмотрению.
9. Алексей 1 (AlX0id) 01.08.12 00:22
(7) chmod660,
Я имел в виду не типовые роли, которые необходимо актуализировать после обновления в любом случае. Если Вы имеете в виду только типовые роли на поддержке - то да, все ОК.
10. Николай Зайцев (Zero_nv) 01.08.12 07:49
Ситуация как вижу знакома многим, и в типовых конфигурациях к сожалению нет штатной роли "Только для Чтения". Хочю предложить свой вариант решения данной проблемы: создать группу доступа "только для чтения" (хотя название роли не играет) и в эту группу помещаем всех кому доступ надо только для чтения. Потом штатными средствами ставим ДЗР очень далекую дату (например 31.12.2050).
Можно считать, что до 01.01.2051 года у этих пользователей установлены права только для чтения
11. Владимир Синяговский (vlasin) 01.08.12 09:21
(10) Zero_nv,
в публикации же написано
сам некоторое время ходил другими путями - например, дата запрета редактирования, которая разрешает менять справочники
12. Владимир Поздняков (Red_Devil) 01.08.12 09:25
Представляю как это все тормозить будет. Если на каждом элементе конфигурации висит подписка на событие...
13. Валентин Терёхин (Valet) 01.08.12 09:33
(12) Red_Devil, В типовых на каждом элементе висит по несколько подписок с более сложным кодом. Так что на общем фоне не заметно должно быть.
14. Александр Беляев (~gekK@~) 01.08.12 09:37
(2) chmod660, "написание цикла в одну строку и впрямь влияет на быстродействие в лучшую сторону."
Утверждалось даже, что написание всего кода в 1 строку быстрее отрабатывает чем с нормальным форматированием(встречались обработки превращающие код модулей в 1 строку)
15. Александр Че (chmod660) 01.08.12 09:41
(10) Zero_nv, как вам уже ответили, дата запрета не решает вопрос изменения справочников и настроек в регистрах сведений.

(12), (13) можно сделать замеры, выполнив перепроведение месяца-двух в УПП с такими добавками и без них.

(14) о, ну на такие жертвы я пойти не готов )
16. Михаил Ражиков (tango) 01.08.12 10:08
+: спасибо, а то я уж чуть было мизантропом ни стал с этим чудом:
http://forum.infostart.ru/forum24/topic66533/
17. Zigfridish (Bassgood) 01.08.12 11:43
Хочу сказать, что аналогичный подход (замена ролевой настройки прав на подписки на события) можно применять также для наложения запрета на такой набор прав для документов как проведение, отмена проведения, изменение проведенных и конечно же на проведение задним числом =)
Уже убедился в том, что когда дело касается разграничения прав, то в некоторых случаях лучше создавать подписки на события, нежели создавать новые роли и потом мучатся с их редактированием, и если требуется более гибкая настройка прав - то реализовать ее в конфигурации.
Nataliy_Abr; chmod660; +2 Ответить 1
18. Андрей Волин (kser87) 01.08.12 12:30
20. Александр Че (chmod660) 01.08.12 12:56
(17) Zigfridish, в принципе, можно нагородить более сложную систему.
например, создав регистр сведений, указывая в нем кому, какой именно доступ, и например, после скольки дней (если речь о документах) запрещать. Или отталкиваться от должности/группы/профиля.
Развивать есть куда, в случае необходимости. Будет сильнее тормозить, но другого выхода зачастую нет.

Главный плюс - прикручивается к типовым без правки поставляемых объектов, и свою задачу выполняет.
Я лично долго боролся с тем, что любой пользователь УПП может править контрагентов, и никак настройкой ролей в режиме предприятия это не побороть.
21. Andrey SAP (Shapat) 01.08.12 13:37
Простой доступ только для чтения настроить ролей
22. Александр Че (chmod660) 01.08.12 14:02
(21) благодарю вас за комментарий
23. Альтаир (Altair777) 01.08.12 15:20
(20) chmod660,

> Развивать есть куда, в случае необходимости
Мне кажется, что такое уже есть - не раз тут натыкался. Вот, к примеру

http://infostart.ru/public/21821/
24. Александр Че (chmod660) 01.08.12 16:18
(23) Altair777, ваша ссылка наверное про другое....
25. Альтаир (Altair777) 01.08.12 17:04
(24) chmod660, возможно. Кажется, это только анализ и раздача ролей.
Но целые подсистемы доступа к данным тут тоже есть.
26. qwe qwerty (quebracho) 01.08.12 17:52
Плюс за тему, и за ник отдельно:)
27. kiril lipatov (kilokilo) 01.08.12 18:00
создать пустую роль, не дающую доступ ни к какому элементу данных;

.. плохо сформулировали, как будто речь идет о доступе на чтение
28. Александр Че (chmod660) 01.08.12 18:05
(27) kilokilo, э.....
я именно имел ввиду, что пустая роль не должна давать никакого доступа на чтение........
29. kiril lipatov (kilokilo) 01.08.12 23:18
/.. Нужно предоставить кому-либо доступ к базе в режиме только-просмотр..

я именно имел ввиду, что пустая роль не должна давать никакого доступа на чтение........
(28) chmod660,

Может, все таки, на запись / сохранение?
30. Александр Че (chmod660) 02.08.12 00:22
(29) kilokilo, нет, всё-таки на чтение.

позвольте дать вам развернутый ответ.
создаваемая роль не содержит никаких разрешений НИ НА КАКИЕ метаданные. проще говоря, все "галочки" внутри этой роли - отключены. Потому что в типовых конфигурациях - например, УПП, УТ (допускаю, что и в других), если вы назначите пользователю только одну созданную вами роль (неважно с какими разрешениями) - он всё равно не сможет ВОЙТИ в систему. Банально, без роли "Пользователь" вы не войдете в УПП без правки оной конфигурации в двух (или трех) точках.
Поэтому вы даете пользователю доступ на чтение метаданных при помощи любых других имеющихся ролей (стандартных и самописных), а эта роль "ТолькоПросмотр" интересна нам только фактом - назначена она пользователю или нет. Назначена - не сможет ничего записать. Но никаких разрешений она содержать не должна.
31. Regina Kucherova (AuroraNorilsk) 02.08.12 07:10
Отличный способ. Автор молодец.

Кстати, на мой взгляд, в случае когда необходимо ограничивать доступ не ко всем объектам одного вида, а по каждому объекту отдельно, есть альтернатива создаваемым ролям.

Вместо ролей можно использовать настройки пользователей (в режиме 1С:Предприятие) и, тем самым, избежать необходимости каждый раз при добавлении нового объекта добавлять новую роль и обновлять конфигурацию.
Т.е., например, для БП 2.0, в ПВХ "Настройки пользователей" создаем для удобства отдельную(ые) группу(ы), внутри которой(ых) будут располагаться наши настройки (тип значения настроек - булево). И далее через справочник "Пользователи" или непосредственно в регистре сведений "Настройки пользователей" устанавливать доступы.
Ну и, соответственно, в подписках на событие проверку делать не на доступность роли, а на доступность настройки. Причем можно постараться сделать код в обработчике подписки на событие универсальным. Таким образом, достаточно всего лишь добавить одну-две (количество зависит от видов источников) подписки на событие (в качестве источника можно указать составной тип данных), а в обработчике, в зависимости от установленных пользователю настроек, определять тип источника и ограничивать доступ.
К тому же, для анализа подобных ограничений доступа к объектам конфигурации, можно будет легко составить отчет с использованием всего лишь одного запроса (из регистра сведений "Настройки пользователей").

Возможно, что вы увидите в предлагаемом мною методе недостатки. Будет интересно выслушать критику.
32. kiril lipatov (kilokilo) 02.08.12 09:14
позвольте дать вам развернутый ответ.
создаваемая роль не содержит никаких разрешений НИ НА КАКИЕ метаданные. проще говоря, все "галочки" внутри этой роли - отключены. Потому что в типовых конфигурациях - например, УПП, УТ (допускаю, что и в других), если вы назначите пользователю только одну созданную вами роль (неважно с какими разрешениями) - он всё равно не сможет ВОЙТИ в систему. Банально, без роли "Пользователь" вы не войдете в УПП без правки оной конфигурации в двух (или трех) точках.
Поэтому вы даете пользователю доступ на чтение метаданных при помощи любых других имеющихся ролей (стандартных и самописных), а эта роль "ТолькоПросмотр" интересна нам только фактом - назначена она пользователю или нет. Назначена - не сможет ничего записать. Но никаких разрешений она содержать не должна.
(30) chmod660,
большое спасибо
33. Владимир Синяговский (vlasin) 02.08.12 11:14
(30) chmod660,
никак не пойму принципиальность условия "никаких разрешений она содержать не должна".
Наличие этой роли и есть флаг - что в ней отмечено уже не важно, разве нет?
34. Александр Че (chmod660) 02.08.12 11:58
(33) vlasin, это не жесткое требование, а разумная настойчивая рекомендация.

Вы правы, в рамках рассматриваемой системы - неактуально, и флагом есть наличие самой роли. Однако если вы с её помощью разрешите пользователю что-то, что он видеть не должен, это будет неверно методически. Например, вы создаете пользователя с ролью "Мастер смены" и, ставя, ему роль "Запрет редактирования" - даете доступ, например, к кассе и зарплате. И юзер видит то, что не должен. Спрашивается - зачем? Вот поэтому я и пишу, что роль не должна содержать разрешений. Ибо плюсов тут точно никаких, а потенциальных минусов, ям и неочевидных причин для скандала - есть.
35. DZENN (Dzenn) 02.08.12 14:46
Реализацию не скачивал, но идея годная, хорошая и правильная.
36. Александр Че (chmod660) 02.08.12 15:05
(35) DZENN, спасибо!
реализацию видно по картинке, три подписки и три процедурки наваять уже несложно, если ухватил суть. Но может кому и ЦФник пригодится, для пущей ясности. Ну и чтобы видно было, что это не теория, а вполне рабочий механизм.
37. Алекс Ю (AlexO) 02.08.12 15:23
(2) chmod660,
автор, вы не догадались, что можно просто создать роль копированием с "Пользователь" и скопом одним движением (ну ладно - двумя) снять галочки со всех документов и справочников?
Еще одна стаья "ба, а в 1с можно справку по F1 вызывать!"
когда-то замечал информацию, что написание цикла в одну строку и впрямь влияет на быстродействие в лучшую сторону.

только у тру-1сников. Если ты не тру-1сник - это наоборот, будет тормозить выполнение кода в десятки раз!
38. Zigfridish (Bassgood) 02.08.12 15:26
(31) AuroraNorilsk, тогда уж не регистр "Настройки пользователей", а регистр "Значения дополнительных прав пользователей", а то получится, что пользователь через свои настройки сам будет определять можно ему редактировать данные или нет.
39. Алекс Ю (AlexO) 02.08.12 15:35
(38) Zigfridish,
ребята, не доведет вас до добра такое отношение к 1с в частности и к работе в общем.
40. Александр Че (chmod660) 02.08.12 15:45
(37) AlexO, вы не "вкурили" главного - программист должен сперва автоматизировать собственную деятельность. Мой способ - решение с максимальной эффективностью и высокой сопровождаемостью. А у вашего способа навскидку недостатки:

1. предложенный вам способ еще требует правки кода, ибо войти может только тот, у кого роль называется именно "Пользователь".
2. После добавления метаданных нужно не забыть еще проставить доступ на чтение у этой вашей роли "Пользователь2"
3. после обновления типовой конфы вам, вероятно, придется снова создавать копированием новую роль и снимать двумя махами с неё галочки.

такие кустарные способы не для меня, спасибо. если вы не видите преимуществ или они вам не важны - спасибо, что ознакомили нас со своим мнением, приходите еще.
Krio2; zqzq; Brawler; +3 Ответить 1
41. Александр Че (chmod660) 02.08.12 15:58
(31), (38)
а еще лучше не использовать типовой регистр, а сделать свой. Чем меньше правок в типовой, тем проще обновляться...
42. Zigfridish (Bassgood) 02.08.12 16:12
(41) chmod660, Править сам регистр не придется, просто использовать его для хранения значения доп. права на изменение данных наряду со значениями других типовых доп. прав (в ПВХ "Права пользователей" в режиме предприятия добавить свое новое право).
43. Zigfridish (Bassgood) 02.08.12 16:13
(39) AlexO, а чем по-вашему лучше добавление новой роли от добавления подписки на события?
44. Александр Че (chmod660) 02.08.12 16:16
(42) Zigfridish, а потом 1С решат что-то в этом регистре убрать или вовсе от него откажутся, и вам придется переделывать. Маловероятно, пожалуй. Но мне было бы спокойнее со своим регистром.

(43) позвольте, я отвечу. подписка отразится на быстродействии, но насколько критично, как уже ранее писали в комментариях, будет это влияние? В типовых и вправду более громоздкие подписки на все регистры.
45. Алекс Ю (AlexO) 02.08.12 16:35
Простой доступ только для чтения
http://forum.infostart.ru/forum24/topic67178/

(40) chmod660,
предложенный вам способ еще требует правки кода

создать пустую роль, не дающую доступ ни к какому элементу данных;

т.е. вы не знаете, что тоже правите конфигурацию в своем случае?
у кого роль называется именно "Пользователь"

как роль "Пользователь" связана с другими ролями?
После добавления метаданных нужно не забыть еще проставить доступ на чтение у этой вашей роли "Пользователь2"

После добавления нового объекта в старой роли вообще не будет никаких галочек. Ни на чтение, ни на полный доступ (если не поставлена галочка в роли "Устанавливать права для новых объектов".
создать три подписки на события перед записью: для всех Документов, Справочников, Регистров сведений;

и как потом разберетесь, где и когда выполняется подписка "для всех документов", а где - только та, которая понадобится для конкретного по обработке события ПередЗаписью?
в обработчиках подписок анализировать доступность этой роли, и возвращать отказ, если роль доступна.

в типовых давно уже есть роли, соответствующие "только чтение на все".
Другое дело - что вам все равно понадобится тонкая поднастройка, а не просто "все запретить" или "все разрешить".
Такого не бывает.
46. Алекс Ю (AlexO) 02.08.12 16:36
(43) Zigfridish,
лучше используйте типовое все.
а чем по-вашему лучше добавление новой роли

это вы их противопоставляете, и юзаете проверки ролей в подписках :)
47. Александр Че (chmod660) 02.08.12 16:48
(45) AlexO,
1. я правлю конфигурацию, добавляя свои объекты. что позволяет автоматически (или с минимумом хлопот) обновлять типовые элементы, входящие в поставку.

2.
как роль "Пользователь" связана с другими ролями?

отвечаю (УПП)

// перед началом работы системы
Процедура ПередНачаломРаботыСистемы(Отказ)
	Если НЕ РольДоступна("Пользователь")
		Предупреждение("Вам не назначена роль ""Пользователь"". Запуск конфигурации невозможен.");
		Отказ = Истина;
		Возврат;
	КонецЕсли;
	Отказ = НЕ УправлениеПользователями.ПользовательОпределен();
КонецПроцедуры
...Показать Скрыть


3.
После добавления нового объекта в старой роли вообще не будет никаких галочек.

вот именно. и, таким образом, задача "дать пользователю доступ только на просмотр" не выполнится, поскольку он не сможет просмотреть эти данные.

4.
и как потом разберетесь, где и когда выполняется подписка "для всех документов"

вы не поверите, с помощью Конфигуратора.

5.
, а не просто "все запретить" или "все разрешить"

такое бывает. более того, на моей памяти такое уже бывало больше одного раза.
48. Алекс Ю (AlexO) 02.08.12 16:57
(47) chmod660,
вы не поверите, с помощью Конфигуратора.

ну да, ну да...
вам отдельно от 1с сделали в конфигураторе менеджер Подписок :)
PS/
А, щас опять студенты налетят! Инструмент "Управление подписками". А то груды "знаний" не оберешься потом...
такое бывает. более того, на моей памяти такое уже бывало больше одного раза.

вот именно поэтому за вас уже хотя бы это - сделано.
49. Александр Че (chmod660) 02.08.12 17:25
(48) AlexO, не понимаю, в чем проблема отладки подписок. У нас с вами наверное, два разных конфиругатора. Просветите общественность, что в вашем не так?

вот именно поэтому за вас уже хотя бы это - сделано

в конфигурациях, с которыми я работаю - этого нет.
50. Алекс Ю (AlexO) 02.08.12 17:33
(49) chmod660,
в моем и в Конфигураторе 1С, в отличие от вашего - нет жесткого понятия последовательности выполнения подписок. А также какого-либо контроля за ними, окромя визуально лезть туда.
Просветите общественность

Общественность студентов - да, не в курсе. остальные - в курсе.
51. Александр Че (chmod660) 02.08.12 17:45
(50) AlexO, не понимаю, как последовательность подписок влияет на тему данной публикации.

последовательность вызова подписок - да, проблема есть. в контексте освещаемого вопроса - несущественна. не стоит обсуждать проблемы мироздание, когда нужно решать простую задачу.

Общественность студентов не понимает представителей академиков, высказывающихся иносказательно, да еще о не касающихся темы проблемах.
52. Алекс Ю (AlexO) 02.08.12 18:18
(51) chmod660,
не понимаю, как последовательность подписок влияет на тему данной публикации

хоть вопрос и с подковыкой, но коммунисты не боятся говорить прямо и открыто о своих твердых убеждениях, посему отвечаю:
подписок ПередЗаписью может быть несколько на данный документ/справочник.
53. Александр Че (chmod660) 02.08.12 18:27
(52) AlexO, из уважения к вашему возрасту, я буду писать помедленнее.

Тезисы:
1. тема публикации: "Простой доступ только для чтения"
2. задача решается подпиской, которая может запретить или не запретить доступ.
3. последовательность подписок неизвестна, их может быть >1
4. они все отработают, в неизвестном нам порядке.
5. наша подписка, описанная в публикации, определит, нужно запрещать запись или нет.
6. поставленная цель будет достигнута.

внимание, задача: что должен ответить истинный коммунист, на прямой, как палка Ильича, вопрос:
как последовательность подписок влияет на тему данной публикации?
54. Zigfridish (Bassgood) 02.08.12 18:36
(46) AlexO, я вообще (как и (31)) предложил использовать только подписку на события без добавления новой роли, вместо нее использовать типовой механизм дополнительных прав пользователей. Понятное дело, что лучше использовать все типовое, но не всегда же этим типовым можно обойтись.
(50) AlexO, где-то читал, что подписки выполняются в той последовательности, в которой они расположены в метаданных, но лично не проверял. И я не совсем понял какая разница какой по счету будет вызвано событие "Перед записью" из нашей подписки - самой первой из всех или же самой последней, на что это принципиально может повлиять?
55. Regina Kucherova (AuroraNorilsk) 03.08.12 05:13
(38) Zigfridish, я привела пример конкретно для конфигурации БП 2.0. Там нет регистра "Значения дополнительных прав пользователей".
56. Regina Kucherova (AuroraNorilsk) 03.08.12 05:55
И да, я соглашусь с (41) chmod660, что в таком случае лучше всего использовать всё-таки свой регистр. Метод будет намного универсальнее и не будет зависеть от той или иной типовой/нетиповой конфигурации.
57. Алексей Фурманов (Aleksey-29) 03.08.12 08:46
(31), у себя реализовал так же для согласования заказов покупателей экономическим отделом. Но только использовал доп. настройки пользователя
58. Алексей Заболотнов (z-alexey) 03.08.12 10:10
А мне кажется не взлетит. Пример: добавляем нового юзера в конфигураторе. Он заходит первый раз в программу. 1С пытается создать новый элемент в справочнике "Пользователи" - а подписка говорит: низя. И пользователь отваливается :)
Конечно можно зарегить его ручками, но это другая история )
59. Алекс Ю (AlexO) 03.08.12 10:27
(53) chmod660,
как последовательность подписок влияет на тему данной публикации?

так, что с подписками не все ясно
3. последовательность подписок неизвестна, их может быть >1

так еще и загромождение идет - что откуда, где проверяется? Догадайся сам, или позвони предыдущему программисту.
(54) Zigfridish,
где-то читал, что подписки выполняются в той последовательности, в которой они расположены в метаданных

это только догадки, которые не подтверждены опытным путем: вроде так принято считать, но не всегда так работает, а схема работы подписок до сих не ясна и не освещена 1С.
(56) AuroraNorilsk,
что в таком случае лучше всего использовать всё-таки свой регистр

да давайте уж сразу два - один запасной.
(58) z-alexey,
а подписка говорит: низя

это только один из примеров некорректной отработки "неучтенного условия".
60. Алекс Ю (AlexO) 03.08.12 10:29
(53) chmod660,
на прямой, как палка Ильича

что за палка Ильича?
(товарищи и боевые друзья собрались в кружок и приготовились конспектировать)
61. Regina Kucherova (AuroraNorilsk) 03.08.12 10:50
(59) AlexO, ну зачем же запасной ) у меня и своего то нет ) использую типовой.
62. Максим Шафранюк (ClockMaster) 03.08.12 12:49
Идея простая и в этом ее минус, требует доработки, например настройки пользователей нельзя записать, если на пример в БП назначить Роль Бухгалтер и Запрет редактирования. Пользователь из базы сразу же вываливается
63. Алекс Ю (AlexO) 03.08.12 13:02
(62) ClockMaster,
Идея простая и в этом ее минус

минус идеи не в том, что она простая, а в том, что она не проработана, а автор мало знаком со спецификой программирования 1с.
64. Александр Че (chmod660) 03.08.12 13:38
(58) z-alexey,
Пример: добавляем нового юзера в конфигураторе.

1. одинэс советует заводить юзеров из предприятия.
2. создайте сперва без ограничения, зайдите под ним сами, выйдите и верните ограничения.


(59) AlexO, учтите все условия, и будет вам щастье. Или давайте я учту, если вы готовы платить деньги ))

(62) ClockMaster, загляните или в прилагаемый ЦФ-ник, или хоть в картинку. В коде есть пример, как некоторые, определенные программистом регистры можно разрешить редактировать. Я не считаю, что ридонли-юзер может сохранять свои настройки. Думаете иначе - никто ж не мешает докодить. Идея проста - и в этом её плюс. Пример прост - ну чтож, я не продаю подситему, берите и совершенствуйте.

(63) AlexO, и идея, и реализация чудесно выполняют поставленную задачу. Она проработана ровно настолько, насколько мне нужно. Я не заставляю вас внедрять, страдайте дальше с ролями. В интересы автора не входит обсуждать в комментариях к этой статье трудности отладки либо другие недостатки конфигуратора. Замечаниям по существу всегда рад, но отвечаю даже на бестолковые.



ЗЫ:
(59)
Догадайся сам, или позвони предыдущему программисту.

нормальные люди пишут комментарии. почитайте на досуге, что это и зачем используется. Возможно, вам пригодится.
65. Влад Шнурков (vladshnurkoff) 03.08.12 16:43
chmod660, как говорят китайцы - "НиСы"! Описанный алгоритм реализуется за 10 минут со 100%-ным положительным результатом и полностью удовлетворяет условию поставленной задачи. Кто-то более простое может предложить? За идею плюс конечно же.
66. Zigfridish (Bassgood) 03.08.12 17:46
(59) AlexO,
так еще и загромождение идет - что откуда, где проверяется? Догадайся сам, или позвони предыдущему программисту.

Я хотел бы спросить, а как Вы поступаете допустим в таких случаях, когда требуется доработать документ так, чтобы он начал двигать какие-то ваши регистры? Вы весь свой алгоритм проведения дописываете в модуль документа или же все таки используете для таких случаев подписку на события? Что Вы предпочтете - менее трудоемкие последующие обновления конфигурации, посредством использования подписки на событие, которая вызывается непонятным образом, или же геморрой при обновлении с четким знанием в какой момент будет исполняется ваш алгоритм проведения?
67. Александр Че (chmod660) 03.08.12 19:00
(65) vladshnurkoff, спасибо, целиком с вами согласен.
68. Константин Матвеев (koka) 04.08.12 16:26
Оригинально и просто. Однозначно плюс.
69. Игорь Фелькер (Brawler) 04.08.12 16:50
Уже давно сам придумал такой же вариант ограничения на редактирование справочников, но пока не реализовывал ибо все важные справочники типа статей затрат, прочих доходов и расходов.... еще не отработаны бухами до конца в силу не понимания начерта эти справочники нужны и что влечет за собой их изменение. Про контрагентов, договорах... молчу, срача дочерта.

По поводу последовательностей там отработки событий подписки. Ну может я плохо знаю 1С, но кажется запись идет одной транзакцией минимум и даже, если чего и успеют записать другие обработчики, все должно откатиться, если хотя бы один из обработчиков сделает так "Отказ = Истина;"
70. Наталья Литвин (НатальяАлекс) 06.08.12 13:40
(5) kapustinag, А в чем состоит отличие от установки даты запрета по конкретной организации или пользователю? Не пойму в чем оригинальность данного метода?
71. Александр Че (chmod660) 06.08.12 14:11
(70) НатальяАлекс, читайте внимательно.
этот метод запрещает редактировать справочники + регистры сведений + что угодно, дата запрета - только документы.
72. Наталья Литвин (НатальяАлекс) 06.08.12 14:42
О_о! Прошу прощения, я действительно, невнимательно читала... Идея очень неплоха!
73. Ксения (mamba) 07.08.12 16:57
74. Роман (Raminus) 08.08.12 16:58
задумка интересная, посмотрим, плюсик авансом!
75. shage (DrSender) 09.08.12 10:25
Плюс! Надо использовать-буду разделять доступ по дате для разных видов документов.
76. Андрей Моисеев (nihfalck) 09.08.12 13:01
прекрасный способ. как говорится - все гениальное просто :)
спасибо за идею.
77. Олег Владимирович (olezhe) 09.08.12 13:14
Поставил плюс. Как раз в конторе подняли тему прав с запретом редактирования.

А ещё бывает, надо разграничить права: кадрам одно, приказчикам другое. Наверное, можно эту же идею и тут как-то приспособить...
78. olga pt (pt_olga) 09.08.12 14:47
интересная идея... но что-то мне в ней не нравится, но пока сформулировать четко не могу)))
потестирую и может найду грабли, которые пока только на интуитивном уровне

автору в любом случае спасибо и плюс :)
79. Александр Че (chmod660) 09.08.12 15:08
(72), (73), (74), (75), (76), (77) - очень приятно, спасибо.

(78) - если вы после нахождения граблей, поделитесь вашими результатами тут - то вам будет еще большее спасибо и от автора, и от всех плюсующих )
80. Андрей (andru_dv) 12.08.12 22:44
Хорошая идея, попробуем внедрить на тестовой базе УТ, насчет граблей отпишусь позже.
Продукт скорее всего потребует шлифовки, подгонки и т.д.
81. mosAdm (mosAdm) 15.08.12 10:14
(0) Читаю статью, читаю комментарии и понять не могу А ЗАЧЕМ????????

Зачем писать код? Зачем создавать подписки на события? Зачем эта статья?

Всё заканчивается на первом пункте "Создаем роль" и даем доступ к объектам конфигурации "Только чтение" И ВСЕ!!!
Прикрепленные файлы:
82. Александр Че (chmod660) 15.08.12 10:52
(81) mosAdm, вы читаете невнимательно.
Если, как вы утверждаете, "И ВСЕ!!!!", тогда назначьте в УПП (например) ТОЛЬКО эту роль любому существуюшему пользователю и попробуйте войти в базу - вы не сможете. Если же вы еще добавите роль "Пользователь" - как того требует УПП без доработки - то до лампочки (если не глубже) становятся ваши права на чтение справочников, т.к. "Пользователь" может редактировать, например, контрагентов и номенклатуру..
это раз.

два - и это описано в статье - при добавлении новых метаданных, вам придется поддерживать актуальность вашей роли вручную - добавлять в неё новые метаданные.

и три - с вашим способом, если есть задача обеспечить доступ на только просмотр не на всю базу, а с правами Кассир - нужно создавать роль. С правами Экономист - нужно вторую. С правами Мастер смены - создавать третью, и так далее. (и все эти роли поддерживать). С моим методом вы даете нужный набор прав, и отмечаете единственной ролью, что доступ "только просмотр". всё.
zqzq; compreSSor; Ioryk; vladir; Redokov; +5 Ответить 2
83. Александр Че (chmod660) 15.08.12 10:55
я, пожалуй, в последний раз повторял в комментариях то, что написано в статье.
если программист не может понять "зачем", или "чем отличается", или ему просто не нравится - оставляю таковых при собственном мнении.
84. mosAdm (mosAdm) 15.08.12 11:16
(0),(82) - войдешь не войдешь в УПП, УТ или БП и пр.- вопросы не по теме статьи. Коротко - войдешь без подписок на события.
Поддержка 1-й роли при обновлении при добавлении метаданных не составляет проблем, не раздувайте слона из мышки.

С моей колокольни путь предложенный в статье не оптимальный для заявленной темы статьи.

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

ЗЫ
в УПП "пробую добавлять", а работаю больше 7-ми лет.
85. mosAdm (mosAdm) 15.08.12 11:18
(83) а обижаться не стоит, тут выше все хвалят, "молодец" говорят.
86. Алекс Ю (AlexO) 15.08.12 11:58
(66) Zigfridish,
или же все таки используете для таких случаев подписку на события?

ну установите подписку при обновлении формы документа.
А то книжек начитаются, а в конфигуратор никто и не лазил.
с четким знанием в какой момент будет исполняется ваш алгоритм проведения?

о да, особенно - при нагромождлении подписок на один объект.
Книжку закройте, и начните конфигуратором пользоваться. Многие глупости отпадут сами собой.
(64) chmod660,
страдайте дальше с ролями

т.е. вы таким образом измазали какашками весь механизм ролей в 1С? :)
87. mosAdm (mosAdm) 15.08.12 12:11
(82) Я извиняюсь, но третий аргумент

> и три - с вашим способом, если есть задача обеспечить доступ на только просмотр не на всю базу

никак не сработает, в силу того, что заявлено в статье:

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

т.е. объединение с другими ролями тоже ничего не даст.
88. Александр Че (chmod660) 15.08.12 12:22
(84) mosAdm,
войдешь не войдешь в УПП, УТ или БП и пр.- вопросы не по теме статьи.

или вы не в теме (тогда не вводите в заблуждение юзеров) , или у нас с вами разное УПП.
почитайте (47), я там отвечал на такой вопрос.

путь предложенный в статье не оптимальный для заявленной темы статьи.

согласен, изменить название нужно, я подумаю, как.

(85) какие обиды, надоело просто.
(87) из этого сообщения лично я никак не понял, что же вы пытались сообщить. третий аргумент работает, но ваши доводы в тумане.
89. Александр Че (chmod660) 15.08.12 12:32
(86) AlexO,
ну установите подписку при обновлении формы документа.

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

отдельное спасибо за диагностику, кто что чем измазал, никто даже не сомневается в вашей высокой компетенции в этом вопросе.
90. mosAdm (mosAdm) 15.08.12 13:06
(88)

1. Речь не идет о пользователях (юзерах), статья для них?

2. УПП может и разное, но в (47) есть замечательная процедура " Если НЕ РольДоступна("Пользователь")" - ни о чем не говорит?
а если продолжить так например " Если НЕ РольДоступна("Пользователь") Или НЕ РольДоступна("ИмяВашейРоли")" и в этом случае вход будет не возможен?

3.Не оптимальный путь это не только название статьи, но и методика. Создать два объекта конфигурации и код к нему писать. Фууууууууу. Все делается одним объектом и без кода. Опять зачем тратить дополнительные ресурсы? В предложенной методике, сначала система проверит набор прав потом даст отлуп на запись.


4.Вы противоречите себе сами. Либо пользователю запрещено записывать объекты (Отказ объекта при записи) и как не объединяй роли все-равно получишь ОТКАЗ. Либо код подписки на событие придется поправлять. А?

ЗЫ
Не в качестве рекламы, но на эту тему есть более актуальная статья http://infostart.ru/public/147074/
в которой более правильный подход реализован через регистр сведений.

Я всё сказал.
91. Александр Че (chmod660) 15.08.12 13:46
(90) mosAdm,
я долго думал.
но мне нечего возразить человеку, который в качестве более правильного подхода советует мне посмотреть статью, в которой мой же подход используется.
у нас с вами не только УПП разное, но и логика. рад, что вы сказали всё, и больше вы ничем меня удивите.
92. mosAdm (mosAdm) 15.08.12 14:04
(90 не это просто слишком большое самомнение называть "своим подходом" использование подписки на событие и процедуры "при записи".
93. Александр Че (chmod660) 15.08.12 15:00
(92) mosAdm, вначале, в (81) вы писали, что нужно только роль создать -
"И ВСЕ!!!"

однако вам указали, что не всё - что еще придется модуль приложения править. и тогда обновлять конфигурацию поставщика, постоянно помня об этом изменении. да еще и новые метаданные в роли закидывать. Особенно, если таких ролей-просмотров горе-программист насоздавал несколько. Мне неизвестна логика, при которой сделать раз и навсегда (добавить пописки и 5 строк кода) сложнее, чем постоянно проставлять галочки.

Когда вы в (84) пишете, что
А вот третий пункт в статье не обозначен никак
, это говорит о том, что статью вы читали по диагонали, этот момент отмечен - я пишу про экономиста-толькоПросмотр, кассира-толькоПросмотр и так далее.

вы обвиняете меня в противоречии, однако же это тоже от непонимания того, о чем идет речь. извините, но более простых слов я уже не могу найти. Равно как и "своим подходом" я называю реализацию запрета редактирования. Жаль, что это тоже вам непонятно.
94. Zigfridish (Bassgood) 15.08.12 15:25
(86) AlexO,
ну установите подписку при обновлении формы документа.

Лично я такой подписки на событие ни в книжках, ни в конфигураторе не встречал... советую вам все же почитать книжки, перед тем как лазить в конфигураторе и писать подобные глупости.
И Вы так и не дали нормальный вменяемый ответ на вопрос, а только лишь вырвали пару фраз из его контекста. Видимо подписки придумали и используют только недалекие люди (ох уж и дураки эти разработчики платформы и типовых конфигураций), к которым видимо вы не относитесь (или только так считаете).
о да, особенно - при нагромождлении подписок на один объект.

Ну создать несколько подписок на одно событие одного объекта догадаетесь наверное только вы и потом писать здесь как же сложно понять где исполняется код при вызове этого события, видимо для таких целей вы так и не научились должным образом пользоваться отладчиком...
Допиливайте и дальше процедуры событий объектов непосредственно в их модулях и удачи в обновлениях конфигурации (а также всем последующим программистам, к которым перейдет это добро), я уже понял, что для вас процесс обновления представляется очень интересным и занятным делом.
95. Алекс Ю (AlexO) 15.08.12 15:32
(89) chmod660,
ну установите роль на обновление формы документа

т.е. вы даже книжек не читали, раз такое пишите? ))
Обоснуйте, как вам в голову пришла мысль обновлять форму строго по определенной роли. А у остальных не обновлять, пусть старую версию видят.
Мне просто интересно, поможет вам знакомство с линухом (на что вы усиленно намекаете) и недавняя учеба в институте обосновать свои мысли, или вы стандартный россиянский студент.
(90) mosAdm,
Либо пользователю запрещено записывать объекты (Отказ объекта при записи)

он одного не может понять - либо Пользователь запрещена запись, либо - есть штатные средства RLS запрета не только конкретному пользователю, а разруливание по Контрагентам, Складам и прочее по всем пользователям.
Что опять же - никакого кода.
96. Zigfridish (Bassgood) 15.08.12 15:41
(95) AlexO,
он одного не может понять - либо Пользователь запрещена запись, либо - есть штатные средства RLS запрета не только конкретному пользователю, а разруливание по Контрагентам, Складам и прочее по всем пользователям.

Ага, давайте теперь еще и RLS воспользуемся только ради того, чтобы запретить пользователю записывать данные =)
97. Алекс Ю (AlexO) 15.08.12 15:44
(96) Zigfridish,
Ага, давайте теперь еще и RLS воспользуемся

а вы считаете, что проверка везде и всюду минимум трех подписок - совсем никакой нагрузки не создает?
98. Александр Че (chmod660) 15.08.12 16:06
(95) АлеxО,
Обоснуйте, как вам в голову пришла мысль обновлять форму строго по определенной роли

точно так же, как вам пришла в голову мысль установить подписку на обновление формы.
я считал вас достаточно умным собеседником, чтобы указывать на сарказм в моей фразе. всегда неприятно ошибаться, но в дальнейшем, используя иронию или иные небуквальные смыслы, специально для вас это упомяну и выделю курсивом. (ТУТ ИРОНИИ НЕТ)
Мне просто интересно, поможет вам знакомство с линухом (на что вы усиленно намекаете) и недавняя учеба в институте обосновать свои мысли, или вы стандартный россиянский студент.

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

(95)
вы не отличаете три разных понятия "Разрешено", "Не разрешено", "Запрещено". Важно понимать, что "Не разрешено" <> "Запрещено". Более того, внутри 1С вообще "Запрещено" отсутствует, хотя в документации пишут:
Права доступа могут иметь два состояния: "Разрешено" (отметка установлена) и "Запрещено" (отметка снята).

Так вот если в одной роли отметка снята, а в другой поставлена - в результате действует "Разрешено". Даже магическое слово RLS не может отменить того факта, что запрещения средствами ролей в 1С нет.


насчет
есть штатные средства RLS запрета не только конкретному пользователю

пруф или это метанация?
Для написания сообщения необходимо авторизоваться
Прикрепить файл
Дополнительные параметры ответа