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 ca, din moment ce nu toată lumea are nevoie de un modul, atunci nu este întotdeauna necesară afișarea tuturor elementelor/câmpurilor asociate cu acesta.

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

Este bine dacă trebuie doar să ascundeți câmpurile sub formă de documente, dar putem avea și formulare de înregistrare cu care este posibilă și interacțiunea utilizatorului. Scrierea unei funcții universale de control al 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 atrage atenția asupra utilizării lor într-un mod nestandard. Poate fi familiar pentru mulți dezvoltatori avansați, dar am ajuns la această metodă complet întâmplător. Mai exact, a fost inspirat din practica programării în JavaScript.

Cazul nr. 1: o 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. Să ne uităm la 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 unei constante, trebuie să setați drepturi de citire pentru rolurile corespunzătoare. 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.

O opțiune de funcție poate rezolva această problemă mai elegant. Ideea este aceasta: creați o constantă (de exemplu, ). Nu îi atribuim drepturi. Creați o opțiune funcțională cu același nume și indicați-o în proprietate "Depozitare" indică o constantă „Posibilitatea de salvare a datelor”. Am pus și steagul „Tratament privilegiat la primire”.

Asta este, acum oriunde în cod unde trebuie să te referi la o constantă scriem astfel:

Deoarece am setat opțiunea în modul privilegiat, nu trebuie să specificăm drepturi suplimentare pentru constantă. Desigur, nu este nevoie să aplicați această tehnică în toate situațiile imaginabile și de neconceput. Amintiți-vă, alocarea corectă a drepturilor este cheia liniștii sufletești. Folosiți trucul numai în cazurile cu adevărat necesare.

Cazul nr. 2. Nivel suplimentar de abstractizare

Nu știu cum să numesc această metodă mai corect, dar în mintea mea sună exact așa. Să ne uităm la 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 unui director. 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 detecta accesul la constantă. Permiteți-mi să vă reamintesc că, dacă nu folosim o opțiune funcțională ca un wrapper, atunci ar trebui să tratăm constanta astfel:

Constants.Ability toSaveData.Get();

Găsim toate apelurile și le înlocuim cu calea către noul obiect de stocare. De acord, acest lucru 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, indicați 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 funcțională va rămâne același:

GetFunctionalOption(„DataSavingAbility”);

Opțiunile funcționale sunt 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 contabilitatea depozitului. Dacă nu se utilizează contabilitatea depozitului, atunci este logic să eliminați 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ă " Contabilitate prin Depozite".
Stocare: este indicat 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 evidența depozitelor" și selectați-o în câmpul de stocare. Această constantă va fi responsabilă pentru activarea și dezactivarea opțiunii funcționale. Bifați caseta „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 rezultat avem:

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

Ai o întrebare sau ai nevoie de ajutor de la un consultant?

Deci, am creat o opțiune funcțională care controlează câmpuri de tip DirectoryLink.Warehouse

Să ne uităm acum la un exemplu de utilizare a parametrilor opțiunilor funcționale.
Să adăugăm o nouă opțiune funcțională " Contabilitatea valutară"
Depozitare: Director.Organizare.Detalii.Contabilitatea valutară

Să adăugăm la compoziția documentului detaliile „Setarea prețurilor articolelor” - „Moneda”

Sub forma unui document în procedurile „When CreatedOnServer” și „OrganizationWhenChanged”
Să adăugăm următorul cod:

Actualizăm configurația și o lansăm.
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, am primit controlul parametric al câmpului „Moneda” din documentul „Setarea prețurilor articolelor”. Acestea. pentru organizația „Alpha” va fi afișat câmpul „Moneda”, iar pentru organizația „Beta” câmpul „Moneda” 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 Organizație = "Alpha", moneda este afișată; schimbați în „Beta” - moneda este eliminată

1. Drepturi de acces.

De fapt, totul este foarte simplu. În 1C implicit tot ceea ce nu este permis este interzis. Mânca o singură entitate responsabilă de acces utilizator la orice funcționalitate sau date. Această entitate este numită „Drept de acces”. Se întâmplă să fie singurul un element responsabil de accesul la un anumit mod de operare, director, detalii....

Numărul de tipuri de drepturi de acces este predeterminat de platformă. În total, platforma 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 obiectului, permițându-vă să lucrați cu diverse 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....). Există doar cinci tipuri de acces pentru registrul de informații. Toate aceste drepturi pot fi setate doar la nivel de director în ansamblu. De asemenea, puteți restricționa accesul la nivel de acreditări. Dar în acest caz, doar o parte din tipurile de drepturi sunt disponibile (pentru directoare acestea sunt drepturi de vizualizare și editare).

Toate drepturile de acces sunt interconectate și depind unele de altele. Există drepturi de nivel superior și inferior. Nu puteți acorda un drept de nivel inferior dacă utilizatorul nu are dreptul de a efectua o acțiune de nivel superior.

Sa luam in considerare drepturi de acces la director. Această diagramă arată că majoritatea drepturilor sunt clarificări ale unor drepturi mai generale. Dacă Right1 este complet situat 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 de citire nu este disponibil, atunci toate celelalte drepturi nu sunt disponibile. Dacă dreptul „Adăugați” nu este disponibil, atunci dreptul „Adăugați 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 doar dacă aveți drepturile de „Vizualizare” și „Editare”. Dar puteți da „Vizualizare” fără „Modificare” sau „Modificare” fără „Vizualizare”.

Un drept de acces este unitatea minimă de acces. Tot controlul accesului se reduce la eliberarea utilizatorului setul necesar de drepturi. Obiectele rămase (roluri, grupuri de acces) sunt pur și simplu legături suplimentare care servesc pentru gruparea și eliberarea mai convenabilă a drepturilor de acces.

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

Să vedem cum se face exact acordarea drepturilor de acces utilizatorului. Pentru comoditatea eliberării drepturilor de acces în platforma 1C, o specială Mecanismul „Roli”.. 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 seturi de drepturi responsabile pentru directoarele conexe cu informațiile de contact. Cel mai într-un mod simplu stabilirea rolului utilizatorului este deschiderea cardului utilizatorului de securitate a informațiilor în configurator și bifarea casetelor de lângă rolurile de care are nevoie utilizatorul. Aceasta este o metodă universală și funcționează în orice configurație. Cu toate acestea, odată cu creșterea complexității configurațiilor și creșterea numărului de roluri, a devenit destul de intensivă în muncă. 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 roluri separate, și profiluri care conțin seturi de mai multe roluri.

Să luăm în considerare schema de atribuire a drepturilor de acces utilizatorilor, utilizată î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. Fiecare grup de acces este apoi asociat cu un profil de acces. Drept urmare, avem posibilitatea de a specifica nu doar roluri pentru utilizator, ci și seturi de roluri în funcție de funcțiile pe care le îndeplinește.

Din punct de vedere tehnic acest sistem eliberarea drepturilor este implementată cu participarea a două subsisteme standard. Subsistemul „Control acces” este utilizat pentru configurarea conexiunii grupurilor de acces cu roluri predefinite în configurare. Subsistemul „Utilizatori” este utilizat pentru a configura conexiunile între utilizatorii de securitate a informațiilor și grupurile de acces de configurare.

3. „Logica permisiunii” ca regulă pentru intersecția rolurilor.

Este important de înțeles că în 1C logica generală de control al accesului este logica permisiunii. În platforma 1C în general nu există mecanisme de refuzare a accesului. Există doar mecanisme emiterea accesului. În mod implicit, accesul la toate datele este refuzat și setarea accesului constă în acordarea fiecărui utilizator a drepturilor de care are nevoie. Aceasta înseamnă că, dacă un anumit rol oferă utilizatorului dreptul de a vizualiza documentele „Vânzări de bunuri”, atunci acest drept nu poate fi luat în niciun fel alte roluri sau orice altă platformă și mecanisme de configurare. Inițial nu puteți acorda acces deplin la director, ci puteți filtra datele la care dăm acces folosind RLS. Dar dacă accesul a fost deja acordat, atunci acesta nu mai poate fi preluat de alte roluri.

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

Platforma are capacitatea de a acorda utilizatorului drepturi suplimentare în timp ce efectuează o operațiune separată. Această caracteristică se numește Mod privilegiat. Acesta permite utilizatorului să efectueze acțiuni asupra datelor care nu sunt disponibile pentru el. Cu toate acestea, platforma nu are capacitatea de a reduce nici măcar temporar drepturile utilizatorului.

4. Controlul accesului indirect.

Există mecanisme separate care, deși nu sunt direct destinate controlului accesului, îl influențează indirect și pot fi folosite pentru restricții suplimentare. Să ne uităm 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 un mecanism pur de interfață, conceput pentru a simplifica interfața pentru utilizator. A apărut în platforma 8.2 ca urmare a unei funcționalități de configurare mai complexe. Opțiunile funcționale sunt destinate pentru a se ascunde de interfață funcționalitate care nu este utilizată de această companie sau de către acest utilizator. Mecanismul afectează doar afișarea datelor. Comenzile dispar din interfață, iar detaliile dezactivate de opțiunile funcționale sunt ascunse pe formulare. în care utilizatorul are în continuare 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ă asigurarea accesului la obiecte în ansamblu. Pentru a consulta cărți, documente, detalii de referință. Drepturile de acces afectează accesul la obiecte, opțiunile funcționale afectează afișarea obiectelor în interfață. Adesea apare sarcina de a permite unui utilizator accesul la datele din director sau document. Dar nu la toate datele, ci doar la o parte din ele. De exemplu, permiteți accesul la documentele de implementare pentru o singură organizație.

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

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 limitează eliberarea drepturilor. RLS afectează doar conexiunea specifică „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 pentru Organization1, iar un alt rol permite accesul la documente pentru Warehouse1, atunci utilizatorul va avea în cele din urmă acces la toate documentele care indică Organization1 SAU Warehouse1. 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 standard, această problemă este de obicei rezolvată prin crearea unui rol în care sunt înregistrate toate filtrele RLS posibile. Acest rol este apoi atribuit tuturor utilizatorilor care lucrează cu aceste directoare. De asemenea, este controlat ca utilizatorul să nu aibă alte roluri disponibile care să conțină dreptul de acces la documente restricționate.

De asemenea, este de remarcat faptul că filtrele RLS nu pot fi aplicate tuturor tipurilor posibile de acces la date, ci numai tipuri de acces de nivel superior. De exemplu, pentru directoare, din cele șaisprezece tipuri de acces disponibile, filtrele RLS pot fi aplicate doar la patru principale: Citire, Modificare, Adăugare și Ștergere. Aceasta înseamnă că nu putem, de exemplu, să acordăm utilizatorului simultan dreptul de „Editare” fără un filtru pentru abilitatea de a lucra programatic cu orice document și dreptul de „Editare” cu un filtru RLS de organizație pentru lucru interactiv. Dacă avem nevoie ca utilizatorul să poată edita documente cu un filtru RLS, ni se cere să impunem un filtru general la nivelul superior de „Editare” 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 este numit "Drepturi de acces". 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 separarea datelor. Acest mecanism este proiectat să funcționeze într-unul singur baza fizica date din mai multe baze de date independente având o configuraţie comună şi cărți de referință generale. În unele cazuri foarte limitate, acest mecanism poate fi considerat control al accesului. Când este activat, fiecare utilizator poate lucra numai într-una dintre bazele de date independente, dar poate utiliza date comune.

Într-un anumit sens general, acest mecanism poate fi considerat și un filtru de date și un caz special al implementării 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 efectua o astfel de filtrare fără încetinirile inerente ale RLS.

De fapt RLS este doar selecții suplimentare, adăugat automat la fiecare interogare de bază de date. Împărțirea datelor înseamnă adăugarea unui separatorîn toate tabelele partiționate și indecșii acestora, inclusiv în cel grupat. Datele sunt grupate în funcție de separator, adică. redistribuit fizic pe discîn grupuri separate pentru fiecare valoare a separatorului. Datorită acestui fapt, fiecare utilizator lucrează doar 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 rulează ca utilizator complet care nu are un filtru bazat pe valorile separatoare, toate interogările sunt executate foarte, foarte lent. Fără valoarea separatorului, este imposibil să folosiți pe deplin indici, astfel încât cantitatea de date citită fizic de pe disc și procesată cu fiecare solicitare poate crește cu ordine de mărime. În consecință, în realitate, separarea are sens numai dacă toți utilizatorii care lucrează constant în baza de date vor lucra numai în propria lor zonă.

4.4. Cod program.

Poate cel mai universal mod de a stabili restricții suplimentare este codul programului. Ele pot influența orice mecanism de platformă. 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 poate aplica un filtru în rapoartele sale 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 garanta protecția datelor împotriva modificărilor prin adăugarea 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. Prin conectarea la configurație, extensia adaugă restricții și verificări personalizate tuturor cărților de referință și documentelor. Filtrează datele afișate utilizatorilor în liste, verificând 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 pentru obținerea datelor interzise prin cerere, prelucrare proprie sau raportare. Cu excepția cazului în care limitați foarte strict lista de funcționalități de configurare utilizate de utilizator și adăugați un filtru separat fiecărui mecanism (formular, procesare, raport, cerere) permis utilizatorului.

4.5. Comparație de opțiuni.

Să încercăm să comparăm pe scurt opțiunile luate în considerare pentru limitarea suplimentară a datelor.

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 de a o împărți corect în roluri. Pentru a filtra datele disponibile, cea mai fiabilă modalitate 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 separarea datelor sunt mecanisme destul de 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 funcțională- acestea sunt obiecte de configurare 1C 8.3 (8.2), care împreună reprezintă un mecanism pentru opțiunile funcționale. Mecanismul de opțiuni funcționale este o funcționalitate care vă permite să determinați setul 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 într-o configurație.

De ce ar putea fi necesar să dezactivați funcționalitatea?

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

Adesea, funcționalitatea suplimentară poate complica munca angajaților. Un exemplu banal de utilizare a opțiunilor funcționale în 1C - baza de date păstrează înregistrări pentru o organizație sau depozit, atunci de ce să oblige 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.

Mecanism de opțiuni de funcție include două obiecte de metadate:

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

Mai multe detalii

Opțiune funcțională 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 Storage , 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 valoric al opțiunilor funcționale. Mai mult, un parametru al opțiunilor funcționale poate determina valoarea axei de coordonate „sa” simultan pentru multe opțiuni funcționale.

[colaps]

Opțiunile funcționale pot afecta:

1. la interfata utilizator:
   • global ;
   • rechizite (inclusiv coloane de rechizite de forma, cum ar fi Tabelul Valorilor sau ValueTree);
   • formular comenzi;
2. asupra rapoartelor implementate folosind un sistem de compunere a datelor;
3. la algoritmi scrisi într-un limbaj î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 duce la o modificare a interfeței 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

• Stocarea este un câmp în care trebuie să selectați un obiect de tip boolean. De obicei, se folosesc constante.
• la primire - steag-ul este responsabil pentru capacitatea de a primi valoarea unei opțiuni funcționale în modul privilegiat.
• Compoziție - o listă de obiecte și detalii despre obiect, a căror vizibilitate este activată/dezactivată atunci când o opțiune funcțională este activată/dezactivată (va fi controlată folosind un formular gestionat).

De exemplu, în funcție de condițiile unei anumite implementări, este posibil să se dezactiveze contabilitatea mărfurilor pe depozit, astfel încât la înregistrarea documentelor pentru intrarea mărfurilor, câmpul Depozit să nu fie afișat în formularul de document.

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

1. Opțiunile funcționale pot avea valori de orice tip (nu neapărat boolean).
2. Când adăugați o nouă constantă pentru a utiliza o opțiune de funcție, asigurați-vă că o includeți în subsistemul corespunzător ș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țională este dezactivată:
   • atribut, care este un parametru de comandă;
   • tipul de parametru 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. Atributele de bază ale unui tip de formular 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. Atributul formular al unui tip de referință este dezactivat dacă obiectul de configurare care formează acest tip este dezactivat de o opțiune funcțională. Atributul de formă al unui tip compus este dezactivat dacă opțiunile funcționale dezactivează toate tipurile constituente.
4. Un tabel de formular va fi dezactivat dacă afișează date de atribute de formular care sunt dezactivate 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 complex) 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

Un parametru de opțiune funcțională este creat utilizând obiectul de configurare 1C „Parametri de opțiune funcțională”.

[colaps]

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

Proprietățile parametrului opțiunilor funcționale:

• Utilizare - setează un set de obiecte ale căror valori vor determina modul în care trebuie selectată valoarea unei opțiuni funcționale. Lista de obiecte disponibile include directoare și dimensiuni de registru 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 mulți parametri de opțiune a funcției.