مقدار پارامتر rls 1s تنظیم نشده است. دفترچه یادداشت یک برنامه نویس. ایجاد یک محدودیت RLS

برنامه 1C دارای یک سیستم داخلی از حقوق دسترسی است که در Configurator - General - Roles قرار دارد.

ویژگی این سیستم چیست و هدف اصلی آن چیست؟ این به شما امکان می دهد مجموعه ای از حقوق را که با موقعیت های کاربران یا فعالیت های آنها مطابقت دارد، توصیف کنید. این سیستمحقوق دسترسی ثابت است، به این معنی که، همانطور که مدیر حقوق دسترسی را روی 1C تنظیم کرده است، همینطور است. علاوه بر استاتیک، سیستم دوم حقوق دسترسی - پویا (RLS) وجود دارد. در این سیستم حقوق دسترسی بسته به پارامترهای داده شده در حین کار به صورت پویا محاسبه می شود.

نقش ها در 1C

به رایج ترین تنظیمات امنیتی در برنامه های مختلفمجموعه ای از مجوزهای خواندن / نوشتن برای گروه های کاربری مختلف و در آینده: گنجاندن یا حذف یک کاربر خاص از گروه ها است. از چنین سیستمی استفاده می شود، به عنوان مثال، در سیستم عاملویندوز AD ( اکتیو دایرکتوری). سیستم امنیتی مورد استفاده در نرم افزار 1C، نام - نقش ها را گرفت. آن چیست؟ Roles در 1C یک شی است که در پیکربندی در شاخه قرار دارد: General - Roles. این نقش‌های 1C گروه‌هایی هستند که حقوق به آنها اختصاص داده شده است. در آینده، هر کاربر می تواند شامل و از این گروه حذف شود.

با دوبار کلیک بر روی نام نقش، ویرایشگر حقوق مربوط به نقش را باز می کنید. در سمت چپ لیستی از اشیاء وجود دارد، هر یک از آنها را علامت گذاری کنید و در سمت راست گزینه هایی برای حقوق دسترسی احتمالی خواهید دید:

— خواندن: گرفتن سوابق یا قطعات جزئی آنها از جدول پایگاه داده.
- اضافه کردن: سوابق جدید با حفظ رکوردهای موجود.
- تغییر: ایجاد تغییرات در رکوردهای موجود.
- حذف: برخی از سوابق، بدون تغییر نگه داشتن بقیه.

توجه داشته باشید که تمام حقوق دسترسی را می توان به دو گروه اصلی تقسیم کرد - این یک حق "ساده" و چنین حقی با اضافه کردن ویژگی "تعاملی" است. در اینجا منظور چیست؟ و مطلب زیر است.

در صورتی که کاربر فرمی را باز می کند، به عنوان مثال، پردازش، و در عین حال روی آن با ماوس کلیک می کند، برنامه در زبان داخلی 1C شروع به انجام اقدامات خاصی می کند، به عنوان مثال، حذف اسناد. برای مجوز چنین اقداماتی که توسط برنامه انجام می شود، حقوق 1C به ترتیب "به سادگی" مسئول است.

در صورتی که کاربر مجله را باز می کند و شروع به وارد کردن چیزی به تنهایی از صفحه کلید می کند (مثلاً اسناد جدید)، حقوق "تعاملی" 1C مسئول اجازه چنین اقداماتی هستند. هر کاربر می تواند چندین نقش را به طور همزمان در دسترس داشته باشد، سپس مجوز اضافه می شود.

RLS در 1C

می توانید دسترسی به دایرکتوری (یا سند) را فعال کرده یا آن را غیرفعال کنید. شما نمی توانید آن را کمی روشن کنید. برای این منظور، توسعه خاصی از سیستم نقش 1C وجود دارد که RLS نامیده می شود. این یک سیستم حقوق دسترسی پویا است که محدودیت های دسترسی جزئی را معرفی می کند. به عنوان مثال، فقط اسناد یک سازمان و انبار خاص در دسترس کاربر قرار می گیرد، بقیه را نمی بیند.

باید در نظر داشت که سیستم RLS باید با دقت بسیار مورد استفاده قرار گیرد، زیرا درک طرح پیچیده آن نسبتاً دشوار است و کاربران مختلف ممکن است هنگام مقایسه یک گزارش مشابه، که از موارد مختلف تولید می شود، سؤالاتی داشته باشند. کاربران بیایید چنین مثالی را در نظر بگیریم. شما یک دایرکتوری خاص (به عنوان مثال سازمان ها) و یک حق خاص (مثلاً خواندن) را انتخاب می کنید، یعنی اجازه خواندن برای نقش 1C را می دهید. در همان زمان متن درخواست را در پنل راه دور Data Access Restrictions تنظیم می کنید که بر اساس آن، بسته به تنظیمات، False یا True تنظیم می شود. به طور معمول، تنظیمات در یک ثبت اطلاعات خاص ذخیره می شوند.

این پرس و جو به صورت پویا (زمانی که تلاشی برای سازماندهی خواندن انجام می شود) برای همه ورودی های دایرکتوری اجرا می شود. این کار به این صورت است: آن دسته از رکوردهایی که درخواست امنیتی برای آنها اختصاص داده شده است - درست است، کاربر می بیند، اما دیگران نمی بینند. حقوق 1C با محدودیت های تعیین شده با رنگ خاکستری برجسته شده است.

عملیات کپی همان تنظیمات RLSبا استفاده از قالب ها انجام می شود. برای شروع، شما یک الگو ایجاد می‌کنید و نام آن را می‌گذارید، برای مثال MyTemplate، که در آن درخواست امنیتی را منعکس می‌کنید. سپس در تنظیمات حقوق دسترسی، نام این قالب را به این صورت مشخص کنید: «#MyTemplate».

هنگامی که کاربر در حالت 1C Enterprise کار می کند، هنگام اتصال به RLS، ممکن است پیام خطایی مانند: "حقوق ناکافی" ظاهر شود (برای مثال برای خواندن دایرکتوری XXX). این نشان می دهد که سیستم RLS خواندن برخی از رکوردها را مسدود کرده است. برای جلوگیری از نمایش مجدد این پیام، باید کلمه ALLOWED را در متن درخواست وارد کنید.

تمام تنظیمات حقوق کاربر که در چارچوب این مقاله انجام خواهیم داد در بخش 1C 8.3 "اداره" - "تنظیمات کاربر و حقوق" قرار دارند. این الگوریتممشابه در اکثر تنظیمات به فرم های مدیریت شده. برنامه حسابداری 1C به عنوان مثال استفاده خواهد شد، اما تنظیم حقوق در سایر برنامه ها (1C UT 11، 1C ZUP 3، 1C ERP) دقیقاً به همین روش انجام می شود.

بیایید به بخش "کاربران" در پنجره تنظیمات برویم. در اینجا دو لینک می بینیم: "کاربران" و "تنظیمات ورود". اولین آنها به شما امکان می دهد مستقیماً به لیست کاربران این مورد بروید پایگاه اطلاع رسانی. قبل از ایجاد یک کاربر جدید، تنظیمات احتمالی ورود به سیستم را در نظر بگیرید (پیوند در سمت راست).

در این فرم تنظیمات، می توانید پیچیدگی رمز عبور (حداقل 7 کاراکتر، محتوای اجباری) را تنظیم کنید انواع مختلفشخصیت ها و غیره). در اینجا می توانید طول رمز عبور، مدت اعتبار آن و ممنوعیت دسترسی به برنامه را برای کاربرانی که برای مدت زمان مشخصی فعالیت نداشته اند را مشخص کنید.

اکنون می توانید مستقیماً به افزودن یک کاربر جدید به 1C بروید. همانطور که در تصویر زیر نشان داده شده است، می توانید این کار را با کلیک بر روی دکمه "ایجاد" انجام دهید.

قبل از هر چیز اشاره کنیم نام و نام خانوادگی- "آنتونوف دیمیتری پتروویچ" و ما از دایرکتوری مناسب انتخاب می کنیم شخصی. در اینجا می توانید بخشی را که کارمند ما در آن کار می کند نیز مشخص کنید.

نام ورود به سیستم "AntonovDP" به طور خودکار به عنوان مخفف نام کامل "Antonov Dmitry Petrovich" جایگزین شد. یک رمز عبور و احراز هویت برای 1C Enterprise تنظیم کنید. در اینجا همچنین می توانید مشخص کنید که آیا کاربر داده شدهخود تغییر رمز عبور

فرض کنید می خواهیم هنگام راه اندازی این پایگاه اطلاعاتی، دیمیتری پتروویچ آنتونوف در لیست انتخابی موجود باشد. برای انجام این کار، باید پرچم را در مورد "نمایش در لیست انتخاب" تنظیم کنید. در نتیجه، پنجره مجوز هنگام شروع برنامه مانند تصویر زیر خواهد بود.

بیایید به یکی دیگر از تنظیمات مهم در کارت راهنمای کاربر توجه کنیم - "ورود به برنامه مجاز است." اگر تاخیر تنظیم نشده باشد، کاربر به سادگی نمی تواند وارد این پایگاه اطلاعاتی شود.

حقوق دسترسی

پس از پر کردن تمام داده های کارت کاربر - آنتونوف دیمیتری پتروویچ، آنها را یادداشت می کنیم و به تنظیم حقوق دسترسی، همانطور که در شکل زیر نشان داده شده است، ادامه می دهیم.

قبل از ما لیستی از نمایه های دسترسی برنامه را که قبلاً وارد شده بود باز کردیم. کادرهای مورد نیاز را علامت بزنید.

دسترسی به پروفایل های گروه

پروفایل های گروه دسترسی را می توان از فرم اصلی برای تنظیم کاربران و حقوق پیکربندی کرد. به بخش «گروه‌های دسترسی» بروید و روی پیوند «دسترسی به پروفایل‌های گروه» کلیک کنید.

بیایید ایجاد کنیم گروه جدیداز فرم لیست باز شده در بخش جدولی در برگه "عملکردهای مجاز (نقش ها)"، لازم است کادرهای مربوط به نقش هایی را علامت بزنید که بر حقوق دسترسی کاربران موجود در گروهی که ایجاد می کنیم تأثیر می گذارد. همه این نقش ها در پیکربندی ایجاد و پیکربندی می شوند. آنها را نمی توان از حالت کاربر تغییر داد یا ایجاد کرد. شما فقط می توانید از یک لیست موجود انتخاب کنید.

RLS: محدودیت دسترسی سطح رکورد

به شما امکان می دهد تا دسترسی به داده های برنامه را در بخش های خاص با انعطاف بیشتری پیکربندی کنید. برای فعال کردن آن، پرچم را روی موردی به همین نام در فرم تنظیمات کاربر و حقوق تنظیم کنید.

لطفاً توجه داشته باشید که فعال کردن این تنظیم ممکن است بر عملکرد سیستم تأثیر منفی بگذارد. نکته این است که مکانیسم RLS همه درخواست ها را بسته به آن تغییر می دهد محدودیت های ایجاد شده.

بیایید به نمایه گروه دسترسی "گروه آزمایشی" که قبلا ایجاد کردیم برویم. شکل زیر نشان می دهد که پس از فعال کردن محدودیت دسترسی در سطح رکورد، یک تب اضافی "محدودیت های دسترسی" ظاهر شد.

بیایید فرض کنیم که می‌خواهیم کاربرانی که گروه آزمایشی به آنها اختصاص داده شده است به داده‌های همه سازمان‌های موجود در این پایگاه اطلاعاتی دسترسی داشته باشند، به جز مواردی که در نمایه مشخص شده است.

در قسمت جدول بالا، محدودیت دسترسی بر اساس سازمان را تنظیم کنید. در قسمت پایین، توضیح خواهیم داد که دسترسی به داده ها (اسناد، دایرکتوری ها و غیره) برای سازمان روگا LLC فراهم نخواهد شد.

1C دارای یک سیستم حقوق دسترسی داخلی است (این سیستم نقش 1C نامیده می شود). این سیستم ثابت است - همانطور که مدیر حقوق را روی 1C تنظیم کرده است.

علاوه بر این، یک سیستم پویا از حقوق دسترسی (به نام - RLS 1C) وجود دارد. در آن، حقوق 1C به صورت پویا در زمان کار کاربر بر اساس پارامترهای مشخص شده محاسبه می شود.

یکی از رایج‌ترین تنظیمات امنیتی در برنامه‌های مختلف، مجموعه‌ای از مجوزهای خواندن/نوشتن برای گروه‌های کاربری و سپس - گنجاندن یا حذف یک کاربر از گروه‌ها است. به عنوان مثال، سیستم مشابهی در ویندوز AD (Active Directory) استفاده می شود.

چنین سیستم امنیتی در 1C Roles 1C نامیده می شود. Roles 1C در پیکربندی در شاخه General / Roles قرار دارد. نقش های 1C به عنوان گروه هایی عمل می کنند که حقوق 1C به آنها اختصاص داده شده است. در مرحله بعد، کاربر شامل یا از این گروه حذف می شود.

با دوبار کلیک بر روی نام نقش 1C، ویرایشگر حقوق نقش 1C را باز می کنید. در سمت چپ لیستی از اشیاء 1C وجود دارد. هر کدام را انتخاب کنید و گزینه‌های مربوط به حقوق دسترسی در سمت راست نمایش داده می‌شوند (حداقل: خواندن، افزودن، تغییر، حذف).

برای شاخه بالا (نام پیکربندی فعلی) حقوق اداری 1C و دسترسی به راه اندازی گزینه های مختلف نصب شده است.

همه حقوق 1C به دو گروه تقسیم می شوند - حق "ساده" و حق یکسان با افزودن "تعاملی". چه مفهومی داره؟

هنگامی که کاربر فرمی را باز می کند (به عنوان مثال پردازش) و دکمه ای را روی آن فشار می دهد، برنامه به زبان داخلی 1C اقدامات خاصی را انجام می دهد، به عنوان مثال، اسناد را حذف می کند. برای مجوز این اقدامات (به صورت برنامه ریزی شده) - "به سادگی" حقوق 1C مسئول است.

وقتی کاربر مجله‌ای را باز می‌کند و به تنهایی شروع به انجام کاری از صفحه کلید می‌کند (به عنوان مثال، وارد کردن اسناد جدید)، اینها حقوق 1C "تعاملی" هستند.

یک کاربر می تواند چندین نقش در دسترس داشته باشد، در این صورت مجوزها با هم اضافه می شوند.

بخش امکان تنظیم حقوق دسترسی با استفاده از نقش ها یک شی 1C است. یعنی می توانید دسترسی به دایرکتوری را فعال یا غیرفعال کنید. نمیشه یه ذره روشن کرد

برای این کار، یک فرمت از سیستم نقش 1C به نام 1C RLS وجود دارد. این یک سیستم پویا از حقوق دسترسی است که به شما امکان می دهد تا حدی دسترسی را محدود کنید. برای مثال کاربر فقط اسناد یک انبار و سازمان خاص را می بیند و بقیه را نمی بیند.

با دقت! هنگام استفاده از طرح گیج کننده RLS 1C، کاربران مختلف ممکن است وقتی سعی می کنند گزارش مشابه تولید شده از کاربران مختلف را تأیید کنند، سؤالاتی داشته باشند.

شما یک دایرکتوری خاص (مثلاً سازمان ها) و یک حق خاص (مثلاً خواندن) را می گیرید. شما اجازه خواندن برای نقش 1C را می دهید. در پانل محدودیت دسترسی به داده، متن پرس و جو را تنظیم می کنید که بسته به تنظیمات، TRUE یا FALSE را برمی گرداند. تنظیمات معمولاً در ثبت اطلاعات ذخیره می شوند (به عنوان مثال، ثبت اطلاعات پیکربندی Accounting UserAccessRightsSettingsUsers).

این درخواست به صورت پویا (هنگام اجرای خواندن)، برای هر ورودی دایرکتوری اجرا می شود. بنابراین، برای آن دسته از رکوردهایی که پرس و جو امنیتی برای آنها TRUE برگردانده شده است، کاربر آن را می بیند، اما بقیه نمی بینند.
حقوق 1C که مشمول محدودیت های RLS 1C هستند با رنگ خاکستری برجسته شده اند.

کپی کردن همان تنظیمات RLS 1C با استفاده از الگوها انجام می شود. شما یک الگو می سازید، نام آن را می گذارید (مثلاً) MyTemplate، یک درخواست امنیتی در آن مشخص می کنید. بعد، در تنظیمات حقوق دسترسی 1C، نام قالب را به این صورت مشخص کنید: "#MyTemplate".

هنگامی که کاربر در حالت 1C Enterprise کار می کند، هنگامی که RLS 1C در حال اجرا است، ممکن است پیام خطای "حقوق ناکافی" را دریافت کند (به عنوان مثال، برای خواندن فهرست Xxx).

این بدان معناست که RLS 1C خواندن چندین رکورد را مسدود کرده است.

برای جلوگیری از ظاهر شدن چنین پیامی، لازم است از کلمه ALLOWED () در متن درخواست به زبان داخلی 1C استفاده کنید.

مثلا:

نسخه هشتم پلت فرم 1C: Enterprise (امروز 8.3) تغییرات زیادی را در رابطه با "هفت" انجام داد که در میان آنها مکانیسم محدود کردن حقوق دسترسی در سطح رکورد به ویژه برجسته بود. اگرچه در تئوری می‌توانید بدون آن کار کنید، اما تنها با استفاده از نقش‌ها، RLS به شما اجازه می‌دهد تا به چیزهای بیشتری دست پیدا کنید تنظیم دقیقدسترسی داشته باشید. اما برای عملکرد صحیح این مکانیسم، باید ماهیت آن را به وضوح درک کنید و تجربه کافی در توسعه در 1C داشته باشید.

RLS چیست؟

ماهیت این عملکرد در توانایی توسعه دهنده برای جلوگیری از دسترسی کاربر یا گروه خاصی از کاربران به جداول یا فیلدهای جداول پایگاه داده است. به طور معمول، محدودیت‌هایی برای جلوگیری از مشاهده و ویرایش محرمانه توسط کاربران 1C استفاده می‌شود. اطلاعات طبقه بندی شدهبرای مثال، کارمندان یک شرکت گروهی را محدود کنید تا اسناد را فقط برای سازمان خود مشاهده کنند. همچنین، مکانیسم محدود کردن حقوق دسترسی در سطح رکورد می تواند برای حذف اطلاعات غیر ضروری از رابط استفاده شود.

برای اینکه بتوانید درخواست هایی برای محدودیت های RLS بنویسید، باید یک نقش ایجاد کنید یا یک نقش موجود را انتخاب کنید. تنظیم RLS در 1C 8.3 می تواند برای اقدامات کاربر زیر استفاده شود:

• اضافه
• خواندن؛
• حذف؛
• تغییر دادن.

علاوه بر گسترده ترین امکانات برای پیکربندی دسترسی، RLS دارای معایبی نیز می باشد:

1. الزامات صلاحیت برنامه نویس، از آنجایی که پرس و جو باید با در نظر گرفتن قوانین نحوی به زبان داخلی نوشته شود.
2. عدم توانایی در اشکال زدایی سریع شرایط؛
3. فرصت های محدودبا توجه به توضیح منطق: شرایط بسیار پیچیده هنوز باید در ماژول های اسناد و دایرکتوری ها نوشته شود.
4. در نسخه سرویس گیرنده-سرور پایگاه های داده، رشد ضمنی جداول موجود در پرس و جو امکان پذیر است. علاوه بر این، پیگیری این فرآیند بسیار دشوار است.
5. منابع مورد نیاز محدودیت های RLS مقدار زیادی از قدرت ماشین مشتری و سرور را مصرف می کند.
6. اسناد کمی به رایگان در دسترس است.

مشکل دیگری که ممکن است پس از راه اندازی 1C RLS ایجاد شود می تواند گزارش باشد. واقعیت این است که توسعه دهندگان محدودیت های احتمالی RLS را پیش بینی می کنند و گزارش ها را به گونه ای می سازند که فقط داده های مجاز را نشان می دهند. اگر کاربران محدودیت های RLS متفاوتی را پیکربندی کرده باشند، داده های گزارش برای پارامترهای یکسان ممکن است برای آنها متفاوت باشد. این می تواند سوالاتی را ایجاد کند، بنابراین هنگام طراحی گزارش یا نوشتن پرس و جو در RLS، باید چنین موقعیت هایی را در نظر بگیرید.

ایجاد یک محدودیت RLS

برای اضافه کردن یک محدودیت RLS، باید نقش مورد نظر را پیدا کرده و با دوبار کلیک آن را باز کنید.

پنجره ای که باز می شود شامل 2 تب است: "حقوق" و "الگوهای محدودیت". برای اعمال محدودیت‌های خاص بر روی یک عمل خاص، باید آن را انتخاب کرده و روی علامت سبز رنگ در قسمت پایین سمت راست کلیک کنید. خطی ظاهر می شود که در آن می توانیم محدودیت های 1C RLS را در زبان داخلی 1C تنظیم کنیم.

اگر سینتکس 1C را می دانید (مانند پشت دست خود)، می توانید مستقیماً در قسمت "محدودیت دسترسی" بنویسید. توسعه دهندگان 1C امکان باز کردن سازنده پرس و جو را فراهم کرده اند که به شما کمک می کند و به شما می گوید که این محدودیت در چه مواردی می تواند اعمال شود. برای باز کردن آن باید بر روی دکمه سه نقطه (Select) یا F4 کلیک کنید و پنجره ای با دکمه "Query Builder ..." ظاهر می شود.

در پنجره ای که ظاهر می شود، می توانید محدودیت ها را نه تنها برای این فهرست، بلکه برای سایر اشیاء سیستم نیز پیکربندی کنید. برای انجام این کار، باید آنها را در تب "جدول و فیلدها" اضافه کنید. ما محدودیت هایی را در زمینه های کتاب مرجع "Nomenclature" تجویز می کنیم و روی "OK" کلیک می کنیم. به نام متغیرها توجه کنید: پارامترهای RLS در ابتدای جلسه کاربر تنظیم می شوند و باید در شی ابرداده قرار گیرند.

در برگه "الگوهای محدودیت"، پرس و جوهایی تنظیم می شوند که هنگام کپی کردن همان تنظیمات RLS در 1C 8.3 ضروری هستند. پس از اینکه الگوی خود را اضافه کردید، می توانید از نام آن در تنظیمات حقوق دسترسی استفاده کنید.

همچنین امکان افزودن محدودیت برای چندین نقش به طور همزمان وجود دارد. برای انجام این کار، در درخت پیکربندی، روی قسمت "نقش ها" کلیک راست کرده و مورد "همه نقش ها" را انتخاب کنید.

به عنوان یک نتیجه، مایلم یادآوری کنم که این مقاله برای مشاوران توسعه دهنده 1C طراحی شده است و می تواند به کسانی که قبلاً تجربه توسعه در 1C: Enterprise را داشته اند کمک کند. علیرغم سادگی ظاهری، دانش معنایی و درک ساختار فرآیندهای تجاری شرکت یا سازمان مشتری خود برای توزیع صحیح حقوق نیاز به سطح معینی از دانش و تجربه دارد.

چاپ (Ctrl+P)

محدودیت دسترسی به داده ها

مکانیسم محدودیت دسترسی به داده ها (همچنین به عنوان RLS، امنیت سطح ردیف شناخته می شود) به شما امکان می دهد حقوق دسترسی را نه تنها در سطح اشیاء ابرداده، بلکه در سطح اشیاء پایگاه داده 1C: Enterprise نیز مدیریت کنید. برای محدود کردن دسترسی به داده ها می توان از اشیاء 1C:Enterprise زیر استفاده کرد:
● نقش ها،
● پارامترهای جلسه،
● گزینه های کاربردی،
● ماژول های مشترک ممتاز،
● کلمه کلیدی ALLOWED در زبان پرس و جو.
اشتراک گذاری این اشیاء به شما امکان می دهد حداکثر انعطاف پذیری را در مواقعی که لازم است بین کاربرانی که عملکردهای مختلف را انجام می دهند، از حقوق دسترسی به داده ها متمایز کنید، ارائه دهید.
محدودیت‌های دسترسی به داده‌ها را می‌توان بر روی عملیات داده‌های زیر اعمال کرد (حق دسترسی): خواندن (راست خواندن)، افزودن (حق افزودن)، اصلاح (حق اصلاح)، و حذف (حق حذف). کاربر فعلی قادر خواهد بود عملیات درخواستی را در موارد زیر انجام دهد:
● برای عملیات خواندن و حذف، شی در پایگاه داده باید با محدودیت دسترسی به داده ها مطابقت داشته باشد.
● برای عملیات افزودن، محدودیت دسترسی به داده باید با شیئی که قصد دارید در پایگاه داده بنویسید مطابقت داشته باشد.
● برای عملیات تغییر، محدودیت دسترسی به داده باید هم قبل از تغییر (برای خواندن شی) و هم بعد از تغییر (برای نوشتن شی) با شی مطابقت داشته باشد.
هنگام اعمال محدودیت های دسترسی به داده ها، به خاطر داشته باشید که فقط یک شرط را می توان برای عملیات اصلاح، افزودن و حذف تعیین کرد و بیش از یک محدودیت دسترسی به داده را می توان برای عملیات خواندن تعیین کرد. به این معنی که برای خواندن فیلدهای مختلف یک شی می توان شرایط مختلفی را تنظیم کرد و در هنگام تنظیم یک شرط، هم نام یک فیلد خاص و هم فیلد ویژه سایر فیلدها را مشخص کرد. در حالت اول، شرط فقط در صورتی اعمال می شود که انتخاب (که در حال خواندن داده ها است) حاوی فیلدی باشد که محدودیت برای آن تنظیم شده باشد، و در حالت دوم، محدودیت برای همه فیلدهای شی اعمال می شود، به جز برای فیلدهایی که محدودیت ها به صراحت برای آنها تنظیم شده است.
هنگام تنظیم محدودیت در یک فیلد خاص، در صورت رعایت محدودیت، این فیلد خوانده می‌شود و هنگام تنظیم محدودیت در سایر فیلدها، داده‌های شی تنها در صورتی خوانده می‌شوند که محدودیت برای همه فیلدهای شی موجود در درخواست خواندن داده رعایت شود. .
برای اشیاء پایگاه داده از انواع زیر می توان محدودیت های مختلفی را بر روی آنها اعمال کرد انواع متفاوتتغییرات (افزودن، اصلاح، حذف):
● طرح های مبادله,
● کتابهای راهنما،
● اسناد،
● طرح ها انواع ویژگی ها,
● نمودارهای حساب،
● طرح های انواع سکونتگاه،
● فرآیندهای کسب و کار،
● وظایف.
برای انواع زیر از اشیاء پایگاه داده، ممکن است محدودیت هایی برای خواندن نه تنها کل شی، بلکه فیلدهای جداگانه آن اعمال شود:
● طرح های مبادله،
● کتابهای راهنما،
● اسناد،
● مجلات مستند،
● طرح هایی از انواع مشخصه،
● نمودارهای حساب،
● طرح های انواع سکونتگاه،
● ثبت اطلاعات،
● فرآیندهای کسب و کار،
● وظایف.
توجه! هنگام دسترسی به فیلدهای اشیاء پایگاه داده با استفاده از ویژگی های اشیاء برنامه از زبان داخلی 1C: Enterprise، کل شیء خوانده می شود، نه فقط مقدار فیلد مورد استفاده. استثنا زمانی است که نما دریافت می شود، زمانی که فقط مقادیر فیلدهای درگیر در تولید view خوانده می شود.
محدودیت‌های دسترسی در نقش‌ها وجود دارند، می‌توان آن‌ها را برای اکثر اشیاء فراداده مشخص کرد و به زبان خاصی که زیرمجموعه‌ای از زبان پرس و جو است، نوشته می‌شوند.

زبان محدودیت دسترسی به داده ها

محدودیت‌های دسترسی به داده‌ها در یک زبان خاص، که زیرمجموعه‌ای از زبان پرس و جو است ( توصیف همراه با جزئیاتزبان پرس و جو زبان محدودیت دسترسی به داده تغییرات زیر را در مورد زبان پرس و جو دارد:
● در جستار محدودیت دسترسی به داده، همیشه یک جدول به عنوان منبع داده وجود دارد - این جدول شیئی است که محدودیت بر روی آن اعمال شده است (مبحث اصلی محدودیت).
● توضیحات درخواست کوتاه شده است. زبان محدودیت دسترسی به داده فقط از بخش های FROM و WHERE زبان پرس و جو استفاده می کند. بنابراین، توضیحات زبان پرس و جو به شرح زیر است:
[مجاز] [متفاوت] [ اولین<Количество> ]
<لیست فیلدهای انتخاب>
[از جانب <Список источников> ]
[جایی که<Условие отбора> ]
[دسته بندی بر اساس <Поля группировки> ]
[داشتن<Условие отбора> ]
[برای تغییر [ <Список таблиц سطح بالا> ]]
در حالی که شرح زبان پرس و جو محدودیت دسترسی به داده به شرح زیر است:
[نام مستعار جدول شی محدودیت اصلی]
[از جانب <Список источников> ]
[جایی که<Условие отбора> ]

پرسش‌های فرعی مورد استفاده در زبان محدودیت دسترسی به داده‌ها دارای مجموعه محدودی از امکانات مجاز هستند.
● می توانید پارامترهای جلسه و گزینه های عملکردی را به عنوان عناصر شرط مشخص کنید.
● در هرجایی از درخواست محدودیت دسترسی به داده، می‌توان از الگوها برای تسهیل نوشتن محدودیت‌ها استفاده کرد.
بخش اصلی محدودیت، شرایطی است که برای هر رکورد در جدول پایگاه داده که مشمول محدودیت دسترسی به داده است، ارزیابی می شود. یک رکورد در صورتی در دسترس تلقی می شود که در نتیجه شرط یک رکورد از جدول شی اصلی محدودیت، یک جدول غیر خالی (یعنی جدولی با 1 یا چند رکورد) به دست آید. اگر شرط منجر به یک جدول خالی شود، رکوردی که شرط به این ترتیب انجام شده است غیرقابل دسترسی در نظر گرفته می شود. علاوه بر این، تغییر رکورد جدول موضوع اصلی محدودیت
در صورتی معتبر تلقی می شود که ورودی محدودیت تعیین شده برای حق را چه قبل و چه بعد از انجام عملیات اصلاح نقض نکند.

فیلدهای جدول

در محدودیت های دسترسی به داده، می توانید از:
● فیلدهای جدول شیئی که محدودیت دسترسی به داده برای آن شرح داده شده است.
به عنوان مثال، اگر محدودیتی برای خواندن عناصر دایرکتوری Counterparties اعمال شود، می توان از فیلدهای دایرکتوری Counterparties و قسمت های جدولی آن در محدودیت استفاده کرد. به طور خاص، ساده ترین محدودیت ها برای خواندن عناصر دایرکتوری Counterparties ممکن است به شکل زیر باشد:

WHERE نام = "کارخانه آجر"
یا مثل این:

جایی که محصولات.نام= "قرمز آجری"
محصول کجاست قسمت جدولیطرف مقابل دایرکتوری.
● فیلدهای جدول اشیاء قابل دسترسی با پیوندهای موجود در شی محدودیت اصلی.
به عنوان مثال، اگر ویژگی Primary Manager دایرکتوری Counterparties دارای نوع پیوند به دایرکتوری Users باشد، محدودیت دسترسی می تواند به عنوان مثال شکل زیر را داشته باشد:

جایی که PrimaryManager.Code= "ایوانف"
یا:

جایی که PrincipalManager.Individual.Name= "پتروفسکی"
● فیلدهای جدول اشیاء مرتبط با موضوع اصلی محدودیت توسط شرایط خاص و عبارات روی آنها.
برای مثال، محدودیت زیر ممکن است برای خواندن عناصر دایرکتوری Counterparties اعمال شود:

طرف مقابل
از جانب
دایرکتوری.پیمانکارانطرف مقابل AS
چپ پیوستن دایرکتوری.کاربرانکاربران چگونه
SW = Users.Name
WHERE = "پتروفسکی"
این محدودیت از فیلدهای عناصر دایرکتوری Users مرتبط با این عنصر دایرکتوری Counterparties با مقدار فیلدهای Name استفاده می کند.

سوالات فرعی

پرسش‌های فرعی برای تشکیل مجموعه‌هایی از رکوردها استفاده می‌شوند که می‌توان از آنها استفاده کرد:
● برای پیوند با جدول شی محدودیت اصلی.
● به عنوان عملوند عملیات مقایسه IN یا NOT IN استفاده شود.
سوالات فرعی می توانند از هر یک از ویژگی های زبان پرس و جو استفاده کنند به جز:
● عملگر در سلسله مراتب ;
● نتایج را ارائه می دهد.
● نتایج پرس و جوهای تو در تو نباید شامل بخش های جدولی باشد.
● برخی از جداول مجازی، به ویژه باقی می ماند و گردش می کند.
در مثال زیر از محدودیت در خواندن از دایرکتوری Counterparties، یک پرسش فرعی به عنوان مجموعه ای از رکوردها برای پیوند دادن به هدف اصلی محدودیت استفاده می شود:

طرف مقابل
از جانب
دایرکتوری.پیمانکارانطرف مقابل AS
چپ پیوستن
(انتخاب کنید
Users.Name، Users.Individual
از جانب
دایرکتوری.کاربرانکاربران چگونه
جایی که
کاربران.کد> "Petechkin") کاربران AS
بر Counterparties.MainManager.Name = کاربران. نام
جایی که Users.Individual.Name= "پتروفسکی"
مثال زیر محدودیتی را در خواندن از دایرکتوری PassportData of Individuals نشان می دهد که در آن از یک پرسش فرعی استفاده می شود.
به عنوان عملوند عملگر مقایسه ای B:

جایی که
PassportDataIndividual.Individual AT
(متفاوت را انتخاب کنید
کارمندان.فردیبه عنوان یک فرد
از جانب
ثبت اطلاعات.کارمندانکارگران AS)
اگر نیاز به دریافت داده از بخش جدولی در زیرپرسوجو دارید، در بخش FROM زیرپرس و جو باید مستقیماً به بخش جدول دسترسی داشته باشید. به عنوان مثال، به جای:

پیوند را به عنوان پیوند انتخاب کنید.
محصولات.نامچگونه نام محصول
از جانب دایرکتوری.پیمانکاران
به عنوان یک کوئری تو در تو در یک محدودیت، باید از:

گزینه های جلسه

درخواست محدودیت دسترسی به داده ها می تواند شامل پارامترهای جلسه باشد. به عنوان مثال، برای خواندن عناصر دایرکتوری گروه های ایمیلمحدودیت دسترسی زیر را می توان تنظیم کرد:

جایی که Owner.AccountAccess.User = &CurrentUser
و مالک.AccessAccount.Administration= درست

CurrentUser یک پارامتر جلسه است

گزینه های عملکردی

درخواست‌های محدودیت دسترسی به داده‌ها ممکن است شامل گزینه‌های کاربردی باشد. فقط می توان از گزینه های تابع مستقل از پارامتر استفاده کرد. به عنوان مثال، اگر جستجوی Nomenclature دارای ویژگی Main Warehouse باشد، محدودیت در خواندن این ویژگی ممکن است به شکل زیر باشد:

WHERE &Warehouse Accounting = درست است

جایی که حسابداری انبار یک گزینه کاربردی است

ویژگی های استفاده

در محدودیت های مربوط به اشیاء پایگاه داده از انواع زیر، نمی توان از تمام فیلدهای شی داده اصلی محدودیت استفاده کرد:
● در رجیسترهای انباشت، محدودیت‌های دسترسی فقط می‌توانند شامل اندازه‌گیری شی محدودیت اصلی باشند.
● در دفاتر حسابداری در محدودیت ها فقط می توانید از ابعاد ترازنامه موضوع اصلی محدودیت استفاده کنید.
توجه داشته باشید. اگر در شرایط محدود کردن دسترسی به داده های ثبت گردش انباشت، از اندازه گیری هایی استفاده شود که در مجموع ها لحاظ نمی شود، سپس
هنگام دسترسی به جدول مجازی گردش مالی از مجموع ذخیره شده استفاده نمی شود و پرس و جو به طور کامل مطابق جدول حرکات اجرا می شود.

اقدامات محدودیت دسترسی

محدودیت‌های دسترسی در طول هر اجرای عملیات مربوطه بر روی اشیاء پایگاه داده (از دیالوگ‌ها، از زبان داخلی، از طریق پرس‌وجوها) بررسی می‌شوند و می‌توانند به یکی از دو روش عمل کنند:
● همه . روش "همه چیز" به این معنی است که برخی از عملیات داده ها (از دیالوگ ها، از زبان داخلی یا از طریق پرس و جوها) باید بر روی تمام اشیاء پایگاه داده ای که توسط این عملیات ذکر شده اند انجام شود. اگر چنین عملیاتی باید اشیاء پایگاه داده را بخواند یا تغییر دهد که محدودیت‌های دسترسی مناسب برای آن‌ها رعایت نشده باشد، عملیات پایان می‌یابد.
به دلیل نقض دسترسی از کار افتاد.
● مجاز است. روش "مجاز" به این معنی است که هنگام انجام عملیات روی داده ها، فقط آن دسته از اشیاء پایگاه داده که محدودیت های دسترسی مربوطه را برآورده می کنند باید خوانده شوند. اشیاء پایگاه داده که محدودیت‌های دسترسی را برآورده نمی‌کنند، در طول چنین عملیاتی مفقود تلقی می‌شوند و بر نتیجه عملیات تأثیری نمی‌گذارند.
هنگامی که 1C:Enterprise به پایگاه داده دسترسی پیدا می کند، محدودیت های دسترسی به داده ها بر روی اشیاء پایگاه داده اعمال می شود. در نسخه سرویس گیرنده-سرور 1C:Enterprise، محدودیت هایی بر روی سرور 1C:Enterprise اعمال می شود.
نحوه عمل محدودیت ها که برای اجرای هر عملیات روی داده ها انتخاب می شود، با هدف این عملیات و میزان مسئولیت نتایج آن تعیین می شود. به طور خاص، روش "مجاز" در هنگام نمایش استفاده می شود لیست های پویاو برخی فعالیت های تعاملی دیگر روش "همه" هنگام انجام هرگونه عملیات با اشیاء برنامه از زبان داخلی 1C: Enterprise، از جمله هرگونه تغییر در اشیاء پایگاه داده استفاده می شود. بنابراین، برای مثال، ممکن است ایجاد یک انتخاب برای متد Select() از مدیران دایرکتوری‌ها، اسناد و سایر موارد، و به دنبال آن دور زدن نتیجه در صورتی که یک محدودیت به اندازه کافی پیچیده بر روی شی مربوطه تنظیم شود، دشوار باشد، زیرا هر شرطی نیست. در محدودیت حقوق دسترسی می توان به اندازه کافی به عنوان انتخابی برای متد Select() نمایش داد.
در کوئری‌ها، می‌توانید نحوه عملکرد محدودیت‌های دسترسی به داده‌ها را کنترل کنید. برای انجام این کار، زبان پرس و جو یک کلمه کلیدی ارائه می دهد مجاز. اگر درخواست ALLOWED را مشخص نکرده باشد، محدودیت ها به صورت "همه" اعمال می شوند. اگر کلمه ALLOWED مشخص شده باشد، روش "مجاز" انتخاب می شود.
مهم است که اگر کلمه کلیدی ALLOWED در یک پرس و جو مشخص نشده باشد، تمام فیلترهای مشخص شده در آن پرس و جو نباید با هیچ یک از محدودیت های خواندن اشیاء پایگاه داده استفاده شده در پرس و جو تضاد داشته باشند. علاوه بر این، اگر از جداول مجازی در پرس و جو استفاده شود، فیلترهای مربوطه باید بر روی خود جداول مجازی اعمال شوند.
مثال:

انتخاب کنید
اطلاعات تماس SliceFirst.View
از جانب RegisterInformation.ContactInformation.SliceLast(، Type = &Type)
چگونه اطلاعات تماس SliceFirst
جایی که
ContactInformationSliceFirst.Type = &Type
هنگام استفاده از تکنیک شی، دسترسی به داده ها در حالت ALLOWED پشتیبانی نمی شود. فرض بر این است که تکنیک شی برای حیاتی ترین عملیات روی داده ها از جمله تغییر آنها استفاده می شود. برای به دست آوردن تمام داده ها با استفاده از فناوری شی، صرف نظر از محدودیت های تعیین شده، می توانید انجام دهید اقدامات لازمدر یک ماژول ممتاز یا از طرف یک کاربر با حقوق کامل. هیچ وسیله ای برای به دست آوردن تنها داده های مجاز در فناوری شی وجود ندارد.

مکانیسم محدودیت

هر گونه عملیات بر روی داده های ذخیره شده در پایگاه داده در 1C: Enterprise در نهایت منجر به دسترسی به پایگاه داده با برخی از
درخواست برای خواندن یا اصلاح داده ها در هنگام اجرای پرس و جوها در پایگاه داده، مکانیسم های داخلی 1C:Enterprise محدودیت های دسترسی را اعمال می کند. که در آن:
● فهرستی از حقوق (خواندن، افزودن، به روز رسانی، حذف)، فهرستی از جداول پایگاه داده، و فهرستی از فیلدهای استفاده شده توسط این پرس و جو ایجاد می شود.
● از بین تمام نقش‌های کاربر فعلی، محدودیت‌های دسترسی به داده‌ها برای همه حقوق، جداول و فیلدهای درگیر در پرس و جو انتخاب می‌شوند. علاوه بر این، اگر هر نقشی حاوی محدودیت های دسترسی به داده های جدول یا فیلد نباشد، به این معنی است که مقادیر فیلدهای مورد نیاز از هر رکوردی در این جدول موجود است. به عبارت دیگر، عدم وجود محدودیت دسترسی به داده ها به معنای وجود محدودیت است
حقیقت کجاست.
● مقادیر فعلی تمام پارامترهای جلسه و گزینه های عملکردی شرکت کننده در محدودیت های انتخاب شده بازیابی می شوند.
دریافت مقدار پارامتر جلسه از کاربر فعلی نیازی به حق دریافت آن مقدار ندارد. با این حال، اگر مقدار برخی از پارامترهای جلسه تنظیم نشده باشد، خطا رخ می دهد و کوئری پایگاه داده اجرا نمی شود.
بازیابی گزینه های عملکردی تحت تأثیر حالت Privileged در ویژگی بازیابی گزینه عملکردی است.
اگر این ویژگی پاک شود، کاربر فعلی باید به شیئی که گزینه تابع در آن ذخیره شده است دسترسی خواندن داشته باشد.
● محدودیت های ناشی از همان نقش با یک عملیات AND ترکیب می شوند.
● محدودیت های دریافت شده از نقش های مختلف با هم OR می شوند.
● شرایط ساخته شده به جستارهای SQL اضافه می شوند که با آن 1C:Enterprise DBMS را فراخوانی می کند. هنگام دسترسی به داده ها از سمت شرایط محدودیت دسترسی، هیچ بررسی حقوقی انجام نمی شود (نه به اشیاء ابرداده و نه برای اشیاء پایگاه داده). علاوه بر این، مکانیسم اضافه کردن شرایط بستگی به حالت انتخاب شده عملکرد محدودیت های "همه" یا "مجاز" دارد.
راه "همه چیز"
وقتی محدودیت‌هایی با استفاده از روش «همه» اعمال می‌شود، شرایط و فیلدهایی به جستارهای SQL اضافه می‌شود تا 1C:Enterprise بتواند اطلاعاتی در مورد اینکه آیا داده‌های ممنوعه برای کاربر معین در فرآیند اجرای یک پرس و جو پایگاه داده استفاده شده است یا خیر، به دست آورد. . اگر از داده های ممنوعه استفاده شده باشد، درخواست لغو می شود. اعمال محدودیت های دسترسی به روش "همه" به صورت شماتیک در شکل 1 نشان داده شده است. یکی:

برنج. 1. روش "همه چیز".

روش "مجاز".
هنگامی که محدودیت ها با استفاده از روش "مجاز" اعمال می شوند، چنین شرایطی به پرس و جوهای SQL اضافه می شوند تا ورودی های ممنوعه برای کاربر فعلی بر نتیجه پرس و جو تأثیر نگذارند. به عبارت دیگر، هنگامی که محدودیت ها در حالت "مجاز" اعمال می شود، رکوردهای ممنوعه برای این کاربر گم شده در نظر گرفته می شوند که به صورت شماتیک در شکل 3 نشان داده شده است.

سایر اشیاء مربوط به محدودیت های دسترسی به داده ها

هنگام توسعه تنظیمات با استفاده از محدودیت‌های دسترسی به داده‌ها، اشیاء ابرداده مانند پارامترهای جلسه، گزینه‌های عملکردی و ماژول‌های مشترک با پرچم Privileged می‌توانند مفید باشند.
گزینه های جلسه
پارامترهای Session را می توان در محدودیت های دسترسی به داده ها به همان روشی که پارامترهای پرس و جو را می توان در یک پرس و جو استفاده کرد.
گزینه های عملکردی
گزینه های عملکردی مستقل از پارامتر را می توان در محدودیت های دسترسی به داده ها به همان شیوه ای که پارامترهای پرس و جو را می توان در یک پرس و جو استفاده کرد.
ماژول های مشترک ممتاز

اگر چک باکس Privileged برای یک ماژول مشترک انتخاب شود، اجرای رویه ها و عملکردهای این ماژول دارای مشخصات مهمی است:
● در نسخه سرویس گیرنده-سرور 1C: Enterprise، فقط ماژولی که روی سرور اجرا می شود می تواند دارای امتیاز باشد.
● اجرای رویه ها و توابع یک ماژول ممتاز و هر چیزی که از آنها فراخوانی می شود با خاموش شدن سیستم محدودیت انجام می شود.
حقوق هم برای اشیاء و هم داده های فراداده. بنابراین، از یک ماژول ممتاز، هر عملیاتی را می توان روی آن انجام داد
هر شی، حتی اگر کاربر فعلی حقوق مناسب را نداشته باشد.
ماژول های ممتاز برای نصب اولیهمقادیر پارامتر جلسه مورد استفاده در محدودیت های دسترسی به داده ها.
ماژول های رایج هنوز می توانند برای برخی اقدامات کل نگر روی داده ها توسط کاربر با حقوق محدود استفاده شوند.
به عنوان مثال، اگر توابع کاربر شامل وارد کردن و ارسال اسناد باشد، اما کاربر نباید به داده‌هایی دسترسی داشته باشد که با ارسال یک سند تحت تأثیر قرار می‌گیرند، در این صورت اجرای عملیات ارسال می‌تواند به یک ماژول ممتاز منتقل شود. این به کاربر این امکان را می دهد که اسناد را بدون اعطای حقوق به سایر اطلاعات (مثلاً ثبت نام) پست کند.
حالت ممتاز
تنظیم حالت ممتاز هنگام کار با داده ها امکان پذیر است. نصب نرم افزارحالت ممتاز
ممکن است در صورت انجام عملیات گسترده با داده های پایگاه اطلاعاتی مورد نیاز باشد، و هیچ فایده ای برای بررسی حقوق دسترسی به داده وجود ندارد.
برای توضیح حالت ممتاز، اینجا را ببینید.

با استفاده از پیش پردازنده

هنگام ویرایش متن محدودیت دسترسی به داده ها، می توان از دستورالعمل های پیش پردازنده استفاده کرد. دستورالعمل های زیر موجود است:

#اگر<Выражение>#سپس
#السیف<Выражение>#سپس
#در غیر این صورت
#ENDESSI
<Выражение>- خودسرانه بیان بولیدر یک زبان داخلی که نتیجه آن از نوع Boolean است. عبارت ممکن است شامل موارد زیر باشد:
● عملیات مقایسه<, >, <=, >= , =, <> ;
● عملیات منطقی AND, OR, NOT ;
● Session Parameters - سینتکس &Parameter است که در آن Parameter نام پارامتر جلسه است.
اگر نتیجه عبارت #IF یا #ELSEIF True باشد، متن بعد از کلمه کلیدی #THEN در متن حاصل از دستور محدودیت دسترسی قرار می گیرد. اگر عبارت به False ارزیابی شود، متن بعد از کلمه کلیدی #THEN در متن دستورالعمل محدودیت دسترسی قرار نمی گیرد. اگر هیچ یک از شرایط قبلی رعایت نشده باشد، متن بعد از عبارت #ELSE در متن محدودیت دسترسی به دست آمده قرار می گیرد.
توجه داشته باشید. اگر متن محدودیت دسترسی به داده‌ها حاوی دستورالعمل‌های پیش‌پردازنده باشد، این محدودیت هنگام ویرایش از بررسی نحو عبور نمی‌کند و نمی‌توان آن را با استفاده از سازنده تغییر داد.
مثال:

#IF &CurrentUser<>"کلیمووا" #پس
<текст ограничения доступа>
#ENDESSI
اینجا کاربر فعلی- پارامتر جلسه از نوع DirectoryLink.Users.
این ساختار به این معنی است که شرط تنظیم محدودیت های دسترسی برای همه کاربران از دایرکتوری بررسی می شود، به جز کاربر Klimova.

الگوهای متن محدودیت دسترسی

یک نقش می تواند حاوی لیستی از الگوهای محدودیت دسترسی باشد که در برگه Restriction templates در فرم نقش توضیح داده شده است. همچنین قالب های محدودیت دسترسی را می توان در ویرایشگر ویرایش گروهی محدودیت ها و قالب های دسترسی ویرایش کرد.
هر الگوی محدودیت دسترسی یک نام و متن دارد. نام الگو از قوانین معمول برای نام های پذیرفته شده در سیستم 1C: Enterprise پیروی می کند.
متن الگو شامل بخشی از متن در زبان محدودیت دسترسی به داده است و ممکن است حاوی پارامترهایی باشد که با نماد برجسته شده اند.
“#”.
بعد از شخصیت “#” ممکن است به دنبال داشته باشد:
● یکی از کلید واژه ها:
● پارامتر به دنبال شماره پارامتر در قالب داخل پرانتز.
● CurrentTable – به معنای درج نام کامل جدولی است که محدودیت برای آن ساخته شده است.
● CurrentTableName- نشان دهنده درج در متن نام کامل جدول (به عنوان یک مقدار رشته، در علامت نقل قول) است که دستورالعمل به آن اعمال می شود، در نسخه فعلی زبان داخلی؛
● NameCurrentAccessRight - حاوی نام حقی است که محدودیت فعلی برای آن انجام شده است: READ/READ، ADD/INSERT، MODIFY/
به روز رسانی، حذف;
● نام پارامتر الگو – به معنای درج محدودیت پارامتر الگوی مربوطه در متن است.
● نماد "#" - به معنای درج یک علامت "#" در متن است.

یک عبارت محدودیت دسترسی می تواند شامل موارد زیر باشد:

● یک الگوی محدودیت دسترسی، که در قالب مشخص شده است
#TemplateName("مقدار پارامتر الگو 1"، "مقدار پارامتر الگو 2"، ...). هر پارامتر الگو در دو گیومه محصور شده است. اگر نیاز به تعیین یک کاراکتر نقل قول دوگانه در متن پارامتر دارید، از دو گیومه استفاده کنید.
● عملکرد StrContains (جایی که به دنبالش هستیم، آنچه به دنبالش هستیم). این تابع برای جستجوی رخداد WhatLooking for در رشته WhereLooking برای جستجو طراحی شده است. اگر مطابقت پیدا شود، درست است، در غیر این صورت نادرست است.

● عملگر + برای الحاق رشته ها.
برای سهولت در ویرایش متن الگو، در تب Restriction templates در فرم نقش، دکمه Set template text را کلیک کنید. در گفتگوی باز شده، متن الگو را وارد کرده و روی OK کلیک کنید.
سیستم 1C:Enterprise نحو متون الگو را بررسی می کند، نحو را برای استفاده از الگوها بررسی می کند، و متون الگوهای محدودیت دسترسی نقش را به متن درخواست جایگزین می کند.
جایگزینی ماکرو الگو به صورت زیر است:
● جایگزینی وقوع پارامترها در متن الگو با مقادیر پارامتر از عبارت استفاده از الگو در متن محدودیت.
● در جایگزینی عبارت استفاده از الگو در متن پرس و جو با متن قالب حاصل.
هنگام فراخوانی سازنده query برای شرایطی که شامل الگوهای محدودیت دسترسی است، هشداری در مورد جایگزینی همه الگوها صادر می شود.
در زیر نمونه هایی از الگوهای محدودیت آورده شده است:

به منظور مدیریت انعطاف پذیر دسترسی کاربر به داده ها مطابق با عملکردها، هنگام تنظیم محدودیت های دسترسی به داده ها، توصیه می شود
اصول زیر را رعایت کنید:
● باید مجموعه ای از اطلاعات را انتخاب کنید (ممکن است به کاربر فعلی وابسته باشد) که برای آن مناسب است آماده سازی اولیه. اطلاعات انتخاب شده باید از یک سو محدودیت های دسترسی به داده ها را تا حد امکان ساده کند و از سوی دیگر نباید بیش از حد بزرگ باشد. آن را بر اساس پارامترهای جلسه توزیع کنید.
● مقادیر پارامترهای جلسه را در کنترلر SetSessionParameters() ماژول جلسه تنظیم کنید.
● محدودیت های دسترسی را برای آن دسته از داده هایی که برای آنها موجه است تنظیم کنید (داده ها مخفی هستند یا مهمترین آنها برای حفظ یکپارچگی سیستم). به خاطر داشته باشید که تنظیم محدودیت های دسترسی می تواند دسترسی به این داده ها را کند کند. محدودیت های بیش از حد پیچیده نیز می تواند منجر به کاهش سرعت شود.
● در صورت لزوم، اطمینان حاصل کنید که تعداد محدودی از عملیات داده توسط کاربر انجام می شود دسترسی کاملارائه این داده ها، انتقال این اقدامات به ماژول های دارای امتیاز، یا فعال و غیرفعال کردن صریح حالت ممتاز در مکان های مناسب در کد برنامه، نامناسب است.
● بررسی های مختلفی که سیستم هنگام نوشتن اشیاء در حالت ممتاز دسترسی دارند انجام می دهد.

این به شما امکان می دهد در صورت کارکرد پیکربندی با این داده ها، محدودیت های مربوط به حقوق را در سطح سوابق برای فیلدهای مربوطه غیرفعال نکنید.
فقط در حالت مدیریت شده برنامه ریزی شده است:

● برای دایرکتوری ها هنگام بررسی والد، مالک و منحصر به فرد بودن کد.
● برای اسناد، فرآیندهای تجاری و وظایف هنگام بررسی منحصر به فرد بودن شماره؛
● برای طرح های مبادله هنگام بررسی منحصر به فرد بودن کد غیرفعال می شود.
● برای نمودارهای حساب ها و نمودارهای انواع مشخصه هنگام بررسی والد و منحصر به فرد بودن کد.

هنگام ایجاد یک جستجوی محدودیت داده، برخی از محدودیت ها و ویژگی هایی وجود دارد که باید در نظر داشته باشید:

● اگر محدودیت های دسترسی به داده ها برای یک جدول شی تنظیم شده باشد و از اتصال با چنین جدولی در کوئری داده استفاده شود، در این صورت شرط join (بخش پرس و جو نرم افزار) اجازه استفاده از قسمت جدولی شی با محدودیت دسترسی مشخص را نمی دهد.
● اگر یک پرس و جو جدولی را مشخص کند که از یک فیلد در پرس و جو استفاده نمی کند، تمام محدودیت های دسترسی به داده ها بر روی این جدول اعمال می شود. مثلا یک درخواست SELECT QUANTITY(*) FROM Directory.Counterpartiesبا توجه به تمام محدودیت های دسترسی مشخص شده برای دایرکتوری تست اجرا خواهد شد. محدودیت ها "توسط OR" اعمال می شود. این بدان معنی است که تمام رکوردهایی که حداقل با یک شرط قابل دسترسی هستند در دسترس خواهند بود. اگر شرایط برای برخی از فیلدها تنظیم نشده باشد، پرس و جو برای تمام رکوردهای جدول اجرا می شود.
اگر پرس و جو از یک جدول سطح بالا استفاده می کند، محدودیت های مشخص شده برای ستون های جداول تودرتو اعمال نمی شود.
اگر یک پرس و جو از یک جدول تودرتو استفاده می کند، محدودیت ها برای جدول تودرتو و جدول سطح بالا اعمال می شود.
مثلا یک درخواست SELECT QUANTITY(*) FROM Directory.Counterparties.Agreementsبا در نظر گرفتن تمام محدودیت‌های دایرکتوری طرفین و همچنین با در نظر گرفتن محدودیت‌های مربوط به بخش جدولی توافقنامه اجرا خواهد شد.

● اگر دسترسی به فیلدهای مورد نیاز برای به دست آوردن نمایشی از شی فوق داده ارجاع شده توسط محدودیت های دسترسی ممنوع شود
داده یا دسترسی به شی در سطح دسترسی ممنوع است، پس دریافت نمایشی از چنین شیئی بر روند تراکنش جاری تأثیر نمی گذارد.

سازنده محدودیت دسترسی به داده ها

برای فراخوانی سازنده در قسمت جدول محدودیت‌های دسترسی به داده، در ستون محدودیت دسترسی، به حالت ویرایش بروید و
روی دکمه انتخاب کلیک کنید و در فرم باز شده روی دکمه Query Builder… کلیک کنید.
فرم سازنده روی صفحه نمایش داده می شود:

با کمک آن، شرایط برای تنظیم محدودیت های دسترسی به داده ها شکل می گیرد.
در برگه جداول و فیلدها، اشیاء مورد نیاز را در لیست پایگاه داده انتخاب کرده و به لیست جداول منتقل کنید. اگر بیش از یک جدول مشخص شده باشد، تب Relationships به فرم طراح اضافه می شود.

در تب Links، شرایطی شکل می گیرد که بر پیوندهای بین فیلدهای جدول تحمیل می شود. برای وارد کردن یک شرط جدید، روی دکمه افزودن کلیک کرده و یکی از جداول موجود در ستون Table1 را انتخاب کنید. در ستون Table2، جدولی را انتخاب کنید که فیلدهای آن مربوط به فیلدهای اول است. در زیر لیست شرایط، کنترل هایی وجود دارد که شرط پیوند جداول را تشکیل می دهند.
اگر یک نوع شرط ساده انتخاب شده باشد، فیلدهای مربوط به جداول مشخص شده در فیلد1 و فیلد2 انتخاب شده و شرط مقایسه تنظیم می شود. اگر فیلدهایی انتخاب شوند که مقایسه نشده اند، متن زیر در خط لیست شرایط در ستون شرط پیوند نمایش داده می شود: شرط نادرست پر شده است.
در تب Conditions، در صورت نیاز، باید شرایطی را که بر اساس آن داده های منبع انتخاب می شوند، مشخص کنید.

برای هر فیلد انتخابی باید نوع شرط را انتخاب کرده و نام پارامتر را مشخص کنید. یک پارامتر جلسه به عنوان یک پارامتر مجاز است. شرایط چندگانه مجاز است. در این حالت در ستون Condition فیلد جدول شرط، متن شرط در چند خط نمایش داده می شود.
در هر زمانی هنگام ایجاد یک درخواست، متن درخواست را می توان با کلیک بر روی دکمه درخواست مشاهده کرد.

ویرایش دسته ای محدودیت های دسترسی و الگوها

حالت ویرایش گروهی محدودیت ها و قالب های حقوق دسترسی با دستور All access limits فراخوانی می شود منوی زمینهشاخه های نقش. فرم باز شده شامل دو تب است: محدودیت های دسترسی و قالب های محدودیت.

نشانک محدودیت های دسترسیشما می توانید تمام محدودیت های دسترسی وارد شده را در لیست کلی مشاهده کنید (برای همه نقش ها، اشیاء، حقوق، ترکیب های فیلد).
امکان اضافه کردن محدودیت دسترسی برای چندین نقش، شی، حقوق و ترکیبی از نقش ها به طور همزمان وجود دارد.
شما می توانید لیست را با معیارهای مختلف فیلتر کنید.

حالت ویرایش گروهی به شما امکان می دهد محدودیت های انتخاب شده در لیست را حذف کنید.
امکان ویرایش محدودیت های انتخاب شده وجود دارد. در این صورت امکان تغییر ترکیب فیلدها و/یا محدودیت دسترسی وجود دارد.
حالت ویرایش دسته ای همچنین به شما امکان می دهد محدودیت های انتخاب شده را در نقش های دیگر کپی کنید.

نشانک الگوهای محدودیتشما می توانید تمام الگوهای محدودیت دسترسی موجود در راه حل اعمال شده را مشاهده کنید، در حالی که فقط 10 خط اول از متن الگو در جدول نمایش داده می شود که در صورتی که متن الگو بیش از 10 خط باشد با علامت "..." پایان می یابد. پنجره ویرایش قالب، متن کامل قالب را نمایش می دهد.

امکان افزودن یک الگوی محدودیت دسترسی برای چندین نقش به طور همزمان وجود دارد.