Funkcionalne opcije I Parametar funkcionalne opcije- ovo su objekti konfiguracije 1C 8.3 (8.2), koji zajedno predstavljaju mehanizam za funkcionalne opcije. Mehanizam funkcionalnih opcija je funkcionalnost koja vam omogućava da odredite skup funkcionalnosti koji su potrebni korisnicima.

Jednostavno rečeno, mehanizam funkcionalnih opcija je prekidač za uključivanje/isključivanje za različite funkcionalnosti u konfiguraciji.

Zašto biste možda trebali onemogućiti funkcionalnost?

Nabavite 267 video lekcija na 1C besplatno:

Često dodatna funkcionalnost može otežati rad zaposlenika. Trivijalan primjer korištenja funkcionalnih opcija u 1C - baza podataka vodi evidenciju za jednu organizaciju ili skladište, zašto onda obavezuje korisnika da popuni ove podatke u svim dokumentima?

Šta kontrolišu funkcionalne opcije?

Prije svega, korištenje funkcionalnih opcija najprikladnije se ogleda u sučelju: detalji obrasca, obrasci naredbi, opći interfejs - sve se to može povezati s funkcionalnim opcijama. Ovisno o vrijednosti funkcionalnih opcija, možete ograničiti prikaz podataka u izvještaju napravljenom na bazi .

1. Prava pristupa.

U stvari, sve je vrlo jednostavno. U 1C standardno sve sto nije dozvoljeno je zabranjeno. Jedi samo jedan entitet odgovoran za pristup korisnika na bilo koju funkcionalnost ili podatke. Ovaj entitet se zove "Pristup pravi". Ona je slučajno jedini element odgovoran za pristup određenom režimu rada, direktorijumu, detaljima....

Broj tipova prava pristupa je unapred određen platformom. Ukupno, platforma ima dvije glavne grupe prava pristupa. Zajedničko za cijeli sistem prava pristupa mehanizmima platforme, odgovoran za pristup određenim režimima rada platforme (Administracija, Ekskluzivni režim, Tanki klijent, Interaktivno otvaranje eksternih izveštaja....). I dozvole objekata, što vam omogućava rad s različitim konfiguracijskim objektima. Njihov broj ovisi o vrsti konfiguracijskog objekta. Na primjer, imenik ima 16 različitih tipova pristupa (Čitanje, Dodaj, Promjena, Izbriši....). Postoji samo pet vrsta pristupa registru informacija. Sva ova prava mogu se postaviti samo na razini direktorija kao cjeline. Također možete ograničiti pristup na nivou vjerodajnica. Ali u ovom slučaju je dostupan samo dio tipova prava (za direktorije su to prava View i Edit).

Sva prava pristupa su međusobno povezana i zavisna jedno od drugog. Postoje prava višeg i nižeg nivoa. Ne možete dodijeliti pravo nižeg nivoa ako korisnik nema pravo da izvrši radnju višeg nivoa.

Hajde da razmotrimo prava pristupa direktorijumu. Ovaj dijagram pokazuje da su većina prava pojašnjenja opštijih prava. Ako je Desno1 u potpunosti locirano na dijagramu unutar pravokutnika drugog Right2, onda Desno1 ne može biti izdano bez izdavanja Right2. Najčešći pravac je pravo "čitaj". Ako pravo čitanja nije dostupno, tada nisu dostupna sva ostala prava. Ako pravo "Dodaj" nije dostupno, onda se ne može postaviti pravo "Interaktivno dodavanje". Kako god, sistem prava se ne može nazvati punopravnom hijerarhijom. Na primjer, pravo na "Uređivanje" se može dati samo ako imate prava "Pregled" i "Uređivanje". Ali možete dati "View" bez "Change" ili "Change" bez "View".

Pravo pristupa je minimalna jedinica pristupa. Sva kontrola pristupa se svodi na izdavanje korisniku potrebnog skupa prava. Preostali objekti (uloge, pristupne grupe) su jednostavno dodatne veze koje služe za grupisanje i pogodnije izdavanje prava pristupa.

2. Uloge - mehanizam za dodjelu prava pristupa

Pogledajmo kako se to tačno radi davanje prava pristupa korisniku. Za praktičnost izdavanja prava pristupa na 1C platformi, poseban "Roli" mehanizam. To je sloj između korisnika baze podataka i prava pristupa. Svaka uloga kombinuje skup prava pristupa, čija dodela ima smisla samo u isto vreme. Na primjer, u ulozi „Pročitaj informacije o kontaktu“ logično je kombinirati skupove prava odgovornih za povezane direktorije s kontakt informacijama. Većina na jednostavan način postavljanje uloge korisniku je otvaranje korisničke kartice informacione sigurnosti u konfiguratoru i označavanje okvira pored uloga koje su korisniku potrebne. Ovo je univerzalna metoda i radi u bilo kojoj konfiguraciji. Međutim, sa sve većom složenošću konfiguracija i povećanjem broja uloga, postalo je prilično radno intenzivno. Stoga, u trenutnim standardnim rješenjima postoji dodatni sloj između korisnika informacione sigurnosti i uloga. Ovaj sloj je implementiran u obliku Podsistem "Kontrola pristupa".. Omogućava vam da kombinujete uloge u veće entitete - "Profile" i da korisniku dodelite ne pojedinačne uloge, već profile koji sadrže skupove od nekoliko uloga.

Razmotrimo šemu za dodjelu prava pristupa korisnicima, koja se koristi u većini tipičnih konfiguracija. U pojednostavljenom obliku, može se predstaviti na sljedeći način. Uvedeni su novi entiteti "Pristupite profilu" I "Pristupna grupa". Svaki pristupni profil uključuje nekoliko uloga. I svakom korisniku je dodijeljena jedna ili više pristupnih grupa. Svaka pristupna grupa je tada povezana s pristupnim profilom. Kao rezultat, dobijamo priliku da specificiramo ne samo uloge za korisnika, već i skupove uloga ovisno o funkcijama koje obavlja.

Sa tehničkog stanovišta, ovaj sistem za izdavanje prava se realizuje uz učešće dva standardna podsistema. Podsistem "Kontrola pristupa" se koristi za konfigurisanje veze pristupnih grupa sa ulogama unapred definisanim u konfiguraciji. Podsistem "Korisnici" se koristi za konfiguriranje veza između korisnika sigurnosti informacija i grupa pristupa konfiguraciji.

3. “Logika dozvole” kao pravilo za ukrštanje uloga.

Važno je shvatiti da je u 1C opća logika kontrole pristupa logika dozvole. U 1C platformi općenito ne postoje mehanizmi za uskraćivanje pristupa. Postoje samo mehanizmi izdavanje pristupa. Podrazumevano, pristup svim podacima je odbijen, i Podešavanje pristupa se sastoji u tome da se svakom korisniku izdaju prava koja su mu potrebna. To znači da ako neka uloga korisniku daje pravo na pregled dokumenata „Prodaja robe“. ovo pravo se ni na koji način ne može oduzeti druge uloge ili bilo koju drugu platformu i mehanizme konfiguracije. U početku ne možete dati puni pristup direktoriju, već filtrirati podatke kojima dajemo pristup pomoću RLS-a. Ali ako je pristup već odobren, onda ga više ne mogu vratiti druge uloge.

Zato je kod ograničavanja pristupa korisnika direktoriju po ulogama vrlo važno provjeriti da korisniku nije dodijeljena neka druga uloga istom direktoriju. U suprotnom, prva uloga će dati potreban pristup, koji druga ne može odbiti.

Platforma ima mogućnost da korisniku da dodatna prava dok obavlja zasebnu operaciju. Ova funkcija se zove Privilegirani način rada. Omogućava korisniku da izvrši radnje na podacima koji mu nisu dostupni. Međutim, platforma nema mogućnost čak ni privremenog smanjenja prava korisnika.

4. Indirektna kontrola pristupa.

Postoje zasebni mehanizmi koji, iako nisu direktno namijenjeni kontroli pristupa, na njega utiču indirektno i mogu se koristiti za dodatna ograničenja. Pogledajmo njihove glavne karakteristike.

4.1. Funkcionalne opcije.

Sistem kontrole pristupa se ponekad naziva mehanizmom funkcionalne opcije. Ovo nije sasvim tačno, jer funkcionalne opcije ni na koji način ne utiču na pristup podacima. Ovo je čisto interfejs mehanizam, dizajniran da pojednostavi interfejs za korisnika. Pojavio se u platformi 8.2 kao rezultat složenije konfiguracijske funkcionalnosti. Predviđene su funkcionalne opcije sakriti od interfejsa funkcionalnost koju ne koristi ova konkretna kompanija ili ovaj određeni korisnik. Mehanizam utiče samo na prikaz podataka. Komande nestaju iz interfejsa, a detalji onemogućeni funkcionalnim opcijama su skriveni na obrascima. Gde korisnik i dalje ima pristup svim ovim komandama i detaljima. Može raditi sa skrivenim podacima programski koristeći obradu bez ikakvih problema.

Možete pročitati više o radu s funkcionalnim opcijama na ITS-u

4.2. RLS (Record Level Security)

Svi gore navedeni mehanizmi utječu na pružanje pristupa objektima u cjelini. Za referentne knjige, dokumente, referentne detalje. Prava pristupa utiču na pristup objektima, funkcionalne opcije utiču na prikaz objekata u interfejsu. Često se javlja zadatak da se korisniku omogući pristup podacima o direktoriju ili dokumentu. Ali ne na sve podatke, već samo na njihov dio. Na primjer, dozvolite pristup dokumentima implementacije samo jednoj organizaciji.

Postoji dodatni mehanizam za konfiguraciju ove rezolucije RLS (Record Level Security). Kao što samo ime govori, ovaj mehanizam kontrole pristupa je na nivou posebnih zapisa tabele. Ako prava pristupa omogućavaju pristup tabelama kao celini (direktoriji) ili kolonama tabele (detalji), onda RLS određuje specifične redove tabele (zapise) sa kojima je korisniku dozvoljeno da radi. Omogućava vam da odredite podatke koji su dostupni korisniku.

Kada analizirate ovaj mehanizam, uvijek to treba imati na umu RLS nije mehanizam za uskraćivanje pristupa. On je mehanizam filtriranje izdavanja pristupa. One. RLS ne utiče na prava korisnika; to je filter koji ograničava izdavanje prava. RLS utiče samo na konkretnu vezu „Uloga” - „Pravo pristupa” u kojoj je registrovan. I ne utiče na prava pristupa koja daju druge uloge. Na primjer, ako jedna uloga dozvoljava pristup dokumentima samo za Organizaciju1, a druga uloga dozvoljava pristup dokumentima za Skladište1, tada će korisnik na kraju imati pristup svim dokumentima koji ukazuju na Organizaciju1 ILI Skladište1. Stoga, ako korisnik ima nekoliko uloga, onda filter koji koristi RLS mora biti instaliran u svakoj ulozi za oba polja (po organizaciji i skladištu). U standardnim rješenjima ovaj zadatak se obično rješava kreiranjem jedne uloge u kojoj se registruju svi mogući RLS filteri. Ova uloga se zatim dodjeljuje svim korisnicima koji rade s ovim direktorijima. Također je kontrolirano da korisnik nema na raspolaganju druge uloge koje sadrže pravo pristupa ograničenim dokumentima.

Također je vrijedno napomenuti da se RLS filteri ne mogu primijeniti na sve. mogući tipovi pristup podacima, ali samo do Vrste pristupa najvišeg nivoa. Na primjer, za direktorije, od šesnaest dostupnih tipova pristupa, RLS filteri se mogu primijeniti na samo četiri glavna: čitanje, izmjena, dodavanje i brisanje. To znači da ne možemo, na primjer, korisniku istovremeno dati pravo „Uredi“ bez filtera za mogućnost programskog rada sa bilo kojim dokumentom i pravo „Uredi“ sa RLS filterom po organizaciji za interaktivni rad. Ako nam je potrebno da korisnik može uređivati ​​dokumente pomoću RLS filtera, od nas se traži da nametnemo opći filter na najvišem nivou "Uredi" ili "Čitanje".

S obzirom na ukupnu složenost mehanizama, obično je prilično teško shvatiti šta je točno dostupno određenom korisniku tipične konfiguracije. Za provjeru dodijeljenih prava u tipičnim konfiguracijama postoji vrlo zgodan izvještaj koji se zove "Prava pristupa". Analizira sva prava koja su data korisniku i prikazuje konačnu listu prava koja su izdala sve grupe pristupa, uzimajući u obzir RLS filtere.

4.3. Razdvajanje podataka.

Drugi mehanizam koji utiče na pristup podacima je razdvajanje podataka. Ovaj mehanizam je dizajniran za održavanje nekoliko nezavisnih baza podataka u jednoj fizičkoj bazi podataka koje imaju zajedničku konfiguraciju i zajedničke direktorije. U nekim vrlo ograničenim slučajevima, ovaj mehanizam se može smatrati kontrolom pristupa. Kada je omogućeno, svaki korisnik može raditi samo u jednoj od svojih nezavisnih baza podataka, ali koristiti zajedničke podatke.

U nekom opštem smislu, ovaj mehanizam se takođe može smatrati filterom podataka i posebnim slučajem implementacije RLS-a. Za razliku od RLS-a, odvajanje je mnogo rigidniji mehanizam. A zahvaljujući ovoj rigidnosti, programeri imaju tehničku mogućnost da koriste dodatne indekse za obavljanje takvog filtriranja bez inherentnog usporavanja RLS-a.

Zapravo RLS je samo dodatni izbor, dodaje se automatski svakom upitu baze podataka. Razdvajanje podataka je dodavanje separatora u sve particionirane tabele i njihove indekse, uključujući i onu grupiranu. Podaci se grupišu prema separatoru, tj. fizički preraspodijeljen po disku u zasebne grupe za svaku vrijednost separatora. Zahvaljujući tome, svaki korisnik radi samo sa svojim podacima, a server ne mora fizički skenirati cijelu tablicu sa svakim zahtjevom. Dovoljno je vidjeti samo područje podataka trenutne particije.

Međutim, upravo zbog ove fizičke preraspodjele podataka, kada se radi kao punopravni korisnik koji nema filter baziran na vrijednostima separatora, svi upiti se izvršavaju vrlo, vrlo sporo. Bez vrijednosti separatora nemoguće je u potpunosti koristiti indekse, tako da količina podataka fizički pročitanih s diska i obrađenih sa svakim zahtjevom može povećati za redove veličine. Shodno tome, u stvarnosti, razdvajanje ima smisla samo ako će svi korisnici koji stalno rade u bazi podataka raditi samo unutar svog područja.

4.4. Programski kod.

Možda je najuniverzalniji način postavljanja dodatnih ograničenja programski kod. Oni mogu uticati na bilo koje mehanizme platforme. Na primjer, da ograniči pristup dokumentima, programer može dodati filter u obrazac liste dokumenata, u obrazac za odabir i može programski provjeriti mogućnost pregleda podataka dokumenta prilikom otvaranja određenog obrasca dokumenta. Programer može primijeniti filter u svojim izvještajima prilikom odabira podataka.

Međutim, programski kod ne postoji način da se ograniči prava u cjelini konfiguracijom. Najviše što programer može učiniti je da ugradi ograničenja u specifične pojedinačne mehanizme preuzimanja podataka. Zbog činjenice da 1C koristi objektni model za rad s podacima, programski kod može garantovati zaštitu podataka od modifikacije, dodajući potrebne provjere u objektni modul. Ali programer ne može u potpunosti jamčiti da korisnik definitivno neće moći dobiti informacije o implementacijskim dokumentima drugih ljudi putem drugih izvještaja ili obrade.

Ovaj princip se koristi, na primjer, u. Povezivanjem na konfiguraciju, proširenje dodaje prilagođena ograničenja i provjere svim referentnim knjigama i dokumentima. Filtrira podatke prikazane korisnicima na listama, provjerava pristup prilikom pregledavanja ili mijenjanja podataka. Osigurava da se zabranjeni podaci ne mogu mijenjati. Ali ne može filtrirati podatke u izvještajima ili upitima.

Uvijek postoje opcije za dobivanje zabranjenih podataka na zahtjev, vlastitu obradu ili prijavu. Osim ako vrlo striktno ograničite listu funkcionalnosti konfiguracije koju koristi korisnik i dodate poseban filter svakom mehanizmu (obrazac, obrada, izvještaj, zahtjev) koji je dozvoljen korisniku.

4.5. Poređenje opcija.

Pokušajmo ukratko uporediti razmatrane opcije za dodatno ograničenje podataka.

5. Rezultati.

Svaki način postavljanja ograničenja ima svoje prednosti i nedostatke. Sa tehnološke tačke gledišta, najispravniji način je da se pravilno podijeli na uloge. Najpouzdaniji način filtriranja dostupnih podataka je korištenje RLS-a. Mehanizam je dizajniran za ovaj zadatak. Ograničenja tačke najlakše je implementirati pomoću koda. Funkcionalne opcije i razdvajanje podataka su prilično specifični mehanizmi koji nemaju za cilj ograničavanje pristupa. Iako se u nekim slučajevima mogu koristiti za to.

Funkcionalne opcije su uobičajeni konfiguracijski objekti. Oni su dio mehanizma funkcionalnih opcija i omogućavaju vam da odaberete funkcionalnost u aplikacijskom rješenju koja se može uključiti/isključiti tokom implementacije bez promjene samog aplikativnog rješenja.

Na primjer, u zavisnosti od uslova konkretne implementacije, potrebno je onemogućiti obračun robe po skladištima. Tako da prilikom pripreme dokumenata za prijem robe, teren Stock nije prikazano u obrascu dokumenta.

U tu svrhu se u konfiguraciji može definirati funkcionalna opcija Računovodstvo skladišta, pohranjen u konstanti tipa Boolean.

Različiti objekti konfiguracije ili njihovi detalji mogu biti povezani sa ovom funkcionalnom opcijom. Na primjer, možete povezati atribut s ovom funkcionalnom opcijom Stock dokument Prijem robe.

Zatim, tokom implementacije, možete omogućiti ili onemogućiti ovu funkcionalnu opciju u određenoj bazi podataka u načinu rada 1C:Enterprise.

Platforma će automatski uključiti i isključiti prikaz svih relevantnih elemenata interfejsa (polja, komande, kolone liste, elementi izveštaja). U našem slučaju, polje će biti skriveno ili prikazano Stock u svim oblicima dokumenata Prijem robe.

Izlaskom platforme 1C:Enterprise 8.2, u stablu konfiguracije pojavio se novi objekat - "Funkcionalne opcije". Aktivno se koristi u svim standardnim konfiguracijama baziranim na upravljanim formama, a služi za pojednostavljenje procesa prikaza pojedinačnih detalja i objekata u interfejsu. Na primjer, u vašoj konfiguraciji postoji modul za razmjenu s vanjskim web servisima. Ovaj modul koristi niz detalja u dokumentima, registrima i pojedinačnim komponentama u podsistemima. Modul je opcioni i nije neophodan za svaku kompaniju. Logično je da budući da nije svima potreban modul, nije uvijek potrebno prikazati sve elemente/polja koja su s njim povezana.

U starijim verzijama platforme, rješavanje takvih problema zahtijevalo je pisanje dodatnog koda, koji je morao biti pozvan u svim zavisnim dijelovima. Na primjer, ako smo trebali sakriti određene detalje obrasca (ovisno o vrijednosti postavke), tada smo morali pozvati odgovarajući kod prilikom otvaranja obrasca. Ovo nije bilo baš zgodno i u većini slučajeva programeri su odustali od takvih stvari.

Dobro je ako trebate samo sakriti polja u obliku dokumenata, ali možemo imati i registarske obrasce sa kojima je moguća i interakcija korisnika. Pisanje univerzalne kontrolne funkcije ekrana je prilično teško i zahtijeva dodatno vrijeme, koje nikad nije dovoljno.

Funkcionalne opcije su dizajnirane da riješe ovu i mnoge druge poteškoće povezane s prikazom elemenata interfejsa/kompozicije dostupnih objekata u korisničkom interfejsu. U ovoj napomeni neću razmatrati primjere korištenja glavne svrhe funkcionalnih opcija, već ću skrenuti pažnju na njihovu upotrebu na nestandardan način. Možda je poznat mnogim naprednim programerima, ali ja sam do ove metode došao sasvim slučajno. Tačnije, inspirisan je praksom programiranja u JavaScript-u.

Slučaj br. 1: funkcionalna opcija kao omotač preko drugih objekata

Prva nestandardna karakteristika funkcionalnih opcija je mogućnost stvaranja omota. Razmotrimo najviše najjednostavniji primjer– konstante. Na primjer, dodajete novu konstantu u konfiguraciju s velikim brojem korisničkih uloga. Da bi korisnici mogli pristupiti vrijednosti konstante, morate postaviti prava čitanja na odgovarajuće uloge. Ako prava nisu postavljena, tada korisnici neće moći dobiti njegovu vrijednost. Ako ima mnogo uloga i one nisu naslijeđene od osnovne uloge, morat ćete potrošiti vrijeme na potvrđivanje odgovarajućih polja.

Funkcijska opcija može elegantnije riješiti ovaj problem. Ideja je sljedeća: kreirati konstantu (na primjer, ). Mi ne dodjeljujemo prava na to. Kreirajte funkcionalnu opciju istog imena i označite je u svojstvu "Skladištenje" ukazuju na konstantu "Mogućnost uštede podataka". Postavili smo i zastavu "Privilegovani tretman po prijemu".

To je to, sada bilo gdje u kodu gdje trebate upućivati ​​na konstantu pišemo ovako:

Pošto smo postavili opciju na privilegirani način rada, ne moramo specificirati nikakva dodatna prava za konstantu. Naravno, nema potrebe primjenjivati ​​ovu tehniku ​​u svim zamislivim i nezamislivim situacijama. Zapamti kompetentan aranžman prava su ključ mira. Koristite trik samo u zaista neophodnim slučajevima.

Slučaj br. 2. Dodatni nivo apstrakcije

Ne znam kako bih tačnije nazvala ovu metodu, ali u mom umu zvuči upravo tako. Pogledajmo prethodni primjer. I dalje imamo istu konstantu „Mogućnost čuvanja podataka“. S njim radimo koristeći istoimenu funkcionalnu opciju kao omotač.

Sada zamislite da se želimo riješiti konstante i prebaciti se na korištenje direktorija. Tipičan scenario za rješavanje takvog problema (ako koristimo samo konstantu) bi bio pokretanje globalnog alata za pretraživanje kako bi se otkrio pristup konstanti. Dopustite mi da vas podsjetim da ako ne koristimo funkcionalnu opciju kao omotač, onda bismo konstantu trebali tretirati ovako:

Konstante.Mogućnost SaveData.Get();

Pronalazimo sve pozive i zamjenjujemo ih putanjom do novog skladišnog objekta. Slažem se, ovo je prilično nezgodno. Ako smo koristili prethodni slučaj (koristeći funkcionalnu opciju kao omot), onda za „premještanje“ trebamo samo otići na svojstva funkcionalne opcije i promijeniti svojstvo "Skladištenje". Na primjer, navedite tamo "imenik" ili "Registar informacija". Nisu potrebne igre sa globalnom pretragom. Kod za pristup vrijednosti konstante kroz funkcionalnu opciju ostat će isti:

GetFunctionalOption("DataSavingAbility");

Objekt 1c "Funkcionalne opcije" - imaju za cilj da istaknu funkcionalnost u aplikativnom rješenju koje se može uključiti (isključiti) tokom implementacije bez mijenjanja samog sebe (zajedno sa podsistemima čine interfejs 1C tankog klijenta). Oni su dio mehanizma funkcionalnih opcija.

Mehanizam funkcionalnih opcija uključuje dva objekta metapodataka:

1. Funkcionalna opcija;
2. Parametri funkcionalnih opcija.

Više detalja

Funkcionalna opcija predstavlja objekat metapodataka koji može direktno uticati na sastav interfejsa aplikacije (ako funkcionalna opcija pohranjuje svoju vrijednost u Boolean atribut). Koristeći objekte ovog tipa, možete sakriti elemente koji se odnose na nedostupnu funkcionalnost. Na primjer, opcija Računovodstvo valuta može sakriti valute, polje Valuta iz i kolonu Iznos valute iz izvještaja.

Izvor vrijednosti funkcionalne opcije je objekt metapodataka odabran kao svojstvo Storage, na primjer može biti .

Ako je vrijednost funkcionalne opcije pohranjena u atributu direktorija ili resursu, potrebne su dodatne informacije koje točno pokazuju kako odabrati vrijednost opcije. U tu svrhu je obezbeđen poseban objekat metapodataka - Funkcionalne opcije Parametri.

Možemo reći da su parametri funkcionalnih opcija koordinatne ose vrednosnog prostora funkcionalnih opcija. Štaviše, jedan parametar funkcionalnih opcija može istovremeno odrediti vrijednost “svoje” koordinatne ose za mnoge funkcionalne opcije.

[kolaps]

Funkcionalne opcije mogu imati uticaj:

1. na korisnički interfejs:
   • globalno ;
   • detalji (uključujući kolone detalja obrasca kao što su Tabela vrijednosti ili ValueTree);
   • naredbe forme;
2. o izvještajima koji se implementiraju korištenjem sistema sastavljanja podataka;
3. na algoritme napisane na ugrađenom jeziku - moguće je dobiti vrijednosti funkcionalnih opcija iz ugrađenog jezika i koristiti ih u različitim uslovima, na primjer, da smanjite količinu proračuna (pogledajte, na primjer,).

PAŽNJA! Ako klijentska aplikacija radi sa datotečnom verzijom infobaze preko web servera, tada će se promijeniti funkcionalna opcija korisnički interfejs tek nakon ponovnog pokretanja web servera (ponovno pokretanje klijentske aplikacije neće promijeniti korisnički interfejs).

Svojstva funkcionalnih opcija 1C

• Skladištenje je polje u kojem trebate odabrati objekt tipa Boolean. Obično se koriste konstante.
• prilikom prijema - zastavica je odgovorna za mogućnost primanja vrijednosti funkcionalne opcije u privilegovanom načinu rada.
• Kompozicija - lista objekata i detalja o objektu, čija se vidljivost uključuje/isključuje kada je funkcionalna opcija uključena/isključena (kontrolisaće se pomoću obrasca za upravljanje).

Na primjer, u zavisnosti od uslova konkretne implementacije, možete onemogućiti obračun robe po skladištu tako da se prilikom registracije dokumenata za prijem robe polje Skladište ne prikazuje u obrascu dokumenta.

Karakteristike korištenja 1C funkcionalnih opcija:

1. Funkcionalne opcije mogu imati vrijednosti bilo koje vrste (ne nužno Boolean).
2. Kada dodajete novu konstantu za korištenje opcije funkcije, obavezno je uključite u odgovarajući podsistem i dodijelite joj dozvole.
3. Rad s funkcionalnim opcijama dostupan je iz ugrađenog jezika, zahvaljujući kojem programer može kreirati vlastite algoritme za vrijednosti funkcionalnih opcija.
4. Naredba komandnog interfejsa će biti isključena iz komandnog interfejsa ako je funkcionalna opcija onemogućena:
   • atribut koji je parametar komande;
   • tip parametra naredbe (ako je tip parametra naredbe složen, tada naredba postaje nedostupna kada su svi tipovi parametara onemogućeni).

PAŽNJA! Funkcionalne opcije i njihovi parametri ne utiču na sastav baze podataka: sve tabele i polja su prisutne u bazi bez obzira na stanje funkcionalnih opcija.

Utjecaj funkcionalnih opcija na detalje i naredbe obrasca:

1. upravljani tip obrasca<Вид>Objekt ( DirectoryObject, DocumentObject, itd.) će biti onemogućeno ako je odgovarajući objekt onemogućen funkcionalnom opcijom. Analiziraju se samo one funkcionalne opcije koje nemaju parametre.
2. Osnovni atributi tipa upravljanog obrasca DynamicListće biti onemogućeno ako funkcionalna opcija onemogućuje konfiguracijski objekt koji je naveden kao glavna tablica dinamičke liste. Analiziraju se samo one funkcionalne opcije koje nemaju parametre.
3. Atribut forme referentnog tipa je onemogućen ako je konfiguracijski objekt koji formira ovaj tip onemogućen funkcionalnom opcijom. Atribut forme kompozitnog tipa je onemogućen ako funkcionalne opcije onemogućavaju sve sastavne tipove.
4. Tablica obrasca će biti onemogućena ako prikazuje podatke atributa obrasca koji su onemogućeni funkcionalnom opcijom.
5. U dijalogu za odabir tipa nema tipova (na primjer, za polja za unos pridružena atributima složenog tipa) ako su konfiguracijski objekti koji formiraju ove tipove onemogućeni funkcionalnom opcijom. Informacije o tipovima onemogućenim funkcionalnim opcijama se keširaju na strani klijenta i brišu nakon 20 minuta ili tokom poziva metode UpdateInterface().

PAŽNJA! Za razliku od komandnog sučelja, vrijednosti parametara funkcionalnih opcija postavljaju se samo za određenu instancu obrasca.

Kreiranje parametra funkcionalnih opcija

Parametar funkcionalne opcije kreira se pomoću 1C konfiguracijskog objekta "Parametri funkcionalne opcije".

[kolaps]

Ovo se može učiniti u prozoru za konfiguraciju dodavanjem novog objekta.

Svojstva parametara funkcionalnih opcija:

• Upotreba - postavlja skup objekata čije će vrijednosti odrediti kako treba odabrati vrijednost funkcionalne opcije. Lista dostupnih objekata uključuje direktorije i dimenzije registra informacija. Za svaki parametar funkcionalnih opcija u ovoj listi možete odabrati jedan direktorij (sa cijele liste direktorija) i jednu dimenziju svakog informacionog registra.

PAŽNJA! Ne možete koristiti isti objekt metapodataka u više parametara opcija funkcije.