Групи за достъп за физически лица 1в. Добавяне на нов потребител и присвояване на права за него

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“

Edition 2.0" създайте нов потребител и му задайте необходимите права. За да направите това, отидете в секцията „Администриране“. Изберете елемента от менюто „Настройки на потребителя и правата“. Тук отиваме в директорията „Потребители“.

Нека добавим нов потребител. Да посочим името му - Иванов Иван Иванович. Нека поставим отметка, че достъпът до информационната база е разрешен. Ние автоматично ще попълним вашето име за вход в информационната база данни. Можем също да зададем парола за потребителя. Ще бъде поискано при влизане. Попълваме го два пъти. Можем също да използваме удостоверяване на операционната система, ако сме го конфигурирали. Къде можем да избираме потребители и потребителски списъци в нашата система. И тогава ще бъде възможно да деактивирате „1:C Enterprise Authentication“. Потребителят ще влезе автоматично в системата, без да въвежда парола. Този тип удостоверяване е най-удобен за работа в разпределени мрежови системи.

В следващата стъпка трябва да посочим лице за нашия нов потребител. Да отидем в директорията "Физически лица". Нека създадем нов. Посочваме фамилията, собственото име и бащиното име. Моля, посочете датата си на раждане – задължително е. А на следващия етап може би ни очаква изненада.

Трябва да посочим групата за достъп за дадено лице, тъй като използваме достъп на ниво запис до директорията на лицата. Тези. Всеки потребител на информационната база може да има достъп до определена секция от директория „Лични лица”, посочена в отделна йерархия, наречена „Групи за достъп на лица”. В този случай той не е попълнен, така че не можем да го изберем в нашите данни.

Да се ​​върнем към „Настройки на потребителя и правата“. Да намерим „Групи за достъп за физически лица“. И нека създадем елементите на тази директория. Нека създадем група за достъп – „Enterprise Employees“. И нека създадем група за достъп – „Контрагенти“. Можете да използвате различни групи за достъп за лица във вашата информационна база данни. Например, можете също да ги разделите на клиенти и доставчици. Можете да използвате разделянето на лицата по конкретни мениджъри, които работят с тях. Можете да организирате регионален клон на групи от хора.

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

Да се ​​върнем към потребителя. Сега можем да изберем лицето Иванов Иван Иванович. И запишете нашия елемент по абсолютно същия начин. Новият потребител е записан и сега трябва да предоставим на новия потребител правата, с които ще работи в системата.

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

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

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

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

Следващото ниво на предоставяне на права е „групи за достъп“. Една група за достъп съответства на един профил на група за достъп. Въпреки това можем да използваме един и същ профил на група за достъп в няколко различни групи за достъп. За какво е всичко това? Групите за достъп разширяват възможността за ограничаване на потребителския достъп до базата данни. Какво означава? Това означава, че имаме един профил с определени роли, но в групите за достъп описваме какви допълнителни ограничения са наложени на този профил.

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

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

Нека да видим какъв вид група е това, как е структурирана, от какво се състои. Както виждаме, за групата е зададен профил. И можем също да видим членовете на нашата група за достъп. Тук, тъй като има отделни потребители, например Иванов Иван Иванович, когото добавихме. Тук има и потребителски групи, за които ще говорим малко по-късно. Тези. Можете да добавите както отделен потребител, така и група от потребители. И също така допълнително описва ограниченията за достъп до отделни директории.

Нека да видим как е структуриран профилът на групата за достъп. Отворете профила на счетоводителя. И тук виждаме набор от роли, които са присъщи на този профил на група за достъп. Също така в раздела „Ограничения за достъп“ са посочени ограниченията, присъщи на този профил.
Сега нека разберем какво представляват потребителските групи. Да преминем към групите на Иван Иванович Иванов. Ето само списък с групи. Както виждаме, Иван Иванович Иванов не е включен в нито една от групите. Нека го включим в групата „счетоводители“, като просто щракнем върху квадратчето. И щракнете върху бутона „Запис“.

Сега да преминем към „Права за достъп“. И тук ще видим, че Иван Иванович Иванов автоматично влезе през потребителската група „счетоводители“ в групата за достъп „счетоводители“. Тези. По този начин имаме два начина за присвояване на права на потребителите. Например, нека добавим нашия Иванов Иван Иванович към друга група, например „складари“. Щракнете върху „Запис“. Нека отидем в директорията "Потребители". Тук виждаме само списък с потребители без йерархия. Ако отидем в групата „счетоводители“, тогава ще видим Иван Иванович Иванов в групата „счетоводители“. Също така, ако отидем в групата „складари“. В групата “складари” ще видим и Иван Иванович Иванов.

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

Печат (Ctrl+P)

Настройки за потребители и права

Програмата осигурява едновременна работа на няколко потребителя. Броят на потребителите на програмата е технически неограничен (броят на едновременните потребители е ограничен само от броя на наличните лицензи).

Ако само един потребител ще работи с програмата, тогава няма нужда да го добавяте към списъка с потребители.

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

списък с потребители

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

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

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

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

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

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

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

Когато има малък брой потребители (или когато има само един потребител), обикновено не са необходими групи.

Потребителски настройки

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

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

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

Докато работи с програмата, потребителят може да персонализира съдържанието и външния вид на различни форми - например да изключи показването на отделни детайли, за да освободи място във формуляра. За да направите това, всички формуляри имат команда Редактиране на формуляр.

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

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

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

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

Можете да ограничите достъпа:

■ към всички обекти от определен тип (например, всички документи за заплати не са достъпни за служител по персонала);

■ към някои от техните копия (например документите за заплати на друга организация не са достъпни за служителя по заплати на една организация) - така нареченото ограничение на достъпа на ниво запис.

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

Забележка
Не трябва да използвате конфигурационния режим, за да конфигурирате потребители и права за достъп. Настройването на потребителски права за достъп трябва да се извършва само с помощта на групи за достъп в режим 1C:Enterprise.

Групи за достъп и профили на групи за достъп

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

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

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

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

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

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

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

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

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

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

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

Доставени профили на групи за достъп

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

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

■ Служител по персонала (без достъп до заплата). Различава се от служителя по персонала по това, че не е налице преглед и промяна на планираната ведомост;

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

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

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

В подсистемата " Контрол на достъпа“, включени в 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 се осигурява с минимални промени в подсистемата. В случай, че критерият (или предметът) за ограничаване на правата за достъп е голям и непрекъснато се разширява (например директория " Контрагенти"), тогава е възможно чрез вашата допълнителна директория (инструмент за разграничаване) да разделите критерия (или темата) за достъп на определени области ( в нашия случай чрез "Групи за достъп на контрагенти"), в противен случай самите елементи на директорията могат да се използват като разделител за достъп (и има смисъл) (например в директорията " организации"). Безспорно предимство на използването на подсистемата е и унифицирането на администрирането на правата за достъп в информационната база.

Публикации по темата