1s zup група за достъп за физически лица. Добавяне на нов потребител и присвояване на права за него. Схема на взаимодействие на обекта

В тази статия ще ви разкажа как работи механизмът за конфигуриране на „ограничаване на достъпа на ниво запис“ в 1C:UPP 1.3. Информацията за статията е събрана към май 2015 г. Оттогава UPP не е радикално актуализиран, тъй като 1C избра 1C:ERP за свой флагман. Все пак UPP работи правилно в много предприятия, така че публикувам резултатите от моето изследване на RLS в UPP в тази статия. Определено ще бъде полезно на някого.

Всичко е сухо, компресирано и без вода. Как обичам))).

Настройки за права за достъп.

Схема на взаимодействие на обекти.

В UPP 1.3 контролът на достъпа се осъществява от подсистемата „Контрол на достъпа“ от BSP версия 1.2.4.1.

Метаданни, използвани в системата за контрол на достъпа в УПП:

1. Справка „Профили за потребителски разрешения“
2. Информационен регистър „Стойности на допълнителни потребителски права“
3. План на типове характеристики „Права на потребителя“
4. Директория "Потребители"
5. Системен справочник „Потребители на ИС“
6. Директория "Потребителски групи"
7. Регистър на информация "Потребителски настройки"
8. План от типове характеристики „Потребителски настройки“
9. Изброяване „Типове обекти за достъп“
10. Регистър на информацията „Цел на видовете ограничения за достъп“
11. Изброяване „Области с данни на обекти за достъп“
12. Информационен регистър „Настройки на правата за достъп на потребителя“
13. Опция за сесия „Използване на ограничение до<ВидДоступа>».

Активирайте ограниченията за достъп на ниво запис.

Ограничението на нивото на запис (RLS) е активирано в интерфейса
„Администриране на потребители“ -> „Достъп до ниво на запис“ -> „Настройки“.

Достъпът на ниво запис се определя чрез типове обекти за достъп. Списък с типове обекти за достъп (съответните директории са посочени в скоби):

• „Контрагенти“ („Контрагенти“)
• „Организации“ („Организации“)
• „Физически лица“ („Физически лица“)
• "Проекти" ("Проекти")
• „Складове („Складове (места за съхранение)“)
• "Кандидати" ("Кандидати")
• Бележки (типове записи на бележки)
• "Деления" ("Деления")
• „Подразделения на организации“ („Подразделения на организацията“)
• „Номенклатура (промяна)“ („Номенклатура“)
• "Спецификации" ("Спецификации")
• „Цени на артикули“ („Видове цени на артикули“)
• „Външна обработка“ („Външна обработка“)

*Списъкът с възможни типове достъп е фиксиран и се съдържа в изброяването „Типове обекти за достъп“.

Директория „Профили за потребителски разрешения“.

Настройването на достъп до обекти на информационна база започва с настройка на потребителски профил с разрешения.

Профил обединява

• набор от роли – права за достъп до обекти
• допълнителни потребителски права – права върху функционалността на програмата.

Резултатът от настройката на профил е запис в информационния регистър „Стойности на допълнителни потребителски права“.
Този регистър не се използва в радарната конфигурация.

Могат да се записват допълнителни права за профил или потребител. Освен това, ако са конфигурирани допълнителни права за профил и профилът е свързан с потребител, тогава допълнителни права не могат да бъдат конфигурирани индивидуално за потребителя.
*Списъкът с права е посочен по отношение на типовете характеристики „Права на потребителя“

Самият профил в табличния раздел „списък с роли“ съдържа всички роли, които са активирани за него. Когато съставът на ролите на профила се промени, табличната част „Роли“ на всички потребители на информационната база (не директорията „Потребители“), на които е присвоен този профил, се попълва отново.

Връзката между директория „Потребители” и „Потребители на информационна база” се осъществява чрез атрибута „IB User Identifier” на директория „Потребители”, който съхранява GUID на потребителя на ИС.

Съставът на потребителските роли също не е достъпен за редактиране, ако на потребителя е присвоен конкретен профил.

Възможно е потребителят да посочи „Потребителски настройки“. Това са различни сервизни настройки за типично автоматично поведение на системата в определени ситуации.

Резултатът от настройките се записва в информационния регистър „Потребителски настройки“.

Списъкът с настройки и техните възможни стойности се съдържа в плана за характерен тип „Настройки на потребителя“.
*Не се използва в настройките за ограничаване на достъпа на ниво запис.

Директория "Потребителски групи".

Използва се за организиране на потребителите в групи и, наред с други неща, за конфигуриране на ограничения за достъп на ниво запис.

Един потребител може да бъде включен в няколко групи.

Във формуляра за потребителска група можете да конфигурирате списък с видове достъп.

Разрешенията за обект на ниво запис се конфигурират само за потребителски групи, а не за отделни потребители.

Ако вашата конфигурация използва ограничения за достъп на ниво запис, тогава всеки потребител трябва да бъде включен в една от групите.

ВАЖНО! Потребителите, които не са включени в нито една група, няма да могат да работят с онези обекти, чийто достъп е определен на ниво запис. Това важи за всички обекти - независимо дали се използват съответните типове обекти за достъп или не.

Ако даден потребител е член на няколко групи, които имат различни настройки за права на достъп на ниво запис, тогава наличността на даден обект за потребителя ще бъде определена чрез комбиниране на настройките от няколко потребителски групи с помощта на „ИЛИ“.

ВАЖНО! Включването на потребител в голям брой групи може да доведе до ниска производителност. Следователно не трябва да включвате потребител в голям брой групи.

След записване на промени в потребителска група се попълва Информационен регистър „Задаване на видове ограничения за достъп“. Този регистър съхранява записи за съответствие с потребителска група за определен тип достъп.

*Регистрът се използва в шаблоните за ограничаване на достъпа

Формуляр „Настройки за достъп“.

Формата за задаване на ограничения за достъп на ниво запис се извиква от командата „Настройки за достъп“ на формуляра за списък с директории „Потребителски групи“.

От дясната страна на формуляра разделите представят таблици с настройки за всеки тип достъп, отбелязани с квадратчета за отметка във формуляра за потребителска група.

Формулярът за настройка на права за достъп има отделна страница с формуляр за всеки тип достъп със собствен набор от настройки. Необходимата страница е активирана, когато свързаният с нея тип достъп е отметнат в потребителската група.

Сравнение на видовете достъп и възможните настройки:

Права за достъп.

„Четене“ - потребителят ще види елемента от директорията в списъка и ще може да го отвори за преглед, а също така ще може да го избере от списъка, когато попълва подробности за други обекти.

„Запис“ - потребителят ще може да променя:

• елементи на някои директории - видове обекти за достъп (не всички - има изключения, вижте по-долу),
• данни (документи, регистри, подчинени директории), свързани с тези елементи на директорията

Изключение: достъпът до елементи на някои директории - типове обекти за достъп - не зависи от правото "Запис". Това са директории: Организации, Отдели, Отдели на организации, Складове, Проекти. Те се отнасят до обекти с основни данни, така че само потребител с ролята „Настройка на основни данни...“ може да ги променя.

За типа обект за достъп " Номенклатура (промяна)„Правото за достъп до „запис“ е дефинирано само на ниво група на директория „Номенклатура“; не е възможно да се зададе право на „запис“ за индивидуален елементСправочник.

Няма ограничение за достъп до „четене“ на справочника „Номенклатура“ и свързаната с него информация, тъй като по принцип не е ясно какъв вид достъп трябва да се даде до документ, ако списъкът с номенклатура, който е в документа, съдържа и двете „разрешени ” и „забранени” » позиции.

Ограничението на достъпа до директориите „Отдели“ и „Отдели на организации“ не важи за информация за данни за персонала, лични данни на служители и данни за заплати.

Области с данни.

Областите с данни са определени за следните типове обекти за достъп:

• Контрагенти
• Физически лица
• Цени на артикулите

За обект за достъп тип „Контрагенти“

• Контрагенти (списък)— определя видимостта на контрагентите в списъка на директорията „Контрагенти“. Зависи от стойността на отметката в колоната „Видимост в списъка“.
• Изпълнители (допълнителна информация)— определя способността за „четене“/„запис“ на елемента от директорията „Контрагенти“ и допълнителната информация, свързана с него. информация (договори, лица за контакт и др.). Зависи от стойността на квадратчето за отметка в съответните колони „Преглед на допълнителни. информация"/"Редактиране на допълнителна информация" информация."
• Контрагенти (данни)— определя способността за „четене“/„запис“ на данни (директории, документи, регистри), свързани с директорията „Контрагенти“. Зависи от стойността на квадратчето за отметка в колоната „Преглед на данни“/„Редактиране на данни“.

За тип обект за достъп „Физически лица“Предоставени са следните области с данни:

• Физически лица (списък)— определя видимостта на дадено лице в списъка на директорията „Лични лица“. Зависи от стойността на отметката в колоната „Видимост в списъка“.
• Физически лица (данни)— определя способността за „четене“/„запис“ на данни (директории, документи, регистри), свързани с директорията „Лични лица“. Зависи от стойността на квадратчето за отметка в колоната „Преглед на данни“/„Редактиране на данни“.

За тип обект за достъп „Цени на артикули“Предоставени са следните области с данни:

• Фирмени цени—определя възможността за „четене“/„записване“ на цени за артикулите на компанията.
• Цени на изпълнителя— определя способността за „четене“/„записване“ на цените на позициите на контрагентите.

*Зоните с данни са затворен списък от елементи, съдържащи се в изброяването „Области с данни на обекти за достъп“.

Групи за достъп.

За следните типове обекти за достъп настройките на правата се извършват само чрез групи за достъп (имената на директорията са посочени в скоби):

• „Контрагенти“ („Групи за достъп на контрагенти“)
• „Лични лица“ („Групи за достъп от лица“)
• „Кандидати“ („Групи кандидати“)
• „Спецификации на артикула“ („Цели на използване на спецификациите“)

Групата за достъп се посочва за всеки елемент от директорията (в специален атрибут).

Настройките за достъп от „група за достъп...“ се извършват в допълнителна форма за задаване на права за достъп, която се извиква с една от двете команди:

• „Достъп до текущи елементи“
• „Достъп до директорията като цяло“

под формата на списък с директории “Групи за достъп...”.

Пример: Документът „Поръчка за получаване на стоки” е ограничен от видовете обекти за достъп „Контрагенти”, „Организации”, „Складове”.

Ако предоставите достъп до празна стойност за типа достъп „Контрагенти“, потребителят ще види документи, в които атрибутът „Контрагенти“ не е попълнен.

Достъп до елемент или група от директория.

В зависимост от това дали се конфигурира достъп до елемент на директория или група, настройката засяга или самия елемент, или подчинени групи.

Съгласно това във формуляра „Настройване на права за достъп“ в колоната „Тип наследяване на права за достъп на йерархични директории“ са зададени следните стойности:

• Само за текущо разрешение– за елемент от директория правата се прилагат за посочения елемент
• Раздайте на подчинените– за група директории правата се прилагат за всички подчинени елементи

След записване на настройките за ограничаване на достъпа за потребителски групи, информационният регистър „Настройки за потребителски права за достъп“ ще бъде попълнен в системата.

*Регистрът се използва в шаблоните за ограничаване на достъпа.

Използване на шаблони.

Шаблоните в UPP 1.3 са написани за всеки тип достъп поотделно и за възможни комбинации от видове достъп, като правило, за всяка потребителска група.

Например , в демо версията на UPP потребителската група „Покупки“ е конфигурирана. За тази група е разрешено използването на типове достъп „Организации“, „Контрагенти“, „Складове“. Съответно в системата са създадени редица шаблони за ограничаване на достъпа:

• "Организация"
• "Организационен_запис"
• "контрагенти"
• „Запис на контрагентите“
• "Складове"
• "Складове_запис"
• „Организация на контрагента“
• "CounterpartyOrganization_Record"
• "ОрганизацияСклад"
• "OrganizationWarehouse_Record"
• „CounterpartyOrganizationWarehouse_Record“
• "CounterpartyWarehouse"
• "CounterpartyWarehouse_Record"

Тоест всички възможни комбинации от видове достъп, които могат да се използват в текстовете за ограничаване на достъпа.

Като цяло схемата за изграждане на шаблона е една и съща за всички видове достъп и изглежда така:

1. Проверка на включването на типа достъп, който се проверява.
2. Директорията „Потребителски групи” е прикрепена към главната таблица и се проверява дали потребителят е включен в поне една група.
3. Регистърната таблица „Настройки на правата за достъп на потребителя“ според условията на свързване е приложена към информационния регистър „Присвояване на типове стойности за достъп“ — Обектът за достъп е стойността за достъп, предадена на параметъра на шаблона. — Тип обект за достъп – зависи от контекста на разработване на шаблона — Област за данни.— Потребител.

Резултатът от връзката определя дали достъпът е разрешен или не.

Край на втората част.

В подсистемата " Контрол на достъпа“, включени в BSP, настройки за достъп към данни на ниво запис на таблици на база данни (RLS)извършва се с помощта на две директории - " Достъп до групови профили" И " Групи за достъп". Настройката на потребителските роли се извършва през първата директория, докато настройката на RLS може да се извърши през двете директории, посочени по-горе - по избор на администратора на базата данни.

Бих искал да отбележа, че подсистемата има способността да диференцира достъпа до данни както елементарно, така и чрез набор от елементи, комбинирани заедно според някаква характеристика. Като пример, нека вземем директорията " Физически лица", възможността за конфигуриране на RLS, за която е налична в почти всички стандартни конфигурации и се извършва с помощта на специална справочна книга" ". За всеки елемент от директория " Физически лица"Възможно е да се посочи в подробностите" Група за достъп"съответния елемент от директорията" Индивидуални групи за достъп", след което за всеки потребител (или група от потребители) се посочва съответната група за достъп от налични за работа лица. Така директорията " Физически лица" действа като обект на ограничение на достъпа (почти всеки системен обект може да действа като такъв), а директорията " Индивидуални групи за достъп„като средство (инструмент) за ограничаване на достъпа до субекта.

Сега нека да преминем към факта, че да кажем, че трябва да организираме ограничения за достъп до някакъв конфигурационен обект според определен критерий, но няма възможност за конфигуриране на такива ограничения в програмата. Като пример за разглеждане, нека вземем типична конфигурация " Счетоводство на предприятието 3.0„(BP), която включва подсистема“ Контрол на достъпа", и в който няма възможност за конфигуриране на RLS с помощта на директорията " Контрагенти". Преди да направите промени в конфигурацията Бих искал също да направя резервация - направените промени зависят от версията на BSP, използвана в конфигурацията, но принципът остава същият. Въпросната статия използва BSP версия 2.2.2.44.

И така, последователността от нашите действия в конфигуратора, чиято цел е да реализира възможността за конфигуриране на RLS конфигурацията според директорията " Контрагенти" (в нашия случай, предмет на ограничения за достъп), ще бъде както следва:
1. Филтрирайте конфигурационното дърво с метаданни по подсистема " Стандартни подсистеми" - "Контрол на достъпа".
2. Чрез настройката за поддръжка на конфигурация (ако се използва механизмът за поддръжка), активирайте възможността за промяна на следните обекти на конфигурация:
А. Корен на конфигурацията.
b. указател " Контрагенти".
V. Дефиниран тип " AccessValue".
г. Абонамент за събитието " ".
д . Общ модул " ".
3. Добавете нова директория към конфигурацията " Групи за достъп на контрагенти".
4. Добавете към директорията " Изпълнители"нов реквизит" Група за достъп"референтен тип към нашата нова директория.
5. За определен тип " AccessValue"включете препратки към директории в съставния тип" Контрагенти" И " Групи за достъп на контрагенти".
6. За да се абонирате за събитие "UpdateAccessValueGroups "също посочете справочника като източник" Контрагенти".
7. Отворете споделения модул "Access ControlOverridable " и вмъкнете кодовите фрагменти по-долу в три от неговите процедури.
8. От ролята " Промяна на достъпа на членовете на групата" копирайте RLS шаблони с имена на ролята, от която се нуждаете (или роли, които определят достъпа до директорията) По стойности" И " ByValuesExtended". Задайте вашите роли да използват един от шаблоните според изискваното право (например, " Четене“), както е показано на екранната снимка по-долу.
9. Стартирайте конфигурацията в режим " предприятия"с параметър за стартиране" Стартирайте InformationBaseUpdate" (или извикайте процедурата за експортиране " UpdateSettingsОграничения за достъп"общ подсистемен модул" Access ManagementService").

Нека обърнем внимание на доста важен момент: може да се наложи да добавите още редове код към последната процедура, ако планирате да ограничите достъпа не само до директорията "Контрагенти", но също и към всички други конфигурационни обекти, свързани с тази директория, например за ограничаване на достъпа до документи "Продажба на стоки и услуги"по подпори" Контрагент" - в този случай обект на ограничаване на достъпа е документ и справочник "Контрагенти"е критерий за ограничаване на достъпа до елемент с помощта на инструмент за разделител на директории"Групи за достъп на контрагенти".

Процедура при попълване на типове достъп (типове достъп) Експортиране на заплата Управление на достъпа Попълнете свойства на типа достъп (типове достъп); // +Нашето вмъкванеAccessType =AccessTypes.Add(); AccessType.Name = "Групи акаунти"; // име на типа достъп (използвано в роли за RLS) AccessType.Presentation = NStr("ru = "Групи от контрагенти""); AccessType.ValueType = Type("DirectoryLink.Counterparties"); // критерий за ограничаване на достъпа AccessType.ValueGroupType = Type("DirectoryLink.AccessGroups of Counterparties"); // инструмент за ограничаване на достъпа // - Нашата процедура за вмъкване Край на процедурата при попълване на Използване на тип достъп (име на тип достъп, използване) Експортиране на заплата Управление на достъпа Попълване на използване на тип достъп (име на тип достъп, използване). ; // +Нашето вмъкване If AccessTypeName = "Contractor Groups" Then Use = True; endIf; // -Нашето вмъкване Край на процедура Процедура при попълване на типове ограничения на правата на обекти с метаданни (Описание) Експорт // + Нашето вмъкване // указващо правата на обекти с метаданни, които са обхванати от RLS Описание = Описание + " | Директория. Контрагенти. Групи контрагенти |. // -Нашата EndProcedure за вмъкване

След като завършите актуализацията на информационната сигурност в програмата, трябва да направите следното:
1. Попълнете директорията, която току-що добавихте към системата " Групи за достъп на контрагенти".
2. Uелементи на директория " Контрагенти"попълнете необходимите данни" Група за достъп".
3. В директорията " Достъп до групови профили"(или в справочника" Групи за достъп") в раздела " Ограничения за достъп"подходящо конфигуриране на RLS по групи за достъп на контрагента (екранът по-долу показва потребителите, на които е присвоен профилът" Нашият нов профил за достъп", ще работи в директорията само с контрагенти, включени в групи за достъп " Търговия на едро" И " са често срещани").
4. Може да се наложи в конфигурацията да се предвиди механизъм за автоматично попълване на детайлите " Група за достъп"за нови елементи от директорията" Контрагенти“ (за да се улесни администрирането му).

Резюме:Използване на "подсистемата" Контрол на достъпа"от BSP прави възможно управлението на RLS за всякакви конфигурационни обекти, като същевременно работи с поне две стандартни директории" Достъп до групови профили" И " Групи за достъп". Разширяването на възможностите за конфигуриране на RLS се осигурява с минимални промени в подсистемата. В случай, че критерият (или предметът) за ограничаване на правата за достъп е голям и непрекъснато се разширява (например директория " Контрагенти"), тогава е възможно чрез вашата допълнителна директория (инструмент за разграничаване) да разделите критерия (или темата) за достъп на определени области ( в нашия случай чрез "Групи за достъп на контрагенти"), в противен случай самите елементи на директорията могат да се използват като разделител за достъп (и има смисъл) (например в директорията " организации"). Безспорно предимство на използването на подсистемата е и унифицирането на администрирането на правата за достъп в информационната база.

21.09.2014

Задачата е да се ограничи достъпът до информация за клонове на отделни подразделения в ZUP за служителя по персонала и счетоводителя.

Видовете обекти за достъп ще бъдат по организации и лица.Настройка на контрол на достъпа на ниво запис

Главно меню - Инструменти - Настройки на програмата - раздел Ограничения за достъп

Тъй като първоначално взехме чиста база данни, нека я напълним с данни.

Нека създадем организации с име.

Централна организация

Клон на централна организация (като отделно подразделение)

Втори клон на централната организация (като отделно подразделение)

Нека създадем групи за достъп за отделни лица:

CO (за лица от централния офис)

CO клон (за физически лица от клона)

Втори клон на CO (за лица от втори клон)

CO + CO клон (за лица, работещи в CO и CO клон)

CO + Втори клон на CO (за лица, работещи в CO и втория клон на CO)

CO клон + втори CO клон (за лица, работещи и в двата клона)

Нека създадем потребителски групи:

CO Group

Group Branch CO

Група на Втори клон на Централен район

Напомням, че поставяме отметки за всички видове обекти за достъп - Организации и физически лица.

След като въведете потребителски групи, можете да им зададете групи от лица, към които ще се прилага действието.

В случай на настройка на разграничаването на RLS в отделни клонове, трябва да знаете следната точка - съгласно законите на Руската федерация данъкът върху доходите на физическите лица и застрахователните премии се изчисляват от началото на годината и, най-важното, въз основа на основа на организацията като цяло. Това означава, че счетоводителят на клона, когато изчислява данъците, трябва да знае колко данъци вече са начислени и предоставени обезщетения за това лице във всички други отделни подразделения. А това е достъп до данни от всички останали клонове, включително централния офис.

След този факт може да изглежда, че е невъзможно правилно да се разграничи достъпът до отделни клонове, но това не е така и ето защо. Разработчиците на стандартната ZUP конфигурация са разработили структура от данни, когато при изчисляване на данъците данните за изчисление винаги се записват едновременно за клона и организацията-майка, а при изчисляване за целите на изчисляване на данъците в клона, данните се вземат за организацията майка. Оказва се, че вече не е необходим достъп до всички клонове, а само до организацията-майка. Това вече е по-топло, но фирмите, като правило, искат да ограничат достъпа на клоновете до данните на централната организация. Изглежда, че отново нищо няма да се получи!

Мога да ви уверя, че всичко ще се получи! Ако вземем предвид концепцията на RLS, нито един документ няма да бъде видим, ако има поне един обект, забранен за потребителя, т.е. документи на други организации няма да бъдат видими, ако има поне един обект (физическо лице), забранен за потребителя.

Въз основа на горното, ние правим следните настройки за достъп (бутона „Права“) за потребителски групи.

За централната организация

За групов клон CO

За елемента „Група Втори клон CO“ също правим следните настройки:

В раздела „Организации“ - Централната организация и втория клон, а в раздела „Лични лица“ всички групи за достъп от лица, в които се появява името на втория клон. Всички знамена са вдигнати.

Нека създадем потребители на организации:

Служител по персонала - служител по персонала на централната организация

Кадрови служител 1 - клонов служител по персонала

Служител по персонала 2 - служител по персонала на втори клон

и задайте всички потребители към съответните потребителски групи от списъка с потребители

или го правим в самата потребителска група

Сега да наемем служители.

CO Първи служител (централна организация)

Първи служител на клон (служител на клон)

SecondBranchFirstEmployee (служител на втория клон)

Branch_CO FirstEmployee (служител, нает в клона, прехвърлен в централната организация)

При приемане ние присвояваме групи за достъп на отделни лица

Първи служител на CO - „CO“

Първи служител на клон - „Централен офис на клон“

SecondBranchFirstEmployee - „Втори клон на централния орган“

Branch_CO Първи служител - „CO + Branch CO“

Всички служители са назначени на 01.01.2014 г., а от 01.09.2014 г. служителят на „Клон_CO Първи служител” е преместен от клона в централния офис.

Отваряме дневника „Счетоводство на човешките ресурси за организации“ под администратор, който не подлежи на ограничения на RLS, и виждаме всички документи

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

Отваряме дневника „Счетоводство на организационния персонал“ и виждаме 3 документа, избрани според настройката за ограничение.

Влезте под потребител Kadrovik1

Отваряме списъка със служители и виждаме само „нашите“ служители.

Списанието „Счетоводство на персонала за организациите“ също съдържа само „техните“ документи за персонала.

Влезте под потребител Kadrovik2

Списък на служителите

Списание "Кадрово счетоводство на организациите"

RLS разграничението работи по същия начин по отношение на изчислената информация, но тук няма да давам примери.

Това е всичко, задачата, посочена в заглавието, е изпълнена - потребителите виждат само „своите“ документи.

Освен това можете да се запознаете с нюансите на писане на заявки, когато задавате разделяне

На рекордно нивов моята статия „Използване на директивата Allowed“

Владимир Илюков

Права, роли, профили на групи за достъп и групи за достъп ви позволяват да конфигурирате потребителски права в 1C Enterprise 8.3. Правата на потребителя в 1C 8.3 са набор от действия, които той може да извършва върху директории, документи, отчети и настройки. Много е важно да разберете тези концепции, ако няколко потребители ще работят с програмата и на всеки от тях трябва да бъдат присвоени съответните права.

Статията описва как правилно да разпределите правата между потребителите на програмата 1C ZUP 3.1, така че всеки от тях да може да работи в рамките на своята компетентност и длъжностни характеристики. Материалът в тази статия не изисква специални компютърни познания.

Профили и групи за достъп в 1C ZUP 3.1

За разграничаване на правата за достъп в 1C Enterprise 8.3 се използват „Права“, „Роли“, директории „Потребители“, „Групи за достъп“ и „Профили на групи за достъп“.

Право и роля

Правата и ролите са определени разрешени действия (четене, преглед, изтриване, изпълнение и т.н.) върху константи, директории, документи и други конфигурационни обекти. Всяко право представлява единица действие от списък с възможни. Минималният интегратор на правата е ролята. Всяка роля се състои от набор от специфични права. Правата и ролите се създават в конфигуратора. Потребителят не може да променя техния състав.

Както и в предишните версии на 1C Enterprise 8, потребителят може да бъде регистриран в режим на конфигуратор и да му се присвоят необходимите роли там. Въпреки това, 1C ZUP 3.1 предоставя около няколкостотин налични роли (в потребителската карта те са изброени в раздела „Други“: „Конфигуратор> Администриране> Потребители“).

С толкова много налични роли може да бъде много трудно да се ориентирате. Освен това за непосветените многото заглавия на ролите означават малко. В такава ситуация изборът на роли в конфигуратора за потребителя е много трудоемка задача. Въпреки това, на потребителско ниво в 1C ZUP 3.1 лесно се решава с помощта на директориите „Профили на групи за достъп“ и „Групи за достъп“.

Справочник „Профили на групи за достъп“

Всеки елемент от директорията на Access Group Profiles е интегратор на роли. Връзката към тази справка се намира в „Администриране > Конфигуриране на потребители и права > Групи за достъп > Профили на групи за достъп”. Разработчиците вече са описали най-популярните профили в него.

• администратор,
• хронометрист,
• служител по персонала,
• Калкулатор и др.

Можете да създадете свои собствени профили в директорията, но в повечето случаи това не е необходимо. Предварително дефинираните профили вече съдържат необходимите набори от разрешени за тях роли (разрешени действия). Имайте предвид, че хронометристът има минимален набор от разрешени действия. Но дори и да го опиша, бяха необходими около 50 роли, една рисунка.

Елементите на директорията „Профили на групи за достъп“ се задават като подходяща стойност в атрибута „Профил“ на директорията „Групи за достъп“.

Директория "Групи за достъп"

Смисълът и целта на тази директория е, че тя изброява потребителите (участниците), които ще имат всички права на профила на групата за достъп, който му е присвоен.

За да отворите тази директория, следвайте връзките „Администриране > Настройка на потребители и права > Групи за достъп > Групи за достъп”. В него е предварително инсталирана една група за достъп, наречена „Администратори“. Останалите се създават според нуждите на потребители с пълни права.

Един и същ „Профил на група за достъп“ може да бъде присвоен на различни „Групи за достъп“. Обратно, всяка „Група за достъп“ може да има само един „Профил на група за достъп“. В много случаи е удобно да посочите името на профила на групата за достъп, който му е присвоен, като име на групата за достъп, фигура.

В раздела „Членове на групата“ трябва да посочите потребители от директорията със същото име. Когато избирате, трябва да се ръководите от факта, че групата за достъп обикновено съответства на длъжностните задължения на нейните членове. Колкото по-висока е позицията, толкова повече права. Всяка група за достъп може да има произволен брой участници, фигура.

Връзката между описаните конфигурационни обекти е ясно илюстрирана на следващата фигура.

По принцип един и същ потребител може да бъде член на няколко групи за достъп.

Описание на профилите на групата за достъп в 1C ZUP 3.1

От горното следва, че правата на потребителя се определят от профила на групата за достъп, в която той членува. Остава да разберем как профилите на групата за достъп се различават един от друг. Например от името на профилите 1C ZUP 3.1 не става ясно как точно се различават ролите им.

• Служител по персонала (без достъп до заплата).
• Кадрови служител.
• Калкулатор.

За съжаление техните описания не са дадени в конфигурацията. Съдейки по името, можем да предположим, че потребител с профил „Служител по човешки ресурси“, за разлика от „Служител по човешки ресурси (без достъп до заплата)“, има някакъв вид достъп до заплата. Но в каква степен не е ясно. Друг въпрос: счетоводителят има ли право да работи с документи за персонала?

За тези, които го имат, можете да прочетете описанието на профилите на групата за достъп, дадено от 1C. Публикуван е, но е много кратък. Статията на автора предоставя по-подробно описание на профилите на групите за достъп. В същото време, за да не се изкривяват описанията, дадени от 1C, те са маркирани в статията със специален шрифт.

Администратор

Потребител с профил „Администратор” има право да извършва всичко, което е предвидено от стандартната функционалност. За да направи това, такъв потребител трябва да има активирани роли „Администрация“, „Системен администратор“ и „Пълни права“.

одитор

Вижте всички програмни данни, но без възможност да ги променяте, 1C.

Всички раздели са достъпни за преглед от одитора, с изключение на раздела „Администриране“. Може да преглежда документи за персонал и заплати и да генерира отчети. Одиторът има право само да преглежда регламентираната отчетност. Секцията „Настройки“ също е видима за одитора, но тук той може да преглежда само съществуващите настройки.

Обикновено този профил е включен в групата за достъп на одитори. В същото време е препоръчително да го включите в групата за достъп на тези мениджъри на организацията, които поради служебните си задължения се нуждаят от данните на тази програма, но не знаят как да работят с нея или не трябва.

Хронометрист

Преглед и промяна на документи за проследяване на времето, 1C.

Връзки към дневници, които съдържат документи относно промени в записа на времето, се намират в секциите „Заплата“ и „Настройки“. Секцията „Заплата” съдържа две връзки: „Таблици” и „Индивидуални работни графици”, фигура.

Хронометристът има право да разглежда други обекти, но няма да може да ги променя. Документите за персонала съдържат информация за планираните начисления. Те обаче не се показват на хронометриста и той не може да ги види. Например в документа „Наемане” той ще види само два раздела „Основни” и „Трудов договор”. Разделът „Плащане“ няма да се показва, фигура.

Хронометристът има способността да генерира някои отчети за персонала и отчета „Лист за работно време (T-13)“.

Служител по персонала (без достъп до заплата)

Различава се от служителя по персонала по това, че прегледът и промяната на планираната заплата не е налична, 1C.

Служителите по човешки ресурси без достъп до заплати са лишени от възможността да видят планираните начисления и метода за изчисляване на авансовите плащания. Те също не могат да отпечатат заповедта за приемане, тъй като тя показва начисления. Въпреки това, за разлика от хронометристите, служителите по персонала без достъп до заплати могат да създават нови и да коригират съществуващи документи за персонала.

Освен това „Човешки служител (без достъп до заплата)“ има способността да генерира всички „Човешки отчети“ и да редактира директориите „Лични лица“ и „Служители“. Но той няма права да редактира справочниците „Организации“, „Звена“, „Длъжности“ и тези, свързани с военната регистрация.

Профилът „Човешки служители (без достъп до заплата)“ е предназначен за онези потребители, които не трябва да виждат планирани начисления (заплати, надбавки и др.).

Кадрови служител

Преглеждайте и променяйте информацията за служителите по отношение на досиета на персонала, включително планирани заплати, както и документи за персонала. Вижте директории на структурата на предприятието, 1C.

„Служител Човешки ресурси“, в допълнение към правата, които има „Служител Човешки ресурси (без достъп до заплати)“, има право да назначава, добавя и променя планирани начисления и чертежи в регистраторите по ЧР.

Тоест „Kadrovik“ има възможност не само да вижда планираните начисления, но и да ги променя. Този профил е препоръчително да се използва, когато няма тайна за начисленията на служителите.

Старши кадровик

Различава се от служител по персонала по това, че може да променя директориите на структурата на предприятието и настройките за записи на персонала, 1C.

„Старшият офицер по персонала“, освен правата, които има „Офицерът по човешки ресурси“, има възможност да редактира указателите „Организация“, „Подразделения“, „Длъжности“ и указателите, свързани с военната регистрация. В допълнение, старшите офицери от персонала имат право да променят таблицата с персонала.

По отношение на достъпа до изброените по-долу обекти може да се отбележи следното.

• Настройка > Организации. Всички подробности са достъпни за редактиране с изключение на формата „Счетоводна политика“.
• Настройки > Начисления
• Настройка > Задържания. Може да се разглежда без права за редакция.
• Настройки > Шаблони за първоначално въвеждане на данни. Може да се разглежда без права за редакция.

Калкулатор

Преглед и промяна на документи за изчисляване и изплащане на заплати, вноски, информация за служители (в частта, която засяга изчисленията), 1C.

Потребител с профил „Калкулатор“ има възможност да преглежда документи за персонала, без да може да редактира информация за персонала. Но той има право да промени планираните начисления в тях. Например заплатата, определена от служителя по персонала, може да бъде променена или добавена от калкулатора към друго планирано начисляване.

Счетоводителят не може самостоятелно да създава документи за персонала. Но той има право да зададе нов или да промени съществуващия работен график за списъка на служителите.

• „Настройка > Организации“.
• „Настройка > Заплата“.
• „Настройки > Начисления“.
• „Настройка > Задържания“.
• „Настройки > Шаблони за първоначално въвеждане на данни.“

С други думи, калкулаторът няма право да прави никакви настройки. Работи с готови настройки.

Главен счетоводител

Различава се от калкулатора по това, че е възможно да се променят настройките за изчисляване на заплати, начисления и удръжки, 1C.

В допълнение към правата, които има “Калкулатор”, “Старши счетоводител” има права да променя следните настройки.

• Настройки > Организации.
• Настройки > Начисления.
• Настройки > Задържания.
• Настройки > Шаблони за първоначално въвеждане на данни.

• В същото време „Настройки > Заплата” остава недостъпен за старши счетоводителя. Препоръчително е да присвоите този профил на тези счетоводители, които владеят технологията за генериране на нови видове изчисления.

Мениджър човешки ресурси

Комбинира правата на служител по персонала, счетоводител и хронометрист, 1C.

Тук няма какво да добавя: три в едно. Препоръчително е да използвате този профил, когато един потребител действа едновременно като три лица: хронометрист, служител по персонала и счетоводител.

Старши мениджър персонал

Съчетава правата на старши кадровик, старши счетоводител и хронометрист. Последните два профила се изпълняват за удобство при настройване на програмата в малки организации, където един потребител може да отговаря за всички области на счетоводството, 1C.

Тук е необходимо уточнение. Наистина, старшият мениджър по персонала има право да настройва „Начисления“, „Удръжки“, „Индикатори за изчисляване на заплатите“ и т.н. Но той няма право да настройва „Изчисляване на заплати“ и „Счетоводство на персонала“. Това е вярно поне за версия 3.1.4.167.

Отваряне на външни справки и обработка

Всички потребители, включително одитори и хронометристи, имат право да работят с външни доклади и обработка. От съображения за сигурност обаче по подразбиране възможността за използване на външни отчети и обработка е деактивирана. Ако отчетът (обработката) е получен от надеждни източници, тогава можете да актуализирате възможността за работа с външни отчети и обработка, както следва.

Стартирайте програмата за заплати в потребителски режим като администратор. В системния панел щракнете върху връзката „Главно меню > Инструменти > Опции”. Във формуляра, който се отваря, актуализирайте флага „Показване на команда „Всички функции““ и щракнете върху „OK“.

В него поставихме едноименния флаг. След това в секциите „Персонал“, „Заплати“, „Плащания“, „% данъци и отчетност“ и „Отчетност, сертификати“, в подраздел „Услуга“ ще се покажат връзки „Допълнителни отчети“ и „Допълнителна обработка“. .

Управлявайте датите за забрана за промяна

За да зададете дата за забрана на промени в документи от предишни периоди, трябва да следвате връзките „Администрация > Настройки на потребители и права > Дати за забрана на промени”, фигура.

Потребителите, които не виждат секцията „Администриране“, означават, че нямат право да задават дата за забрана на промени в документи от предишни периоди.

Синхронизиране на данни с други програми

Този профил ви позволява да конфигурирате режима за обмен на данни. Впоследствие, в съответствие с направените настройки, се осигурява обмен между ТРЗ и счетоводни програми. По подразбиране ролите на този профил са достъпни само за администратори: „Администриране > Синхронизиране на данни“.

Трябва да се помни, че профилите „Отваряне на външни отчети и обработка“, „Управление на дати на забрана“ и „Синхронизиране на данни с други програми“ не са самодостатъчни. Това означава, че ако създадете група за достъп с някой от тези профили и свържете потребител само към него, тогава, когато се опита да отвори програмата, ще получим съобщение.

Това показва, че създадената група за достъп няма задължителни роли, свързани с нея, което я прави самодостатъчна.

Заключение

Планираните начисления могат да се задават не само от потребители с профил „Калкулатор” и по-горе, но и от потребители с профил „HR” и по-горе. Но нито планираните, нито еднократните служители на персонала имат право да назначават удръжки.

Достъпът до настройките „HR Accounting” и „Payroll Calculation” е достъпен само за потребители с пълни права. Висшият мениджър по персонала няма такива права.

За да се разграничат потребителските права, по правило предварително инсталираните профили са напълно достатъчни. Ако е необходимо, можете да създадете нови профили. В същото време, за да създадете самодостатъчен профил, той трябва да включва някои задължителни роли, като например „Стартиране на тънък клиент“, „Основни права“ и т.н. На практика е по-лесно да направите копие на профила, който е най-близък по отношение на правата и след това го редактирайте, ако е необходимо.

Всички настройки на потребителските права, които ще направим в рамките на тази статия, се намират в раздел 1C 8.3 „Администриране“ - „Настройки на потребител и права“. Този алгоритъм е подобен в повечето конфигурации на управлявани формуляри. Програмата 1C Accounting ще бъде използвана като пример, но настройката на правата в други програми (1C UT 11, 1C ZUP 3, 1C ERP) се извършва по абсолютно същия начин.

Нека отидем в секцията „Потребители“ на прозореца с настройки. Тук виждаме две хипервръзки: „Потребители“ и „Настройки за влизане“. Първият от тях ви позволява да отидете директно до списъка с потребители на тази информационна база. Преди да създадете нов потребител, нека разгледаме възможните настройки за влизане (хипервръзка вдясно).

В тази форма за настройки можете да конфигурирате сложността на паролата (най-малко 7 знака, задължително съдържание от различни типове знаци и т.н.). Можете също така да посочите дължината на паролата, нейния период на валидност и да забраните на потребителите да влизат в програмата, ако не са били активни за определен период от време.

Сега можете да продължите директно към добавяне на нов потребител към 1C. Това може да стане, като щракнете върху бутона „Създаване“, както е показано на изображението по-долу.

На първо място, ще посочим пълното име - „Дмитрий Петрович Антонов“ и ще изберем физическо лице от съответната директория. Тук можете да посочите и отдела, в който работи наш служител.

Името за вход „AntonovDP“ автоматично беше заменено с абревиатура на пълното име „Дмитрий Петрович Антонов“. Нека да настроим парола и удостоверяване на 1C Enterprise. Тук можете също да посочите дали този потребител може да промени паролата си самостоятелно.

Да кажем, че искаме Дмитрий Петрович Антонов да бъде наличен в списъка за избор при стартиране на тази информационна база. За да направите това, трябва да поставите отметка в квадратчето до елемента „Показване в списъка за избор“. В резултат на това прозорецът за оторизация при стартиране на програмата ще изглежда както е показано на фигурата по-долу.

Нека обърнем внимание на друга важна настройка в картата на потребителския указател - „Входът в програмата е разрешен“. Ако забавянето не е зададено, тогава потребителят просто няма да може да влезе в тази информационна база.

Права за достъп

След като попълним всички данни в потребителската карта - Дмитрий Петрович Антонов, ще ги запишем и ще преминем към настройка на правата за достъп, както е показано на фигурата по-долу.

Пред нас се отвори списък с профили за достъп, въведени преди това в програмата. Поставете отметки в квадратчетата, които са задължителни.

Достъп до групови профили

Профилите на групата за достъп могат да бъдат конфигурирани от главния потребител и формата за настройка на правата. Отидете в секцията „Групи за достъп“ и щракнете върху хипервръзката „Профили на групи за достъп“.

Нека създадем нова група от формата със списък, която се отваря. В табличния раздел на раздела „Разрешени действия (роли)“ поставете отметки в квадратчетата за онези роли, които ще повлияят на правата за достъп на потребителите, включени в групата, която създаваме. Всички тези роли се създават и конфигурират в конфигуратора. Те не могат да се променят или да се създават нови от потребителски режим. Можете да избирате само от съществуващия списък.

RLS: Ограничение за достъп на ниво запис

Позволява ви по-гъвкаво да конфигурирате достъпа до програмни данни в определени области. За да го активирате, поставете отметка в квадратчето със същото име във формата за настройки на потребителя и правата.

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

Нека отидем на профила на групата за достъп „Тестова група“, който създадохме по-рано. Фигурата по-долу показва, че след активиране на ограниченията за достъп на ниво запис се появява допълнителен раздел „Ограничения за достъп“.

Да приемем, че искаме потребителите, присвоени на тестова група, да имат достъп до данни за всички организации в тази информационна база, с изключение на тези, посочени в профила.

В горната таблична част ще зададем ограничения за достъп по организации. В долната част ще поясним, че достъп до данни (документи, директории и др.) няма да бъде предоставен на организацията „Roga LLC“.