تحديد سجلات مَن يراها الزائر

الهدف

أن تقول مرة واحدة إن سجلات جدول ما تعود إلى العميل الذي تسمّيه، فيرى كل زائر بوابة مسجَّل سجلاته هو ولا يرى سجلات أحد سواه — عبر كل واجهة API مخصّصة تستعملها بوابتك، وكل واحدة يضيفها أحد لاحقًا.

المشكلة التي تحلّها

تقرأ بوابتك عبر واجهات API مخصّصة، ويستطيع السكربت أن يسأل مَن المتصل:

var mine = runQuery({
  entity: 'par_ticket',
  filter: { connector: 'And', conditions: [
    { field: 'par_customer', operator: 'Equals', value: portalCustomerId() }
  ]}
});

وهذا يعمل، ويعمل منذ صار بإمكان الزوّار تسجيل الدخول. المشكلة أنه يجب أن يُكتب مجددًا في كل سكربت، وأنه لا يُرى حين يغيب: واجهة بلا هذه التصفية تبدو تمامًا كواجهة بها، وتُرجع الصفوف بكل رضا، وتُظهر تذاكر عميل لعميل آخر.

قاعدة علاقة البوابة تُخرج هذه الجملة من السكربتات وتضعها على الجدول.

قبل أن تبدأ

بوابتك مضبوطة على من يسجّلون الدخول — انظر مطالبة الزوّار بتسجيل الدخول. فالجدول الذي له قاعدة علاقة لا تستطيع قراءته بوابةٌ يفتحها أي أحد، إذ لا يوجد مَن تعود إليه سجلاته.
لجدولك حقل يحمل العميل — والشكل المعتاد بحثٌ إلى Account، لأن شركة الزائر هي ذلك.
زوّارك أعضاء في عميل. ومن سجّل ولم ينضمّ إلى شركة بعد لا يطابق شيئًا البتة، وهي الإجابة الآمنة وغالبًا ليست ما تريده أن يراه.

الخطوات

افتح الحل واختر سياسات البيانات.
اضغط جديد وسمِّها — التذاكر تعود إلى عميلها.
اضبط النوع على سجلات مَن (بوابة).
اختر الجدول.
اكتب الشرط:
```
Record.par_customer == Portal.CustomerId
```
إنه محرّر الشيفرة في المنصّة، فالاسم الذي لا يعرفه، مثل Portal.CustomrId، يُسطَّر تحته أثناء الكتابة بدل أن يُرفض عند الحفظ.
اترك سارية مُفعّلة، واضغط حفظ.

هذه هي الميزة كلها. لا شيء آخر يحتاج إلى منح أو إشارة أو تشغيل.

بماذا يمكنك المقارنة

خمسة أشياء عن الزائر المسجَّل، ويجب أن يذكر الشرط واحدًا منها على الأقل — وإلا فهو لا يقول لمن تعود هذه السجلات.

	ما هو
`Portal.CustomerId`	الشركة التي ينتمي إليها. وهو ما ستستعمله في كل مرة تقريبًا
`Portal.ContactId`	سجل جهة الاتصال الخاص به، حين يوجد
`Portal.UserId`	مستخدم البوابة نفسه
`Portal.Email`	عنوان بريده
`Portal.Role`	`"Owner"` أو `"Billing"` أو `"Member"` في شركته

يمكنك وصل الشروط بـ && و||، ومقارنة حقول الجدول نفسه أيضًا:

Record.par_customer == Portal.CustomerId && Record.par_status != "Draft"

CurrentUser ليس الزائر

على البوابة، «المستخدم المسجَّل» هو خادم البوابة نفسه — هوية واحدة يشترك فيها كل من يستعملها. لذلك لا تستطيع قاعدة العلاقة قراءة CurrentUser، ولا تستطيع سياسة البيانات العادية قراءة Portal. وترفض الشاشة كليهما عند الحفظ.

ماذا تفعل بالضبط

تُضيَّق كل قراءة، أيًّا كانت الواجهة التي تسأل. ويمكنك حذف التصفية من السكربتات التي فيها واحدة؛ ولست مضطرًا.
يُرفض إنشاءٌ يخزّن سجلًا باسم عميل آخر، مقابل السجل كما سيُحفظ فعلًا. وكذلك تعديلٌ ينقله.
الزائر الذي لا ينتمي إلى شركة لا يرى شيئًا — لا السجلات التي عميلها فارغ.
قاعدة واحدة لكل جدول. وإن احتجت إلى استبدال واحدة، فاكتب الجديدة بلا تفعيل سارية، ثم بدّل بينهما.

ما لا تفعله

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

ولا تُمنح لدور، وسترفضك الشاشة إن حاولت. إنها تخصّ الجدول. وهذا هو المقصود — فالقاعدة التي عليك تذكّر منحها قاعدةٌ يمكنك نسيان منحها.

معالجة المشكلات

«يجب أن تقول قاعدة علاقة البوابة أي السجلات تعود إلى الزائر.» شرطك لا يذكر Portal إطلاقًا. وهو كما كُتب تصفيةٌ عادية، وذلك شيء آخر.

«… هي بالفعل قاعدة علاقة البوابة لـ…» قاعدة واحدة تقرّر لمن تعود سجلات جدول. أطفئ الأخرى، أو حرّرها بدل إضافة ثانية.

الزائر لا يرى شيئًا البتة. تحقّق من أنه عضو في عميل، وأن الحقل في شرطك هو الحقل الذي يحمل العميل فعلًا — فالشرط الذي يقارن الحقل الخطأ لا يطابق شيئًا، لا كل شيء، وذلك عن قصد.

ترفض البوابة الحفظ والجدول في قائمتها. البوابة مضبوطة على أي أحد. والجدول الذي تعود سجلاته إلى زائر مسجَّل يحتاج إلى بوابة لها زائر مسجَّل.

الهدف​

المشكلة التي تحلّها​

قبل أن تبدأ​

الخطوات​

بماذا يمكنك المقارنة​

ماذا تفعل بالضبط​

ما لا تفعله​

معالجة المشكلات​

ذات صلة​