Juurdepääsu saab programmis seadistada mitmes kohas, kuid soovitatav on seda teha kasutajaprofiili jaoks. Me läheme administraatori profiilile ja mida me näeme?

Seadeväärtuste redigeerimine on keelatud. See on täiesti normaalne ja te ei tohiks proovida neid mujale installida. Süsteem lihtsalt mõtleb kui kasutajal on üks rollidest - " Täielikud õigused", siis on talle kõik lubatud,sõltumata lisaõiguste seadistustest. Seetõttu pole mõtet neid üles seada. Teiste profiilide puhul on lisaõigused sobivad.

Täiendavaid õiguste seadistusi saab teha mitte ainult profiili, vaid ka rühma ja jaoks konkreetne kasutaja.

Kuidas süsteem käitub, kui kasutaja ja tema profiili lisaõiguste väärtused ei ühti? Võib tunduda, et süsteem peaks sel juhul kasutama õiguse väärtust, seatud kasutajale, kui täpsem. Aga see pole tõsi! Profiiliõiguste prioriteet on kõrgem kui kasutajarühmal ja kasutajal.Olles profiili väärtuse õigesti lugenud, ei vaata programm isegi seda, mis seal grupi jaoks on määratud, mistõttu on vaja see profiilis seadistada.

Miks on siis võimalik grupi ja kasutaja õigusi täita, kui neid nagunii ei kasutata? Ja neid kasutatakse siis, kui kasutajale pole profiili antud. Milliseid õigusi süsteem sel juhul võtab? Vaatame konfiguraatorist:

Funktsioon ReadValueUserRight (parem, vaikeväärtus, kasutaja) ReturnValues= Uus massiiv ; Taotlus = uus taotlus; Request.SetParameter("Kasutaja", Kasutaja); Request.SetParameter( "Kasutaja õigused", Seadus); Taotlus.Tekst = „VALI LUBATUD ERINEVAD | RegisterValueRightValue|ALT | Inforegister.Kasutaja täiendavate õiguste väärtused AS Register Õiguste väärtus|KUS | RegisterValueRight.Right = &UserRight | Ja RegisterValueRight.UserB| (VALI | UsersGroups.Link AS Link| FROM | Directory.UserGroups.UsersGroups AS UsersGroups| KUS | UsersGroups.User = &Kasutaja | | KOMBINEERI KÕIK| | VALI | VÄÄRTUS (kataloog.Kasutajarühmad.Kõik kasutajad) | | KOMBINEERI KÕIK| | VALI | &kasutaja)"; Näidis = Taotlus. Käivita (). Vali(); Kui proovivõtt. Kogus() = 0 Siis ReturnValues. Lisa(vaikeväärtus); Muidu Hüvasti valik. Järgmine() Loop ReturnValues. Lisa(Valik.Väärtus); EndCycle; endIf; tagastama ReturnValues; EndFunction

Funktsioon tagastab kasutaja, kasutajarühma ja rühma Kõik kasutajad jaoks määratud õiguste väärtuste massiivi.

Funktsioon RightIsUser (parem, vaikeväärtus) ArrayRightValues ​​​​= GetUserRightValue (parem, vaikeväärtus); Tagasta ArrayValuesRights.Find(True)<>Määratlemata; EndFunction

Ärge unustage rühma "Kõik kasutajad". See hõlmab kõiki süsteemi kasutajaid, kuid harva vaatab keegi, millised õigused sellele on määratud. Samuti mitte õige otsus määrab selle rühma väärtuse, kui soovime, et see kehtiks kõigile kasutajatele. Kordan, profiilil on kõrgem prioriteet, selles peaksite muutma täiendavaid õigusi.

Tasub ka lisada, et süsteem ei loe seda registrit iga kord, vaid asetab andmed pärast esimest lugemist vahemällu ja võtab sealt seejärel andmed. Seetõttu jõustub kasutajale määratud väärtus alles järgmisel seansil.

Niisiis, teeme kokkuvõtte:

Kui kasutajal on roll "Täielikud õigused", siis ei pea ta lisaõiguste väärtusi määrama. Kui kasutajale antakse profiil, võetakse vastava profiili väärtus. Kui profiil pole määratud, loeb süsteem grupi, kasutaja ja grupi "Kõik kasutajad" väärtused ja valib ühe vastavalt põhimõttele: kui see on lubatud ühes kohas, siis on see lubatud kõik.

Ja seega peame lisama süsteemile juurdepääsuõigused, et AINULT teavet VAATA, ilma muutmis- või muutmisõiguseta.

Kasuta standardne funktsionaalsus ei ole võimalik, kuna samal rollil "Kasutaja" UCP-s on õigus mõnda kataloogi muuta. Lisaks peate looma õigused, mis ei sõltu täiendavatest kasutajaõigustest ja mida on üsna lihtne konfigureerida (nii et peate märkima ainult ühe ruudu).

Lahendus

Lahendus ise on üsna lihtne mitme nüansiga. Lisame konfiguratsioonile uue rolli "DEV_ViewOnly". Selles määrame iga konfiguratsiooni metaandmete objekti jaoks lugemise, vaatamise ja vastuvõtmise õigused.

Uute objektide edasiarendamise ja hilisema õiguste seadmise mugavuse huvides seame valiku “Määra õigused uutele objektidele”.

Juba praegu, lisades selle rolli kasutajale, anname talle juurdepääsu enamuse andmebaasitabelite lugemiseks/vaatamiseks. Standardmehhanism ei võimalda aga süsteemis töötada, kui kasutajale pole määratud standardset “Kasutaja” rolli. Teeme selle korda. Moodulis regulaarne rakendus sündmuste käitlejas "Enne süsteemi käivitumist" parandame saadaoleva rolli "Kasutaja" kontrolli:

// Enne süsteemi käivitumist// Protseduur enne süsteemi töö alustamist (tõrge) Kui EI RoleAvailable(" Kasutaja ") JA (NOT RoleAvailable(" Täielikud õigused ") ) JA EI RoleAvailable(" DEV_ViewOnly" ) Seejärel hoiatus(" Sulle rolli pole määratud" "Kasutaja" " . Konfigureerimist ei saa käivitada." ) ; Failure = True ; Return ; EndIf ; Failure = NOT User Management. UserDefined() ; //IBVersiooni värskendamine Keeldumine = Kliendi teabebaasi värskendamisest keeldumine VÕI MITTE uuendada. PossibleUpdateInformationBase(); // Lõpeta IB-versiooni värskendamine Menetluse lõpp

Sest korralik toimimine konfiguratsiooni, lisame ja muudame ka üldisest moodulist "Kasutajahaldusserver" ekspordifunktsiooni "Kasutaja on lubatud käivitada konfiguratsiooni" tingimust:

Funktsioon UserAllowedRunConfiguration() Ekspordi, kui EI RoleAvailable("Kasutaja") AND (NOTRoleAvailable("Täielikud õigused")) // !!! Lubame käivitada rolli "DEV_ViewOnly" jaoks!!! AND (NOT RoleAvailable(" DEV_ViewOnly" ) ) Seejärel tagasta Väär; EndIf; Tagasta Tõene; EndFunction //

Viimase sammuna tuleb saadaolevad kasutajarollid automaatselt kustutada teabebaas, kui sellesse on installitud roll "DEV_ViewOnly". Pärast puhastamist jätke ainult see roll. Tuletan meelde, et vaikimisi lisab süsteem saadaolevatele rollidele alati rolli “Kasutaja”.

Enne kataloogielemendi "Kasutajad" salvestamist kustutame rollide loendi. Siin programmi kood töötleja enne kataloogi kirjutamist:

Toiming DEV_BeforeRecordUserBeforeRecord(Allikas, Keeldumine) Ekspordi UserIB = teabebaasi kasutajad. FindByUniqueIdentifier (Source.IBUserIdentifier); Kui UserIB< >Määratlemata Siis Rollid = IB kasutaja. Rollid; Kui Roli. Sisaldab (Metaandmed. Rollid. DEV_ViewOnly) Seejärel rollid. Clear() ; Rollid. Add(Metadata. Rolls. DEV_ViewOnly) ; EndIf ; IB kasutaja. Kirjuta() ; EndIf ; Menetluse lõpp

Ärge unustage lisada rollile "DEV_ViewOnly" õigusi programmi käivitamiseks täiskliendirežiimis, õhuke klient ja veebiklient, vastasel juhul ei saa kasutaja lihtsalt programmi käivitada. Vajadusel määrake muud juurdepääsuõigused.

Režiimis 1C: Enterprise

Pärast loodud rolli määramist kasutajale saab ta vaadata teabebaasis kogu teavet.

Kasutaja ei saa ühtegi kataloogikirjet muuta ega dokumendi postitamist tühistada.

Programmil 1C on sisseehitatud juurdepääsuõiguste süsteem, mis asub jaotises Configurator - General - Roles.

Kuidas seda süsteemi iseloomustatakse ja mis on selle peamine eesmärk? See võimaldab kirjeldada õiguste komplekte, mis vastavad kasutaja positsioonidele või tegevuste tüüpidele. See süsteem juurdepääsuõigused on oma olemuselt staatilised, mis tähendab, et kuna administraator määras juurdepääsuõigused 1C-le, nii see ka on. Lisaks staatilisele on olemas ka teine ​​juurdepääsuõiguste süsteem - dünaamiline (RLS). Selles süsteemis arvutatakse juurdepääsuõigused dünaamiliselt, sõltuvalt antud parameetrid, sisse tööprotsess.

Rollid 1C-s

Kõige tavalisemate turvaseadete juurde erinevaid programme on nn lugemis-/kirjutamisluba erinevad rühmad kasutajad ja tulevikus: konkreetse kasutaja kaasamine või väljaarvamine rühmadest. Sellist süsteemi kasutatakse näiteks operatsioonisüsteem Windows AD ( Active Directory). Kasutatud turvasüsteem tarkvara 1C, sai nime - rollid. Mis see on? Rollid 1C-s on objekt, mis asub haru konfiguratsioonis: Üldine - Rollid. Need 1C rollid on rühmad, millele on õigused määratud. Edaspidi saab iga kasutaja sellesse gruppi kaasata või sellest välja jätta.

Topeltklõpsates rolli nimel, avate rolli õiguste redaktori. Vasakul on objektide loend, märkige mõni neist ja paremal näete võimalike juurdepääsuõiguste valikuid:

— lugemine: kirjete või nende osaliste fragmentide hankimine andmebaasi tabelist;
— uute kirjete lisamine olemasolevate salvestamise ajal;
- muuta: muudatuste tegemine olemasolevaid kirjeid;
— kustutamine: mõned kirjed, ülejäänud muutmata jätmine.

Pange tähele, et kõik juurdepääsuõigused saab jagada kahte põhirühma - see on "lihtne" õigus ja see on täpselt õige, kui on lisatud "interaktiivne" tunnus. Mida see tähendab? Ja point on selles.

Juhul, kui kasutaja avab vormi, näiteks töötleb, ja samal ajal klõpsab sellel hiirega, hakkab programm sisseehitatud 1C keeles tegema konkreetseid toiminguid, näiteks kustutama dokumente. "Lihtsalt" 1C õigused vastutavad selliste toimingute lubamise eest programmis.

Juhul, kui kasutaja avab päeviku ja hakkab klaviatuurilt midagi iseseisvalt sisestama (näiteks uusi dokumente), vastutavad selliste toimingute lubamise eest 1C “interaktiivsed” õigused. Igal kasutajal on korraga juurdepääs mitmele rollile, seejärel liidetakse õigused.

RLS 1C-s

Saate lubada juurdepääsu kataloogile (või dokumendile) või selle keelata. Te ei saa seda "natuke sisse lülitada". Selleks on 1C rollisüsteemi teatud laiendus, mida nimetatakse RLS-iks. See dünaamiline süsteem juurdepääsuõigustega, millega kehtestatakse osalised juurdepääsupiirangud. Näiteks muutuvad kasutajale kättesaadavaks ainult teatud organisatsiooni ja lao dokumendid, ülejäänuid ta ei näe.

Tuleb meeles pidada, et RLS-süsteemi tuleb kasutada väga ettevaatlikult, kuna selle keerulist skeemi on üsna raske mõista, erinevad kasutajad Samas võib tekkida küsimusi, kui võrreldakse näiteks sama aruannet, mis on loodud erinevatelt kasutajatelt. Vaatleme seda näidet. Valite konkreetse kataloogi (näiteks organisatsioonid) ja konkreetse õiguse (näiteks lugemise), see tähendab, et lubate lugemist 1C rolli jaoks. Sel juhul määrate kaugpaneelil Data Access Restrictions päringu teksti, mille järgi määratakse see olenevalt seadetest kas Väär või Tõene. Tavaliselt salvestatakse sätted spetsiaalsesse teaberegistrisse.

See päring täidetakse dünaamiliselt (kui proovite lugemist korraldada) kõigi kataloogikirjete jaoks. See toimib järgmiselt: need kirjed, millele turvapäring on määratud – Tõsi, kasutaja näeb, aga teised mitte. 1C õigused kehtestatud piirangud, esile tõstetud halliga.

Kopeerimisoperatsioon samad seaded RLS toodetakse mallide abil. Alustuseks loote malli, nimetades seda näiteks MyMalliks, milles kajastate turbetaotlust. Seejärel määrake juurdepääsuõiguste sätetes selle malli nimi järgmiselt: "#MyMall".

Kui kasutaja töötab režiimis 1C Enterprise, võib RLS-iga ühenduse loomisel ilmuda tõrketeade, näiteks: "Ebapiisavad õigused" (näiteks kataloogi XXX lugemiseks). See näitab, et RLS-süsteemil on mõne kirje lugemine blokeeritud. Selle teate uuesti ilmumise vältimiseks peate päringu teksti sisestama sõna ALLOWED.

   

Muudatusõigus ja toimetamisõigus – mis vahe on?

Milles täpselt erinevus seisneb?

Lühidalt:
Muuda- määrab objekti muutmise võimaluse/võimatuse üldse.
Redigeerimine- kannab interaktiivset tähendust.

Rohkem detaile:

Interaktiivsed ja põhiõigused

Kõik süsteemi 1C:Enterprise toetatud õigused võib jagada kaheks suured rühmad: põhiline ja interaktiivne. Põhiõigused kirjeldavad süsteemi andmeelementidega või kogu süsteemis tervikuna tehtavaid toiminguid ning neid kontrollitakse alati, olenemata sellest, kuidas andmetele ligi pääsetakse. Interaktiivsed õigused kirjeldavad toiminguid, mida kasutaja saab interaktiivselt teha. Seetõttu kontrollitakse neid ainult interaktiivsete toimingute tegemisel standardseid meetodeid kasutades, ja sisse klient-server versioon Kõik õiguste kontrollid (v.a interaktiivsed) tehakse serveris.

Põhiõigused ja interaktiivsed õigused on omavahel seotud. Näiteks on olemas põhiõigus nimega Kustuta, millel on kaks interaktiivset õigust: Interaktiivne eemaldamine ja lipuga märgitute interaktiivne eemaldamine. Kui kasutajal on keelatud kustutada, siis on tema jaoks keelatud ka kõik interaktiivsed kustutamised. Samal ajal, kui kasutajal on lubatud interaktiivselt kustutada märgitud üksusi, tähendab see, et tal on lubatud ka kustutada.

Pealegi võivad põhiõigused üksteisest sõltuda. Selle tulemusena moodustuvad üsna keerulised seoste ahelad, mida süsteem jälgib automaatselt: niipea, kui arendaja mõne õiguse loa eemaldab, eemaldab süsteem ise kõigi sellest õigusest sõltuvate õiguste load. Ja vastupidi, kui arendaja määrab õiguse, installib süsteem ise kõik õigused, millest see õigus sõltub.

Näiteks selleks, et kasutajal oleks märgitud üksuste interaktiivse kustutamise õigus, peab tal olema interaktiivse redigeerimise õigus. See õigus nõuab omakorda interaktiivset õigust Vaade:

Õige Märgistatud interaktiivne eemaldamine Eemaldus. Interaktiivne seadus Redigeerimine nõuab põhiõigust Muuda. Interaktiivne seadus Vaade nõuab põhiõigust Lugemine.

Lisaks põhiõigused Muuda Ja Eemaldus nõuavad põhiõigust Lugemine.

Samuti võite olla huvitatud

Igas mitmikmängus raamatupidamissüsteem kasutajaõigused tuleks jagada vastavalt töökohustused töötaja. Suured ettevõtted pööra sellele tähelepanu Erilist tähelepanu, sest Mida suurem on ettevõte, seda rohkem on infosüsteemis andmeid ning seda suurem on kokkupõrgete ja vigade tõenäosus. Mida saab vale pakkuda? kasutajaõiguste seadistamine:

Ebapädev andmesisestus

- andmete muutmine suletud perioodil või tagasiulatuvalt
- kasutajate ebajärjekindlad muudatused andmetes, töötamine sama dokumendi (objekti) kallal erinevates kohtades

Nagu näete, on mitut tüüpi vigu, mida kasutajad võivad tahtmatult sisse tuua. Seega võivad kattumised õiguste jaotamisega kaasa tuua äärmiselt ebasoovitavaid tagajärgi. Peamised:

Dokumentide laskumine elektroonilisel ja trükitud kujul
- lahknevused juhtimises ja raamatupidamises
- valed kaubajäägid ladudes
- valed aruanded ostude, müügi, tootmise kavandatud teostamise kohta
- vale planeerimine ja prognoosimine
- käibepõhise palgaplaanide vale arvestus, lisatasude alamaksmine jms.
- täiendavad tööjõukulud vigade või tagasiulatuvalt tehtud kohanduste leidmiseks ja parandamiseks

Need on peamised Negatiivsed tagajärjed valesti konfigureeritud kasutajaõigused. Saate seda loendit täiendada oma vigadega, mis ilmnesid 1C-s valesti konfigureeritud kasutajaõiguste tõttu.
Õigesti kavandatud Infosüsteem Kui mitte täielikult loetletud vigu vältida, siis neid minimeerida ja prognoositavamaks muuta. Mida me mõtleme sõna etteaimatav all? Näiteks kui kasutajaõigused on konfigureeritud nii, et eelmise numbri andmed võivad muutuda piiratud arv kasutajaid, siis kitseneb vea eest vastutava töötaja otsing. Lisaks antakse juurdepääs millegi tagantjärele muutmiseks kas süsteemiadministraatoritele või kõige vastutustundlikumatele töötajatele, kes suhtuvad protsessi tasakaalustatult, vastutades kõigi tehtud muudatuste eest.
Tinglikult kõike kasutajaõigused versioonis 1C (8.1 / 8.2) võib jagada:
- vaadata andmeid
- andmesisestus
- sisestatud andmete muutmine
- kustutamine

Tavaliselt saab kõik kasutajaõiguste sätted jagada tarkvaraks (teostatakse konfiguraatoris) ja kasutajaks (teostatakse 1C Enterprise'is).

ÕIGUSTE SEADISTAMINE KONFIGURAATORI LÄBI

Allpool on näide dokumendi "Kaubade ja teenuste müük" kasutajaõiguste "Haldur" seadistamisest koos õigusega luua ja postitada dokumenti ning keelata konfiguraatori režiimis redigeerimine ja tagasiulatuvad muudatused.

Kõiki neid parameetreid saab määrata kas kõikidele programmiobjektidele või konfigureerida igaühe jaoks eraldi. Näiteks: kasutaja saab sisestada ja redigeerida kirjet kataloogis "Nomenklatuur", kuid tal on õigus vaadata ainult "Kaubade müügi" dokumente.
Õiguste seadmisel on samuti väga oluline kõigega arvestada tööfunktsioonid töötaja, et ei tekiks kasutajaõiguste liigset “pigistamise” olukorda, et ta ei saaks oma kohustusi täita. Sel juhul aitab iga konfiguratsiooniobjekti jaoks eraldi õiguste üksikasjalik konfigureerimine.
Sest õiged seadistused õigused punktis 1C, peaks töö läbi viima programmi administraator koos ärianalüütiku või osakonnajuhiga. Töökohustuste korrektsemaks tõlkimiseks programmi saavad nemad aidata töökirjeldus töötajaid, kui neid on, et programmi administraator saaks paremini aru, milliseid funktsioone töötaja täpselt täidab. Samuti on soovitatav infole mugavamaks ligipääsuks kasutada programmiliideseid (maske). Liides on menüüüksuste ja ikoonide komplekt kiire juurdepääs keskendunud teatud tegevusele kuulumisele: hankimine, müük, varud, sularaha, täis. Õigesti valitud või konfigureeritud liides tagab programmi mugavama kasutamise ja välistab liigse programmikoormuse mittevajalikud funktsioonid jne. Kuid pidage meeles, et mõned funktsioonid ja liidese ikoonid võivad olla nähtavad, kuid mitte kasutajale kättesaadavad, kui tal pole vaatamisõigusi. Need. Menüüelemendi olemasolu liideses ei taga selle jaotise üksuse vaatamist ega andmete sisestamist.

ÕIGUSTE SEADISTAMINE 1C ETTEVÕTTE KAUDU

Välja arvatud tarkvarapiirangud dokumentide, muude 1C objektide kataloogide haldamiseks ja redigeerimiseks saate dokumentide automaatse asendamise hõlbustamiseks konfigureerida ka lisaõigusi: organisatsioonid, käibemaksumäärad, peamine tarnija, jaotus, dokumendi koostamise koht jne. Sageli võivad automaatse asendamise väärtused, mis on konfigureeritud, oluliselt lihtsustada esmaste dokumentide sisestamist ja välistada korduvate detailide pideva valimise dokumentidesse.

Pärast kasutaja valimist, kes peab seadistusi tegema, algab seadistus ise, valides parameetrid ja märgistades vajalikud ruudud:

Lõpetama täielik kohandamine tuleb konfigureerida täiendavad kasutajaõigused

Ja nagu kasutaja põhiseadete seadistamisel, tehke lisaseadeid:

Oleme esitanud mõned väljavõtted 1C programmis kasutaja juurdepääsuõiguste määramise põhireeglitest. Õigeks konfigureerimiseks soovitame võtta ühendust 1C administraatorite või 1C programmide hooldusteenuseid pakkuvate ettevõtetega.
Kui teil on vaja konfigureerida, eraldada kasutajaõigused 1C-s või vajate nõu, võtke meiega abi saamiseks ühendust. Me töötame otse või eemalt võrdse efektiivsusega.