Cinci pași de setare - acces la directoare la nivel de înregistrare. Caietul unui programator Restricţionarea accesului la nivel de înregistrări în 1s

Configurarea accesului la nivelul intrărilor din director.

Această setare a fost inclusă în configurație nu cu mult timp în urmă, personal cred că setarea este foarte utilă.

Această setare este necesară pentru cei care trebuie să restricționeze accesul la director în contextul elementelor acestui director. De exemplu, un manager trebuie să vadă doar cumpărătorii, precum și rapoartele și jurnalele de documente, numai pentru contrapărțile la care are acces, iar un contabil trebuie să aibă acces complet la toate elementele directorului, de exemplu, „Contrapărți”. .

Propun să luăm în considerare un exemplu pe exemplul configurației SCP.

În această etapă, este necesar să se definească un set de grupuri de utilizatori.

Administratori;

directori de vanzari;

manageri de achizitii;

În a doua etapă, sunt definite grupuri de acces la director.

Cumpărători;

Furnizori;

De obicei, listele de grupuri de mai sus sunt discutate cu conducerea și abia apoi introduse în program.

Acum este necesar să descriem setările reale care trebuie efectuate în 1C.

Activați „Acces restricționat la nivel de înregistrare”. Serviciu - gestionarea utilizatorilor și accesului - Opțiuni de acces la nivel de înregistrare. Vezi fig. 1.

Se va deschide formularul de procesare „Parametri de acces la nivel de înregistrare”, vezi Fig. 2.

Pe acest formular, trebuie să activați efectiv restricția, pentru care este responsabil indicatorul „Restricționați accesul la nivel de înregistrare după tipuri de obiecte” și să selectați acele directoare pentru care se va aplica restricția. Acest articol tratează numai directorul „Contrapărți”.

Mai mult, acele grupuri de utilizatori și contrapărți care au fost definite la începutul articolului ne vor fi utile.

Grupurile de contrapărți sunt înscrise în cartea de referință „Grupuri de utilizatori”, vezi Fig. 3.

Se va deschide forma elementului de referință „Grupuri de utilizatori”, vezi Fig. 4.

În partea stângă a ferestrei este indicat obiectul de acces (avem „antreprenori”), în dreapta sunt indicați utilizatorii care fac parte din grup, în acest exemplu, aceștia sunt „Administratori”.

Pentru fiecare grup de utilizatori pe care îl definiți, trebuie să efectuați această setare, nu ar trebui să existe un singur utilizator care să nu fie inclus în grup.

În al treilea pas, trebuie să introduceți „Acces grupuri de contrapărți”, directorul „Acces grupuri de contrapartide” este responsabil pentru acest lucru. Vezi fig. 5.

Pentru exemplul nostru, acestea sunt: Cumpărători, Furnizori, Alții. Vezi fig. 6.

În această etapă, trebuie să atribuiți un grup de acces fiecărui element din directorul „contrapărți”. Vezi fig. 7.

Un grup de acces pentru o contrapartidă este atribuit în fila „altă parte”. De obicei folosesc o prelucrare standard auxiliară pentru a atribui date de grup. „Procesarea în grup a directoarelor și documentelor”, vă permite să setați masiv grupul dorit pentru acest atribut.

Această etapă este etapa culminantă. În această etapă se configurează accesul „grupurilor de utilizatori” la „grupurile de acces la cont”; acesta se configurează folosind procesarea „Setarea drepturilor de acces la nivel de înregistrare”, vezi Fig. 8.

Raportul dintre grupurile de utilizatori și grupurile de acces de contrapărți este evidențiat cu roșu. Pentru grupurile „Manageri Achiziții” și „Directori de vânzări” relațiile sunt configurate în același mod, sunt indicate doar obiectele de acces la care ar trebui să aibă acces, de exemplu, doar „Furnizori” sau doar „Cumparatori”. Steaguri, de exemplu „Vizibilitatea în listă” sunt drepturile „Obiectului de acces”. Din denumire cred că și funcționalitatea acestor drepturi este clară.

După manipulările de mai sus, ar trebui să aveți acces diferențiat la directorul „Contrapărți”.

Prin analogie, sunt configurate alte directoare.

Important:

Accesul limitat nu se aplică rolului „FullPermissions”;

Setul de roluri de utilizator trebuie să conțină rolul „Utilizator”;

Dacă aveți propriile roluri, atunci trebuie să introduceți șabloane și restricții în rolul dvs. ca în rolul „Utilizator” în raport cu directorul „Contractanți” (vezi codul din Rolul Utilizator făcând clic pe directorul contrapărților).

Cum se stabilesc drepturile de acces în programul 1C 8.3?

În acest articol, vom lua în considerare cum să lucrăm cu utilizatorii în 1C Accounting 8.3:

creați un utilizator nou
configurați drepturi - profiluri, roluri și grupuri de acces
cum să configurați o restricție de drepturi la nivel de înregistrare (RLS) în 1C 8.3 - de exemplu, în funcție de organizație

Instrucțiunea este potrivită nu numai pentru programul de contabilitate, ci și pentru multe altele construite pe baza BSP 2.x: 1C Trade Management 11, Payroll și HR 3.0, ERP 2.0, Small Business Management și altele.

În interfața programului 1C, gestionarea utilizatorilor se realizează în secțiunea „Administrare”, în elementul „Configurarea utilizatorilor și a drepturilor”:

Cum se creează un utilizator nou în 1C

Pentru a crea un utilizator nou în 1C Accounting 3.0 și pentru a-i atribui anumite drepturi de acces, în meniul „Administrare” există un element „Setări utilizator și drepturi”. Noi mergem acolo:

Lista utilizatorilor este gestionată în secțiunea „Utilizatori”. Aici puteți crea un utilizator nou (sau grup de utilizatori) sau puteți edita unul existent. Numai un utilizator cu drepturi administrative poate gestiona lista de utilizatori.

Să creăm un grup de utilizatori cu numele „Contabil”, și în el doi utilizatori: „Contabil 1” și „Contabil 2”.

Pentru a crea un grup, apăsați butonul care este evidențiat în figura de mai sus și introduceți un nume. Dacă în baza de informații există și alți utilizatori care sunt potriviți pentru rolul de contabil, îi puteți adăuga imediat la grup. În exemplul nostru, nu există, așa că facem clic pe „Salvați și închideți”.

Acum să creăm utilizatori. Plasați cursorul pe grupul nostru și faceți clic pe butonul „Creați”:

Introduceți „Accountant 1” în numele complet, setați numele de conectare la „Account1” (va fi afișat la intrarea în program). Parola va fi „1”.

Asigurați-vă că sunt bifate casetele „Conectarea la program este permisă” și „Afișați în lista de selecție”, altfel utilizatorul nu se va vedea pe sine în timpul autorizării.

Lăsați „Modul de pornire” ca „Automat”.

Setarea drepturilor de acces - roluri, profiluri

Acum trebuie să specificați „Permisiuni” pentru acest utilizator. Dar mai întâi trebuie să-l notați, altfel va apărea o fereastră de avertizare, așa cum se arată în figura de mai sus. Faceți clic pe „Scrie”, apoi pe „Permisiuni”:

Selectați profilul „Contabil”. Acest profil este standard și configurat pentru drepturile de bază cerute de un contabil. Faceți clic pe „Înregistrare” și închideți fereastra.

În fereastra „Utilizator (Creare)”, faceți clic pe „Salvați și închideți”. De asemenea, creăm un al doilea contabil. Ne asigurăm că utilizatorii sunt autentificați și pot lucra:

Trebuie remarcat faptul că același utilizator poate aparține mai multor grupuri.

Am ales drepturi de acces pentru contabili dintre cele care au fost incluse implicit în program. Dar există situații când este necesar să adăugați sau să eliminați un drept. Pentru a face acest lucru, este posibil să vă creați propriul profil cu un set de drepturi de acces necesare.

Să mergem la secțiunea „Acces la profiluri de grup”.

Să presupunem că trebuie să permitem contabililor noștri să vadă registrul.

Crearea unui profil de la zero este destul de laborioasă, așa că haideți să copiem profilul „Contabil”:

Și îi vom face modificările necesare - vom adăuga rolul „Vedeți jurnalul de înregistrare”:

Dați noului profil un alt nume. De exemplu, „Contabil cu completări”. Și bifați caseta „Vizualizați jurnalul de înregistrare”.

Acum trebuie să schimbați profilul utilizatorilor pe care i-am creat anterior.

Restricționarea drepturilor la nivel de înregistrare în 1C 8.3 (RLS)

Să ne dăm seama ce înseamnă să restricționezi drepturile la nivel de înregistrare sau așa cum o numesc în 1C - RLS (Securitate la nivel de înregistrare). Pentru a obține această funcție, trebuie să bifați caseta corespunzătoare:

Programul va necesita confirmarea acțiunii și va raporta că astfel de setări pot încetini foarte mult sistemul. De multe ori este necesar ca unii utilizatori să nu vadă documentele anumitor organizații. Doar pentru astfel de cazuri, există o setare de acces la nivel de înregistrare.

Ne întoarcem la secțiunea de gestionare a profilului, facem dublu clic pe profilul „Contabil cu suplimente” și mergem la fila „Restricțiuni de acces”:

„Tip de acces” selectați „Organizații”, „Valori de acces” selectați „Toată lumea este permisă, excepțiile sunt atribuite în grupuri de acces”. Faceți clic pe „Salvați și închideți”.

Acum revenim la secțiunea „Utilizatori” și selectăm, de exemplu, utilizatorul „Contabil 1”. Faceți clic pe butonul „Permisiuni”:

Prin butonul „Adaugă”, selectează organizația, ale cărei date vor fi văzute de „Contabil 1”.

Notă! Utilizarea mecanismului de diferențiere a drepturilor la nivel de înregistrare poate afecta performanța programului în ansamblu. Notă pentru programator: esența RLS este că sistemul 1C adaugă o condiție suplimentară la fiecare solicitare, solicitând informații despre dacă utilizatorul are voie să citească aceste informații.

Alte setari

Secțiunile „Setări de copiere” și „Ștergerea setărilor” nu provoacă întrebări; numele lor vorbesc de la sine. Acestea sunt setări pentru aspectul programului și rapoartelor. De exemplu, dacă ați configurat un aspect frumos al cărții de referință „Nomenclatură”, o puteți replica altor utilizatori.

În secțiunea „Setări utilizator”, puteți modifica aspectul programului și puteți face setări suplimentare pentru ușurință în utilizare.

Caseta de selectare „Permite accesul utilizatorilor externi” vă permite să adăugați și să configurați utilizatori externi. De exemplu, doriți să organizați un magazin online bazat pe 1C. Clienții magazinului vor fi doar utilizatori externi. Drepturile de acces sunt configurate în același mod ca utilizatorii obișnuiți.

Sursa: programmer1s.ru

Un rol este un obiect de metadate, datorită căruia se determină ce obiect și ce acțiuni poate efectua un anumit utilizator asupra acestui obiect. Fiecare rol conține drepturi și, în funcție de drepturile pe care le stabilește administratorul bazei de date, va avea loc controlul accesului. Platforma tehnologică prevede două tipuri de drepturi, acestea sunt: de bază și interactive. Principalele drepturi sunt Citire, Modificare, Adăugare și Ștergere. Interactive sunt efectuate numai atunci când se efectuează operațiuni precum editarea sau ștergerea sub forma: ștergere interactivă, adăugare interactivă și altele.

Astfel, puteți activa o dată pentru totdeauna accesul la un anume director, document și alt obiect de metadate și în întregime. Puteți oferi acces sau puteți lua. Nu poți da puțin. Dar la urma urmei, apare adesea o situație când, de exemplu, există un director uriaș și fiecare utilizator ar trebui să vadă doar anumite elemente în el. Adică, în funcție de o anumită condiție, trebuie să aibă loc selecția elementelor obiectului! Și acum, începând cu versiunea platformei tehnologice 1C 8.1, a apărut un mecanism foarte puternic de restricționare a accesului la date la nivel de înregistrare numit RLS (Record Level Security). Restricțiile sunt un set de anumite condiții în care accesul va fi acordat sau nu.

Restricțiile de acces la utilizarea unui sistem RLS dinamic se aplică operațiunilor de bază: Citire, Modificare, Adăugare și Ștergere. Există o caracteristică importantă, și anume că mai multe restricții la nivel de înregistrare pot fi aplicate operației de citire, în timp ce numai o singură condiție este aplicată tuturor celorlalte operațiuni. Acest mecanism vă permite să impuneți restricții nu numai asupra anumitor înregistrări, ci și asupra anumitor câmpuri ale înregistrărilor. La ceea ce poate fi necesar să specificați un câmp, precum și un câmp special<Прочие поля>.

Sintaxă și limbaj RLS

Limbajul de restricție a datelor nu este altceva decât un limbaj de interogare, dar foarte mult redus. Dacă condiția este TRUE, atunci utilizatorului curent i se acordă acces la date, dacă este FALS, atunci refuz. Care sunt principalele diferențe față de un limbaj de interogare cu drepturi depline?

Există întotdeauna un singur tabel de date într-o interogare RLS și este de fapt folosit pentru condiții.
Se folosesc doar construcții FROM și WHERE.
În astfel de condiții, puteți specifica opțiuni funcționale și parametri de sesiune ca parametri de interogare.
Mesele virtuale nu sunt permise.
Puteți folosi șabloane pentru a crea restricții
Operatorii TOTAL și ÎN IERARHIE nu sunt aplicabili.

Luați în considerare cum să faceți restricții. de exemplu în fig. 1 arată cea mai simplă constrângere. Constă în faptul că utilizatorul va vedea o singură contraparte cu un nume specific „Sibirskaya Korona LLC”. Puteți filtra după un anumit câmp. De exemplu, dorim ca utilizatorul să vadă doar conturile care se află în folderul părinte „Angajați”.

Textul constrângerii poate fi tastat fie manual, fie, de asemenea, folosind generatorul de interogări familiar. În acest caz, generatorul de interogări nu va fi, de asemenea, cu drepturi depline, dar va fi dotat cu restricții pentru RLS. De asemenea, puteți trece orice parametri & la interogarea de restricție.

Cum funcționează restricțiile

Uneori, atunci când folosește RLS, utilizatorul poate primi o eroare care afirmă că nu există suficiente drepturi. Acest lucru se poate datora modului în care funcționează constrângerile.

TOATE. Adică, în procesul de impunere a restricțiilor, operația se efectuează pe toate datele necesare bazei de date. Cu toate acestea, la citirea și modificarea datelor, dacă restricțiile nu sunt îndeplinite pentru unele înregistrări, atunci apare o blocare din cauza încălcărilor de acces.
PERMIS. Un mod de funcționare în care, ca urmare a impunerii restricțiilor, să fie citite doar acele înregistrări care îndeplinesc condițiile. În acest caz, nu există accidente. Obiectele care nu îndeplinesc cerințele sunt considerate lipsă.

Metoda PERMIS este foarte des folosită la generarea listelor dinamice, altfel ar apărea constant erori de încălcare a drepturilor. Metoda ALL este utilizată la achiziționarea de obiecte folosind funcțiile 1C:Enterprise și de interogare. De fapt, unde sunt instalate aceste metode? Valoarea implicită este ALL.

Utilizarea șabloanelor în RLS

Pentru o utilizare mai convenabilă a restricțiilor în sistemul 1C Enterprise, este oferită utilizarea șabloanelor. Adică dacă folosești aceeași restricție sau știi că va diferi doar în unii parametri, atunci îți creezi propriul șablon. Astfel, în general este posibil să se aranjeze un cod de restricție repetat ca procedură.Șablonul are un nume și un text. Textul conține codul programului de restricții, în el, precum și în procedură, puteți utiliza parametri, iar parametrii se disting prin prefixul #.

Luați în considerare utilizarea șabloanelor încorporate folosind exemplul de configurare 1C: Accounting 8.2. Deschideți rolul CONTABIL și accesați fila Șabloane de constrângeri. Aici șablonul BasicConditionReading este folosit cu următorul conținut:

Unde vedem #Parameter(1)=UserAccessRightSettings.AccessObject. Acesta este chiar parametrul care se poate modifica în funcție de datele transmise. În plus, în orice loc în care dorim să introducem restricții, folosim un șablon ca acesta:

Adică în loc de

#Parameter(1)=AccessRightSettingsUsers.AccessObject

în textul șablonului va fi

Organization=UserAccessRightSettings.AccessObject.

Sau pe un șablon mai simplu. Numele șablonului #MyRestrictions cu următorul conținut:

WHERE #Parameter(1) = &CurrentUser

Ca urmare a transmiterii parametrilor șablonului #MyRestrictions(„Executor”), obținem următoarele

WHERE Artist= &CurrentUser.

Rezultate

Mecanismul de restricționare a accesului la date la nivel de înregistrare este un lucru foarte puternic, dar configurarea lui necesită multă experiență, deoarece vă puteți pierde cu ușurință în aceste „sălbăticii”. Datorită acesteia, se poate face orice diferențiere parțială a datelor. Pe de altă parte, adăugarea diferitelor condiții duce la o scădere a performanței sistemului, deși nesemnificativă. Deoarece platforma 1C adaugă solicitări suplimentare sub formă de restricții la cererea utilizatorului. În toate celelalte privințe, acesta este doar un lucru grozav pentru dezvoltatori!

În sistemul 1C Enterprise 8, astăzi vom continua să studiem mecanismul drepturilor și să aprofundăm în continuare mecanismul RLS (restricționarea drepturilor la nivel de înregistrare).

Mai jos vom lua în considerare avantajele și dezavantajele acestei metode și vom lua în considerare configurarea RLS în 1C Enterprise 8.3 folosind un exemplu.

1С RLS (Securitate la nivel de înregistrare) sau restricție de drepturi la nivel de înregistrare- acestea sunt drepturi de utilizator în sistemul 1C, care vă permite să împărțiți drepturile pentru utilizatori în contextul modificării dinamice a datelor.

Cel mai comun tip de setare 1C RLS este limitarea vizibilității utilizatorului în ceea ce privește organizațiile sau clienții (utilizatorul vede doar datele „lui”).

Principalul avantaj este prezența unui mecanism în general, mecanismul este destul de complex și interesant. Vă permite să diferențiați foarte fin drepturile utilizatorilor - este posibil ca utilizatorii să nu fie conștienți de existența altor date în sistem.

Dezavantajele 1C 8 RLS

Printre deficiențe, se poate remarca o scădere vizibilă a performanței sistemului. Acest lucru se datorează faptului că platforma, atunci când construiește o interogare în baza de date, complică orice interogare a dezvoltatorului cu condiții suplimentare.

Printre deficiențe se numără și complexitatea instalării acestei funcționalități și complexitatea depanării. 1C a lansat foarte puține materiale despre configurarea și operarea acestei funcționalități. Este destul de dificil să găsești un specialist care să configureze corect mecanismul.

Configurarea restricțiilor de drepturi la nivel de înregistrare 1C RLS

Restricționarea drepturilor la nivel de înregistrare (RLS) este utilizată pentru a restricționa următoarele tipuri de drepturi:

Citind
Addendum
Schimbare
Îndepărtarea

Obțineți 267 de lecții video 1C gratuit:

În exterior, configurarea RLS (drepturi la nivel de înregistrare) este similară cu compunerea unui simplu . Un exemplu de șablon pentru restricționarea accesului la vizibilitatea documentelor de către client din antetul documentului:

##Dacă &Utilizați restricții de acces la nivel de înregistrare ##Atunci

CurrentTable FROM #CurrentTable AS CurrentTable
LEFT JOIN (ALEGE DIFERIT
CompositionGroup.Reference AS GroupUsers
DIN
Directory.UsersGroups.UsersGroups Membrii grupului AS
UNDE
CompositionGroup.User = &CurrentUser) AS GroupUsers
Software (&UseAccessPermissionRestrictionsAtRecordLevel)
WHERE (&UseRecordLevelAccessPermissionRestrictions = FALSE
SAU (NU 1 V
(ALEGE PRIMUL 1
1 AS FieldSelection
DIN
Registrul de informații.Atribuirea tipurilor de obiecte de acces AS Atribuirea tipurilor de obiecte de acces
UNDE
AssigningAccessObjectTypes.UserGroup = UserGroups.UserGroup
ȘI ALEGEREA
WHEN AssigningAccessObjectTypes.AccessObjectType = VALUE(Enumeration.AccessObjectTypes.Contractors)
Și CurrentTable.#Parameter(1) LINK Directory.Counterparties
ȘI NU CurrentTable.#Parameter(1) = VALUE(Catalog.Contractors.EmptyReference)
APOI ALEGEREA
CÂND 1 V
(ALEGE PRIMUL 1
1
DIN
Director.Conturi AS Contractori
DE
Drepturi de acces SettingsUsers.AccessObject = Accounts.AccessGroupToAccount
Și UserAccessRightsSettings.AccessObjectType = VALUE(Enumeration.AccessObjectTypes.Contractors)
ȘI (SettingsAccessRightsUsers.User = AssignmentTypesAccessObjects.GroupUsers
SAU UserAccessRightsSettings.User = VALUE(Reference.UserGroups.AllUsers))
Și UserAccessPermissionSettings.Record = TRUE
UNDE
Counterparties.Link = CurrentTable.#Parameter(1))
ATUNCI ADEVARAT
ALTE FALS
Sfârşit
ALTE ADEVĂRAT
Sfârșit = FALS))
ȘI NU UserGroup.UserGroup ESTE NULL)
##EndIf

De fapt, această interogare este adăugată de fiecare dată când se face o interogare la tabelul „#CurrentTable”. Din care ne putem imagina ce sarcină suplimentară poartă mecanismul de restricție la nivel de înregistrare.

După cum puteți vedea, există parametri speciali în cerere, de exemplu „&UseRecordLevelAccessPermissionRestrictions”. Acești parametri din radar sunt selectați din obiectele metadate - „”. De regulă, acestea sunt setate la începutul sesiunii utilizator.

Constructor de restricții de acces la date

Pentru comoditatea dezvoltatorului, 1C 8.3 are un utilitar special pentru a vă ajuta să configurați radarul - Data Access Restriction Constructor. Este apelat din câmpul „Restricție de acces”. După cum urmează:

Adesea este nevoie de a restricționa parțial accesul la date. De exemplu, atunci când un utilizator trebuie să vadă documente numai pentru organizația sa. În astfel de cazuri, 1C utilizează un mecanism de restricție de acces la nivel de înregistrare (așa-numitul RLS - Record Level Securiy).

De exemplu, să presupunem că ne confruntăm cu următoarea sarcină. Întreprinderea menține o contabilitate multi-societate și fiecare contraparte și utilizator al bazei de date aparține unei anumite organizații. Este necesar să se ofere acces la directorul „Contractanți” în așa fel încât fiecare utilizator să poată vizualiza, edita și adăuga contrapartide numai în organizația sa.

Pentru a rezolva problema, vom folosi platforma „1C:Enterprise 8.2″. Să creăm o nouă configurație în proprietățile căreia opțiunea „Aplicație gestionată” va fi selectată ca mod principal de lansare.

În continuare, să creăm directorul „Organizații” și încă două directoare - „Contractanți” și „Utilizatori” cu atributul „Organizație”. În plus față de directoare, avem nevoie de doi parametri de sesiune - „Organizare” și „Utilizator” (de tipurile adecvate). Valorile acestor parametri sunt setate la începutul unei sesiuni de configurare și sunt stocate până la sfârșit. Sunt valorile acestor parametri pe care le vom folosi atunci când adăugăm condiții de restricție de acces la nivel de înregistrare.

Parametrii de sesiune sunt setați într-un modul special - „Modul de sesiune”

În acest modul, descriem procedura predefinită „SetSessionParameters” în care numim funcția modulului general pre-preparat „FullPermissions”. Acest lucru este necesar din cauza particularităților funcționării bazei de date în modul aplicație gestionată, când o parte din codul programului poate fi executată numai pe partea serverului (nu mă voi opri asupra explicarii acestor principii în acest articol).

Cod 1C v 8.x Procedură Setarea parametrilor sesiunii (parametri obligatorii)
FullPermissions.SetSessionParameters();
EndProcedure

În proprietățile modulului „FullPermissions”, bifați casetele „Server”, „Apel server” și „Privilegiat” (cel din urmă înseamnă că procedurile și funcțiile acestui modul vor fi executate fără control de acces). Textul modulului va arăta astfel:

Cod 1C v 8.x Funcția DetermineCurrentUser()
CurrentUser = Directories.Users.FindByName(UserName(), True);
Returnează Utilizatorul curent;
EndFunctions

Procedură SetSessionParameters() Export
CurrentUser = Determină CurrentUser();
CurrentOrganization = Directories.Organizations.EmptyReference();
Dacă ValueFilled(CurrentUser) Atunci
CurrentOrganization = CurrentUser.Organization;
EndIf;
SessionParameters.User = CurrentUser;
SessionParameters.Organization = CurrentOrganization;
EndProcedure

FunctionSessionParameterSet(ParameterName) Export
Returnează ValoareaCompletată(SessionParameters[ParameterName]);
EndFunctions

Funcția RoleAvailableToUser(RoleName) Export
Returnează RoleAvailable(RoleName);
EndFunctions

În modulul aplicației gestionate, vom verifica prezența unui utilizator de configurare în directorul „Utilizatori” (pentru simplitate, îl vom căuta după nume) și vom închide sistemul dacă nu este găsit. Acest lucru este necesar pentru a vă asigura că parametrii sesiunii sunt populați.

Cod 1C v 8.x Procedura de funcționare pre-sistem (Eșec)
// toți, cu excepția administratorului, vor fi verificați pentru prezența în directorul „Utilizatori”.
Dacă nu este FullPermissions.RoleAvailableToUser(„FullPermissions”), atunci
Dacă NU FullPermissions.SessionParameterSet(„Utilizator”), atunci
Avertisment ("Utilizator """ + Nume utilizator() + """ nu a fost găsit în director!");
Respingere = adevărat;
Întoarcere;
EndIf;
EndIf;
EndProcedure

Acum putem merge direct la descrierea restricțiilor de acces. Pentru a face acest lucru, creați rolul „Utilizator” și mergeți la fila „Șabloane de restricții”, unde adăugăm un nou șablon „AccountsReadingChange” cu următorul text șablon: WHERE Organizație = Organizație #Parametru(1)

Textul șablonului de constrângere este o extensie a limbajului de interogare. Spre deosebire de o cerere obișnuită, textul de restricție trebuie să conțină în mod necesar clauza „UNDE”. Ca valori ale parametrilor de interogare (în cazul nostru, este „&Organization”), sunt folosite valorile parametrilor de sesiune cu același nume. O construcție a formei #Parameter(1) înseamnă că sistemul va înlocui textul trecut ca prim parametru în locul în care șablonul este folosit în acest loc. Cu ajutorul șablonului dat, fiecare înregistrare a tabelului va fi verificată (în cazul nostru, va fi căutarea „Contractanți”). Pentru înregistrările a căror valoare de atribut „Organizare” se potrivește cu cea specificată în parametrul de sesiune corespunzător, condiția descrisă în șablon va fi îndeplinită. Astfel, aceste înregistrări vor fi disponibile pentru citire, editare sau adăugare (în funcție de care dintre aceste drepturi se aplică șablonul). Voi demonstra cele de mai sus cu exemplul nostru.

Să mergem la fila „Drepturi” a rolului „Utilizator” și să deschidem lista de drepturi din directorul „Conturi”. Vom folosi șablonul de constrângere „AccountsReadChange” pentru permisiunile „Citire”, „Schimbare” și „Adăugați”.

Pentru dreptul „Citește”, vom folosi un șablon cu parametrul „OR ThisGroup”. În același timp, utilizatorilor acestui rol li se va permite să citească nu numai elementele directorului „Conturi” al organizației lor, ci și toate grupurile acestui director.

#AccountsReadingChange(„SAU AcestGrup”)

Deoarece la adăugarea de noi elemente ale directorului, sistemul realizează o citire implicită a atributelor predefinite (acest lucru este necesar, de exemplu, pentru numerotare), este necesar să se asigure citirea nestingherită a acestor câmpuri. Pentru a face acest lucru, adăugați o linie suplimentară cu un text de restricție gol la tabelul de restricții de acces la date și enumerați câmpurile pentru care se aplică această regulă - Link, Versiune date, Părinte, Cod.

Astfel, sarcina restricționării accesului la nivel de înregistrare este rezolvată. Utilizatorii cu restricții existente vor avea acces să vizualizeze și să editeze date numai pentru organizația lor.