Išleidus 1C:Enterprise 8.2 platformą, konfigūracijos medyje pasirodė naujas objektas - „Funkcinės parinktys“. Jis aktyviai naudojamas visose tipinėse konfigūracijose, pagrįstose valdomomis formomis, ir padeda supaprastinti rodymo procesą individualios detalės, objektai sąsajoje. Pavyzdžiui, jūsų konfigūracijoje yra modulis, skirtas keistis su išorinėmis žiniatinklio paslaugomis. Šiame modulyje naudojama daugybė dokumentų, registrų ir atskirų posistemių komponentų detalių. Modulis yra neprivalomas ir nebūtinas kiekvienai įmonei. Logiška, kad kadangi modulio reikia ne visiems, tai taip pat ne visada būtina rodyti visus su juo susijusius elementus/laukelius.

Senesnėse platformos versijose sprendžiant tokias problemas reikėjo parašyti papildomą kodą, kurį reikėjo iškviesti visose priklausomose skyriuose. Pavyzdžiui, jei reikėjo paslėpti tam tikras formos detales (priklausomai nuo nustatymo reikšmės), tada atidarant formą reikėjo iškviesti atitinkamą kodą. Tai nebuvo labai patogu ir daugeliu atvejų kūrėjai atsisakė tokių dalykų.

Gerai, jei laukelius reikia paslėpti tik dokumentų pavidalu, tačiau galime turėti ir registro formas, su kuriomis galimas ir vartotojo sąveika. Universalios ekrano valdymo funkcijos parašymas yra gana sunkus ir pareikalaus papildomo laiko, kurio niekada neužtenka.

Funkcinės parinktys skirtos išspręsti šį ir daugelį kitų sunkumų, susijusių su sąsajos elementų / galimų objektų sudėties rodymu vartotojo sąsajoje. Šioje pastaboje nenagrinėsiu funkcinių variantų pagrindinės paskirties panaudojimo pavyzdžių, o atkreipsiu dėmesį į jų naudojimą nestandartiniu būdu. Galbūt tai yra žinoma daugeliui pažengusių kūrėjų, bet aš atėjau prie šio metodo visiškai atsitiktinai. Tiksliau, tai buvo įkvėpta programavimo „JavaScript“ praktika.

Atvejis Nr. 1: funkcinė parinktis kaip įvyniojimas virš kitų objektų

Pirmoji nestandartinė funkcinių parinkčių savybė – galimybė kurti įvyniojimus. Pažiūrėkime į paprasčiausią pavyzdį – konstantas. Pavyzdžiui, pridedate naują konstantą prie konfigūracijos su daugybe vartotojo vaidmenų. Kad vartotojai galėtų pasiekti konstantos reikšmę, turite nustatyti atitinkamų vaidmenų skaitymo teises. Jei teisės nenustatytos, vartotojai negalės gauti jo vertės. Jei vaidmenų yra daug ir jie nėra paveldėti iš pagrindinio vaidmens, turėsite skirti laiko atitinkamų langelių pažymėjimui.

Funkcijos parinktis šią problemą gali išspręsti elegantiškiau. Idėja tokia: sukurkite konstantą (pavyzdžiui, ). Mes tam teisių nesuteikiame. Sukurkite to paties pavadinimo funkcinę parinktį ir nurodykite ją nuosavybėje "Saugykla" nurodykite konstantą „Duomenų taupymo galimybė“. Taip pat iškėlėme vėliavą „Privilegijuotas gydymas gavus“.

Tai viskas, dabar bet kurioje kodo vietoje, kur reikia nurodyti konstantą, rašome taip:

Kadangi parinktį nustatėme privilegijuotuoju režimu, mums nereikia nurodyti jokių papildomų konstantos teisių. Žinoma, nereikia taikyti šios technikos visose įmanomose ir neįsivaizduojamose situacijose. Atminkite, kad tinkamas teisių paskirstymas yra raktas į ramybę. Naudokite triuką tik tikrai būtinais atvejais.

Byla Nr.2. Papildomas abstrakcijos lygis

Nežinau kaip teisingiau pavadinti šį metodą, bet mano galva jis skamba būtent taip. Pažvelkime į ankstesnį pavyzdį. Mes vis dar turime tą patį nuolatinį „Galimybę išsaugoti duomenis“. Dirbame su juo naudodami to paties pavadinimo funkcinę parinktį kaip ir įvynioklis.

Dabar įsivaizduokite, kad norėjome atsikratyti konstantos ir pereiti prie katalogo naudojimo. Tipiškas tokios problemos sprendimo scenarijus (jei naudojame tik konstantą) būtų paleisti visuotinės paieškos įrankį, kad būtų galima aptikti prieigą prie konstantos. Leiskite jums priminti, kad jei nenaudojame funkcinės parinkties kaip įvyniojimo, konstantą turėtume traktuoti taip:

Constants.Ability toSaveData.Get();

Surandame visus skambučius ir pakeičiame juos keliu į naują saugojimo objektą. Sutikite, tai gana nepatogu. Jei naudojome ankstesnį atvejį (naudodami funkcinę parinktį kaip įvyniojimą), tada norint „perkelti“ tereikia eiti į funkcinės parinkties ypatybes ir pakeisti savybę "Saugykla". Pavyzdžiui, nurodykite ten "Katalogas" arba „Informacijos registras“. Nereikia žaidimų su pasauline paieška. Kodas, skirtas pasiekti konstantos vertę naudojant funkcinę parinktį, išliks toks pat:

GetFunctionalOption ("DataSavingAbility");

Funkcinės parinktys yra metaduomenų objektas, esantis grupėje „Bendra“:

Funkcinės parinktys yra funkcinių parinkčių mechanizmo dalis, leidžianti įjungti arba išjungti kai kurias programos sprendimo funkcijas, atsižvelgiant į vartotojo poreikius, nekeičiant pačios konfigūracijos.
Pavyzdžiui, ne kiekviena organizacija gali naudoti sandėlio apskaitą. Jei sandėlio apskaita nenaudojama, tikslinga pašalinti sandėlio lauką iš visų dokumentų, katalogų ir registrų – štai tada mums į pagalbą ateina funkcinės galimybės.

Pažiūrėkime į pavyzdį:

Sukurkime funkcinę parinktį " Sandėlių apskaita".
Saugykla: rodomas laukas, kuriame saugoma reikšmė.
Galite pasirinkti konstantą, katalogo atributą arba informacijos registro išteklius.
Mes naudosime konstantą.

Sukurkime konstantą“ Tvarkyti sandėlių apskaitą" ir pasirinkite jį saugojimo lauke. Ši konstanta bus atsakinga už funkcinės parinkties įjungimą ir išjungimą. Pažymėkite langelį "Privilegijuotas režimas gavimo metu". Šis žymimasis laukelis reiškia, kad funkcinės parinkties reikšmės bus gautos privilegijuotu režimu :

Atnaujiname, paleidžiame 1C Enterprise. Nustatykite konstantos reikšmę = True:

Dėl to turime:

Nustatę konstantą = False, gauname:

Turite klausimų ar reikia konsultanto pagalbos?

Taigi, sukūrėme funkcinę parinktį, kuri valdo DirectoryLink.Warehouse tipo laukus

Dabar pažiūrėkime į funkcinių parinkčių parametrų naudojimo pavyzdį.
Pridėkime naują funkcinę parinktį " Valiutų apskaita"
Saugykla: Katalogas.Organizacija.Detalės.Valiutų apskaita

Prie dokumento sudėties pridėkime detales "Prekių kainų nustatymas" - "Valiuta"

Dokumento pavidalu procedūrose „Kai sukurta serveryje“ ir „OrganizationWhenChanged“
Pridėkime šį kodą:

Atnaujiname konfigūraciją ir paleidžiame.
Sukuriame dvi organizacijas ir vienai iš jų pažymime langelį „Valiutų apskaita“.

Ką mes gauname dėl to? Pasinaudojus funkcinės parinkties parametrais, dokumente „Prekių kainų nustatymas“ gavome parametrinį lauko „Valiuta“ valdymą. Tie. „Alfa“ organizacijai bus rodomas laukas „Valiuta“, o „Beta“ organizacijai laukas „Valiuta“ nebus rodomas.
Įsitikinkime tuo. Atidarykite dokumentą ir pabandykite pakeisti lauką „Organizacija“.
Nustačius Organization = "Alpha", rodoma valiuta; pakeisti į „Beta“ – valiuta pašalinama

1. Prieigos teisės.

Tiesą sakant, viskas yra labai paprasta. 1C pagal numatytuosius nustatymus viskas, kas neleistina, yra draudžiama. Valgyk tik vienas subjektas, atsakingas už prieigą bet kokiai funkcijai ar duomenims. Šis subjektas vadinamas „Prieiga dešinėje“. Ji būna vienintelė elementas, atsakingas už prieigą prie konkretaus darbo režimo, katalogo, detalių....

Prieigos teisių tipų skaičių iš anksto nustato platforma. Iš viso platforma turi dvi pagrindines prieigos teisių grupes. Bendra visai sistemai prieigos prie platformos mechanizmų teisės, atsakingas už prieigą prie tam tikrų platformos darbo režimų (Administravimas, Išskirtinis režimas, Plonas klientas, Interaktyvus išorinių ataskaitų atidarymas....). IR objekto leidimai, leidžiantis dirbti su įvairiais konfigūracijos objektais. Jų skaičius priklauso nuo konfigūracijos objekto tipo. Pavyzdžiui, katalogas turi 16 skirtingų prieigos tipų (skaityti, pridėti, keisti, ištrinti...). Yra tik penki informacijos registro prieigos tipai. Visos šios teisės gali būti nustatytos tik viso katalogo lygiu. Taip pat galite apriboti prieigą kredencialų lygiu. Tačiau šiuo atveju galimos tik dalis teisių tipų (katalogams tai yra peržiūros ir redagavimo teisės).

Visos prieigos teisės yra tarpusavyje susijusios ir priklauso viena nuo kitos. Yra aukštesnio ir žemesnio lygio teisės. Negalite suteikti žemesnio lygio teisės, jei vartotojas neturi teisės atlikti aukštesnio lygio veiksmo.

Pasvarstykime prieigos prie katalogo teises.Ši diagrama rodo, kad dauguma teisių yra bendresnių teisių paaiškinimai. Jei „Right1“ yra visiškai diagramoje kito „Right2“ stačiakampio viduje, tada „Right1“ negalima išduoti neišdavus „Right2“. Dažniausia teisė yra „Skaityti“. Jei skaitymo teisė nepasiekiama, visos kitos teisės nėra prieinamos. Jei „Pridėti“ teisės negalima, tada „Interaktyvaus pridėjimo“ teisės nustatyti negalima. Tačiau teisių sistemos negalima pavadinti visaverte hierarchija. Pavyzdžiui, „Redagavimo“ teisė gali būti suteikta tik tuo atveju, jei turite teises „Peržiūrėti“ ir „Redaguoti“. Bet jūs galite duoti „View“ be „Change“ arba „Change“ be „View“.

Prieigos teisė yra minimalus prieigos vienetas. Visa prieigos kontrolė priklauso nuo reikalingų teisių suteikimo vartotojui. Likę objektai (vaidmenys, prieigos grupės) yra tiesiog papildomi įrišimai, skirti grupavimui ir patogesniam prieigos teisių išdavimui.

2. Vaidmenys – prieigos teisių suteikimo mechanizmas

Pažiūrėkime, kaip tiksliai tai daroma suteikiant vartotojui prieigos teises. Kad būtų patogiau išduoti prieigos teises 1C platformoje, specialus „Roli“ mechanizmas. Tai sluoksnis tarp informacijos bazės vartotojų ir prieigos teisių. Kiekvienas vaidmuo sujungia prieigos teisių rinkinį, kurio priskyrimas prasmingas tik tuo pačiu metu. Pavyzdžiui, atliekant vaidmenį „Skaityti kontaktinę informaciją“, logiška derinti teisių, atsakingų už susijusius katalogus, rinkinius su kontaktine informacija. Dauguma paprastu būdu vaidmens nustatymas vartotojui yra Konfigūruotoje atidarykite informacijos saugos vartotojo kortelę ir pažymėkite langelius prie vartotojui reikalingų vaidmenų. Tai universalus metodas ir veikia bet kokioje konfigūracijoje. Tačiau didėjant konfigūracijų sudėtingumui ir didėjant vaidmenų skaičiui, tai tapo gana imli darbui. Todėl dabartiniuose standartiniuose sprendimuose yra papildomas sluoksnis tarp informacijos saugos vartotojo ir vaidmenų. Šis sluoksnis įgyvendinamas formoje „Prieigos kontrolės“ posistemis. Tai leidžia sujungti vaidmenis į didesnius objektus - „Profilius“ ir nebepriskirti atskiri vaidmenys ir profilius, kuriuose yra kelių vaidmenų rinkiniai.

Panagrinėkime prieigos teisių priskyrimo vartotojams schemą, naudojamą tipiškiausiose konfigūracijose. Supaprastinta forma jis gali būti pavaizduotas taip. Įvedami nauji subjektai "Prieigos profilis" Ir "Prieigos grupė". Kiekvienas prieigos profilis turi keletą vaidmenų. Ir kiekvienam vartotojui priskiriama viena ar daugiau prieigos grupių. Tada kiekviena prieigos grupė susiejama su prieigos profiliu. Dėl to gauname galimybę nurodyti ne tik vartotojo vaidmenis, bet ir vaidmenų rinkinius, priklausomai nuo jo atliekamų funkcijų.

Iš techninės pusės šią sistemą teisių išdavimas įgyvendinamas dalyvaujant dviem standartiniams posistemiams. „Prieigos valdymo“ posistemis naudojamas konfigūruoti prieigos grupių su iš anksto konfigūracijoje apibrėžtais vaidmenimis ryšį. „Vartotojų“ posistemis naudojamas ryšiams tarp informacijos saugos vartotojų ir konfigūracijos prieigos grupių konfigūruoti.

3. „Leidimų logika“ kaip vaidmenų sankirtos taisyklė.

Svarbu suprasti, kad 1C yra bendra prieigos valdymo logika leidimo logika. 1C platformoje apskritai nėra prieigos uždraudimo mechanizmų. Yra tik mechanizmai išduodančios prieigą. Pagal numatytuosius nustatymus prieiga prie visų duomenų uždrausta ir prieigos nustatymas susideda iš kiekvienam vartotojui reikalingų teisių suteikimo. Tai reiškia, kad jei koks nors vaidmuo suteikia vartotojui teisę peržiūrėti dokumentus „Prekių pardavimas“, tada ši teisė jokiu būdu negali būti atimta kitus vaidmenis ar bet kokią kitą platformą ir konfigūravimo mechanizmus. Iš pradžių galite nesuteikti visos prieigos prie katalogo, bet filtruoti duomenis, prie kurių suteikiame prieigą, naudodami RLS. Bet jei prieiga jau suteikta, jos nebegali atsiimti kiti vaidmenys.

Štai kodėl, ribojant vartotojo prieigą prie katalogo vaidmenimis, labai svarbu patikrinti, ar vartotojui nėra priskirtas joks kitas vaidmuo tam pačiam katalogui. Priešingu atveju pirmasis vaidmuo suteiks reikiamą prieigą, o antrasis negali paneigti.

Platforma turi galimybę suteikti vartotojui papildomų teisių atliekant atskirą operaciją. Ši funkcija vadinama privilegijuotuoju režimu. Tai leidžia vartotojui atlikti veiksmus su duomenimis, kurie jam nėra prieinami. Tačiau platforma neturi galimybės net laikinai sumažinti vartotojo teisių.

4. Netiesioginė prieigos kontrolė.

Yra atskiri mechanizmai, kurie, nors ir nėra tiesiogiai skirti prieigai kontroliuoti, bet netiesiogiai ją įtakoja ir gali būti naudojami papildomiems apribojimams. Pažvelkime į pagrindines jų savybes.

4.1. Funkcinės parinktys.

Prieigos kontrolės sistema kartais vadinama mechanizmu funkcinės galimybės. Tai nėra visiškai tiesa, nes funkcinės parinktys neturi jokios įtakos prieigai prie duomenų. Tai grynai sąsajos mechanizmas, sukurta siekiant supaprastinti vartotojo sąsają. Jis pasirodė 8.2 platformoje dėl sudėtingesnių konfigūravimo funkcijų. Numatytos funkcinės galimybės pasislėpti nuo sąsajos funkcija, kurios nenaudoja ši konkreti įmonė ar šis konkretus vartotojas. Mechanizmas veikia tik duomenų rodymą. Komandos išnyksta iš sąsajos, o funkcinių parinkčių išjungta informacija yra paslėpta formose. Kuriame vartotojas vis dar turi prieigą prie visų šių komandų ir detalių. Jis gali dirbti su paslėptais duomenimis programiškai, naudodamas apdorojimą be jokių problemų.

Galite perskaityti daugiau apie darbą su funkcinėmis parinktimis ITS

4.2. RLS (rekordinio lygio sauga)

Visi aukščiau išvardyti mechanizmai turi įtakos prieigos prie objektų teikimui kaip visumai. Į žinynus, dokumentus, nuorodų detales. Prieigos teisės turi įtakos prieigai prie objektų, funkcinės parinktys – objektų atvaizdavimui sąsajoje. Dažnai iškyla užduotis leisti vartotojui pasiekti katalogo ar dokumento duomenis. Bet ne visiems duomenims, o tik daliai jų. Pavyzdžiui, leisti pasiekti įgyvendinimo dokumentus tik vienai organizacijai.

Yra papildomas šios skiriamosios gebos konfigūravimo mechanizmas RLS (rekordinio lygio sauga). Kaip rodo pavadinimas, šis prieigos kontrolės mechanizmas yra konkrečių lentelės įrašų lygyje. Jei prieigos teisės suteikia prieigą prie lentelių kaip visumos (katalogų) arba lentelės stulpelių (detalių), RLS nustato konkrečias lentelės eilutes (įrašus), su kuriomis vartotojui leidžiama dirbti. Tai leidžia nustatyti vartotojui prieinamus duomenis.

Analizuodami šį mechanizmą, visada turėtumėte tai atsiminti RLS nėra prieigos uždraudimo mechanizmas. Jis yra mechanizmas prieigos išdavimo filtravimas. Tie. RLS neturi įtakos vartotojo teisėms, tai yra filtras, ribojantis teisių išdavimą. RLS turi įtakos tik tam tikram „Vaidmuo“ - „Prieigos teisė“ ryšiui, kuriame jis užregistruotas. Ir neturi įtakos kitų vaidmenų suteikiamoms prieigos teisėms. Pavyzdžiui, jei vienas vaidmuo leidžia pasiekti dokumentus tik organizacijai1, o kitas vaidmuo suteikia prieigą prie Sandėlio1 dokumentų, vartotojas galiausiai turės prieigą prie visų dokumentų, kuriuose nurodyta Organizacija1 ARBA Sandėlis1. Todėl, jei vartotojui suteikiami keli vaidmenys, tada kiekviename vaidmenyje turi būti įdiegtas filtras naudojant RLS abiem sritims (pagal organizaciją ir sandėlį). Standartiniuose sprendimuose ši problema dažniausiai išsprendžiama sukuriant vieną vaidmenį, kuriame registruojami visi galimi RLS filtrai. Tada šis vaidmuo priskiriamas visiems vartotojams, dirbantiems su šiais katalogais. Taip pat kontroliuojama, kad vartotojas neturėtų kitų vaidmenų, turinčių teisę susipažinti su apribotais dokumentais.

Taip pat verta paminėti, kad RLS filtrai negali būti taikomi visiems galimiems duomenų prieigos tipams, o tik tiems aukščiausio lygio prieigos tipai. Pavyzdžiui, katalogams iš šešiolikos galimų prieigos tipų RLS filtrai gali būti taikomi tik keturiems pagrindiniams: skaitymui, keitimui, įtraukimui ir trynimui. Tai reiškia, kad, pavyzdžiui, negalime vienu metu suteikti vartotojui teisės „Redaguoti“ be filtro, kad būtų galima programiškai dirbti su bet kokiais dokumentais, ir teisės „Redaguoti“ su RLS filtru pagal organizaciją interaktyviam darbui. Jei mums reikia, kad vartotojas galėtų redaguoti dokumentus naudodami RLS filtrą, mes privalome nustatyti bendrą filtrą viršutiniame „Redaguoti“ arba „Skaityti“ lygyje.

Atsižvelgiant į bendrą mechanizmų sudėtingumą, paprastai gana sunku išsiaiškinti, kas tiksliai yra prieinama konkrečiam tipinės konfigūracijos vartotojui. Norint patikrinti suteiktas teises tipinėse konfigūracijose, yra labai patogi ataskaita, kuri vadinama "Prieigos teisės". Ji analizuoja visas vartotojui suteiktas teises ir pateikia galutinį visų prieigos grupių suteiktų teisių sąrašą, atsižvelgdama į RLS filtrus.

4.3. Duomenų atskyrimas.

Kitas mechanizmas, turintis įtakos duomenų prieigai, yra duomenų atskyrimas. Šis mechanizmas skirtas veikti viename fizinę bazę duomenys iš kelių nepriklausomų duomenų bazių, turinčių bendrą konfigūraciją ir bendrieji žinynai. Kai kuriais labai ribotais atvejais šis mechanizmas gali būti laikomas prieigos kontrole. Kai įjungta, kiekvienas vartotojas gali dirbti tik vienoje iš savo nepriklausomų duomenų bazių, bet naudoti bendrus duomenis.

Tam tikra prasme šis mechanizmas taip pat gali būti laikomas duomenų filtru ir ypatingu RLS diegimo atveju. Skirtingai nuo RLS, atskyrimas yra daug griežtesnis mechanizmas. Dėl šio nelankstumo kūrėjai turi techninę galimybę naudoti papildomus indeksus tokiam filtravimui atlikti be būdingo RLS sulėtėjimo.

Tiesą sakant RLS yra tik papildomi pasirinkimai, automatiškai pridedama prie kiekvienos duomenų bazės užklausos. Duomenų padalijimas yra skyriklio pridėjimasį visas skaidytas lenteles ir jų indeksus, įskaitant sugrupuotą. Duomenys grupuojami pagal skyriklį, t.y. fiziškai perskirstomi visame diskeį atskiras grupes kiekvienai skyriklio vertei. Dėl šios priežasties kiekvienas vartotojas dirba tik su savo duomenimis, o serveriui nereikia fiziškai nuskaityti visos lentelės su kiekviena užklausa. Pakanka peržiūrėti tik dabartinio skaidinio duomenų sritį.

Tačiau būtent dėl ​​šio fizinio duomenų perskirstymo, kai dirbate kaip pilnavertis vartotojas, neturintis filtro pagal skyriklio reikšmes, visos užklausos vykdomos labai labai lėtai. Be separatoriaus reikšmės neįmanoma visiškai panaudoti indeksų, todėl duomenų kiekis fiziškai nuskaitomas iš disko ir apdorojamas su kiekviena užklausa didėti dydžiu. Atitinkamai, iš tikrųjų atskyrimas prasmingas tik tuo atveju, jei visi nuolat duomenų bazėje dirbantys vartotojai dirbs tik savo srityje.

4.4. Programos kodas.

Galbūt universaliausias būdas nustatyti papildomus apribojimus yra programos kodas. Jie gali paveikti bet kokius platformos mechanizmus. Pavyzdžiui, norėdamas apriboti prieigą prie dokumentų, kūrėjas gali pridėti filtrą į dokumentų sąrašo formą, į pasirinkimo formą ir gali programiškai patikrinti galimybę peržiūrėti dokumento duomenis atidarydamas konkretų dokumento formą. Pasirinkdamas duomenis, kūrėjas savo ataskaitose gali taikyti filtrą.

Tačiau programos kodas nėra galimybės apriboti teisių kaip visumos konfigūruojant. Daugiausia, ką kūrėjas gali padaryti, tai nustatyti apribojimus į konkrečius individualius duomenų gavimo mechanizmus. Dėl to, kad 1C darbui su duomenimis naudoja objekto modelį, programos kodas gali garantuoti duomenų apsaugą nuo pakeitimo pridedant būtinus patikrinimus prie objekto modulio. Tačiau kūrėjas negali visiškai garantuoti, kad vartotojas tikrai negalės gauti informacijos apie kitų žmonių įgyvendinimo dokumentus per kitas ataskaitas ar apdorojimą.

Šis principas naudojamas, pvz. Prisijungęs prie konfigūracijos, plėtinys prideda pasirinktinius apribojimus ir patikrinimus visoms žinynams ir dokumentams. Jis filtruoja duomenis, rodomus vartotojams sąrašuose, tikrindamas prieigą peržiūrint ar keičiant duomenis. Užtikrina, kad draudžiamų duomenų nebūtų galima pakeisti. Tačiau jis negali filtruoti duomenų ataskaitose ar užklausose.

Visada yra galimybių gauti draudžiamus duomenis pateikus užklausą, tvarkant juos pačiam arba pranešant. Nebent labai griežtai apribosite vartotojo naudojamų konfigūravimo funkcijų sąrašą ir prie kiekvieno vartotojui leidžiamo mechanizmo (formos, apdorojimo, ataskaitos, užklausos) pridėsite atskirą filtrą.

4.5. Pasirinkimų palyginimas.

Pabandykime trumpai palyginti svarstytas papildomas duomenų ribojimo galimybes.

5. Rezultatai.

Kiekvienas apribojimų nustatymo būdas turi savo privalumų ir trūkumų. Technologiniu požiūriu teisingiausias būdas yra teisingai suskirstyti jį į vaidmenis. Patikimiausias būdas filtruoti turimus duomenis yra naudoti RLS. Būtent šiai užduočiai skirtas mechanizmas. Taškų apribojimus lengviausia įgyvendinti naudojant kodą. Funkcinės parinktys ir duomenų atskyrimas yra gana specifiniai mechanizmai, kuriais nesiekiama apriboti prieigos. Nors kai kuriais atvejais jie gali būti naudojami tam.

Funkcinės parinktys Ir Funkcinio pasirinkimo parametras- tai 1C 8.3 (8.2) konfigūracijos objektai, kurie kartu yra funkcinių parinkčių mechanizmas. Funkcinių parinkčių mechanizmas – tai funkcija, leidžianti nustatyti vartotojams reikalingų funkcijų rinkinį.

Paprasčiau tariant, funkcinių parinkčių mechanizmas yra įjungimo / išjungimo jungiklis, skirtas įvairioms konfigūracijos funkcijoms.

Kodėl gali reikėti išjungti funkciją?

Gaukite 267 vaizdo įrašų pamokas 1C nemokamai:

Dažnai papildomas funkcionalumas gali apsunkinti darbuotojų darbą. Trivialus funkcinių parinkčių naudojimo 1C pavyzdys - duomenų bazėje saugomi vienos organizacijos ar sandėlio įrašai, tai kodėl įpareigoti vartotoją šiuos duomenis užpildyti visuose dokumentuose?

Ką valdo funkcinės parinktys?

Visų pirma, funkcinių parinkčių naudojimas patogiausiai atsispindi sąsajoje: formos detalės, komandų formos, bendroji sąsaja – visa tai galima susieti su funkcinėmis parinktimis. Atsižvelgdami į funkcinių parinkčių vertę, galite apriboti duomenų rodymą ataskaitoje, sukurtoje remiantis .

1c objektas „Funkcinės parinktys“ - yra skirti paryškinti programos sprendimo funkcionalumą, kurį galima įjungti (išjungti) diegimo metu nekeičiant savęs (kartu su posistemiais jie sudaro 1C plonojo kliento sąsają). Jie yra funkcinių parinkčių mechanizmo dalis.

Funkcinių parinkčių mechanizmas apima du metaduomenų objektus:

1. Funkcinis variantas;
2. Funkcinių parinkčių parametrai.

Daugiau informacijos

Funkcinis variantas reiškia metaduomenų objektą, kuris gali tiesiogiai paveikti programos sąsajos sudėtį (jei funkcinė parinktis išsaugo savo vertę Būlio atribute). Naudodami šio tipo objektus galite paslėpti elementus, susijusius su nepasiekiamomis funkcijomis. Pavyzdžiui, pasirinkus Valiutos apskaitos parinktį, ataskaitose galima paslėpti stulpelį Valiutos, lauką Valiuta iš ir stulpelį Valiutos suma.

Funkcinės parinkties vertės šaltinis yra metaduomenų objektas, pasirinktas kaip saugyklos ypatybė, pavyzdžiui, tai gali būti .

Jei funkcinės parinkties reikšmė saugoma katalogo atribute arba išteklyje, reikalinga papildoma informacija, nurodanti, kaip tiksliai pasirinkti parinkties reikšmę. Šiuo tikslu yra numatytas atskiras metaduomenų objektas – Funkcinių parinkčių parametrai.

Galima sakyti, kad funkcinių variantų parametrai yra funkcinių variantų reikšmių erdvės koordinačių ašys. Be to, vienas funkcinių parinkčių parametras gali vienu metu nustatyti „savo“ koordinačių ašies reikšmę daugeliui funkcinių variantų.

[sutraukti]

Funkcinės parinktys gali turėti įtakos:

1. į vartotojo sąsają:
   • pasaulinis ;
   • išsami informacija (įskaitant formos informacijos stulpelius, pvz., Vertybių lentelė arba ValueTree);
   • formuoti komandas;
2. apie ataskaitas, įdiegtas naudojant duomenų komponavimo sistemą;
3. į algoritmus, parašytus integruota kalba - iš integruotos kalbos galima gauti funkcinių parinkčių reikšmes ir jas naudoti įvairiomis sąlygomis, pavyzdžiui, norint sumažinti skaičiavimų skaičių (žr. ).

DĖMESIO! Jei kliento programa veikia su informacijos bazės failo versija per žiniatinklio serverį, pakeitus funkcinę parinktį vartotojo sąsaja pasikeis tik iš naujo paleidus žiniatinklio serverį (paleiskite iš naujo kliento programa nesukels vartotojo sąsajos pakeitimo).

Funkcinių parinkčių savybės 1C

• Saugykla yra laukas, kuriame reikia pasirinkti Būlio tipo objektą. Paprastai naudojamos konstantos.
• gavus - vėliavėlė yra atsakinga už galimybę gauti funkcinės parinkties vertę privilegijuotuoju režimu.
• Kompozicija - objektų ir objekto detalių sąrašas, kurio matomumas įjungiamas/išjungiamas, kai įjungiama/išjungiama funkcinė parinktis (bus valdoma naudojant valdomą formą).

Pavyzdžiui, priklausomai nuo konkretaus įgyvendinimo sąlygų, galima išjungti prekių apskaitą pagal sandėlį, kad registruojant dokumentus prekių gavimui, laukelis Sandėlis nebūtų rodomas dokumento formoje.

1C funkcinių parinkčių naudojimo ypatybės:

1. Funkcinės parinktys gali turėti bet kokio tipo reikšmes (nebūtinai Būlio).
2. Pridėdami naują konstantą, kad galėtumėte naudoti funkcijos parinktį, būtinai įtraukite ją į atitinkamą posistemį ir priskirkite jai teises.
3. Darbas su funkcinėmis parinktimis galimas naudojant integruotą kalbą, kurios dėka kūrėjas gali sukurti savo funkcinių parinkčių verčių algoritmus.
4. Komandų sąsajos komanda bus pašalinta iš komandų sąsajos, jei funkcinė parinktis išjungta:
   • atributas, kuris yra komandos parametras;
   • komandos parametro tipas (jei komandos parametro tipas yra sudėtinis, tada komanda tampa nepasiekiama, kai išjungiami visi parametrų tipai).

DĖMESIO! Funkcinės parinktys ir jų parametrai neturi įtakos duomenų bazės sudėčiai: visos lentelės ir laukai yra duomenų bazėje, nepriklausomai nuo funkcinių parinkčių būklės.

Funkcinių parinkčių įtaka formos detalėms ir komandoms:

1. valdomos formos tipas<Вид>Objektas ( DirectoryObject, DocumentObject ir kt.) bus išjungtas, jei atitinkamas objektas bus išjungtas naudojant funkcinę parinktį. Analizuojami tik tie funkciniai variantai, kurie neturi parametrų.
2. Pagrindiniai valdomos formos tipo atributai Dinaminis sąrašas bus išjungtas, jei funkcinė parinktis išjungs konfigūracijos objektą, kuris nurodytas kaip pagrindinė dinaminio sąrašo lentelė. Analizuojami tik tie funkciniai variantai, kurie neturi parametrų.
3. Nuorodos tipo formos atributas yra išjungtas, jei konfigūracijos objektas, sudarantis šį tipą, yra išjungtas funkcinės parinkties. Sudėtinio tipo formos atributas išjungtas, jei funkcinės parinktys išjungia visus sudedamųjų dalių tipus.
4. Formos lentelė bus išjungta, jei joje bus rodomi formos atributo duomenys, kuriuos išjungė funkcinė parinktis.
5. Tipo pasirinkimo dialogo lange nėra tipų (pavyzdžiui, įvesties laukams, susietiems su sudėtingo tipo atributais), jei šiuos tipus sudarantys konfigūracijos objektai yra išjungti dėl funkcinės parinkties. Informacija apie tipus, išjungtus dėl funkcinių parinkčių, talpinama kliento pusėje ir išvaloma po 20 minučių arba metodo iškvietimo metu Atnaujinimo sąsaja ().

DĖMESIO! Skirtingai nuo komandų sąsajos, funkcinių parinkčių parametrų reikšmės nustatomos tik konkrečiam formos egzemplioriui.

Funkcinių parinkčių parametro kūrimas

Funkcinės parinkties parametras sukuriamas naudojant 1C konfigūracijos objektą „Funkcinės parinkties parametrai“.

[sutraukti]

Tai galima padaryti konfigūracijos lange pridedant naują objektą.

Funkcinių parinkčių parametrų savybės:

• Naudojimas – nustato objektų rinkinį, kurio reikšmės nulems, kaip turi būti pasirinkta funkcinės parinkties reikšmė. Galimų objektų sąrašas apima katalogus ir informacijos registro matmenis. Kiekvienam funkcinių parinkčių parametrui šiame sąraše galite pasirinkti vieną katalogą (iš viso katalogų sąrašo) ir vieną kiekvieno informacijos registro dimensiją.

DĖMESIO! Negalite naudoti to paties metaduomenų objekto keliuose funkcijos parinkčių parametruose.