نظرة عامة
الدور هو مجموعة من الأذونات: الكائنات التي يمكن لتطبيق ما قراءتها أو كتابتها، والحقول التي يمكنه رؤيتها، والقدرات على مستوى المنصّة التي يمكنه استخدامها. ترث جميع وظائف منطق كل تطبيق ومكوّنات الواجهة الأمامية الأذونات الخاصة بالدور المُعلَّم باستخدامdefineApplicationRole() (انظر دور الدالة الافتراضي أدناه).
src/roles/restricted-company-role.ts
يتوفر
SystemPermissionFlag.USER_APPS وSystemPermissionFlag.WORKSPACE_APPS
بدءًا من الإصدار 2.54 من twenty-sdk؛ وتُسمّى في الإصدارات الأقدم
CONNECTED_ACCOUNTS وAPPLICATIONS. الأسماء القديمة هي أسماء مستعارة مهملة
للعلامات نفسها، ويحتفظ الدور بكل علامة مرة واحدة فقط. لا يزال تعداد
SystemPermissionFlag، على سبيل المثال باستخدام Object.keys، يعرض الأسماء
القديمة. تُبلّغ واجهة API أيضًا عن هذه العلامات بمفاتيحها القديمة، على سبيل المثال في
currentUserWorkspace.permissionFlags.أمن على مستوى الصف
تتطلب أذونات على مستوى الصف خطة Organization أو أعلى — راجع الأسعار. ما يحدث في خطة لا تتضمن الاستحقاق مشروح في الملاحظات في نهاية هذا القسم. تحدّد أذونات الكائن والحقل أي الكائنات والحقول يمكن لدورٍ معيّن التفاعل معها. محددات الأذونات على مستوى الصف تتعمّق أكثر وتحدّد أي السجلات يمكن لدورٍ معيّن رؤيتها والتصرّف فيها — على سبيل المثال، دور للخدمة الذاتية حيث يرى كل مستخدم خارجي سجلاته الخاصة فقط. عرِّف المحددات باستخدامrowLevelPermissionPredicates على الدور. مثل باقي ملف manifest، يحمل كل محدِّد universalIdentifier خاصًا به، ويشير إلى كائن وحقل باستخدام universalIdentifier الخاصّ بهما، وoperand، وحقل workspaceMember (اختياري) تُحقن قيمته وقت الاستعلام — بحيث يمكنك التعبير عن: “علاقة مالك السجل هي عضو مساحة العمل الحالي”:
src/roles/partner-role.ts
دمج المحددات مع المجموعات
افتراضيًا، يتم دمج محددات الدور باستخدامAND. لدمج بعضها باستخدام OR (أو لتداخل المنطق)، قم بتعريف إدخال rowLevelPermissionPredicateGroups وأشِر كل محدد إليه من خلال predicateGroupUniversalIdentifier. يُتيح هذا الدور للشريك رؤية فرصة (Opportunity) إذا كان إمّا مالكها أو جهة الاتصال لها:
src/roles/partner-opportunities-role.ts
- امنح كل محدد وكل مجموعة قيمة
universalIdentifierثابتة (أي uuid) — فهي المفتاح الذي يعرّف الكيان عبر الترقيات، كما أنّ المحددات تشير إلى المجموعات من خلاله. - يمكن للمحددات الإشارة إلى الكائنات والحقول التي يملكها تطبيقك أو إلى كائنات Twenty القياسية.
- يُفرض الأمان على مستوى الصف لمساحات العمل في خطة Organization أو أعلى. في الخطط الأخرى، تظل المسندات المعلنة في بيان التطبيق متزامنة، لكنها لا تُفرض ببساطة.
- تتصرف واجهة Metadata API بشكل مختلف عن البيان هنا: من دون الاستحقاق،
يُرفض
upsertRowLevelPermissionPredicatesمعROW_LEVEL_PERMISSION_FEATURE_DISABLEDبدلاً من المزامنة. لذلك، لا يمكن لمساحة عمل ضمن خطة لا تتضمن الأمان على مستوى الصف إنشاء مسندات خارج بيان التطبيق، حتى مع وجود الحقلrowLevelPermissionPredicatesفي النوعRoleعند فحص المخطط.
الدور الافتراضي للوظيفة
عند إنشاء هيكل لتطبيق جديد، ينشئ CLI ملف دور افتراضي مُصرَّحًا به باستخدامdefineApplicationRole():
src/roles/default-role.ts
defineApplicationRole() غلافًا بسيطًا حول defineRole() يشير إلى الدور المستخدم كإعداد افتراضي لتطبيقك وقت التثبيت. يتطابق التحقق من الصحة مع defineRole، لكن خط تجميع البناء يربط تلقائيًا قيمة universalIdentifier بصفة defaultRoleUniversalIdentifier في بيان التطبيق (manifest)، وبالتالي لا تحتاج إلى الإشارة إليه من defineApplication بنفسك.
الملاحظات:
- يُسمح بوجود استدعاء واحد فقط لـ
defineApplicationRole(...)لكل تطبيق — سيفشل إنشاء بيان التطبيق (manifest) إذا عثر على أكثر من واحد. - استخدم
defineRole()(وليسdefineApplicationRole()) لأي أدوار إضافية يأتي بها تطبيقك. - لا يزال تعيين
defaultRoleUniversalIdentifierصراحةً علىdefineApplication()مدعومًا للتوافق مع الإصدارات السابقة، ولكنه مُهمَل لصالحdefineApplicationRole(). يمكنه أيضًا تسمية دور لا يعرّفه تطبيقك، مثل الدور الافتراضي المضمّن للتطبيق المخصص لمساحة العمل الذي يحتفظ بهtwenty app pull؛ وعندئذٍ لا يمكن لعملية البناء التحقق من ذلك الدور، لذا يجب أن يكون موجودًا في مساحة العمل المستهدفة. - يُعد الدور الذي يمكن إسناده إلى أعضاء مساحة العمل أو مفاتيح API (
canBeAssignedToUsersأوcanBeAssignedToApiKeys، وكلاهماtrueعند حذفه) دورًا مخصصًا، ويتطلب خطة Organization أو أعلى: في الخطط الأخرى يُرفض التثبيت. أبقِ كليهماfalseفي الأدوار التي لا يعمل بها سوى تطبيقك ووكلائه.
أدوار الوكلاء
دور التطبيق هو ما تراجعه مساحة العمل عند تثبيت تطبيقك، لذا يجب أن يغطي كل ما يمكن للتطبيق نفسه القيام به. يجب ألا يمنح أي دور تُسنده إلى وكيل عبرroleUniversalIdentifier في defineAgent() صلاحيات أكثر من دور التطبيق: فلا إجراء على كائن، ولا وصول إلى حقل، ولا علامة إذن، ولا نطاق على مستوى الصف يفتقر إليه دور التطبيق. إذا حدث ذلك، يفشل الإصدار مع ظهور خطأ يسرد الصلاحيات الزائدة. لا تخضع الأدوار التي يوفرها تطبيقك لأعضاء مساحة العمل أو مفاتيح API لهذه القاعدة، لأن التطبيق لا يعمل بها مطلقًا. يتطلب التحقق دور التطبيق في مصدر تطبيقك، لذا يتم تخطيه عندما يُعرَّف الدور الافتراضي في مكان آخر.
أفضل الممارسات
- ابدأ من الدور المُنشأ تلقائيًا، ثم قم بتقييده تدريجيًا — إذ يمنح الإعداد الافتراضي صلاحيات قراءة واسعة، وهو ما نادرًا ما تريده في بيئة الإنتاج.
- استبدل
objectPermissionsوfieldPermissionsبالكائنات والحقول الدقيقة التي تحتاجها وظائفك فعليًا. permissionFlagUniversalIdentifiersتتحكم في الوصول إلى القدرات على مستوى المنصة. اجعلها في حدّها الأدنى.- تحمل علامة إذن يعرّفها تطبيقك باستخدام
definePermissionFlag()قيمةpermissionType: وهي'tool'(القيمة الافتراضية) لإمكانية يمكن منحها لوكيل أو لمستخدم، و'settings'لعلامة تفتح منطقة الإعدادات. - اطّلع على مثال عملي:
examples/hello-world/src/roles/default-role.ts.