1c ֆունկցիոնալ ընտրանքների օրինակ: Բաշխված տեղեկատվական համակարգերի կառուցում, որոնում, սովորական առաջադրանքներ, ֆունկցիոնալ տարբերակներ

1. Մուտքի իրավունքներ.

Իրականում ամեն ինչ շատ պարզ է. Լռելյայն 1C-ում ամեն ինչ, ինչ չի կարելի, արգելված է. Ուտել մուտքի համար պատասխանատու միայն մեկ կազմակերպությունօգտագործողը ցանկացած ֆունկցիոնալության կամ տվյալների համար: Այս սուբյեկտը կոչվում է «Մուտքի իրավունք». Նա պատահում է միակտարր, որը պատասխանատու է աշխատանքի որոշակի ռեժիմի, գրացուցակի, հատկանիշի հասանելիության համար...

Մուտքի իրավունքների տեսակների քանակը կանխորոշված ​​է հարթակի կողմից: Ամբողջ հարթակն ունի մուտքի իրավունքի երկու հիմնական խումբ. Ընդհանուր ամբողջ համակարգի համար մուտքի իրավունքներ հարթակի մեխանիզմներին, պատասխանատու է հարթակի որոշակի գործառնական ռեժիմների մուտքի համար (Կառավարում, Բացառիկ ռեժիմ, Նիհար հաճախորդ, Արտաքին հաշվետվությունների ինտերակտիվ բացում...): ԵՎ օբյեկտի թույլտվությունները, որը թույլ է տալիս աշխատել տարբեր կոնֆիգուրացիայի օբյեկտների հետ: Նրանց թիվը կախված է կոնֆիգուրացիայի օբյեկտի տեսակից: Օրինակ, գրացուցակը ունի 16 տարբեր տեսակներմուտք (Կարդալ, Ավելացնել, Փոփոխել, Ջնջել...): Տեղեկատվական ռեգիստրի համար հասանելի է ընդամենը հինգ տեսակ: Այս բոլոր իրավունքները կարող են սահմանվել միայն ամբողջ գրացուցակի մակարդակում: Դուք կարող եք նաև սահմանափակել մուտքը հատկանիշի մակարդակով: Բայց այս դեպքում հասանելի է իրավունքների տեսակների միայն մի մասը (դիրեկտորիաների համար դրանք դիտել և խմբագրել իրավունքներն են):

Մուտքի բոլոր իրավունքները փոխկապակցված են և կախված են միմյանցից: Կան ավելի բարձր իրավունքներ և ավելի շատ ցածր մակարդակ. Դուք չեք կարող ավելի ցածր մակարդակի իրավունք տալ, եթե օգտվողն իրավունք չունի կատարել ավելի բարձր մակարդակի գործողություններ:

Հաշվի առեք գրացուցակ մուտքի իրավունք:Այս գծապատկերը ցույց է տալիս, որ իրավունքների մեծ մասը ավելի շատերի ճշգրտում է ընդհանուր իրավունքներ. Եթե ​​Right1-ը ամբողջությամբ գտնվում է մեկ այլ Right2-ի ուղղանկյունի ներսում գտնվող գծապատկերի վրա, ապա Right1-ը չի կարող տրվել առանց Right2-ի թողարկման: Ամենատարածված իրավունքը «Կարդալ» իրավունքն է։ Եթե ​​«Կարդալ» իրավունքը բացակայում է, ապա մնացած բոլոր իրավունքները անհասանելի են: Եթե ​​հավելվածի իրավունքը հասանելի չէ, ապա Ինտերակտիվ հավելվածի իրավունքը չի կարող սահմանվել: Այնուամենայնիվ, իրավունքների համակարգը չի կարելի անվանել լիարժեք հիերարխիա։Օրինակ, «Խմբագրել» իրավունքը կարող է տրվել միայն այն դեպքում, եթե ունեք «Դիտել» և «Փոխել» իրավունքները: Բայց կարելի է տալ «View» առանց «Change»-ի կամ «Change» առանց «View»-ի։

Մուտքի իրավունքը մուտքի ամենափոքր միավորն է: Մուտքի բոլոր հսկողությունը հանգում է օգտվողին իրավունքի ճիշտ փաթեթի տրամադրմանը:Մնացած օբյեկտները (դերերը, մուտքի խմբերը) պարզապես լրացուցիչ կապ են, որը ծառայում է խմբավորմանը և ավելի հարմար տրամադրելու մուտքի իրավունքը:

2. Դերեր՝ մուտքի իրավունքի տրամադրման մեխանիզմ

Եկեք նայենք, թե ինչպես է այն աշխատում օգտատիրոջ մուտքի իրավունքի տրամադրում։ 1C հարթակում մուտքի իրավունքներ տրամադրելու հարմարության համար հատուկ «Ռոլի» մեխանիզմ. Այն շերտ է տեղեկատվական բազայի օգտագործողների և մուտքի իրավունքների միջև: Յուրաքանչյուր դեր միավորում է մուտքի իրավունքի մի շարք, որոնց նշանակումը իմաստ ունի միայն միաժամանակ: Օրինակ, «Կարդալ կոնտակտային տվյալները» դերում տրամաբանական է միավորել հարակից դիրեկտորիաների համար պատասխանատու իրավունքների խմբերը կոնտակտային տեղեկատվության հետ: Մեծ մասը պարզ ձևովՕգտագործողի դերը սահմանելը բացելով IB օգտվողի քարտը կոնֆիգուրատորում և ստուգելով օգտատիրոջ անհրաժեշտ դերերի կողքին գտնվող վանդակները. Սա ունիվերսալ միջոց է և աշխատում է ցանկացած կոնֆիգուրացիաներով: Այնուամենայնիվ, կոնֆիգուրացիաների բարդացման և դերերի քանակի ավելացման հետ մեկտեղ այն բավականին աշխատատար է դարձել։ Հետեւաբար, ընթացիկ ստանդարտ լուծումներկա լրացուցիչ շերտ IB օգտագործողի և դերերի միջև: Այս շերտը իրականացվում է ձևով «Մուտքի վերահսկում» ենթահամակարգ. Այն թույլ է տալիս միավորել դերերը ավելի մեծ միավորների մեջ՝ «Պրոֆիլներ» և օգտատիրոջը հատկացնել ոչ թե առանձին դերեր, այլ մի քանի դերերի հավաքածուներ պարունակող պրոֆիլներ:

Դիտարկենք օգտվողներին մուտքի իրավունքներ հատկացնելու սխեման, որն օգտագործվում է շատ բնորոշ կոնֆիգուրացիաներում: Պարզեցված ձևով այն կարելի է ներկայացնել հետևյալ կերպ. Ներդրվում են նոր սուբյեկտներ «Մուտքի պրոֆիլ»Եվ «Access Group». Յուրաքանչյուր մուտքի պրոֆիլ ներառում է մի քանի դերեր: Եվ յուրաքանչյուր օգտվողին հատկացվում է մեկ կամ մի քանի մուտքի խմբեր: Հաջորդը, յուրաքանչյուր մուտքի խումբ կապված է մուտքի պրոֆիլի հետ: Արդյունքում մենք հնարավորություն ենք ստանում օգտատիրոջ համար նշել ոչ միայն դերեր, այլ դերերի հավաքածուներ՝ կախված նրա կատարած գործառույթներից։

Տեխնիկական տեսանկյունից այս համակարգըիրավունքների թողարկումն իրականացվում է երկու ստանդարտ ենթահամակարգերի մասնակցությամբ։ «Մուտքի կառավարում» ենթահամակարգն օգտագործվում է մուտքի խմբերի միավորումը կազմաձևում նախապես սահմանված դերերի հետ կարգավորելու համար: «Օգտվողներ» ենթահամակարգն օգտագործվում է IS օգտվողների և կազմաձևման մուտքի խմբերի միջև կապեր ստեղծելու համար:

3. «Թույլտվությունների տրամաբանություն»՝ որպես դերերի հատման կանոն։

Կարևոր է հասկանալ, որ 1C-ում մուտքի վերահսկման ընդհանուր տրամաբանությունն է թույլտվության տրամաբանություն. 1C հարթակում ընդհանրապես մուտքի սահմանափակումներ չկան. Կան միայն մեխանիզմներ մուտքի տրամադրում. Լռելյայնորեն, բոլոր տվյալների մուտքն արգելված է, և մուտքի կարգավորումն այն է, որ յուրաքանչյուր օգտվողին տրամադրի իրեն անհրաժեշտ իրավունքները. Սա նշանակում է, որ եթե ինչ-որ դեր օգտվողին իրավունք է տալիս դիտել «Ապրանքների վաճառք» փաստաթղթերը, ապա ոչ մի կերպ չի կարելի այս իրավունքը խլելայլ դերեր կամ ցանկացած այլ հարթակ և կազմաձևման մեխանիզմներ: Դուք կարող եք սկզբում տրամադրել ոչ ամբողջական մուտք դեպի գրացուցակ, բայց զտել այն տվյալները, որոնց մենք թույլ ենք տալիս մուտք գործել RLS-ի միջոցով: Բայց եթե մուտքն արդեն տրված է, ապա այն այլևս չի կարող խլվել այլ դերերով:

Այդ իսկ պատճառով, երբ սահմանափակել օգտվողների մուտքը գրացուցակ ըստ դերերի, շատ կարևոր է ստուգել, ​​որ օգտագործողին որևէ այլ դեր վերապահված չէ նույն գրացուցակում: Հակառակ դեպքում, առաջին դերը կտա անհրաժեշտ մուտքը, որը երկրորդը չի կարող հերքել։

Պլատֆորմը հնարավորություն ունի օգտատիրոջը տալ լրացուցիչ իրավունքներ կոնկրետ գործողության տևողության համար։ Այս հատկությունը կոչվում է «Արտոնյալ ռեժիմ»: Այն թույլ է տալիս օգտվողին գործողություններ կատարել այն տվյալների վրա, որոնք իրեն հասանելի չեն: Այնուամենայնիվ, հարթակում օգտատիրոջ իրավունքները նույնիսկ ժամանակավորապես նվազեցնելու հնարավորություն չկա։

4. Անուղղակի մուտքի վերահսկում.

Կան առանձին մեխանիզմներ, որոնք թեև ուղղակիորեն նախատեսված չեն մուտքի վերահսկման համար, բայց անուղղակիորեն ազդում են դրա վրա և կարող են օգտագործվել լրացուցիչ սահմանափակումների համար։ Եկեք նայենք նրանց հիմնական հատկանիշներին:

4.1. ֆունկցիոնալ ընտրանքներ.

Մուտքի վերահսկման համակարգը երբեմն կոչվում է մեխանիզմ ֆունկցիոնալ ընտրանքներ. Սա լիովին ճիշտ չէ, քանի որ ֆունկցիոնալ ընտրանքները որևէ կերպ չեն ազդում տվյալների հասանելիության վրա: Սա զուտ ինտերֆեյսի մեխանիզմ է,նախագծված է օգտագործողի համար ինտերֆեյսը պարզեցնելու համար: Այն հայտնվել է հարթակ 8.2-ում՝ կոնֆիգուրացիայի ֆունկցիոնալության բարդացման արդյունքում։ Ֆունկցիոնալ տարբերակները նախատեսված են ինտերֆեյսից թաքնվելու համարֆունկցիոնալություն, որը չի օգտագործվում այս կոնկրետ ընկերությունում կամ այս կոնկրետ օգտվողում: Մեխանիզմը ազդում է միայն տվյալների ցուցադրման վրա: Հրամանները անհետանում են ինտերֆեյսից, և ֆունկցիոնալ ընտրանքների միջոցով անջատված մանրամասները թաքնված են ձևաթղթերի վրա: Որտեղ օգտատերը մուտք ունի այս բոլոր հրամաններն ու մանրամասները. Այն կարող է աշխատել թաքնված տվյալների հետ ծրագրային կերպով՝ օգտագործելով մշակումը առանց որևէ խնդիրների:

Դուք կարող եք ավելին կարդալ ITS-ի ֆունկցիոնալ ընտրանքների հետ աշխատելու մասին

4.2. RLS (գրառման մակարդակի անվտանգություն)

Վերը թվարկված բոլոր մեխանիզմները ազդում են ընդհանուր առմամբ օբյեկտների հասանելիության ապահովման վրա: Գրացուցակներին, փաստաթղթերին, տեղեկատուների մանրամասներին: Մուտքի իրավունքները ազդում են օբյեկտների հասանելիության վրա, ֆունկցիոնալ ընտրանքները ազդում են ինտերֆեյսի օբյեկտների ցուցադրման վրա: Հաճախ խնդիր կա՝ թույլ տալ օգտվողին մուտք գործել գրացուցակի կամ փաստաթղթի տվյալներ: Բայց ոչ բոլոր տվյալներին, այլ միայն դրանցից մի քանիսին։ Օրինակ, թույլ տվեք մուտք գործել իրականացման փաստաթղթեր միայն մեկ կազմակերպության համար:

Այս թույլտվությունը սահմանելու լրացուցիչ մեխանիզմ կա։ RLS (գրառման մակարդակի անվտանգություն). Ինչպես անունն է հուշում, մուտքի վերահսկման այս մեխանիզմը գտնվում է աղյուսակի հատուկ գրառումների մակարդակում: Եթե ​​մուտքի իրավունքները թույլ են տալիս մուտք գործել աղյուսակներ որպես ամբողջություն (դիրեկտորիաներ) կամ աղյուսակների սյունակներ (մանրամասներ), ապա RLS-ը սահմանում է աղյուսակների հատուկ տողեր (գրառումներ), որոնց հետ օգտատերը թույլատրվում է աշխատել: Այն թույլ է տալիս սահմանել այն տվյալները, որոնք հասանելի են օգտատիրոջը:

Այս մեխանիզմը վերլուծելիս միշտ արժե հիշել դա RLS-ը մուտքի մերժման մեխանիզմ չէ. Նա է մեխանիզմը մուտքի թողարկման զտում. Նրանք. RLS-ը չի ազդում օգտատիրոջ իրավունքների վրա, այն զտիչ է, որը սահմանափակում է իրավունքների տրամադրումը։ RLS-ն ազդում է միայն այն կոնկրետ կապի «Դերի» վրա՝ «Մուտքի իրավունք», որում այն ​​գրանցված է: Եվ չի ազդում այլ դերերի կողմից տրված մուտքի իրավունքների վրա: Օրինակ, եթե մի դերը թույլ է տալիս մուտք գործել փաստաթղթեր միայն Կազմակերպություն1-ի կողմից, իսկ մյուս դերը թույլ է տալիս մուտք գործել փաստաթղթեր Warehouse1-ի կողմից, ապա արդյունքում օգտվողին հասանելի կլինի բոլոր փաստաթղթերը, որոնք նշում են Organization1 OR Warehouse1: Հետևաբար, եթե օգտագործողին մի քանի դեր է վերապահված, ապա RLS օգտագործող զտիչը պետք է տեղադրվի յուրաքանչյուր դերումերկու դաշտերի համար (ըստ կազմակերպության և պահեստի): Տիպիկ լուծումներում այս խնդիրը սովորաբար լուծվում է՝ ստեղծելով մեկ դեր, որում գրանցված են բոլոր հնարավոր RLS ֆիլտրերը։ Այնուհետև այս դերը նշանակվում է այս դիրեկտորիաների հետ աշխատող բոլոր օգտվողներին: Այն նաև վերահսկում է, որ օգտատերը մուտք չունենա այլ դերեր, որոնք պարունակում են սահմանափակ փաստաթղթեր մուտք գործելու իրավունք:

Հարկ է նաև նշել, որ RLS ֆիլտրերը կարող են կիրառվել ոչ թե տվյալների հասանելիության բոլոր հնարավոր տեսակների վրա, այլ միայն բարձր մակարդակի մուտքի տեսակները. Օրինակ, հասանելի տասնվեց տիպի մուտքի դիրեկտորիաների համար RLS ֆիլտրերը կարող են կիրառվել միայն չորս հիմնականների վրա՝ ընթերցում, փոփոխում, ավելացում և ջնջում: Սա նշանակում է, որ մենք չենք կարող, օրինակ, օգտատիրոջը տալ «Փոփոխություն» իրավունքը առանց ֆիլտրի ցանկացած փաստաթղթի հետ ծրագրային աշխատելու հնարավորության համար և «Խմբագրել» իրավունքը RLS ֆիլտրի հետ՝ ինտերակտիվ աշխատանքի կազմակերպման համար, միաժամանակ: Եթե ​​ցանկանում ենք, որ օգտատերը կարողանա խմբագրել փաստաթղթերը RLS ֆիլտրով, մենք պետք է կիրառենք ընդհանուր զտիչ վերին մակարդակի «Փոփոխել» կամ «Կարդալ»:

Հաշվի առնելով մեխանիզմների ընդհանուր բարդությունը, սովորաբար բավականին դժվար է պարզել, թե կոնկրետ ինչն է հասանելի տիպիկ կոնֆիգուրացիայի կոնկրետ օգտագործողի համար: Տրված իրավունքները ստուգելու համար բնորոշ կոնֆիգուրացիաներկա շատ հարմար ռեպորտաժ, որը կոչվում է «Թույլտվություններ». Այն վերլուծում է օգտատիրոջը տրված բոլոր իրավունքները և ցուցադրում է մուտքի բոլոր խմբերի կողմից տրված իրավունքների վերջնական ցանկը՝ հաշվի առնելով RLS ֆիլտրերը։

4.3. Տվյալների տարանջատում.

Մեկ այլ մեխանիզմ, որն ազդում է տվյալների հասանելիության վրա տվյալների փոխանակում. Այս մեխանիզմը նախատեսված է մեկում օգտագործելու համար ֆիզիկական հիմքմի քանի անկախ տվյալների բազաների տվյալներ, որոնք ունեն ընդհանուր կոնֆիգուրացիա և ընդհանուր գրացուցակներ: Որոշ շատ սահմանափակ դեպքերում այս մեխանիզմը կարելի է դիտարկել որպես մուտքի վերահսկում: Երբ այն միացված է, յուրաքանչյուր օգտվող կարող է աշխատել միայն իր անկախ տվյալների բազաներից մեկում, բայց միևնույն ժամանակ օգտագործել ընդհանուր տվյալներ։

Որոշ ընդհանուր իմաստով այս մեխանիզմը կարելի է համարել նաև տվյալների զտիչ և RLS-ի իրականացման հատուկ դեպք: Ի տարբերություն RLS-ի, տարանջատումը շատ ավելի կոշտ մեխանիզմ է: Եվ այս կոշտության շնորհիվ մշակողները տեխնիկական հնարավորություն ունեն օգտագործելու լրացուցիչ ինդեքսներ՝ առանց RLS-ին բնորոշ դանդաղումների նման զտում կատարելու համար:

Իրականում RLS-ը պարզապես լրացուցիչ պայքար է, ավտոմատ կերպով ավելացվել է տվյալների բազայի յուրաքանչյուր հարցումին: Տվյալների բաժանումը սահմանազատող է ավելացնումբոլոր բաժանված աղյուսակներին և դրանց ինդեքսներին, ներառյալ կլաստերայինը: Տվյալները խմբավորվում են բաժանարարի համատեքստում, այսինքն. ֆիզիկապես վերաբաշխված սկավառակի վրաՎ առանձին խմբերյուրաքանչյուր սահմանազատիչ արժեքի համար: Դրա շնորհիվ յուրաքանչյուր օգտատեր աշխատում է միայն իր սեփական տվյալներով, և սերվերը կարիք չունի ֆիզիկապես սկանավորելու ամբողջ աղյուսակը յուրաքանչյուր հարցումով։ Բավական է դիտել միայն ընթացիկ բաժանման տվյալների տարածքը:

Այնուամենայնիվ, հենց տվյալների այս ֆիզիկական վերաբաշխման պատճառով է, որ երբ աշխատում է լիարժեք օգտվողը, որը չունի զտիչ ըստ սահմանազատիչների արժեքների, բոլոր հարցումները շատ, շատ դանդաղ են ընթանում: Առանց սահմանազատող արժեքի, ինդեքսների լիարժեք օգտագործումը հնարավոր չէ, այնպես որ սկավառակից ֆիզիկապես կարդացված և յուրաքանչյուր հարցումով մշակված տվյալների քանակը կարող է պատվերների բարձրացում. Ըստ այդմ, իրականում տարանջատումը իմաստ ունի միայն այն դեպքում, եթե տվյալների բազայում մշտապես աշխատող բոլոր օգտվողները կաշխատեն միայն իրենց տարածքում:

4.4. Ծրագրի կոդը.

Լրացուցիչ սահմանափակումներ սահմանելու ամենահամընդհանուր միջոցը, թերեւս, դա է ծրագրավորման կոդը. Նրանք կարող են ազդել հարթակի ցանկացած մեխանիզմի վրա: Օրինակ, փաստաթղթերի հասանելիությունը սահմանափակելու համար մշակողը կարող է զտիչ ավելացնել փաստաթղթերի ցանկի ձևին, ընտրության ձևին և կարող է ծրագրային կերպով ստուգել փաստաթղթի տվյալները դիտելու հնարավորությունը հատուկ փաստաթղթի ձևը բացելիս: Մշակողը իր հաշվետվություններում կարող է ֆիլտր կիրառել տվյալներ ընտրելիս:

Այնուամենայնիվ, ծրագրի կոդը Չկա որևէ կերպ սահմանափակելու իրավունքները որպես ամբողջություն կոնֆիգուրացիայի միջոցով. Առավելագույնը, ինչ կարող է անել ծրագրավորողը, տվյալների որոնման հատուկ մեխանիզմների մեջ սահմանափակումներ ստեղծելն է: Շնորհիվ այն բանի, որ 1C-ն օգտագործում է օբյեկտի մոդել տվյալների հետ աշխատելու համար, Ծրագրի կոդը կարող է երաշխավորվել, որ պաշտպանում է տվյալները փոփոխություններից, ավելացնելով անհրաժեշտ ստուգումները օբյեկտի մոդուլին: Բայց մշակողը չի կարող լիովին երաշխավորել, որ օգտատերը հաստատ չի կարողանա տեղեկատվություն ստանալ այլ մարդկանց կատարման փաստաթղթերի մասին այլ հաշվետվությունների կամ մշակման միջոցով:

Այս սկզբունքը օգտագործվում է, օրինակ, ք. Կազմաձևին միանալով՝ ընդլայնումը ավելացնում է օգտվողի սահմանափակումները և ստուգում բոլոր գրացուցակները և փաստաթղթերը: Այն զտում է օգտատերերին ցուցադրվող տվյալները ցուցակներում, ստուգում է մուտքը տվյալներ դիտելիս կամ փոփոխելիս: Ապահովում է, որ արգելված տվյալները չեն կարող փոխվել: Բայց այն չի կարող զտել տվյալները հաշվետվություններում կամ հարցումներում:

Միշտ կան արգելված տվյալներ խնդրանքով, սեփական մշակմամբ կամ զեկույցով ստանալու տարբերակներ: Հնարավո՞ր է շատ խստորեն սահմանափակել օգտագործողի կողմից օգտագործվող կազմաձևման ֆունկցիոնալության ցանկը և առանձին զտիչ ավելացնել օգտվողին թույլատրված յուրաքանչյուր մեխանիզմի (ձև, մշակում, հաշվետվություն, հարցում):

4.5. Ընտրանքների համեմատություն.

Փորձենք համառոտ համեմատել լրացուցիչ տվյալների սահմանափակման դիտարկված տարբերակները։

Ինչպես միացնել այն	Ինչ կլինի
Ֆունկցիոնալ ընտրանքներ- ինտերֆեյսի մեխանիզմ՝ ֆունկցիոնալությունը թաքցնելու համար
1. Ավելացրեք պահեստային տեղ ֆունկցիոնալ տարբերակի համար՝ հաստատուն, տեղեկատու գրքի հատկանիշ կամ տեղեկատվական ռեգիստրի ռեսուրս: 2. Կազմաձևին ավելացրեք ֆունկցիոնալ տարբերակ և նշեք դրա մեջ նախկինում ստեղծված պահեստի վայրը: 3. Ֆունկցիոնալ տարբերակի հատկություններում նշեք դրա կազմը, նշեք բոլոր կազմաձևման օբյեկտները, որոնք կախված կլինեն դրանից: 4. Միացնել ֆունկցիոնալ տարբերակի օգտագործումը ձեռնարկության ռեժիմում:	1. Ֆունկցիոնալ տարբերակում ներառված բոլոր օբյեկտներն այլևս չեն ցուցադրվի հրամանի միջերեսում: 2. Տարբերակի կողմից թաքնված բոլոր դաշտերը կվերանան ձևաթղթերում և հաշվետվություններում:
RLS (գրառման մակարդակի անվտանգություն)- լրացուցիչ զտիչներ թույլատրված դերերի իրավունքների վրա
1. Գրանցեք RLS ֆիլտրերը յուրաքանչյուր օգտվողի դերում՝ սահմանափակման կարիք ունեցող յուրաքանչյուր իրավունքների համար: Նշում. Ձեռնարկությունների ռեժիմում որևէ գործողություն չի պահանջվում: Զտիչները կկիրառվեն ավտոմատ կերպով:	1. Կազմաձևված զտիչը կավելացվի IB-ի յուրաքանչյուր հարցումին: 2. Տվյալները, որոնք չեն համապատասխանում RLS ֆիլտրին, հնարավոր չէ ստանալ ոչ մի կերպ. դրանք չեն ցուցադրվի ձևաթղթերում, հաշվետվություններում. չի ընտրվի որևէ հարցումով:
Տվյալների տարանջատում- պահպանում մի քանի անկախ մեկ ֆիզիկական տվյալների բազայում
1. Կազմաձևին ավելացրեք ընդհանուր հատկանիշ, որը որոշում է համօգտագործվող տվյալների կազմը: 2. Ավելացնում է նստաշրջանի երկու պարամետր՝ օգտագործման դրոշի և ընթացիկ տվյալների բաժանման արժեքի համար: 3. Տվյալների տարանջատումը հնարավոր դարձնելու համար ավելացրեք ծրագրի կոդը և լրացրեք անջատիչի ընթացիկ արժեքը:	1. Տվյալների բաժանման հնարավորությունը կազմաձևում ավելացնելուց անմիջապես հետո, աղյուսակները, որոնց համար ավելացվել է բաժանման հնարավորությունը, ֆիզիկապես կվերակառուցվեն: «Delimiter» դաշտը կավելացվի սահմանազատողի արժեքը պահելու համար: Սեղանների բոլոր ինդեքսները կվերակառուցվեն: Նրանց որպես առաջին դաշտ կավելացվի բաժանարար դաշտը: 2. Բաժանումը միացնելուց հետո. Բացարձակապես բոլոր հարցումները IS-ին կզտվեն բաժանարարի արժեքով: Ցանկացած տվյալ գրելիս անջատիչի արժեքը ինքնաբերաբար կլրացվի ըստ նիստի պարամետրի արժեքի։
Ծրագրի կոդը- կետերի ցանկացած լրացուցիչ սահմանափակում
1. Ավելացրեք կոդը՝ կոնֆիգուրացիայի մեջ անհրաժեշտ սահմանափակումները կիրառելու համար:	1. Կկատարի ճիշտ այն, ինչ գրված է: Նշում. կոդը չի ազդում ընդհանուր կազմաձևի վրա, այլ միայն կոնկրետ մեխանիզմի վրա, որի համար գրված է գործողությունը

5. Արդյունքներ.

Սահմանափակումներ սահմանելու յուրաքանչյուր մեթոդ ունի իր դրական և բացասական կողմերը: Տեխնիկայի տեսանկյունից ամենաճիշտ ճանապարհը դերերի գրագետ բաժանումն է։ Առկա տվյալները զտելու համար ամենահուսալի միջոցը RLS-ի օգտագործումն է: Հենց այս առաջադրանքի համար է նախատեսված մեխանիզմը: Կետային սահմանափակումներն ամենահեշտն է կիրառվել՝ օգտագործելով կոդը: Ֆունկցիոնալ ընտրանքները և տվյալների փոխանակումը բավականին կոնկրետ մեխանիզմներ են, որոնք նախատեսված չեն մուտքը սահմանափակելու համար: Թեև որոշ դեպքերում դրանք կարող են օգտագործվել դրա համար:

1C:Enterprise 8.2 պլատֆորմի թողարկմամբ նոր օբյեկտ հայտնվեց կոնֆիգուրացիայի ծառում. «Ֆունկցիոնալ ընտրանքներ». Այն ակտիվորեն օգտագործվում է բոլոր ստանդարտ կոնֆիգուրացիաներում՝ հիմնված կառավարվող ձևերի վրա և ծառայում է ինտերֆեյսում առանձին ատրիբուտների, օբյեկտների ցուցադրման գործընթացի պարզեցմանը: Օրինակ, ձեր կոնֆիգուրացիայի մեջ կա արտաքին վեբ ծառայությունների հետ փոխանակման մոդուլ: Այս մոդուլը օգտագործում է մի շարք մանրամասներ փաստաթղթերում, գրանցամատյաններում և ենթահամակարգերի առանձին բաղադրիչներում: Մոդուլը ընտրովի է և չի պահանջվում յուրաքանչյուր ընկերության կողմից: Տրամաբանական է, քանի որ ոչ բոլորին է պետք մոդուլը, ուրեմն միշտ չէ, որ անհրաժեշտ է ցուցադրել դրա հետ կապված բոլոր տարրերը/դաշտերը:

Պլատֆորմի հին տարբերակներում նման խնդիրների լուծումը պահանջում էր լրացուցիչ կոդ գրել, որը պետք է կանչվեր բոլոր կախյալ բաժիններում։ Օրինակ, եթե մեզ անհրաժեշտ էր թաքցնել ձևի որոշակի մանրամասներ (կախված պարամետրի արժեքից), ապա ձևը բացելիս անհրաժեշտ էր զանգահարել համապատասխան կոդը: Դա այնքան էլ հարմար չէր և շատ դեպքերում ծրագրավորողները հրաժարվեցին նման բաներից։

Դե, եթե ցանկանում եք թաքցնել միայն դաշտերը փաստաթղթերի տեսքով, բայց մենք դեռ կարող ենք ունենալ ռեգիստրների ձևեր, որոնց հետ հնարավոր է նաև օգտատերերի փոխազդեցություն: Ընդհանուր ցուցադրման կառավարման գործառույթ գրելը բավականին դժվար է և կպահանջի լրացուցիչ ժամանակ, որը երբեք բավարար չէ:

Ֆունկցիոնալ տարբերակները նախագծված են լուծելու այս և շատ այլ դժվարություններ, որոնք կապված են ինտերֆեյսի տարրերի ցուցադրման հետ/օգտագործողի միջերեսում առկա օբյեկտների կազմին: Այս գրառման մեջ ես չեմ դիտարկի ֆունկցիոնալ տարբերակների հիմնական նպատակի օգտագործման օրինակները, բայց ուշադրություն կդարձնեմ դրանց օգտագործմանը ոչ այնքան ստանդարտ ձևով: Թերևս դա ծանոթ է շատ առաջադեմ ծրագրավորողների, բայց ես այս մեթոդին եկել եմ միանգամայն պատահաբար: Ավելի ճիշտ, այն ոգեշնչված էր JavaScript-ում ծրագրավորման պրակտիկայից։

Դեպք #1. ֆունկցիոնալ տարբերակ՝ որպես փաթաթող այլ առարկաների վրա

Ֆունկցիոնալ ընտրանքների առաջին ոչ ստանդարտ առանձնահատկությունը փաթաթաներ ստեղծելու ունակությունն է: Հաշվի առեք ամենաշատը ամենապարզ օրինակըհաստատուններ են: Օրինակ, դուք ավելացնում եք նոր հաստատուն կոնֆիգուրացիայի մեջ, որն ունի մեծ թվով օգտվողի դերեր: Որպեսզի օգտվողները մուտք գործեն հաստատունի արժեքը, դուք պետք է սահմանեք համապատասխան դերեր՝ կարդալու թույլտվությունները: Եթե ​​իրավունքները սահմանված չեն, ապա օգտվողները չեն կարողանա ստանալ դրա արժեքը: Եթե ​​կան շատ դերեր, և դրանք ժառանգված չեն բազային դերից, ապա ստիպված կլինեք ժամանակ ծախսել համապատասխան վանդակները ստուգելու համար:

Ֆունկցիոնալ տարբերակը կարող է ավելի էլեգանտ լուծել այս խնդիրը։ Գաղափարը հետևյալն է՝ մենք ստեղծում ենք հաստատուն (օրինակ՝ )։ Մենք դրա նկատմամբ իրավունքներ չենք վերապահում։ Մենք ստեղծում ենք համանուն ֆունկցիոնալ տարբերակ և նշում այն ​​սեփականության մեջ «Պահեստավորում»նշեք հաստատուն «Տվյալները պահպանելու ունակություն». Դրոշն էլ դրեցինք «Ստացման արտոնյալ ռեժիմ».

Վերջ, հիմա կոդի ցանկացած վայրում, որտեղ ցանկանում եք հղում կատարել հաստատունին, մենք գրում ենք այսպես.

Քանի որ մենք ընտրանքը դրել ենք արտոնյալ ռեժիմի վրա, ոչ լրացուցիչ իրավունքներպետք չէ նշել հաստատունի համար: Իհարկե, անհրաժեշտ չէ կիրառել այս տեխնիկան պատկերացնելի և աներևակայելի իրավիճակների բոլոր դեպքերում: Հիշեք, որ իրավունքների իրավասու դասավորությունը մտքի խաղաղության բանալին է: Օգտագործեք հնարքը միայն խիստ անհրաժեշտության դեպքում:

Գործ թիվ 2. Աբստրակցիայի լրացուցիչ մակարդակ

Ես չգիտեմ, թե ինչպես ճիշտ անվանել այս մեթոդը, բայց իմ կարծիքով դա հնչում է հենց այդպես: Դիտարկենք նախորդ օրինակը։ Մենք դեռ ունենք նույն մշտական ​​«Տվյալները պահպանելու ունակությունը»: Մենք աշխատում ենք դրա հետ՝ օգտագործելով փաթաթան համանուն ֆունկցիոնալ տարբերակը:

Հիմա պատկերացրեք, որ մենք ուզում էինք ազատվել հաստատունից և անցնել տեղեկատու գրքույկի օգտագործմանը: Նման խնդրի լուծման տիպիկ սցենարը (եթե մենք օգտագործում ենք միայն հաստատուն) կլինի գլոբալ որոնման գործիքի գործարկումը՝ հաստատունին հղում գտնելու համար։ Հիշեցնեմ, որ եթե մենք ֆունկցիոնալ տարբերակ չենք օգտագործում որպես փաթաթան, ապա պետք է անդրադառնանք այսպիսի հաստատունին.

Constants.DataSaveAbility.Get();

Մենք գտնում ենք բոլոր զանգերը և փոխարինում այն ​​նոր պահեստային օբյեկտի ուղով: Համաձայնեք, բավականին անհարմար է: Եթե ​​մենք օգտագործել ենք նախորդ դեպքը (օգտագործելով ֆունկցիոնալ տարբերակ որպես փաթաթում), ապա «տեղափոխելու» համար անհրաժեշտ է միայն անցնել ֆունկցիոնալ տարբերակի հատկություններին և փոխել հատկությունը։ «Պահեստավորում». Օրինակ, դրեք այնտեղ «տեղեկատու»կամ «Տեղեկատվության ռեգիստր». Համաշխարհային որոնումով խաղեր չեն պահանջվում: Ֆունկցիոնալ տարբերակի միջոցով հաստատունի արժեքին մուտք գործելու կոդը կմնա նույնը.

GetFunctionOption («DataSavePossibility»);

30.03.2017

Ֆունկցիոնալ տարբերակներ 1C 8.3 (մեխանիզմ, օգտագործում)

Սկսել կարևորնշեք, որ գործառույթի ընտրանքների մեխանիզմը ՉԻսահմանափակում է տվյալների հասանելիությունը, բայց միայն վերահսկում է ձևի տվյալների տեսանելիությունը (ցուցադրումը): Պլատֆորմում գտնվող օբյեկտների հասանելիությունը սահմանափակելու համար օգտագործվում է դերերի մեխանիզմը:
Հետևաբար, մենք սկսում ենք ֆունկցիոնալ տարբերակների մեխանիզմի մեր դիտարկումը խնդրի նկարագրությամբ: Մեր մինի-կոնֆիգուրացիայի մեջ կա մեկ գրացուցակ «Պահեստներ»: Ենթադրենք, որ բոլոր օգտվողները մուտք ունեն այս գրացուցակը:
Կրկին! Ֆունկցիոնալ ընտրանքների մեխանիզմը վերահսկում է տվյալների ցուցադրումը ձևի վրա և չի սահմանափակում մուտքը դեպի մետատվյալների օբյեկտ (տեղեկատու, փաստաթուղթ, ռեեստրի գրառումներ….) Անհրաժեշտ է կատարել «Օգտագործել բազմաթիվ պահեստներ» պարամետրը: (Այո, այո ... Դա UT 11.X-ում է, այնտեղ արված է կազմակերպությունների համար). Եթե ​​մենք օգտագործում ենք մի քանի պահեստ, ապա ինտերֆեյսում հասանելի է պահեստի գրացուցակը, եթե ոչ, ապա հրամանը, որը բացում է մեկ պահեստ (ենթադրում ենք, որ այս դեպքում կա միայն մեկը, և չենք բարդացնում առաջադրանքը):

Կազմաձևման մետատվյալների օբյեկտներ

Այս առաջադրանքն իրականացնելու համար մեզ անհրաժեշտ է.

• Երկու ֆունկցիոնալ տարբերակ «UseMultipleWarehouses» և «Do NotUseMultipleWarehouses»: Առաջինը պատասխանատու է գրացուցակի առկայության համար, իսկ երկրորդը՝ պահեստը «բացելու» ալգորիթմը կանչելու ընդհանուր հրամանի առկայության համար։
• Ֆունկցիոնալ ընտրանքների արժեքները պահելու համար «Բուլյան» տիպի համանուն հաստատուններ
• տեղեկատու «Պահեստներ»
• «Բաց հիմնական պահեստ» գլխավոր հրամանատարություն. Մի մոռացեք դրա համար նշել հրամանների խումբ, հակառակ դեպքում մի կիրառեք կոնֆիգուրացիան (սխալ կլինի)

Եվ ավելացրեք մեկ ենթահամակարգ, որտեղ մենք ներառում ենք բոլոր առկա օբյեկտները

Ֆունկցիոնալ ընտրանքների կարգավորում

Առաջին տարբերակը «Օգտագործեք բազմաթիվ պահեստներ»: Արժեքը պահվում է նույնանուն հաստատունում, ներառված է «Պահեստներ» գրացուցակը։ Այսպիսով, երբ հաստատունի արժեքը «True» է, գրացուցակը հասանելի է ինտերֆեյսում, սխալի դեպքում գրացուցակը նույնպես չի ցուցադրվի ինտերֆեյսում (ենթահամակարգերի բովանդակությունը, օբյեկտի ձևերը և այլն):

Երկրորդ «Մի օգտագործիր MultipleWarehouses» գործառույթը սահմանվում է, երբ առաջին «UseMultipleWarehouses»-ը ՉԻ դրված:
Նրանք. եթե մենք չենք օգտագործում մի քանի պահեստներ (UseMultipleWarehouses = FALSE և «Warehouses» որոնումը հասանելի չէ), ապա ցուցադրվում է «Open MainWarehouse» հրամանը, որի հասանելիությունը վերահսկվում է «Do not UseMultipleWarehouses» տարբերակով (Do notUseMultipleWarehouses = ՃԻՇՏ)

Համակարգի վարքագծի ստուգում

Տարբերակ թիվ 1. UseMultipleWarehouses = True, Do NotUseMultipleWarehouses = False: «Պահեստներ» գրացուցակը հասանելի է միջերեսում

Տարբերակ թիվ 2. UseMultipleWarehouses = False, Do NotUseMultipleWarehouses = True: «Պահեստներ» տեղեկագիրքը հասանելի չէ միջերեսում, փոխարենը հասանելի է «Բաց հիմնական պահեստ» ընդհանուր հրամանը:

Ֆունկցիոնալ ընտրանքներսովորական կոնֆիգուրացիայի օբյեկտներ են: Դրանք ֆունկցիոնալ ընտրանքների մեխանիզմի մի մասն են և թույլ են տալիս կիրառական լուծումում ընտրել այնպիսի գործառույթ, որը կարող է միացվել/անջատվել իրականացման ընթացքում՝ առանց կիրառական լուծումը փոխելու:

Օրինակ, կախված կոնկրետ իրականացման պայմաններից, անհրաժեշտ է նախատեսել ապրանքների հաշվառումն անջատել պահեստներով: Որպեսզի ապրանքների ստացման փաստաթղթերը գրանցելիս դաշտը Բաժնետոմսերչի ցուցադրվում փաստաթղթի տեսքով:

Դա անելու համար կոնֆիգուրացիայի մեջ կարող է սահմանվել ֆունկցիոնալ տարբերակ Պահեստի հաշվառում, պահվում է տիպի հաստատունով բուլյան.

Դուք կարող եք կապել տարբեր կոնֆիգուրացիայի օբյեկտներ կամ դրանց ատրիբուտները այս ֆունկցիոնալ տարբերակի հետ: Օրինակ, դուք կարող եք կապել հենարանները այս ֆունկցիոնալ տարբերակի հետ Բաժնետոմսերփաստաթուղթ Ապրանքների ստացում.

Այնուհետև, իրականացման ընթացքում, դուք կարող եք միացնել կամ անջատել այս ֆունկցիոնալ տարբերակը կոնկրետ տեղեկատվական բազայում 1C:Enterprise ռեժիմում:

Պլատֆորմը ավտոմատ կերպով կմիացնի և կանջատի բոլոր համապատասխան ինտերֆեյսի տարրերի ցուցադրումը (դաշտեր, հրամաններ, ցուցակի սյունակներ, հաշվետվության տարրեր): Մեր դեպքում դաշտը կթաքցվի կամ կցուցադրվի Բաժնետոմսերբոլոր փաստաթղթերի ձևերով Ապրանքների անդորրագիր.