סקילים — ישויות ושדות

חמישה סקילים על שכבת הנתונים: מה קיים בבסיס הנתונים, איך שדה נראה בטופס, ואיך שדה אחד משפיע על שני. בשלושה מהם שם השדה הוא ההגדרה.

בקשה אחת (“תקים לי מודול ניהול ספקים”) הופכת לחבילה שלמה:

מודול חדש
├── שכבת נתונים
│   ├── טבלה ראשית (Suppliers)
│   ├── טבלת סטטוסים (SupplierStatuses) עם Name + Color
│   ├── טבלאות בנות (SupplierOrders) עם Pointer חזרה
│   └── CLP מבוסס-תפקידים על כל טבלה חדשה
├── שכבת ממשק
│   ├── דף כרטיס (apps/mybusiness/Supplier — יחיד)
│   ├── דף רשימה (apps/mybusiness/Suppliers — רבים)
│   └── פריט תפריט עם אייקון
├── שכבת התנהגות
│   └── קובץ JS חיצוני שמוזרם ל-S3 ומחובר לדף
└── נתוני דמה
    └── סטטוסים עם צבעים + רשומות לדוגמה

ערכת הסטטוסים הדיפולטיבית: פעיל #28a745 · ממתין לאישור #ffc107 · מושהה #dc3545 · לא פעיל #6c757d.

1. הרשאות מבוססות‑תפקידים, לא *. CLP עם {"*": true} עובר את שכבת ה‑API (קריאה אנונימית ב‑REST מצליחה), אבל ה‑front-end בודק חברות בתפקיד והמשתמש רואה “אין הרשאות”. טבלה שנוצרת ב‑Create-Table נולדת עם CLP ברירת מחדל שאינו מבוסס תפקידי CRM: find/get ל‑requiresAuthentication, create/update/delete ל‑role:Admin בלבד (CLP ריק לגמרי נוצר רק ב‑POST /parse/schemas גולמי). Set-Table-Permissions היא קריאה חובה על כל טבלה חדשה:

{
  "find":     { "role:CRM": true, "role:Admin": true, "role:Support": true },
  "get":      { "role:CRM": true, "role:Admin": true, "role:Support": true },
  "create":   { "role:CRM": true, "role:Admin": true, "role:Support": true },
  "update":   { "role:CRM": true, "role:Admin": true, "role:Support": true },
  "delete":   { "role:CRM": true, "role:Admin": true, "role:Support": true },
  "addField": {}
}

הסכימה דורשת את כל שש המפתחות — create, delete, update, find, get, addField. השמטת מפתח פעולה נדחית בוולידציה (addField: expected object); הדריסה השקטה היא בתוך פעולה, כשתפקיד שלא נכלל ב‑find שנשלח מאבד את ההרשאה בלי שגיאה.

2. עמודת Pointer שמציגה מחרוזת היא type: "String". ה‑type של עמודה הוא הטיפוס של הערך המוצג, לא של הקשר:

// ✓ נכון — מציג את שם הלקוח דרך Pointer
{
  "field": "AccountId.Name",
  "type": "String",
  "aggrField": "AccountId.Accounts.Name",
  "inlineOptions": { "type": "autocomplete", "required": false, "readonly": false }
}

// ✗ שגוי — הטבלה לא תרנדר שורות
{ "field": "AccountId.Name", "type": "Pointer" }

השגיאה בקונסול: Cannot create property 'Name' on string.

inlineOptions: autocomplete ל‑Pointer שמצביע לטבלה גדולה (Accounts, _User), select ל‑lookup קטן (סטטוסים, סוגים).

הקישור בין הרשימה לכרטיס נעשה ב‑Edit-Table-View:

"editView": {
  "openFrom": "modal-left",
  "useIframe": true,
  "page": "apps/mybusiness/Supplier",
  "popupWidthPercent": 45
}

Create-Form-Page מייצר תמיד דף על בסיס NewMaster, ואין כלי MCP או API לשנות masterPageId של דף קיים: הדפים יושבים באוסף פרטי של Simbla, לא במחלקות Parse. לכן הכרטיס עובד בתוך iframe אבל מציג שדות ריקים כשפותחים אותו ישירות לפי URL — NewMaster לא נופל חזרה לפרמטרים מה‑URL.

שדה שמאחסן מערך של מזהי Pointer ונרנדר כ‑multi-pick של Select2, בלי שורת JavaScript. הפלטפורמה מזהה זאת משם השדה:

1. Get-Schema(className: "<HostTable>")     — הטבלה קיימת? אין התנגשות שם?
2. Create-Table + Create-Many               — טבלת ה-lookup, עם 2-3 ערכים לפחות
3. Add-Field-to-Table                       — השדה עצמו
4. הצבה על דף הטופס                          — כאן יש פער, ראו למטה
5. אימות                                    — Get-Data על הרשומה

Add-Field-to-Table({
  "table": "Accounts",
  "fields": [{
    "name": "array_sector_Pointer_AccountTypes",
    "type": "Array",
    "label": "סקטור בחירה מרובה"
  }]
})

הטיפוס חייב להיות Array, לא Pointer ולא String. ההצבה על הדף — עם targetClass:

Edit-Page({ "pageId": "<formPageId>", "actions": [
  { "actionType": "add-new-field", "fieldName": "array_sector_Pointer_AccountTypes",
    "label": "סקטור בחירה מרובה", "fieldType": "Array", "targetClass": "AccountTypes",
    "toExistingRow": "P272", "toExistingColumn": 0 }
]})

הפלט:

<select class="select-pointer form-control" multiple
        id="array_sector_Pointer_AccountTypes"
        name="array_sector_Pointer_AccountTypes"
        targetclass="AccountTypes"
        data-subclass-pointers="[…]"></select>

בזמן ריצה ה‑<select> מאותחל כ‑Select2 מרובה‑בחירה. התווית יושבת ב‑<label> שלצד השדה; ה‑<select> אינו נושא data-dictionary.

תמיד containedIn, אף פעם לא equalTo:

{ "F": "array_tags_Pointer_Tags",
  "C": "containedIn",
  "V": ["zY2p6jpXqm", "io3Z6YsMcG"],
  "T": "Array" }

להצגת השמות המחוברים בעמודת דוח — נקודות: array_tags_Pointer_Tags.Tags.Name.

• קידומת או מפריד שגויים נכשלים: Array_AccountTypes, array_sector_AccountTypes (חסר _Pointer_), array_sector_pointer_AccountTypes (p קטנה). Pointer תלוי רישיות.
• רישיות של טבלת היעד — array_x_Pointer_accounttypes לא ייפתר.
• type: "Pointer" במקום "Array" — השדה יאחסן ערך יחיד; ה‑multi-pick ייראה עובד, אבל רק הבחירה האחרונה תישמר.
• טבלת lookup ריקה — הדרופ‑דאון יציג “אין אפשרויות”.
• שינוי שם של שדה מערך אחרי שנשמרו נתונים — הערכים מתייתמים; Parse שומר אותם תחת השם הישן. העבירו נתונים לפני שינוי שם.
• מערכים מבוססי _Dictionary (הסגנון הישן, Sector_By_V) הם מנגנון אחר, לא מכוסה כאן.

דרופ‑דאון שמציג רק את הערכים ששייכים לבחירה בשדה אחר על אותו טופס. מנגנון ילידי, בלי JavaScript ובלי חוקי טופס.

שלושה שמות, מנגנון אחד:

// 1. טבלת הבן, עם Pointer חזרה לאב
Create-Table({
  "name": "SalesSubDepartments",
  "fields": [{ "name": "SalesDepartmentId", "type": "Pointer",
               "targetClass": "SalesDepartments", "label": "מחלקה" }]
})

// 2. תיוג כל רשומת בן — Pointer יחיד, לא Array
Create-Many({ "table": "SalesSubDepartments", "data": [
  { "Name": "B2B-Enterprise", "SalesDepartmentId": {
      "__type": "Pointer", "className": "SalesDepartments", "objectId": "L07ZV34Mqu" } }
]})

// 3. שני שדות על טבלת המארח (הטופס)
Add-Field-to-Table({ "table": "Sales", "fields": [
  { "name": "DepartmentId",    "type": "Pointer", "targetClass": "SalesDepartments",    "label": "מחלקה" },
  { "name": "SubDepartmentId", "type": "Pointer", "targetClass": "SalesSubDepartments", "label": "תת-מחלקה" }
]})

// 4. האב על הדף — Pointer רגיל
Edit-Page({ "pageId": "<formPageId>", "actions": [
  { "actionType": "add-new-field", "fieldName": "DepartmentId", "fieldType": "Pointer",
    "targetClass": "SalesDepartments", "toExistingRow": "P272", "toExistingColumn": 0 }
]})

// 5. הבן על הדף — עם המילה הקסומה
Edit-Page({ "pageId": "<formPageId>", "actions": [
  { "actionType": "add-new-field", "fieldName": "SubDepartmentId", "fieldType": "Pointer",
    "targetClass": "SalesSubDepartments",
    "subclassDepend": "SalesDepartments",
    "toExistingRow": "P272", "toExistingColumn": 1 }
]})

• Array של Pointers לאב — הסינון עובד בסמנטיקת שוויון על Pointer יחיד. חפיפה (ערך בן תחת כמה אבות) אינה נתמכת: שכפלו את השורה, אחת לכל אב.
• subclassDepend חסר ב‑add-new-field — הקריאה מחזירה success בשני המקרים; ההבדל מתגלה בזמן ריצה.
• בן לא מתויג (ה‑Pointer לאב ריק) — לא יופיע תחת שום אב.
• שני שדות Pointer על הטופס לאותה טבלת אב — הפלטפורמה לא יודעת מי מניע את הסינון.
• סינון עם חוק טופס — חוקי טופס לא מסננים אפשרויות של Pointer. הפעולות היחידות: readonly, required, hidden, fixed-value, dynamic-value, formula-value, show-message, value-from-url. ראו אוטומציה.

// א. שכבת הנתונים — הסינון מוגדר נכון?
Get-Data({
  "table": "SalesSubDepartments",
  "keys": ["Name", "SalesDepartmentId"],
  "where": { "SalesDepartmentId": {
      "__type": "Pointer", "className": "SalesDepartments", "objectId": "<parentId>" } }
})

// ב. ה-HTML — הקישור על הדף?
Get-Page-Content(pageId, minimal: false)  →  חפשו data-subclass-depend="SalesDepartments"

שדה Date שמתעד אוטומטית מתי שדה אחר נקבע או השתנה. שלושה כלים:

// 1. השדה
Add-Field-to-Table({ "table": "Sales",
  "fields": [{ "name": "OwnerIdSetDate", "type": "Date", "label": "תאריך שיוך אחראי" }] })

// 2. הטריגר — מתי
Set-Trigger({
  "tableName": "Sales", "type": "data change", "active": true,
  "name": "תיעוד תאריך שיוך אחראי",
  "events": ["create", "update"],
  "oneachupdate": true,
  "onSetFields": ["OwnerId"]
})

// 3. הפעולה — מה
Set-Trigger-Action({
  "tableName": "Sales", "triggerId": "<id>", "triggerType": "data change",
  "actionType": "update-object",
  "actionData": { "update-object": {
    "targetClass": "Sales",
    "connection": "current.objectId",
    "fieldsValue": [{ "field": "OwnerIdSetDate", "type": "dynamic",
                      "value": "updatedAt", "visibleVal": "updatedAt" }]
  }}
})

שדות Date מקבלים רק ערכים מסוג dynamic; updatedAt נותן את הרגע הנוכחי.

חותמת מותנית — רק כשהסטטוס הופך ל“הושלם”:

"criterias": [{
  "F": "SaleStatusId", "C": "equalTo", "V": "<objectId>", "T": "Pointer",
  "P": { "targetClass": "SaleStatuses", "visibleVal": "הושלם" }
}]

חותמת על רשומה קשורה — "connection": "source.AccountId" מעדכן את הלקוח המקושר.

כמה שדות — טריגר נפרד לכל שדה. טריגר יחיד עם כמה onSetFields יורה על כל אחד מהם אבל כותב לשדה אחד, ולכן עובד רק כ“תאריך שינוי אחרון” גנרי.

טריגרים יורים גם מכתיבות API ו‑Master Key, ולכן בדיקה דרך Update-Data היא בדיקה תקפה:

Update-Data → שינוי השדה המנוטר
Get-Data(table, objectId, keys: ["OwnerIdSetDate", "updatedAt"])

ריק? Get-Data(table: "_syslogTriggers", order: "-createdAt", limit: 3, keys: ["triggerId", "actionId", "error", "event"]) — שורה לכל פעולה, עם error (אין שדה triggerName; where ב‑MCP דורש מפתח fieldName).

• דפים וממשק — מה שקורה אחרי שהנתונים קיימים
• אוטומציה — הטריגרים שעליהם נשען myb-p-timestamp-field
• כלי סכימה ב‑MCP — Get-Schema, Create-Table, Add-Field-to-Table
• מודל הנתונים ומוסכמות

ציר הזמן ותיעוד השינויים ברשומה, משני הצדדים: אילו טבלאות כותבות יצירה, עדכון ומחיקה ל‑_Timeline (Get-Timeline-Settings / Set-Timeline-Settings), והאם מישהו רואה את זה — חיבור דף ה‑Timeline המשותף והפיד בכרטיס.

• התיעוד מופעל לכל טבלה בנפרד: רק 11 טבלאות מגיעות עם תיעוד פעיל, וטבלה מותאמת אינה מתועדת עד שמפעילים.
• Set-Timeline-Settings מחליף את כל ההגדרה ולא ממזג — קוראים קודם ושולחים את המפה המלאה.
• הגדרה תקינה לבדה לא מספיקה: בלי חיבור התצוגה בדף, הפיד בכרטיס ריק.

טריגרים: “להפעיל ציר זמן לטבלה”, “ציר הזמן ריק”, “מי שינה את הרשומה”, “audit trail”.