تعیین اینکه بازدیدکننده رکوردهای چه کسی را می‌بیند
هدف
یک‌بار بگویید رکوردهای یک جدول از آنِ مشتری‌ای هستند که نام می‌برند، تا هر بازدیدکنندهٔ واردشدهٔ درگاه رکوردهای خودش را ببیند و رکوردهای هیچ‌کس دیگر را نبیند — از راه هر API سفارشی که درگاه شما به کار می‌برد، و هر APIای که بعداً کسی اضافه کند.
مسئله‌ای که حل می‌کند
درگاه شما از راه APIهای سفارشی می‌خواند، و یک اسکریپت می‌تواند بپرسد چه کسی صدا زده است:
var mine = runQuery({
entity: 'par_ticket',
filter: { connector: 'And', conditions: [
{ field: 'par_customer', operator: 'Equals', value: portalCustomerId() }
]}
});
این کار می‌کند و از وقتی بازدیدکنندگان می‌توانند وارد شوند کار کرده است. اشکال این است که باید در هر اسکریپت دوباره نوشته شود، و وقتی نباشد دیده نمی‌شود: APIـای بدون این فیلتر دقیقاً مثل APIـای با آن به نظر می‌رسد، با خوشحالی ردیف برمی‌گرداند، و تیکت‌های یک مشتری را به مشتری دیگر نشان می‌دهد.
قاعدهٔ رابطهٔ درگاه این جمله را از اسکریپت‌ها بیرون میآور د و روی جدول می‌گذارد.
پیش از شروع
- درگاه شما روی کسانی که وارد می‌شوند تنظیم شده باشد — درخواست ورود از بازدیدکنندگان را ببینید. جدولی که قاعدهٔ رابطه دارد را درگاهی که هر کسی می‌تواند بازش کند نمی‌تواند بخواند، چون کسی نیست که رکوردها از آنِ او باشند.
- جدول شما فیلدی داشته باشد که مشتری را نگه می‌دارد — معمولاً یک لوکاپ به 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 را
بخواند. صفحه هنگام ذخیره هر دو را رد می‌کند.
دقیقاً چه می‌کند
- هر خواندن تنگ می‌شود، هر API سفارشی که بپرسد. می‌توانید فیلتر را از اسکریپت‌هایی که دارند حذف کنید؛ مجبور نیستید.
- ساختنی که رکورد را به نام مشتری دیگری ذخیره کند رد می‌شود، در برابر رکورد آن‌گونه که واقعاً ذخیره خواهد شد. ویرایشی که آن را جابه‌جا کند هم همین‌طور.
- بازدیدکننده‌ای که به هیچ شرکتی تعلق ندارد هیچ نمی‌بیند — نه رکوردهایی که مشتری‌شان خالی است.
- هر جدول یک قاعده. اگر باید یکی را جایگزین کنید، قاعدهٔ تازه را بدون تیک در حال اجرا بنویسید و سپس جابه‌جاشان کنید.
چه نمی‌کند
جدول را خصوصی نمی‌کند. افراد خودتان که به پلتفرم وارد شده‌اند همان چیزی را می‌بینند که نقش امنیتی‌شان اجازه می‌دهد، دقیقاً مثل قبل. این قاعده دربارهٔ بازدیدکنندگان درگاه است و جایگزین اعطای دسترسی رکورد به یک نقش نیست.
به نقشی اعطا نمی‌شود و اگر تلاش کنید صفحه رد می‌کند. به جدول تعلق دارد. نکته همین است — قاعده‌ای که باید یادتان بماند اعطایش کنید، قاعده‌ای است که می‌توانید فراموشش کنید.
عیب‌یابی
«یک قاعدهٔ رابطهٔ درگاه باید بگوید کدام رکوردها از آنِ بازدیدکننده است.» شرط شما هرگز Portal
را نام نمی‌برد. آن‌گونه که نوشته شده یک فیلتر معمولی است، که چیز دیگری است.
«… پیش‌تر قاعدهٔ رابطهٔ درگاه برای … است.» یک قاعده تصمیم می‌گیرد رکوردهای یک جدول از آنِ چه کسی است. آن یکی را خاموش کنید، یا به‌جای افزودن دومی همان را ویرایش کنید.
بازدیدکننده اصلاً چیزی نم یبیند. بررسی کنید که عضو یک مشتری باشد، و فیلدی که در شرط آمده همان فیلدی باشد که واقعاً مشتری را نگه می‌دارد — شرطی که فیلد اشتباهی را مقایسه کند عمداً با هیچ رکوردی مطابقت نمی‌کند، نه با همه.
درگاه با این جدول در فهرستش ذخیره نمی‌شود. درگاه روی هر کسی تنظیم شده است. جدولی که رکوردهایش از آنِ بازدیدکنندهٔ واردشده است، درگاهی می‌خواهد که بازدیدکننده‌اش وارد شده باشد.