القيود المفروضة على الوصول إلى البيانات في الأدوار 1s. حقوق الوصول إلى SCP. RLS. معلومات وإعدادات عامة. تقييد الوصول على مستوى التسجيل

توجد كافة إعدادات حقوق المستخدم التي سنقوم بها في إطار عمل هذه المقالة في القسم 1C 8.3 "الإدارة" - "إعدادات المستخدم والحقوق". هذه الخوارزمية متشابهة في معظم التكوينات في النماذج المدارة. سيتم استخدام برنامج المحاسبة 1C كمثال ، لكن إعداد الحقوق في البرامج الأخرى (1C UT 11 ، 1C ZUP 3 ، 1C ERP) يتم بنفس الطريقة تمامًا.

دعنا ننتقل إلى قسم "المستخدمون" في نافذة الإعدادات. نرى هنا ارتباطين تشعبيين: "المستخدمون" و "إعدادات تسجيل الدخول". أولهم يسمح لك بالذهاب مباشرة إلى قائمة مستخدمي قاعدة المعلومات هذه. قبل إنشاء مستخدم جديد ، ضع في اعتبارك إعدادات تسجيل الدخول المحتملة (الارتباط التشعبي الموجود على اليمين).

في نموذج الإعدادات هذا ، يمكنك تعيين تعقيد كلمة المرور (7 أحرف على الأقل ، ومحتوى إلزامي لأنواع مختلفة من الأحرف ، وما إلى ذلك). هنا يمكنك أيضًا تحديد طول كلمة المرور وفترة صلاحيتها وحظر الوصول إلى البرنامج للمستخدمين الذين لم يكن لديهم نشاط لفترة زمنية معينة.

الآن يمكنك الانتقال مباشرة إلى إضافة مستخدم جديد إلى 1C. يمكنك القيام بذلك عن طريق النقر فوق الزر "إنشاء" ، كما هو موضح في الصورة أدناه.

بادئ ذي بدء ، نشير إلى الاسم الكامل - "أنتونوف ديمتري بتروفيتش" ، ونختار فردًا من الدليل المقابل. هنا يمكنك أيضًا تحديد القسم الذي يعمل فيه موظفنا.

تم استبدال اسم تسجيل الدخول "AntonovDP" تلقائيًا كاختصار للاسم الكامل "Antonov Dmitry Petrovich". قم بتعيين كلمة مرور ومصادقة لـ 1C Enterprise. هنا يمكنك أيضًا تحديد ما إذا كان هذا المستخدم مسموحًا له بتغيير كلمة المرور من تلقاء نفسه.

لنفترض أننا نريد أن يكون ديمتري بتروفيتش أنتونوف متاحًا في قائمة الاختيار عند بدء قاعدة المعلومات هذه. للقيام بذلك ، تحتاج إلى تعيين العلم على العنصر "إظهار في قائمة الاختيار". نتيجة لذلك ، ستبدو نافذة التفويض عند بدء البرنامج مثل تلك الموضحة في الشكل أدناه.

دعنا ننتبه إلى إعداد مهم آخر في بطاقة دليل المستخدم - "تسجيل الدخول إلى البرنامج مسموح به". إذا لم يتم تعيين التأخير ، فلن يتمكن المستخدم ببساطة من دخول قاعدة المعلومات هذه.

حقوق الوصول

بعد ملء جميع البيانات الموجودة في بطاقة المستخدم - أنتونوف ديمتري بتروفيتش ، سنقوم بتدوينها والمضي قدمًا في تحديد حقوق الوصول ، كما هو موضح في الشكل أدناه.

قبل أن نفتح قائمة تم إدخالها مسبقًا في ملفات تعريف الوصول إلى البرنامج. حدد المربعات المطلوبة.

الوصول إلى ملفات تعريف المجموعة

يمكن تكوين ملفات تعريف مجموعة الوصول من النموذج الرئيسي لإعداد المستخدمين والحقوق. انتقل إلى قسم "الوصول إلى المجموعات" وانقر على الارتباط التشعبي "الوصول إلى ملفات تعريف المجموعة".

لنقم بإنشاء مجموعة جديدة من نموذج القائمة المفتوحة. في القسم المجدول في علامة التبويب "الإجراءات المسموح بها (الأدوار)" ، من الضروري تحديد المربعات الخاصة بتلك الأدوار التي ستؤثر على حقوق الوصول للمستخدمين المُدرجين في المجموعة التي نقوم بإنشائها. يتم إنشاء كل هذه الأدوار وتكوينها في أداة التهيئة. لا يمكن تعديلها أو إنشاؤها من وضع المستخدم. يمكنك فقط الاختيار من قائمة موجودة.

RLS: تقييد الوصول إلى مستوى التسجيل

يتيح لك تكوين الوصول إلى بيانات البرنامج بشكل أكثر مرونة في أقسام معينة. لتنشيطه ، قم بتعيين العلم على العنصر الذي يحمل نفس الاسم في نموذج إعدادات المستخدم والحقوق.

يرجى ملاحظة أن تمكين هذا الإعداد قد يؤثر سلبًا على أداء النظام. النقطة المهمة هي أن آلية RLS تغير جميع الطلبات وفقًا للقيود المحددة.

دعنا ننتقل إلى ملف تعريف مجموعة الوصول "مجموعة الاختبار" الذي أنشأناه سابقًا. يوضح الشكل أدناه أنه بعد تمكين تقييد الوصول على مستوى التسجيل ، ظهرت علامة تبويب إضافية "قيود الوصول".

لنفترض أننا نريد للمستخدمين الذين تم تعيين مجموعة الاختبار لهم الوصول إلى البيانات لجميع المؤسسات في قاعدة المعلومات هذه ، باستثناء تلك المحددة في ملف التعريف.

في قسم الجدول العلوي ، قم بتعيين قيود الوصول حسب المؤسسة. في الجزء السفلي ، سنوضح أنه لن يتم توفير الوصول إلى البيانات (المستندات والأدلة وما إلى ذلك) لمنظمة Roga LLC.

غالبًا ما تكون هناك حاجة لتقييد الوصول إلى البيانات جزئيًا. على سبيل المثال ، عندما يحتاج المستخدم إلى رؤية المستندات الخاصة بمؤسسته فقط. في مثل هذه الحالات ، يستخدم 1C آلية تقييد الوصول على مستوى السجل (ما يسمى RLS - تأمين مستوى السجل).

على سبيل المثال ، افترض أننا نواجه المهمة التالية. تحتفظ المؤسسة بمحاسبة متعددة الشركات وكل طرف مقابل ومستخدم قاعدة البيانات ينتمي إلى مؤسسة معينة. من الضروري توفير الوصول إلى دليل "المقاولين" بطريقة تمكن كل مستخدم من عرض الأطراف المقابلة وتعديلها وإضافتها إلى مؤسسته فقط.

لحل المشكلة ، سوف نستخدم المنصة "1C: Enterprise 8.2". دعنا ننشئ تكوينًا جديدًا في الخصائص التي سيتم تحديد خيار "التطبيق المُدار" منها كوضع التشغيل الرئيسي.

بعد ذلك ، سننشئ دليل "المنظمات" ومجلدين آخرين - "المقاولون" و "المستخدمون" بالسمة "المؤسسة". بالإضافة إلى الدلائل ، نحتاج إلى معلمتين للجلسة - "المنظمة" و "المستخدم" (من الأنواع المناسبة). يتم تعيين قيم هذه المعلمات في بداية جلسة التكوين ويتم تخزينها حتى تنتهي. سنستخدم قيم هذه المعلمات عند إضافة شروط تقييد الوصول على مستوى السجل.

يتم تعيين معلمات الجلسة في وحدة خاصة - "وحدة الجلسة"

في هذه الوحدة ، نصف الإجراء المحدد مسبقًا "SetSessionParameters" والذي نطلق فيه على وظيفة الوحدة العامة المعدة مسبقًا "FullPermissions". يعد هذا ضروريًا نظرًا لخصائص تشغيل قاعدة البيانات في وضع التطبيق المدار ، عندما لا يمكن تنفيذ جزء من رمز البرنامج إلا على جانب الخادم (لن أتطرق إلى شرح هذه المبادئ في هذه المقالة).

كود 1C v 8.x إجراء إعداد معلمات الجلسة (المعلمات المطلوبة)
FullPermissions.SetSessionParameters () ،
EndProcedure

في خصائص وحدة "FullPermissions" ، حدد المربعات "Server" و "Server call" و "Privileged" (هذا الأخير يعني أن إجراءات ووظائف هذه الوحدة سيتم تنفيذها بدون التحكم في الوصول). سيبدو نص الوحدة كما يلي:

كود 1C v 8.x وظيفة تحديد CurrentUser ()
CurrentUser = Directories.Users.FindByName (UserName () ، True) ،
إرجاع CurrentUser ؛
وظائف النهاية

مجموعة إجراءات الجلسة المعلمات () تصدير
CurrentUser = تحديد CurrentUser () ،
CurrentOrganization = Directories.Organizations.EmptyReference () ؛
إذا ValueFilled (CurrentUser) ثم
CurrentOrganization = CurrentUser.Organization ؛
إنهاء إذا؛
SessionParameters.User = CurrentUser ،
SessionParameters.Organization = CurrentOrganization ؛
EndProcedure

FunctionSessionParameterSet (ParameterName) تصدير
إرجاع ValueFilled (SessionParameters [ParameterName]) ؛
وظائف النهاية

الدالة RoleAvailableToUser (RoleName) Export
إرجاع RoleAvailable (RoleName) ؛
وظائف النهاية

في وحدة التطبيق المُدار ، سوف نتحقق من وجود مستخدم التكوين في دليل "Users" (للتبسيط ، سنبحث عنه بالاسم) ونغلق النظام إذا لم يتم العثور عليه. يعد ذلك ضروريًا لضمان ملء معلمات الجلسة.

الكود 1C v 8.x إجراء التشغيل المسبق للنظام (فشل)
// سيتم فحص الجميع باستثناء المسؤول عن التواجد في دليل "المستخدمون"
إذا لم يكن FullPermissions.RoleAvailableToUser ("FullPermissions") إذن
إذا لم يكن FullPermissions.SessionParameterSet ("المستخدم") ثم
تحذير ("المستخدم" "+ اسم المستخدم () +" "" غير موجود في الدليل! ") ؛
الرفض = صحيح ؛
يعود؛
إنهاء إذا؛
إنهاء إذا؛
EndProcedure

الآن يمكننا الانتقال مباشرة إلى وصف قيود الوصول. للقيام بذلك ، أنشئ دور "المستخدم" وانتقل إلى علامة التبويب "نماذج القيود" ، حيث نضيف نموذجًا جديدًا "AccountsReadingChange" بنص النموذج التالي: حيث المنظمة = المنظمة # المعلمة (1)

نص القالب المقيد هو امتداد للغة الاستعلام. على عكس الطلب العادي ، يجب أن يحتوي نص التقييد بالضرورة على بند "WHERE". نظرًا لأن قيم معلمات الاستعلام (في حالتنا ، هي "& Organization") ، يتم استخدام قيم معلمات الجلسة التي تحمل الاسم نفسه. يعني إنشاء النموذج #Parameter (1) أن النظام سيحل محل النص الذي تم تمريره باعتباره المعلمة الأولى في المكان الذي يُستخدم فيه النموذج في هذا المكان. بمساعدة النموذج المحدد ، سيتم فحص كل سجل في الجدول (في حالتنا ، سيكون البحث عن "المقاولين"). بالنسبة للسجلات التي تطابق قيمة سمة "Organization" الخاصة بها القيمة المحددة في معلمة الجلسة المقابلة ، سيتم استيفاء الشرط الموضح في النموذج. وبالتالي ، ستكون هذه الإدخالات متاحة للقراءة أو التحرير أو الإضافة (بناءً على أي من هذه الحقوق ينطبق عليها النموذج). سأوضح ما ورد أعلاه بمثالنا.

دعنا ننتقل إلى علامة التبويب "الحقوق" لدور "المستخدم" ونفتح قائمة الحقوق في دليل "الحسابات". سنستخدم نموذج قيد "AccountsReadChange" لأذونات "قراءة" و "تغيير" و "إضافة".

بالنسبة إلى حق "القراءة" ، سنستخدم نموذجًا مع المعلمة "OR ThisGroup". في الوقت نفسه ، سيُسمح لمستخدمي هذا الدور بقراءة ليس فقط عناصر دليل "الحسابات" لمؤسستهم ، ولكن أيضًا جميع مجموعات هذا الدليل.

#AccountsReadingChange ("OR ThisGroup")

نظرًا لأنه عند إضافة عناصر جديدة من الدليل ، يقوم النظام بقراءة ضمنية للسمات المحددة مسبقًا (هذا ضروري ، على سبيل المثال ، للترقيم) ، فمن الضروري ضمان قراءة هذه الحقول دون عوائق. للقيام بذلك ، أضف سطرًا إضافيًا بنص تقييد فارغ إلى جدول قيود الوصول إلى البيانات وقم بإدراج الحقول التي تنطبق عليها هذه القاعدة - الارتباط ، إصدار البيانات ، الأصل ، الرمز.

وبالتالي ، يتم حل مهمة تقييد الوصول على مستوى السجل. سيتمكن المستخدمون الذين لديهم قيود حالية من الوصول لعرض البيانات وتحريرها لمؤسستهم فقط.

يحتوي النظام الأساسي 1C: Enterprise 8 على آلية مضمنة لتقييد الوصول إلى البيانات على مستوى السجل. يمكنك قراءة معلومات عامة عنها هنا. باختصار ، سيسمح لك RLS بتقييد الوصول إلى البيانات وفقًا لبعض الشروط على قيم الحقل. على سبيل المثال ، يمكنك تقييد وصول المستخدمين إلى المستندات بناءً على قيمة السمة "Organization". سيعمل بعض المستخدمين مع المستندات الخاصة بمؤسسة "شركة الإدارة" ، بينما يعمل الباقي مع مؤسسة "مصنع الألبان". كمثال.

تحضير

تم تنفيذ المثال في تكوين العرض التوضيحي لـ SCP 1.3. لنقم بإنشاء مستخدم "Storekeeper" وإضافة دور "Storekeeper" بنفس الاسم إليه.

الآن دعنا ننتقل مباشرة إلى تعيين حقوق الوصول على مستوى السجل. دعنا ننتقل إلى واجهة "إدارة المستخدم". في القائمة الرئيسية ، حدد "الوصول على مستوى السجلات -> الخيارات". هنا نقوم بتحديد المربع "تقييد الوصول على مستوى السجل حسب أنواع الكائنات" ، وفي قائمة الكائنات حدد "المؤسسات".

وهكذا ، قمنا بتمكين استخدام RLS. الآن أنت بحاجة إلى إعداده.

لم يتم تكوين التحكم في الوصول على مستوى السجل بشكل منفصل لكل مستخدم أو ملفات تعريف الأذونات. تم تكوين RLS لمجموعات المستخدمين. دعونا نضيف مجموعة مستخدمين جديدة ، دعنا نسميها "أمناء المتاجر"

يُظهر تكوين المجموعة على الجانب الأيمن من النموذج قائمة بالمستخدمين المنتمين إلى هذه المجموعة. دعنا نضيف المستخدم الذي أنشأناه سابقًا. يوجد على اليسار جدول قيود الوصول. في إعداد RLS ، اخترنا أن الوصول سيكون مقيدًا من قبل المؤسسات فقط ، لذلك نرى نوعًا واحدًا فقط من كائن الوصول. انقر على زر "الوصول إلى الإعدادات". يتم فتح معالجة تعيين الأذونات للمجموعة الحالية.

في قائمة كائنات الوصول للمجموعة ، أضف المنظمة "PPE" Entrepreneur "". سنترك نوع وراثة الحقوق دون تغيير. سيتم تعيين الحق في الوصول إلى كائن للقراءة والكتابة. انقر فوق "موافق" ، الإعدادات جاهزة. لقد أنشأنا للتو RLS على مستوى المؤسسة.

ما يراه المستخدم

قم بتشغيل البرنامج تحت المستخدم الذي تم إنشاؤه مسبقًا وافتح دليل "المؤسسات". هذا هو الشكل الذي ستبدو عليه القائمة بالنسبة لمستخدمنا وللمستخدم صاحب الحقوق الكاملة:

كما نرى ، يرى مستخدم صاحب المتجر مؤسسة واحدة فقط فتحنا لها حق الوصول للقراءة. الأمر نفسه ينطبق على المستندات ، مثل إيصالات السلع والخدمات.

وبالتالي ، لن يرى المستخدم المؤسسات التي لم يتم تعيين الوصول إليها له فحسب ، بل لن يتمكن أيضًا من قراءة / كتابة المستندات والكائنات الأخرى في قاعدة المعلومات ، والتي لها حقوق في الدور على السمة "المنظمة ".

لقد نظرنا في أبسط مثال على إعداد RLS. في المقالة التالية ، سنتحدث عن تنفيذ آلية RLS في تكوين الإصدار 1.3 "Manufacturing Enterprise Management".

1C لديه نظام حقوق وصول مدمج (يسمى هذا النظام أدوار 1C). هذا النظام ثابت - حيث قام المسؤول بتعيين الحقوق على 1C ، فليكن.

بالإضافة إلى ذلك ، هناك نظام ديناميكي لحقوق الوصول (يسمى - RLS 1C). في ذلك ، يتم حساب حقوق 1C ديناميكيًا في وقت عمل المستخدم بناءً على المعلمات المحددة.

أحد أكثر إعدادات الأمان شيوعًا في البرامج المختلفة هو مجموعة أذونات القراءة / الكتابة لمجموعات المستخدمين ثم - تضمين أو استبعاد مستخدم من المجموعات. على سبيل المثال ، يتم استخدام نظام مشابه في Windows AD (Active Directory).

يسمى نظام الأمان هذا في 1C الأدوار 1C. تقع الأدوار 1C في التكوين في فرع عام / الأدوار. تعمل أدوار 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 على نظام مدمج لحقوق الوصول ، والذي يقع في Configurator - General - Roles.

ما الذي يميز هذا النظام وما هو هدفه الرئيسي؟ يتيح لك وصف مجموعات الحقوق التي تتوافق مع مواقف المستخدمين أو أنشطتهم. إن نظام حقوق الوصول هذا ثابت بطبيعته ، مما يعني أنه عندما قام المسؤول بتعيين حقوق الوصول إلى 1C ، فهو كذلك. بالإضافة إلى النظام الثابت ، هناك نظام آخر لحقوق الوصول - ديناميكي (RLS). في هذا النظام ، يتم حساب حقوق الوصول بطريقة ديناميكية ، اعتمادًا على المعلمات المحددة ، في سياق العمل.

الأدوار في 1C

إعدادات الأمان الأكثر شيوعًا في البرامج المختلفة هي ما يسمى بمجموعة أذونات القراءة / الكتابة لمجموعات مستخدمين مختلفة وفي المستقبل: تضمين أو استبعاد مستخدم معين من المجموعات. مثل هذا النظام ، على سبيل المثال ، يستخدم في نظام التشغيل Windows AD (Active Directory). يسمى نظام الأمان المستخدم في برنامج 1C بالأدوار. ما هذا؟ الأدوار في 1C هي كائن موجود في التكوين في الفرع: عام - الأدوار. أدوار 1C هذه عبارة عن مجموعات يتم تعيين حقوق لها. في المستقبل ، يمكن تضمين كل مستخدم واستبعاده من هذه المجموعة.

بالنقر المزدوج على اسم الدور ، ستفتح محرر الحقوق للدور. يوجد على اليسار قائمة كائنات ، حدد أيًا منها وعلى اليمين سترى خيارات لحقوق الوصول الممكنة:

- القراءة: الحصول على السجلات أو أجزاءها الجزئية من جدول قاعدة البيانات ؛
- الإضافة: سجلات جديدة مع الاحتفاظ بالسجلات الموجودة ؛
- التغيير: إجراء تغييرات على السجلات الموجودة ؛
- الحذف: بعض السجلات مع الاحتفاظ بالباقي دون تغيير.

لاحظ أنه يمكن تقسيم جميع حقوق الوصول إلى مجموعتين رئيسيتين - هذا حق "بسيط" وهذا حق مع إضافة الخاصية "التفاعلية". ما هو المقصود هنا؟ والشيء هو التالي.

في حالة قيام المستخدم بفتح نموذج ما ، على سبيل المثال ، المعالجة ، وفي نفس الوقت ينقر عليه بالماوس ، يبدأ البرنامج في لغة 1C المدمجة في تنفيذ إجراءات محددة ، على سبيل المثال ، حذف المستندات. للحصول على إذن بمثل هذه الإجراءات التي يقوم بها البرنامج ، تكون حقوق 1C مسؤولة ، على التوالي ، "ببساطة".

في حالة قيام المستخدم بفتح المجلة وبدء إدخال شيء بمفرده من لوحة المفاتيح (المستندات الجديدة ، على سبيل المثال) ، فإن حقوق 1C "التفاعلية" هي المسؤولة عن السماح بمثل هذه الإجراءات. يمكن أن يكون لكل مستخدم عدة أدوار متاحة في وقت واحد ، ثم تتم إضافة الإذن.

RLS في 1C

يمكنك تمكين الوصول إلى الدليل (أو المستند) أو تعطيله. لا يمكنك تشغيله قليلاً. لهذا الغرض ، هناك امتداد معين لنظام الدور 1C ، والذي يسمى RLS. هذا هو نظام حقوق وصول ديناميكي يقدم قيود وصول جزئية. على سبيل المثال ، تصبح المستندات الخاصة بمنظمة ومستودع معين فقط متاحة لاهتمام المستخدم ، ولا يرى الباقي.

يجب أن يؤخذ في الاعتبار أنه يجب تطبيق نظام RLS بعناية شديدة ، نظرًا لأنه من الصعب فهم مخططه المعقد ، وقد يكون لدى المستخدمين المختلفين أسئلة عندما يقارنوا ، على سبيل المثال ، نفس التقرير ، الذي تم إنشاؤه من تحت مختلف المستخدمين. لنفكر في مثل هذا المثال. أنت تختار دليلًا محددًا (المؤسسات ، على سبيل المثال) وحقًا محددًا (القراءة ، على سبيل المثال) ، أي أنك تسمح بالقراءة لدور 1C. في الوقت نفسه ، تقوم بتعيين نص الطلب في اللوحة البعيدة لقيود الوصول إلى البيانات ، وفقًا لضبط False أو True ، وفقًا للإعدادات. عادة ، يتم تخزين الإعدادات في سجل معلومات خاص.

سيتم تنفيذ هذا الاستعلام ديناميكيًا (عند إجراء محاولة لتنظيم القراءة) ، لجميع إدخالات الدليل. إنه يعمل على النحو التالي: تلك السجلات التي عيّن لها طلب الأمان - صحيح ، سيرى المستخدم ، لكن الآخرين لن يفعلوا ذلك. يتم تمييز حقوق 1C ذات القيود الموضوعة باللون الرمادي.

يتم تنفيذ عملية نسخ إعدادات RLS المتطابقة باستخدام القوالب. بادئ ذي بدء ، تقوم بإنشاء قالب ، وتسميته ، على سبيل المثال ، MyTemplate ، حيث تعكس طلب الأمان. ثم ، في إعدادات حقوق الوصول ، حدد اسم هذا القالب بهذه الطريقة: "#MyTemplate".

عندما يعمل المستخدم في وضع 1C Enterprise ، عند الاتصال بـ RLS ، قد تظهر رسالة خطأ مثل: "حقوق غير كافية" (لقراءة الدليل XXX ، على سبيل المثال). يشير هذا إلى أن نظام RLS قد منع قراءة بعض السجلات. لمنع ظهور هذه الرسالة مرة أخرى ، يلزمك إدخال الكلمة "مسموح" في نص الطلب.

https://zabor-vam.ru/product/metallicheskie/zabory-iz-profnastila/