Odată cu lansarea platformei 1C:Enterprise 8.2, un nou obiect a apărut în arborele de configurare - „Opțiuni funcționale”. Este utilizat în mod activ în toate configurațiile tipice bazate pe formulare gestionate și servește la simplificarea procesului de afișare. detalii individuale, obiecte din interfață. De exemplu, în configurația dvs. există un modul pentru schimbul cu servicii web externe. Acest modul folosește o serie de detalii în documente, registre și componente individuale din subsisteme. Modulul este opțional și nu este cerut de orice companie. Este logic, deoarece nu toată lumea are nevoie de modul, atunci nu este întotdeauna necesar să afișați toate elementele / câmpurile asociate acestuia.

În versiunile mai vechi ale platformei, rezolvarea unor astfel de probleme necesita scrierea unui cod suplimentar care trebuia apelat în toate secțiunile dependente. De exemplu, dacă trebuia să ascundem anumite detalii de formular (în funcție de valoarea unei setări), atunci trebuia să apelăm codul corespunzător la deschiderea formularului. Nu a fost foarte convenabil și în majoritatea cazurilor dezvoltatorii au renunțat la astfel de lucruri.

Ei bine, dacă doriți să ascundeți doar câmpurile sub formă de documente, dar putem avea în continuare forme de registre cu care este posibilă și interacțiunea utilizatorului. Scrierea unei funcții generice de control a afișajului este destul de dificilă și va necesita timp suplimentar, ceea ce nu este niciodată suficient.

Opțiunile funcționale sunt concepute pentru a rezolva aceasta și multe alte dificultăți asociate cu afișarea elementelor de interfață / compoziția obiectelor disponibile în interfața cu utilizatorul. În această notă, nu voi lua în considerare exemple de utilizare a scopului principal al opțiunilor funcționale, dar voi acorda atenție utilizării lor într-un mod nu tocmai standard. Poate că este familiar pentru mulți dezvoltatori avansați, dar am ajuns la această metodă destul de întâmplător. Mai exact, a fost inspirat din practica programării în JavaScript.

Cazul #1: opțiune funcțională ca un înveliș peste alte obiecte

Prima caracteristică non-standard a opțiunilor funcționale este capacitatea de a crea ambalaje. Luați în considerare cel mai simplu exemplu - constante. De exemplu, adăugați o nouă constantă la o configurație cu un număr mare de roluri de utilizator. Pentru ca utilizatorii să acceseze valoarea constantei, trebuie să setați rolurile corespunzătoare pentru permisiuni de citire. Dacă drepturile nu sunt setate, atunci utilizatorii nu vor putea obține valoarea acestuia. Dacă există multe roluri și nu sunt moștenite de la rolul de bază, atunci va trebui să petreceți timp bifând casetele corespunzătoare.

Opțiunea funcțională poate rezolva această problemă mai elegant. Ideea este următoarea: creăm o constantă (de exemplu, ). Nu îi atribuim drepturi. Creăm o opțiune funcțională cu același nume și o specificăm în proprietate "Depozitare" specificați o constantă „Posibilitatea de a salva date”. Am pus și steagul „Modul privilegiat la primire”.

Asta e, acum în orice loc din cod în care vrei să te referi la o constantă, scriem astfel:

Deoarece am setat opțiunea în modul privilegiat, nu trebuie specificate drepturi suplimentare pentru constantă. Desigur, nu este necesară aplicarea acestei tehnici în toate cazurile de situații imaginabile și de neconceput. Amintiți-vă, un aranjament competent al drepturilor este cheia liniștii sufletești. Folosiți trucul numai atunci când este absolut necesar.

Cazul numărul 2. Nivel suplimentar de abstractizare

Nu știu cum să numesc corect această metodă, dar după părerea mea sună exact așa. Luați în considerare exemplul anterior. Avem în continuare aceeași constantă „Abilitatea de a salva date”. Lucrăm cu el folosind opțiunea funcțională cu același nume ca un wrapper.

Acum imaginați-vă că am vrut să scăpăm de constantă și să trecem la utilizarea unei cărți de referință. Un scenariu tipic pentru rezolvarea unei astfel de probleme (dacă folosim doar o constantă) ar fi rularea unui instrument de căutare globală pentru a găsi o referință la constantă. Permiteți-mi să vă reamintesc că, dacă nu folosim o opțiune funcțională ca un wrapper, atunci trebuie să ne referim la o constantă ca aceasta:

Constants.DataSaveAbility.Get();

Găsim toate apelurile și le înlocuim cu calea către noul obiect de stocare. De acord, este destul de incomod. Dacă am folosit cazul anterior (folosind o opțiune funcțională ca un wrapper), atunci pentru a „muta” trebuie doar să mergem la proprietățile opțiunii funcționale și să schimbăm proprietatea "Depozitare". De exemplu, pune acolo "Director" sau „Registrul de informații”. Nu sunt necesare jocuri cu căutare globală. Codul pentru accesarea valorii unei constante printr-o opțiune de funcție va rămâne același:

GetFunctionOption ("Posibilitatea de salvare a datelor");

Function Options este un obiect de metadate situat în grupul „General”:

Opțiunile funcționale fac parte din mecanismul opțiunilor funcționale care vă permit să activați sau să dezactivați unele funcționalități în soluția aplicației, în funcție de nevoile utilizatorului, fără a modifica configurația în sine.
De exemplu, nu orice organizație poate folosi controlul stocurilor. Dacă nu se utilizează contabilitatea depozitului, atunci este logic să eliminam câmpul depozit din toate documentele, directoarele și registrele - atunci opțiunile funcționale ne vin în ajutor.

Să ne uităm la un exemplu:

Să creăm o opțiune funcțională " Contabilitatea depozitului".
Stocare: este specificat câmpul care stochează valoarea.
Puteți selecta o constantă, un atribut de director sau o resursă de registru de informații.
Vom folosi o constantă.

Să creăm o constantă" Păstrați contabilitatea în depozite" și selectați-o în câmpul de stocare. Această constantă va fi responsabilă pentru activarea și dezactivarea opțiunii funcționale. Setați caseta de selectare „Mod privilegiat la primire”. Această casetă de selectare înseamnă că valorile opțiunii funcționale vor fi primite în modul privilegiat :

Actualizăm, lansăm 1C Enterprise. Setați valoarea constantei = Adevărat:

Ca urmare, avem:

Când setăm constanta = False, obținem:

Ai o întrebare, ai nevoie de ajutorul unui consultant?

Așadar, am creat o opțiune funcțională care gestionează câmpuri de tip DirectoryLink.Warehouse

Să ne uităm acum la un exemplu de utilizare a parametrilor opțiunilor funcției.
Să adăugăm o nouă opțiune funcțională " Contabilitatea valutară"
Depozitare: Director.Organizație.Propoziții.Contabilitatea valutară

Să adăugăm la compoziție detaliile documentului „Setați prețurile articolelor” - „Moneda”

Sub forma unui document în procedurile „On CreationAtServer” și „OrganizationOnChange”
Să adăugăm următorul cod:

Actualizați configurația și rulați-o.
Creăm două Organizații și pentru una dintre ele bifăm caseta „Contabilitatea valutară”

Ce obținem ca rezultat? Ca urmare a utilizării parametrilor opțiunii funcționale, tu și cu mine am primit controlul parametric al câmpului „Moneda” din documentul „Setare prețuri articole”. Acestea. pentru organizația Alpha, câmpul Monedă va fi afișat, iar pentru organizația Beta, câmpul Monedă nu va fi afișat.
Să ne asigurăm de asta. Deschideți documentul și încercați să schimbați câmpul „Organizare”.
Când setați org="alpha", moneda este afișată; schimbare la „Beta” - moneda este eliminată

1. Drepturi de acces.

De fapt, totul este foarte simplu. În 1C implicit tot ce nu este permis este interzis. Există o singură entitate responsabilă de acces utilizator la orice funcționalitate sau date. Această entitate este numită „Dreptul de acces”. Ea este singura un element responsabil de accesul la un anumit mod de operare, director, atribut....

Numărul de tipuri de drepturi de acces este predeterminat de platformă. Întreaga platformă are două grupuri principale de drepturi de acces. Comun întregului sistem drepturi de acces la mecanismele platformei, responsabil de accesul la anumite moduri de operare ale platformei (Administrare, Mod Exclusiv, Thin client, Deschidere interactiva de rapoarte externe....). Și permisiunile obiectelor, permițându-vă să lucrați cu diferite obiecte de configurare. Numărul acestora depinde de tipul obiectului de configurare. De exemplu, directorul are 16 tipuri diferite de acces (Citire, Adăugare, Modificare, Ștergere....). Pentru registrul de informații există doar cinci tipuri de acces. Toate aceste drepturi pot fi setate doar la nivelul întregului director. De asemenea, puteți restricționa accesul la nivel de atribut. Dar în acest caz, doar o parte din tipurile de drepturi este disponibilă (pentru directoare, acestea sunt drepturi de vizualizare și editare).

Toate drepturile de acces sunt interconectate și depind unele de altele. Există niveluri mai înalte și mai jos. Nu puteți acorda un drept de nivel inferior dacă utilizatorul nu are dreptul de a efectua acțiuni de nivel superior.

Considera drepturi de acces la director.În această diagramă, puteți vedea că majoritatea drepturilor sunt perfecționări ale unor drepturi mai generale. Dacă Right1 este complet amplasat pe diagramă în interiorul dreptunghiului altui Right2, atunci Right1 nu poate fi emis fără emiterea Right2. Cel mai comun drept este dreptul „Citește”. Dacă dreptul „Citește” lipsește, atunci toate celelalte drepturi sunt indisponibile. Dacă dreptul de adăugare nu este disponibil, atunci dreptul de atașare interactiv nu poate fi setat. In orice caz, sistemul de drepturi nu poate fi numit o ierarhie cu drepturi depline. De exemplu, dreptul de „Editare” poate fi acordat numai dacă aveți drepturile de „Vizualizare” și „Modificare”. Dar este posibil să dați „View” fără „Change” sau „Change” fără „View”.

Un drept de acces este cea mai mică unitate de acces. Tot controlul accesului se reduce la eliberarea setului potrivit de drepturi pentru utilizator. Obiectele rămase (roluri, grupuri de acces) sunt doar o legătură suplimentară care servește la gruparea și eliberarea mai convenabilă a drepturilor de acces.

2. Roluri - un mecanism de acordare a drepturilor de acces

Să aruncăm o privire la cum funcționează acordarea drepturilor de acces utilizatorului. Pentru confortul eliberării drepturilor de acces în platforma 1C, o specială Mecanism „Roly”.. Este un strat între utilizatorii bazei de informații și drepturile de acces. Fiecare rol combină un set de drepturi de acces, a căror atribuire are sens numai în același timp. De exemplu, în rolul „Citiți informațiile de contact”, este logic să combinați seturile de drepturi responsabile pentru directoarele conexe cu informațiile de contact. Cel mai într-un mod simplu setarea rolului unui utilizator este deschiderea cardului de utilizator IB în configurator și bifarea casetelor de lângă rolurile de care are nevoie utilizatorul. Acesta este un mod universal și funcționează în orice configurație. Cu toate acestea, odată cu complicarea configurațiilor și creșterea numărului de roluri, a devenit destul de laborios. Prin urmare, în soluțiile standard actuale există un strat suplimentar între utilizatorul de securitate a informațiilor și roluri. Acest strat este implementat sub formă subsistemul „Controlul accesului”. Vă permite să combinați roluri în entități mai mari - „Profiluri” și să nu mai atribuiți utilizatorul roluri individuale, dar profiluri care conțin seturi de roluri multiple.

Luați în considerare schema de atribuire a drepturilor de acces utilizatorilor utilizate în majoritatea configurațiilor tipice. Într-o formă simplificată, poate fi reprezentată după cum urmează. Sunt introduse noi entități „Profil de acces”și „Grup de acces”. Fiecare profil de acces include mai multe roluri. Și fiecărui utilizator i se atribuie unul sau mai multe grupuri de acces. În continuare, fiecare grup de acces este asociat cu un profil de acces. Ca urmare, avem posibilitatea de a specifica pentru utilizator nu doar roluri, ci seturi de roluri în funcție de funcțiile îndeplinite de acesta.

Din punct de vedere tehnic, acest sistem de eliberare a drepturilor este implementat cu participarea a două subsisteme standard. Subsistemul „Access Management” este utilizat pentru a configura asocierea grupurilor de acces cu rolurile predefinite în configurare. Subsistemul „Utilizatori” este utilizat pentru a stabili legături între utilizatorii IS și grupurile de acces de configurare.

3. „Logica permisiunilor” ca regulă de intersecție a rolurilor.

Este important de înțeles că în 1C logica generală a controlului accesului este logica permisiunii. În platforma 1C în general nu există restricții de acces. Există doar mecanisme emiterea accesului. În mod implicit, accesul la toate datele este refuzat și setarea de acces este de a oferi fiecărui utilizator drepturile de care are nevoie. Aceasta înseamnă că, dacă un anumit rol dă utilizatorului dreptul de a vizualiza documentele „Vânzări de mărfuri”, atunci în niciun caz acest drept nu poate fi luat alte roluri sau orice altă platformă și mecanisme de configurare. Inițial, puteți să nu acordați acces complet la director, dar să filtrați datele la care acordăm acces folosind RLS. Dar dacă accesul a fost deja acordat, atunci acesta nu mai poate fi luat de alte roluri.

De aceea, atunci când restricționați accesul utilizatorului la director pe roluri, este foarte important să verificați dacă utilizatorului nu i se atribuie niciun alt rol în același director. În caz contrar, primul rol va oferi accesul necesar, pe care cel de-al doilea nu îl poate nega.

Platforma are capacitatea de a acorda utilizatorului drepturi suplimentare pe durata unei anumite operațiuni. Această caracteristică se numește „Modul privilegiat”. Acesta permite utilizatorului să efectueze acțiuni asupra datelor care nu sunt disponibile pentru el. Cu toate acestea, nu există posibilitatea în platformă de a reduce măcar temporar drepturile utilizatorului.

4. Controlul accesului indirect.

Există mecanisme separate care, deși nu sunt destinate direct controlului accesului, îl afectează indirect și pot fi folosite pentru restricții suplimentare. Să aruncăm o privire la principalele lor caracteristici.

4.1. opțiuni funcționale.

Un sistem de control al accesului este uneori denumit mecanism opțiuni funcționale. Acest lucru nu este în întregime adevărat, deoarece opțiunile funcționale nu afectează în niciun fel accesul la date. Acesta este doar un mecanism de interfață, conceput pentru a simplifica interfața pentru utilizator. A apărut în platforma 8.2 ca urmare a complicației funcționalității de configurare. Opțiunile funcționale sunt destinate pentru a se ascunde de interfață funcționalitate care nu este utilizată în această companie sau în acest anumit utilizator. Mecanismul afectează doar afișarea datelor. Comenzile dispar din interfață, iar detaliile care sunt dezactivate de opțiunile funcționale sunt ascunse pe formulare. în care utilizatorul are acces la toate aceste comenzi și detalii. Poate funcționa cu date ascunse în mod programatic folosind procesarea fără probleme.

Puteți citi mai multe despre lucrul cu opțiunile funcționale pe ITS

4.2. RLS (Securitate la nivel de înregistrare)

Toate mecanismele enumerate mai sus afectează furnizarea de acces la obiecte în general. La directoare, documente, detalii despre directoare. Drepturile de acces afectează accesul la obiecte, opțiunile funcționale afectează afișarea obiectelor în interfață. Adesea există o sarcină care să permită utilizatorului să acceseze datele unui director sau document. Dar nu la toate datele, ci doar la unele dintre ele. De exemplu, permiteți accesul la documentele de implementare pentru o singură organizație.

Există un mecanism suplimentar pentru setarea acestei permisiuni. RLS (Securitate la nivel de înregistrare). După cum sugerează și numele, acest mecanism de control al accesului este la nivelul intrărilor specifice din tabel. Dacă drepturile de acces dau acces la tabele ca întreg (directoare) sau coloane de tabele (detalii), atunci RLS determină anumite rânduri de tabele (înregistrări) cu care utilizatorului i se permite să lucreze. Vă permite să definiți datele care sunt disponibile pentru utilizator.

Când analizați acest mecanism, merită întotdeauna să ne amintim că RLS nu este un mecanism de refuzare a accesului. El este mecanismul filtrarea emiterii accesului. Acestea. RLS nu afectează drepturile utilizatorului, este un filtru care restricționează eliberarea drepturilor. RLS afectează doar acea conexiune specială „Rol” - „Dreptul de acces” în care este înregistrat. Și nu afectează drepturile de acces acordate de alte roluri. De exemplu, dacă un rol permite accesul la documente numai de către Organizația1, iar un alt rol permite accesul la documente de către Depozitul1, atunci, ca rezultat, utilizatorul va avea acces la toate documentele care specifică Organizația1 SAU Depozitul1. Prin urmare, dacă unui utilizator i se acordă mai multe roluri, atunci filtrul folosind RLS trebuie setat în fiecare rol pentru ambele domenii (pe organizare si depozit). În soluțiile tipice, această sarcină este de obicei rezolvată prin crearea unui singur rol, în care sunt înregistrate toate filtrele RLS posibile. Acest rol este apoi atribuit tuturor utilizatorilor care lucrează cu aceste directoare. De asemenea, controlează ca utilizatorul să nu aibă acces la alte roluri care conțin dreptul de acces la documente restricționate.

De asemenea, este de remarcat faptul că filtrele RLS pot fi aplicate nu tuturor tipurilor posibile de acces la date, ci numai tipuri de acces de nivel superior. De exemplu, pentru directoarele din cele șaisprezece tipuri de acces disponibile, filtrele RLS pot fi aplicate numai la patru principale: citire, modificare, adăugare și ștergere. Aceasta înseamnă că nu putem, de exemplu, să acordăm utilizatorului dreptul de „Modificare” fără un filtru pentru abilitatea de a lucra programatic cu orice documente și dreptul de „Editare” cu filtrul RLS pentru organizarea pentru lucrul interactiv în același timp. Dacă dorim ca utilizatorul să poată edita documente cu un filtru RLS, trebuie să aplicăm un filtru general la nivelul superior „Modificare” sau „Citire”.

Având în vedere complexitatea generală a mecanismelor, este de obicei destul de dificil să ne dăm seama ce este exact disponibil pentru un anumit utilizator al unei configurații tipice. Pentru a verifica drepturile acordate în configurațiile tipice, există un raport foarte convenabil, care se numește „Permisiuni”. Analizează toate drepturile acordate utilizatorului și afișează lista finală a drepturilor emise de toate grupurile de acces, ținând cont de filtrele RLS.

4.3. Separarea datelor.

Un alt mecanism care afectează accesul la date este partajarea datelor. Acest mecanism este conceput pentru a fi utilizat într-unul singur baza fizica datele mai multor baze de date independente având o configurație comună și directoare generale. În unele cazuri foarte limitate, acest mecanism poate fi considerat control al accesului. Când este activat, fiecare utilizator poate lucra doar într-una dintre bazele sale independente de date, dar în același timp poate folosi date comune.

Într-un anumit sens general, acest mecanism poate fi considerat și un filtru de date și un caz special de implementare RLS. Spre deosebire de RLS, separarea este un mecanism mult mai rigid. Și datorită acestei rigidități, dezvoltatorii au capacitatea tehnică de a folosi indici suplimentari pentru a face o astfel de filtrare fără încetiniri inerente RLS.

De fapt RLS este doar abordari suplimentare, adăugat automat la fiecare interogare de bază de date. Împărțirea datelor înseamnă adăugarea unui delimitator la toate tabelele partiționate și indecșii acestora, inclusiv cel grupat. Datele sunt grupate în contextul separatorului, adică. redistribuit fizic pe discîn grupuri separate pentru fiecare valoare de delimitare. Datorită acestui fapt, fiecare utilizator lucrează numai cu propriile sale date, iar serverul nu trebuie să scaneze fizic întregul tabel cu fiecare solicitare. Este suficient să vizualizați numai zona de date a partiției curente.

Cu toate acestea, tocmai din cauza acestei redistribuiri fizice a datelor, atunci când un utilizator complet, care nu are un filtru după valorile delimitatoare, funcționează, toate interogările sunt foarte, foarte lente. Fără o valoare de delimitare, utilizarea completă a indicilor nu este posibilă, astfel încât cantitatea de date citită fizic de pe disc și procesată la fiecare solicitare poate ridica in ordine. În consecință, în realitate, separarea are sens numai dacă toți utilizatorii care lucrează constant în baza de date vor lucra numai în zona lor.

4.4. Cod program.

Poate cel mai universal mod de a stabili restricții suplimentare este cod de programare. Ele pot afecta orice mecanisme ale platformei. De exemplu, pentru a restricționa accesul la documente, un dezvoltator poate adăuga un filtru la formularul de listă de documente, la formularul de selecție și poate verifica programatic capacitatea de a vizualiza datele documentului atunci când deschide un anumit formular de document. Dezvoltatorul în rapoartele sale poate aplica un filtru atunci când selectează datele.

Cu toate acestea, codul programului nu există nicio modalitate de a limita drepturile în ansamblu prin configurare. Cel mai mult pe care un dezvoltator poate face este să introducă restricții în mecanismele specifice de recuperare a datelor individuale. Datorită faptului că 1C utilizează un model obiect pentru lucrul cu date, codul programului poate fi garantat pentru a proteja datele împotriva modificărilor, adăugând verificările necesare la modulul obiect. Dar dezvoltatorul nu poate garanta pe deplin că utilizatorul cu siguranță nu va putea obține informații despre documentele de implementare ale altor persoane prin alte rapoarte sau procesări.

Acest principiu este folosit, de exemplu, în. Conectându-se la configurație, extensia adaugă restricții de utilizator și verificări la toate directoarele și documentele. Filtrează datele afișate utilizatorilor în liste, verifică accesul la vizualizarea sau modificarea datelor. Se asigură că datele interzise nu pot fi modificate. Dar nu poate filtra datele din rapoarte sau interogări.

Există întotdeauna opțiuni de obținere a datelor interzise prin cerere, prelucrare proprie sau raportare. Este posibil să se limiteze foarte strict lista de funcționalități de configurare utilizate de utilizator și să se adauge un filtru separat fiecărui mecanism (formular, procesare, raport, solicitare) permis utilizatorului.

4.5. Comparație de opțiuni.

Să încercăm să comparăm pe scurt opțiunile luate în considerare pentru restricții suplimentare de date.

5. Rezultate.

Fiecare metodă de stabilire a restricțiilor are avantajele și dezavantajele sale. Din punct de vedere al tehnologiei, cea mai corectă modalitate este o împărțire competentă în roluri. Pentru a filtra datele disponibile, cel mai fiabil mod este utilizarea RLS. Pentru această sarcină este proiectat mecanismul. Constrângerile punctuale sunt cel mai ușor de implementat folosind cod. Opțiunile funcționale și partajarea datelor sunt mecanisme mai degrabă specifice care nu au scopul de a restricționa accesul. Deși în unele cazuri pot fi folosite pentru aceasta.

Opțiuni funcționaleși Parametru de opțiune de funcție- acestea sunt obiecte de configurare 1C 8.3 (8.2), care împreună reprezintă mecanismul opțiunilor funcționale. Mecanismul de opțiuni funcționale este un funcțional care vă permite să definiți un set de funcționalități de care au nevoie utilizatorii.

Mai simplu spus, mecanismul de opțiuni funcționale este un comutator pornit/oprit pentru diferite funcționalități dintr-o configurație.

De ce ar trebui să dezactivați funcționalitatea?

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

Adesea, funcționalitatea suplimentară poate complica munca angajaților. Un exemplu banal de utilizare a opțiunilor funcționale în 1C este acela că baza de date ține înregistrări pentru o organizație sau depozit, de ce atunci obligă utilizatorul să completeze aceste date în toate documentele?

Ce controlează opțiunile funcționale?

În primul rând, utilizarea opțiunilor funcționale este cel mai convenabil reflectată în interfață: detalii de formular, formulare de comandă, o interfață comună - toate acestea pot fi asociate cu opțiuni funcționale. În funcție de valoarea opțiunilor funcționale, puteți limita producția de date într-un raport bazat pe .

Obiectul 1c „Opțiuni funcționale” - conceput pentru a evidenția funcționalitatea din soluția de aplicație care poate fi activată (dezactivată) în timpul implementării fără a se schimba (împreună cu Subsistemele, ele formează interfața clientului subțire 1C). Ele fac parte din mecanismul de opțiuni funcționale.

Opțiuni de funcționare Mecanism include două obiecte de metadate:

1. Opțiune funcțională;
2. Parametrii opțiunilor funcționale.

Mai mult

Opțiune de funcție este un obiect de metadate care poate afecta direct compoziția interfeței aplicației (dacă opțiunea funcțională își stochează valoarea într-un atribut boolean). Cu ajutorul obiectelor de acest tip, puteți ascunde elemente care se referă la funcționalități inaccesibile. De exemplu, opțiunea de contabilitate valutară poate ascunde Monede, câmpul Moneda din, coloana Sumă monedă din rapoarte.

Sursa valorii opțiunii funcționale este obiectul de metadate selectat ca proprietate Stocare , de exemplu, poate fi .

În cazul stocării valorii unei opțiuni funcționale într-un atribut de director sau o resursă, sunt necesare informații suplimentare care să indice exact modul de selectare a valorii opțiunii. Un obiect de metadate separat este furnizat în acest scop − Opțiuni de funcție Parametri.

Putem spune că parametrii opțiunilor funcționale sunt axele de coordonate ale spațiului de valori ale opțiunilor funcționale. Mai mult, un parametru al opțiunilor funcționale poate determina valoarea axei de coordonate „sa” simultan pentru o multitudine de opțiuni funcționale.

[ascunde]

Opțiunile funcționale pot afecta:

1. la interfata utilizator:
   • global ;
   • rechizite (inclusiv coloane de rechizite de forma precum Tabel de valori sau Arborele valorii);
   • formular comenzi;
2. asupra rapoartelor implementate folosind un sistem de compunere a datelor;
3. pe algoritmi scrisi în limbajul încorporat - este posibil să obțineți valorile opțiunilor funcționale din limbajul încorporat și să le utilizați în diferite condiții, de exemplu, pentru a reduce cantitatea de calcule (a se vedea, de exemplu, ).

ATENŢIE! Dacă aplicația client funcționează cu versiunea de fișier a bazei de informații prin intermediul serverului web, atunci schimbarea opțiunii funcționale va schimba interfața cu utilizatorul numai după repornirea serverului web (repornirea aplicației client nu va schimba interfața cu utilizatorul).

Proprietățile Opțiunilor funcționale 1C

• Stocare - un câmp în care trebuie să selectați un obiect de tip boolean. De regulă, se folosesc constante.
• la obținerea - steag-ul este responsabil pentru posibilitatea obținerii valorii opțiunii funcționale în modul privilegiat.
• Compoziție - o listă de obiecte și atribute ale obiectelor, a căror vizibilitate este activată / dezactivată atunci când opțiunea funcțională este dezactivată / dezactivată (care urmează să fie controlată folosind un formular gestionat).

De exemplu, în funcție de condițiile unei anumite implementări, puteți prevedea dezactivarea contabilității mărfurilor pe depozite, astfel încât la înregistrarea documentelor de intrare mărfuri, câmpul Depozit să nu fie afișat în formularul de document.

Caracteristici ale utilizării opțiunilor funcționale 1C:

1. Opțiunile de funcție pot avea valori de tip arbitrar (nu neapărat boolean).
2. Când adăugați o nouă constantă pentru a utiliza o opțiune funcțională, asigurați-vă că o includeți în subsistemul adecvat și îi atribuiți permisiuni.
3. Lucrul cu opțiuni funcționale este disponibil din limbajul încorporat, datorită căruia dezvoltatorul își poate crea propriii algoritmi pentru valorile opțiunilor funcționale.
4. Comanda interfeței de comandă va fi exclusă din interfața de comandă dacă opțiunea funcției este dezactivată:
   • atribut, care este un parametru de comandă;
   • tipul parametrului de comandă (dacă tipul de parametru de comandă este compus, atunci comanda devine indisponibilă atunci când toate tipurile de parametri sunt dezactivate).

ATENŢIE! Opțiunile funcționale și parametrii acestora nu afectează compoziția bazei de date: toate tabelele și câmpurile sunt prezente în baza de date, indiferent de starea opțiunilor funcționale.

Influența opțiunilor funcționale asupra detaliilor și comenzilor formularului:

1. tip de formular gestionat<Вид>Un obiect ( DirectoryObject, DocumentObject etc.) vor fi dezactivate dacă obiectul corespunzător este dezactivat de opțiunea funcțională. Sunt analizate doar acele opțiuni funcționale care nu au parametri.
2. Atributul principal al formularului de tip gestionat DynamicList va fi dezactivat dacă opțiunea funcțională dezactivează obiectul de configurare care este specificat ca tabelul principal al listei dinamice. Sunt analizate doar acele opțiuni funcționale care nu au parametri.
3. Un atribut de formular al unui tip de referință este dezactivat dacă obiectul de configurare care formează acel tip este dezactivat de o opțiune funcțională. Atributul formular al unui tip compus este dezactivat dacă opțiunile funcționale dezactivează toate tipurile de componente.
4. Tabelul formular va fi dezactivat dacă afișează datele unui atribut de formular dezactivat de o opțiune funcțională.
5. Nu există tipuri în dialogul de selecție a tipului (de exemplu, pentru câmpurile de intrare asociate cu atribute de tip compus) dacă obiectele de configurare care formează aceste tipuri sunt dezactivate de o opțiune funcțională. Informațiile despre tipurile dezactivate de opțiunile funcționale sunt stocate în cache pe partea clientului și șterse după 20 de minute sau în timpul unui apel de metodă UpdateInterface().

ATENŢIE! Spre deosebire de interfața de comandă, valorile parametrilor opțiunilor funcționale sunt setate numai pentru o anumită instanță a formularului.

Crearea unui parametru de opțiuni funcționale

Parametrul opțiunii funcționale este creat folosind obiectul de configurare 1C „Parametrii opțiunilor funcționale”.

[ascunde]

Acest lucru se poate face în fereastra de configurare prin adăugarea unui nou obiect.

Opțiuni funcție Proprietăți parametru:

• Utilizare - setează un set de obiecte ale căror valori vor determina modul în care trebuie selectată valoarea opțiunii funcționale. Lista obiectelor disponibile include dicționare și dimensiuni ale registrului de informații. Pentru fiecare parametru de opțiuni funcționale din această listă, puteți selecta un director (din întreaga listă de directoare) și o dimensiune a fiecărui registru de informații.

ATENŢIE! Nu puteți utiliza același obiect de metadate în mai mult de un parametru de opțiune de funcție.