Запрет редактирования справочника 1с
В некоторых случаях необходимо запретить пользователям редактировать табличную часть документов, добавлять, изменять или удалять строки и даже изменять их порядок. Реализовать это в 1С очень просто, например, можно полностью отключить возможность изменения состава строк. В этом случае на форме пропадут соответствующие кнопки «Добавить», «Изменить», «Удалить». Можно отдельно отключить возможность изменения порядка строк в табличной части. Так же есть возможность настройки доступных команд, например, можно разрешить только добавлять строки, или только удалять ну или только изменять.
Кстати у табличной части можно вообще убрать командную панель, на которой расположены кнопки «Добавить», «Изменение порядка» и меню «Еще», но через контекстное меню вызванное кликом ПКМ мышки все же это сделать можно будет.
Как убрать возможность добавления, удаления, изменения строк табличной части документа
Давайте рассмотрим все варианты отключение возможности редактирование табличной части.
Открываем конфигуратор и свойства табличной части у которой хотим заблокировать возможность редактирования.
В свойствах ищем раздел «Использование» в нем пункт «Изменять Состав Строк» и снимаем на против него флаг.
В результате этих действий пропадут кнопки «Добавить», «Изменить», «Удалить».
Они исчезнут из всех меню.
Но возможность изменения порядка строк все же остается, для того чтобы её отключить в свойствах табличной части в разделе «Использование» нужно снять флаг напротив пункта «Изменять порядок строк».
Для того чтобы убрать отдельную команду, например, добавления, изменения, удаления или перемещения строк табличной части, нужно открыть пункт «Состав команд» и отметить только необходимые.
Таким образом можно разрешить пользователю например, только добавлять строки в табличную часть.
Вот таким образом можно запретить редактирование табличных частей, либо частично ограничить возможности пользователей. Так же все это можно запретить программно.
В 1С:Бухгалтерии 2.0 (или любой другой конфигурации) может возникнуть следующая проблема: возможность создания и редактирования элементов справочника Номенклатура должны быть не у всех пользователей программы. Для решения этой проблемы можно внести изменения в типовую роль Бухгалтер, обязательную для запуска системы и поэтому установленной у всех пользователей. Но изменение типовой роли может привести к трудностям при обновлении релиза конфигурации, поэтому данное решение не является приемлемым. В 1с запрет редактирования документа или справочника можно сделать гораздо проще.
Как реализовать в 1с запрет редактирования документа или справочника
Рассмотрим решение данной задачи без изменения типовых ролей. Суть его будет заключаться в создании и использовании своих, не типовых, объектов метаданных:
1. В конфигурации создадим новую, не типовую, роль. Назовем ее Номенклатура. Никакие галочки в ней проставлять не нужно, требуется только ее наличие;
2. Добавим в конфигурацию еще один общий модуль. Можно назвать его, к примеру, НастройкиДоступа. Если в вашей базе уже есть не типовой модуль, то можно использовать его;
3. Добавим в конфигурацию еще одну подписку на событие, назовем ее ПередЗаписьюНоменклатураНастройкиДоступа. В настройках подписки укажем тип данных источника — справочник Номенклатура. Выберем нужное событие для подписки (в нашем случае ПередЗаписью). В поле Источник укажем созданный вами общий модуль. Туда автоматически будет добавлена новая процедура, обрабатывающая событие данной подписки;
4. В этой процедуре пишем следующие строки кода:
Данный программный код проверяет наличие у пользователя роли Номенклатура и разрешает или запрещает запись элемента справочника.
5. Установим роль Номенклатура тем пользователям, которым должны иметь возможность записи элементов справочника, теперь никто кроме них не сможет вносить изменения в справочник.
На основании данного алгоритма можно реализовать ограничения на запись любых документов или справочников. Для этого можно использовать одну или несколько не типовых ролей.
Часть 2. Ограничение доступа к справочникам (Настраиваем права доступа в 1С Университет ПРОФ)
Данная статья была написана в попытках решить недостаток способа настройки ролей, описанного в первой части статьи. Напомню, о чем речь: пользователи по умолчанию не имеют доступа к документам, однако они имеют доступ ко всем справочникам (кроме физ.лиц) и некоторым другим объектам, например, константам: они могут добавлять элементы и изменять существующие (удалить не смогут).
А также, если пользователь догадается как включить режим "Все функции", то он сможет изменять константы, запускать любые обработки, бизнес-процессы (ирония в том, что если он сможет добраться через "Все функции", например, до константы "Ограничивать доступ на уровне записей", то ничто не помешает ему ее отключить…).
Это повышает требования к пользователям, но зачастую они меняют элементы сами того не подозревая, без злого умысла.
Таким образом, главный вопрос этой части статьи в том - как запретить доступ на редактирование к тем объектам, к которым доступ разрешен в типовой роли "Пользователь", не трогая саму роль, и, не создавая новых ролей, иметь возможность оперативно разрешать/запрещать доступ определенным пользователям (опять же исходя из цели, обозначенной в части 1, т.е. с минимальными изменениями в типовой конфигурации).
Здесь я опишу два способа (хотя их конечно может быть и больше). Рекомендую прочесть оба, чтобы определиться который Вам подходит и подходит ли вообще.
Начиная с версии 2.0.8 у роли "Пользователь" режим "Все функции" отключен в типовой конфигурации и никаких дополнительных действий не требуется.
Если же у Вас версия ниже, то рекомендуется, всё же немного подкорректировать роль "Пользователь" в конфигураторе, а именно в настройках прав убрать "Режим "Все функции".
Сильных проблем при последующем обновлении программы вызвать не должно, просто надо это запомнить, чтобы делать после каждого обновления. Так мы защитим от намеренного открытия некоторые важные объекты, вроде констант и справочников.
Но опять же, если дотошный пользователь через настройки интерфейса и панелей включит себе то, что мы отключали через шаблоны, то он сможет получить доступ к некоторым справочникам или другим объектам.
Если же случайный доступ принципиально нужно ограничить, то можно попробовать использовать следующее решение, которое позволит через стандартный административный интерфейс предоставлять доступ к справочникам или другим объектам избранным пользователям.
Суть решения: создать подписки на события в момент записи объектов (справочников, констант и т.п.), создать группы пользователей, которым разрешено/запрещено изменять объекты конфигурации, на основании групп предоставлять доступ к редактированию. Будут созданы только пара новых объектов конфигурации, поэтому проблем при обновлении быть не должно.
Т.к. мы не хотим менять типовые объекты конфигурации, то вместо изменения самих объектов для проверки доступа на редактирование к ним будем использовать подписки на события "ПередЗаписью".
Чтобы добавить подписку, необходимо установить следующий режим редактирования: на корневом узле установить "Объект поставщика редактируется с сохранением поддержки" (без наследования на подчиненные объекты):
Скорее всего данный режим у Вас уже установлен (если пользовались внешними обработками выгрузки данных в ФИС).
Начнем со справочников, рассмотрим всё на их примере, а остальные объекты (например, константы) делаются по аналогии.
Для начала, мы вставим небольшой код, который будет запрещать редактирование всех справочников пользователями (по умолчанию редактирование всех справочников разрешено).
Даем наименование (в моем случае "п_" - это регламентированный префикс для всех добавляемых объектов):
Данный код разрешает редактирование только пользователям с полными правами. Дополним его более гибкими правами позже.
Теперь создаем подписку на событие (которая будет срабатывать при попытке записать элемент справочника):
(Если нужно, можно еще дополнительно сделать такую же подписку для констант, тогда в типе данных нужно выбрать "КонстантаМенеджерЗначения" и также для любых других объектов.)
Теперь нужно сделать так, чтобы один пользователь имел доступ, а другой нет. Используем для этого тот же механизм групп, что и ранее для объединения пользователей в группы.
Идея такова - для каждого объекта конфигурации, к которому нужно предоставить доступ, создается группа и любой пользователь, входящий в эту группу, будет иметь доступ на редактирование этого объекта. Можно делать как "разрешающие" группы, так и "запрещающие", т.е. если Вы хотите не всё запрещать, а оставить всё разрешенным (как по умолчанию) и потом отдельно запрещать редактирование некоторых объектов (тогда в указанном выше коде модуля нужно убрать строку "Отказ = Истина;", которая всё запрещает).
Вернемся к нашему примеру. Для удобства можно сгруппировать все папки (группы) пользователей, где будут назначаться права, например, так: (можно задать любую структуру, важны будут только конечные группы)
В этом примере мы решаем, что константы и справочники будут запрещены на редактирование для всех и будем делать разрешающие права в группе "Разрешено редактировать". А на планы видов характеристик будем делать запрещающие права для некоторых пользователей.
Примечание: наименование должно быть таким, как задано "ПолноеИмя" объекта в конфигураторе, например, "Справочник.Дисциплины", "Справочник.ЕдиницыИзмерения", "Константа.ЗаголовокСистемы" и т.п.
Теперь необходимо добавить код в созданный ранее модуль, чтобы обрабатывать вышеуказанные группы (текст кода для копирования см. ниже):
Можно проверять редактирование справочника под пользователем, у которого раньше была ошибка при сохранении и которого мы включили в группу на разрешение. Теперь ошибки быть не должно, и дисциплина сохранится нормально.
Если нужно сделать тоже самое для констант, то опять же создаем подписку "ПередЗаписью" на объекты констант, ссылаемся на ту же процедуру в нашем модуле. В группах создаем соответствующую группу и добавляем в нее пользователей.
В итоге код обеих процедур в нашем модуле может быть следующим:
Для запрета редактирования объектов, которые по умолчанию разрешены (например, некоторые планы видов характеристик и др.), также добавляем подписку на эти объекты, ссылаемся уже на вторую процедуру - ПередЗаписьюОбъектовПроверкаПравЗапрет, в группах создаем соответствующие группы объектов и добавляем пользователей, которым редактирование запрещено.
Этот способ позволяет сделать также всё наоборот. Т.е. оставить все справочники по умолчанию редактируемыми, и добавить запрещающие редактирование правила. Это уже на усмотрение администратора.
Однако в этом способе нельзя использовать один и тот же объект как для разрешения, так и для запрета. Поэтому необходимо сразу определиться, что будет по умолчанию включено, а что нет.
Данный механизм можно попытаться расширить, используя, например, механизм "Администрирование объектов метаданных", как было сделано для документов в типовой конфигурации. Тогда можно будет предоставлять доступ сразу на группы объектов (способ 2)
Предисловие: после описания и обсуждения 1го способа, нами была избрана несколько иная стратегия для справочников - "стратегия запрета".
Её суть: по умолчанию в типовой конфигурации основные объекты разрешены для редактирования (справочники, константы и т.п.). Но есть справочники, к которым доступ необходимо предоставить лишь избранным пользователям или совсем запретить редактирование.
Например, справочники "Типы стандартов" или "Формы обучения" (нам бы не хотелось, чтобы любой из пользователей мог переименовать "очное" на "заочное" и т.п.).
Почему именно так, а не наоборот? Решение было принято из-за сроков (нужно сделать быстро), а "способ разрешения" опасен тем, что на данный момент мы точно не знаем, какие где справочники понадобятся при работе, и, если в разгар приемной кампании всё запретить, может встать работа сотрудников ПК.
Поэтому пока нужно защитить лишь особо важные объекты, а когда с течением времени будут сформированы списки справочников для разных учебных процессов, тогда можно будет перейти к стратегии разрешения.
Однако при детальном обдумывании реализации задачи "стратегии запрета" выяснилось, что первый способ неудобен, т.к. создавая группу объекта нужно будет включить в нее всех пользователей, кому нельзя редактировать объект, которых довольно много (тех, кому разрешено, - единицы). Особенно неудобно, если создается новый пользователь - при создании надо будет не забыть добавить его в группы запрета (если забыть, то он случайно получит доступ на редактирование к защищаемым объектам).
Суть способа 2: всё разрешено для всех, но если что-то разрешено только для кого-то, то оно должно быть автоматически запрещено для всех остальных. Т.е. запрет не глобальный (как в способе 1), а объектно-ориентированный.
Например, если на справочник специально не назначено никаких пользователей, то доступ на редактирование по умолчанию разрешен. Если к справочнику привязали хотя бы одну группу пользователей или пользователя, то будем разрешать редактирование только указанным группам, а всем остальным запрещать.
Реализовывать будем немного другим методом, в отличие от способа 1, а именно расширим стандартный механизм "Администрирование прав объекта" (знакомый нам по первой части статьи).
Механизм базируется на справочнике метаданных, в который нужно добавить имена объектов, доступ к которым нужно регулировать, например, "Справочник.ФормаОбучения", "Справочник.ТипыСтандартов" или "Константа.ЗаголовокСистемы" и т.п.
Теперь выбираем группу пользователей, которым будет разрешено редактирование. Например, справочник дисциплин должны редактировать только сотрудники УМУ, т.к. они создают учебные планы, все остальные только чтение.
Для этого в "Администрировании прав группы" добавляем справочник дисциплин из справочника метаданных (кнопка "Подбор объектов") и ставим право "Изменять" или "Добавлять" ("галка Чтение" на данный момент будет проигнорирована).
Это будет означать, что раз появился кто-то, кому даны особые права, то автоматически другим право редактирования будет запрещено.
Теперь нужно сделать обработчик для этих прав и метаданных. Для этого, как уже описывалось в способе 1 выше, создадим подписку "ПередЗаписью" на все справочники и/или другие нужные объекты.
Типовая ЕРП. У пользователя есть порядка 6 ролей, где разрешено редактирование номенклатуры.
Как, не трогая эти роли запретить ему редактирование вышеуказанного справочника?
(0) > Как, не трогая эти роли запретить ему редактирование вышеуказанного справочника?
Не трогая роли? Элементарно!
Издаётся распоряжение о введении в действие новой инструкции по работе с программой, в которой указано, что пользователю запрещено делать. Заинтересованные ознакамливаются с распоряжением под роспись. Далее организуется контроль за выполнением (стандартный отчет по версиям раз в месяц) и публичные наказания нарушителей.
PS Любые попытки решить чисто административные проблемы программными методами обречены на провал и приводят только к их (проблем) эскалации.
Программировать низзя, роли трогать низзя, менять настройки пользователя низзя.
У вас один шанс, если в ваших ерпях есть настройки рлс на номенклатуру.
(6) Ты первым начал. Пересмотри про 7 перпендикулярных линий красного цвета, одна из них в форме зайчика.
Я просто искал просто решение, оптимальное решение.
Получается, чтобы произвести запрет на номенклатуру, то мне нужно существующие шесть профилей для него пересоздать и добавить новые лично для пользователя.
Возможно есть какое-то простое решение, как добавить ограничение действующее по всем остальным профилям. При это сохранив остальные профили.
В этом случае надо делать свои атомарные роли и каждому давать набор таковых.
(11) Редко, при начальном проектировании можно правильно сделать. Здесь вопрос в последующей гибкости.
В одной конторе все работают (ERP) с ролью "полные права". Задача - скрыть подсистемы ЗП и Кадры для большинства сотрудников. Забрал в расширение роль "Полные права" снял галки "Просмотр" у этих подсистем. Создал, в расширении, новую роль и установил "Просмотр" в истину у подсистем ЗП и Кадры.
Обработкой присвоил новую роль тем сотрудникам которым дали добро на зп и кадры.
(13) Норм решение.
Только я только, что с совещания, и когда не смог за 15 минут найти решения без программирования на меня чуть ли ни вся компания накинулась. Ваша программа за 400 тысяч, вы нам ее посоветовали, а теперь не можем роль ограничить, чтобы вас не звать. Ну и в таком духе.
В 1С можно настроить ограничения по ролям, т.е. запретить пользователям с определенной ролью изменять какие либо реквизиты или объекты конфигурации. Например, при создание или открытии какого либо документа (справочника) можно запретить изменять номер, дату или другие необходимые элементы. На практики подобные задачи встречаются довольно часто, так как некоторые пользователи могут поменять дату документ или его номер, тем самым нарушить учет документооборота. Реализовать все это достаточно просто.
Программное ограничения по ролям в 1С
Допустить у нас в базе есть роль «Пользователь» и нам необходимо всем учетным записям с данной ролью запретить изменять номер и дату документа поступления, а так же указывать в поле «Ответственный» наименование роли.
Для этого в обработчике события «При создании на сервере» пишем вот такой код.
Думаю в нем все понять, если учетная запись под которой создается документ имеет роль «Пользователь» тогда запрещаем редактировать «Номер», «Дату» и в поле «Ответственный» подставляем значение из справочника «Пользователи» которое найдем по коду. Под данным кодом в справочнике находиться «Пользователь».
Запустим 1С и посмотрим что получилось, в итоге ввести что-то с клавиатуры в поля «Номер», «Дата» не получиться.
Но если у данного поля есть возможность выбора, например, как у даты то изменить её все же буде возможно.
Для того чтобы исключить подобную ситуацию можно отключить доступность, без ограничения редактирования.
В этом случае пользователь уже ни чего не сможет сделать.
Вариантов реализации подобных задач очень много, я показал один из, возможно он даже не самый оптимальной. Если Вы знаете другой обязательно поделитесь.
Кстати механизм подставления «Ответственного» тут не совсем корректен, так как в базе может быть много пользователей 10, 20 и если у всех у них есть роль «Пользователь» то она и будет подставляться, тут необходимо подставлять имя пользователя а не роли, с помощью ПользователиИнформационнойБазы.ТекущийПользователь() но об этом в следующей статье.
Читайте также: