Î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.
1C 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
- Schimbarea
- Î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
PE
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
SFARSIT
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ă:
RLS- aceasta este capacitatea dezvoltatorului de a seta o condiție pe tabelele bazei de date pentru anumiți utilizatori (grupuri de utilizatori) și de a le împiedica să vadă prea multe. Condiția este de tip boolean. Dacă valoarea condiției este adevărată, atunci accesul este acordat, în caz contrar, acesta este refuzat.
RLS este utilizat în același timp cu setarea permisiunilor normale. Prin urmare, înainte de a începe configurarea RLS, trebuie să distribuiți drepturile obișnuite asupra obiectelor de configurare.
RLS se aplică următoarelor tipuri de drepturi de acces:
- Citind
- Addendum
- Schimbarea
- Îndepărtarea
Cum se setează RLS
Să ne uităm la un exemplu simplu de configurare. Capturile de ecran au fost făcute pe versiunea 1C Enterprise 8.2 (8.2.9.356). Sintaxa șabloanelor de text de constrângere este descrisă în documentația pentru 8.2 din cartea „Ghidul dezvoltatorului. Partea 1”, așa că nu ne vom opri asupra ei.
Deci, primul pas este definirea șabloanelor de restricții pentru fiecare rol existent.
După aceea, pe baza șabloanelor specificate, sunt stabilite restricții pentru obiectele necesare. Pentru a edita textul condiției, puteți utiliza Data Access Restriction Builder.
Pentru a edita mai multe roluri, este convenabil să gestionați prin fereastra „Toate rolurile”.
Puteți utiliza fereastra Restricții de acces total pentru a copia condițiile în alte roluri. Șabloanele pentru alte roluri pot fi copiate numai manual.
Asta e tot. Puteți verifica rezultatul.
Dezavantajele utilizării RLS:
- Utilizarea mecanismului de restricție a accesului la nivel de înregistrare duce la o creștere implicită a tabelelor implicate în interogare, ceea ce poate duce la erori în modul client-server al bazei de date.
- Pentru controlul scrierii, poate fi dificil sau imposibil să implementați logica complexă a aplicației. În astfel de cazuri, este mai bine să folosiți condițiile din procedura OnWrite().
- Scrierea unei condiții (cereri) necesită o anumită calificare a dezvoltatorului.
- Dificultăți suplimentare pot fi create de imposibilitatea depanării condiției (cererii).
În configurațiile tipice, drepturile la nivel de înregistrare pot fi setate interactiv pentru următoarele obiecte: organizații, contractori, articole de stoc, depozite, divizii, persoane fizice, aplicații candidate și altele.
Trebuie amintit că restricțiile privind drepturile de acces la nivel de înregistrare sunt un mecanism care necesită destul de mult resurse, iar cu cât le setați restricții mai complexe, cu atât programul va funcționa mai lent, în special cu o bază de date mare.
Toate setările pentru drepturile utilizatorului pe care le vom face în cadrul acestui articol se află în secțiunea 1C 8.3 „Administrare” - „Setări pentru utilizatori și drepturi”. Acest algoritm este similar în majoritatea configurațiilor pe formularele gestionate. Programul 1C Accounting va fi folosit ca exemplu, dar setarea drepturilor în alte programe (1C UT 11, 1C ZUP 3, 1C ERP) se face exact în același mod.
Să mergem la secțiunea „Utilizatori” din fereastra de setări. Aici vedem două hyperlinkuri: „Utilizatori” și „Setări de conectare”. Primul dintre ele vă permite să mergeți direct la lista de utilizatori a acestei baze de informații. Înainte de a crea un utilizator nou, luați în considerare posibilele setări de conectare (hiperlink în dreapta).
În acest formular de setări, puteți seta complexitatea parolei (cel puțin 7 caractere, conținut obligatoriu de diferite tipuri de caractere etc.). Aici puteți specifica și durata parolei, perioada de valabilitate a acesteia și interzicerea accesului la program pentru utilizatorii care nu au avut activitate de o anumită perioadă de timp.
Acum puteți trece direct la adăugarea unui nou utilizator la 1C. Puteți face acest lucru făcând clic pe butonul „Creați”, așa cum se arată în imaginea de mai jos.
În primul rând, indicăm numele complet - „Antonov Dmitry Petrovici” și selectăm o persoană din directorul corespunzător. Aici puteți specifica și departamentul în care lucrează angajatul nostru.
Numele de conectare „AntonovDP” a fost înlocuit automat ca abreviere pentru numele complet „Antonov Dmitri Petrovici”. Setați o parolă și o autentificare pentru 1C Enterprise. Aici puteți specifica, de asemenea, dacă acestui utilizator îi este permis să schimbe singur parola.
Să presupunem că dorim ca Dmitri Petrovici Antonov să fie disponibil în lista de selecție atunci când începem această bază de informații. Pentru a face acest lucru, trebuie să setați steagul pe elementul „Afișați în lista de selecție”. Ca urmare, fereastra de autorizare la pornirea programului va arăta ca cea prezentată în figura de mai jos.
Să acordăm atenție unei alte setări importante din cardul ghidului utilizatorului - „Este permisă conectarea la program”. Dacă decalajul nu este setat, atunci utilizatorul pur și simplu nu va putea intra în această bază de informații.
Drepturi de acces
După completarea tuturor datelor din cardul de utilizator - Antonov Dmitry Petrovici, le vom nota și vom trece la setarea drepturilor de acces, așa cum se arată în figura de mai jos.
Înainte de a ne deschide o listă de profiluri de acces introduse anterior în program. Bifați casetele necesare.
Accesați profilurile de grup
Profilurile grupurilor de acces pot fi configurate din formularul principal pentru setarea utilizatorilor și drepturilor. Accesați secțiunea „Grupuri de acces” și faceți clic pe hyperlinkul „Profiluri de acces de grup”.
Să creăm un grup nou din formularul de listă deschis. În secțiunea tabelară din fila „Acțiuni (roluri) permise”, este necesar să bifați casetele pentru acele roluri care vor afecta drepturile de acces ale utilizatorilor incluși în grupul pe care îl creăm. Toate aceste roluri sunt create și configurate în configurator. Ele nu pot fi modificate sau create din modul utilizator. Puteți alege doar dintr-o listă existentă.
RLS: restricție de acces la nivel de înregistrare
Vă permite să configurați mai flexibil accesul la datele programului în anumite secțiuni. Pentru a-l activa, setați steag pe elementul cu același nume în formularul de setări de utilizator și drepturi.
Vă rugăm să rețineți că activarea acestei setări poate afecta negativ performanța sistemului. Ideea este că mecanismul RLS modifică toate cererile în funcție de restricțiile setate.
Să mergem la profilul de grup de acces „Grup de testare” pe care l-am creat mai devreme. Figura de mai jos arată că după activarea restricției de acces la nivel de înregistrare a apărut o filă suplimentară „Restricțiuni de acces”.
Să presupunem că dorim ca utilizatorii cărora le este atribuit grupul de testare să aibă acces la datele pentru toate organizațiile din această bază de informații, cu excepția celor specificate în profil.
În secțiunea tabelară de sus, setați restricția de acces în funcție de organizație. În partea de jos, vom preciza că nu se va asigura accesul la date (documente, directoare etc.) pentru organizația Roga SRL.
Cea de-a opta versiune a platformei 1C:Enterprise (astăzi 8.3) a adus o mulțime de modificări în raport cu cei „șapte”, printre care mecanismul de restricționare a drepturilor de acces la nivel de înregistrare a fost deosebit de proeminent. Deși teoretic te poți descurca fără el, folosind doar roluri, RLS vă permite să reglați accesul. Dar pentru funcționarea corectă a acestui mecanism, trebuie să înțelegeți clar esența acestuia și să aveți suficientă experiență în dezvoltarea în 1C.
Ce este RLS?
Esența acestei funcționalități constă în capacitatea dezvoltatorului de a împiedica un anumit utilizator sau grup de utilizatori să acceseze tabelele sau câmpurile din tabelele bazei de date. De obicei, restricțiile sunt folosite pentru a împiedica utilizatorii 1C să vadă și să editeze informații confidențiale, secrete, de exemplu, restricționând angajații unei companii care face parte dintr-un grup de a vizualiza documente numai pentru organizația lor. De asemenea, mecanismul de restricționare a drepturilor de acces la nivel de înregistrare poate fi folosit pentru a elimina informațiile inutile din interfață.
Pentru a putea scrie cereri pentru restricții RLS, trebuie să creați un rol sau să luați unul existent. Setarea RLS din 1C 8.3 poate fi utilizată pentru următoarele acțiuni ale utilizatorului:
- Plus;
- Citind;
- Îndepărtarea;
- Schimbarea.
Pe lângă cele mai largi posibilități de configurare a accesului, RLS are și dezavantaje:
- Cerințe de calificare a dezvoltatorului, deoarece interogarea va trebui scrisă în limbajul încorporat, ținând cont de regulile de sintaxă;
- Incapacitatea de a depana rapid condițiile;
- Posibilitati limitate de descriere a logicii: conditii prea complexe vor trebui inca scrise in modulele de documente si directoare;
- În versiunea client-server a bazelor de date este posibilă creșterea implicită a tabelelor incluse în interogare. Mai mult, este foarte dificil de urmărit acest proces;
- cerințele de resurse. Limitele RLS consumă multă putere de mașină client și server;
- Puțină documentație este disponibilă gratuit.
O altă problemă care poate apărea după configurarea 1C RLS poate fi rapoartele. Faptul este că dezvoltatorii anticipează posibile restricții RLS și construiesc rapoarte în așa fel încât să arate numai datele permise. Dacă utilizatorii au configurate limite RLS diferite, atunci datele din raport pentru aceiași parametri pot fi diferite pentru ei. Acest lucru poate ridica întrebări, așa că atunci când proiectați rapoarte sau scrieți interogări în RLS, trebuie să luați în considerare astfel de situații.
Crearea unei constrângeri RLS
Pentru a adăuga o restricție RLS, trebuie să găsiți rolul dorit și să îl deschideți făcând dublu clic.
Fereastra care se deschide conține 2 file: „Drepturi” și „Șabloane de restricții”. Pentru a impune anumite restricții asupra unei anumite acțiuni, trebuie să o selectați și să faceți clic pe plusul verde din partea dreaptă jos. Va apărea o linie în care putem seta restricții 1C RLS în limbajul 1C încorporat.
Dacă cunoașteți sintaxa 1C (cum ar fi dosul mâinii), atunci puteți scrie direct în câmpul „Restricție de acces”. Dezvoltatorii 1C au oferit posibilitatea de a deschide constructorul de interogări, care vă va ajuta și vă va spune pe ce se poate face restricția. Pentru a-l deschide, trebuie să faceți clic pe butonul cu trei puncte (Selectare) sau F4 și va apărea o fereastră cu butonul „Query Builder ...”.
În fereastra care apare, puteți configura restricții nu numai pentru acest director, ci și pentru alte obiecte de sistem. Pentru a face acest lucru, trebuie să le adăugați în fila „Tabele și câmpuri”. Prescriem restricții pe câmpurile cărții de referință „Nomenclatură” și facem clic pe „OK”. Atenție la numele variabilelor: parametrii RLS sunt setați la începutul sesiunii utilizator și trebuie să fie conținute în obiectul de metadate.
În fila „Șabloane de restricții”, sunt setate interogări care sunt necesare atunci când copiați aceleași setări RLS în 1C 8.3. După ce ați adăugat șablonul, puteți utiliza numele acestuia în setările drepturilor de acces.
De asemenea, este posibil să adăugați restricții pentru mai multe roluri în același timp. Pentru a face acest lucru, în arborele de configurare, faceți clic dreapta pe secțiunea „Roluri” și selectați elementul „Toate rolurile”.
În concluzie, aș dori să remarc că acest articol se adresează consultanților dezvoltatori 1C și îi poate ajuta, în primul rând, pe cei care aveau deja experiență de dezvoltare pe 1C:Enterprise. În ciuda simplității aparente, cunoașterea semanticii și înțelegerea structurii proceselor de afaceri ale propriei întreprinderi sau organizației clienților pentru distribuirea corectă a drepturilor necesită un anumit nivel de cunoștințe și experiență.
Platforma 1C:Enterprise 8 are un mecanism încorporat pentru restricționarea accesului la date la nivel de înregistrare. Puteți citi informații generale despre el aici. Pe scurt, RLS vă va permite să restricționați accesul la date în funcție de anumite condiții pe valorile câmpului. De exemplu, puteți restricționa accesul utilizatorilor la documente în funcție de valoarea atributului „Organizație”. Unii utilizatori vor lucra cu documente pentru organizația „Management Company”, iar restul cu organizația „Dairy Plant”. Ca exemplu.
Instruire
Exemplul este implementat în configurația demonstrativă a SCP 1.3. Să creăm un utilizator „Storekeeper” și să îi adăugăm rolul „Storekeeper” cu același nume.
Acum să trecem direct la setarea drepturilor de acces la nivel de înregistrare. Să trecem la interfața „Administrare utilizatori”. În meniul principal, selectați „Acces la nivel de înregistrări -> Opțiuni”. Aici bifăm caseta „Restricționați accesul la nivel de înregistrare după tipuri de obiecte”, iar în lista de obiecte selectați „Organizații”.
Astfel, am activat utilizarea RLS. Acum trebuie să-l configurați.
Controlul accesului la nivel de înregistrare nu este configurat separat pentru fiecare utilizator sau profil de permisiune. RLS este configurat pentru grupuri de utilizatori. Să adăugăm un nou grup de utilizatori, să-l numim „Depozitari”
Compoziția grupului din partea dreaptă a formularului arată o listă de utilizatori care aparțin acestui grup. Să adăugăm utilizatorul pe care l-am creat mai devreme. În stânga este un tabel cu restricții de acces. În setarea RLS, am ales ca accesul să fie limitat doar de organizații, așa că vedem un singur tip de obiect de acces. Faceți clic pe butonul „Setări de acces”. Se deschide procesarea pentru setarea permisiunilor pentru grupul curent.
În lista de obiecte de acces pentru grup, adăugați organizația „PPE „Antreprenor””. Vom lăsa neschimbat tipul de moștenire a drepturilor. Dreptul la obiectul de acces va fi setat la citire și scriere. Faceți clic pe „OK”, setările sunt gata. Tocmai am înființat RLS la nivel de organizație.
Ce vede utilizatorul
Rulați programul sub utilizatorul creat anterior și deschideți directorul „Organizații”. Iată cum va arăta lista pentru utilizatorul nostru și pentru un utilizator cu drepturi depline:
După cum putem vedea, utilizatorul depozitar vede o singură organizație pentru care am deschis accesul la citire. Același lucru este valabil și pentru documente, cum ar fi recepțiile de bunuri și servicii.
Astfel, utilizatorul nu numai că nu va vedea organizații, accesul la care nu este setat pentru el, dar nici nu va putea citi/scrie documente și alte obiecte din baza de info, pentru care drepturile în rol pe atributul „Organizație”. " sunt setate.
Am luat în considerare cel mai simplu exemplu de configurare a RLS. În articolul următor, vom vorbi despre implementarea mecanismului RLS în configurația „Manufacturing Enterprise Management” versiunea 1.3.
