תפקידים, הרשאות טבלה וחבילות

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

מי המשתמש          →  _User                        (הכלים בעמוד המשתמשים)
מה הוא רשאי לעשות   →  _Role  ←  Add-Users-to-Role
מה מותר בטבלה      →  CLP    ←  Set-Table-Permissions, שמפנה ל-role:<שם>
ובמקביל: יש לו רישיון?  →  חבילה  ←  Set-Package-for-User

שלוש ההחלטות אינן נגזרות זו מזו

• משתמש בלי חבילה לא יכול להיכנס ל‑CRM — מסך ההתחברות מחזיר “תקלה בשיוך לאפליקצייה” גם אם יש לו תפקיד. (ב‑REST POST /parse/login כן מנפיק session למשתמש כזה — core-api-13; האכיפה היא בממשק.)
• משתמש בלי תפקיד מתחבר ורואה טבלאות ריקות — כי אף CLP לא מזכיר אותו.
• תפקיד חדש לא מעניק כלום עד ששני דברים קורים: מוסיפים אליו משתמשים, וגם מזכירים אותו ב‑CLP של לפחות טבלה אחת.

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

---

תפקידים

Get-Roles

אין פרמטרים. מחזיר לכל תפקיד: objectId, name, description, color.

התפקידים המערכתיים שמגיעים עם כל מערכת:

התפקיד	הקהל הטיפוסי
Admin	ניהול מלא. מופיע כמעט בכל CLP
CRM	משתמש CRM כללי — הטבלאות המרכזיות
Sales	אנשי מכירות — לקוחות, אנשי קשר, מכירות, משימות, פעילויות
Support	נציגי תמיכה — פניות, משימות, פעילויות
Lead Admin	ניהול לידים
Report Admin	דוחות ואנליטיקה
MyBooks Admin	מודול הנהלת החשבונות
Campaign Manager	מודול הדיוור
MyChatAdmin / MyChatUser	מודול הצ’אט — מנהל / נציג

לצדם יופיעו תפקידים מותאמים שנוצרו אצל הלקוח. (מאומת במערכת vanilla: בדיוק עשרת אלה.)

לעולם לא לשנות שם של תפקיד מערכתי

שם התפקיד הוא המפתח המילולי בכל CLP במערכת ("role:Admin": true). שינוי שם מייתם את כל ההפניות בבת אחת, ואין כלי שינוי שם — במכוון. צריך שם אחר בממשק? זו שכבת המינוח, לא התפקיד. צריך ארגון מחדש אמיתי? יוצרים תפקיד מקביל ומעבירים אליו את ה‑CLP בהדרגה.

Create-Role

הפרמטר	טיפוס	חובה	המשמעות
name	String	✔	שם התפקיד
description	String		תיאור
color	Enum		green · red · yellow · orange · azure · purple

JSON

{ "name": "Field Agents", "description": "נציגי שדה — מכירות ותמיכה", "color": "green" }

מחזיר { objectId, createdAt }. שם קיים נדחה: Error: A duplicate value for a field with unique values was provided.

מתי כדאי תפקיד מותאם: קבוצת גישה חלקית (“Finance לקריאה בלבד”), קיבוץ חוצה מחלקות (“Managers”), או תפקיד ענפי שלא מתמפה לעשרה המערכתיים.

ותזכורת: התפקיד לא עושה כלום עד שהוא נכנס ל‑CLP.

Get-Role-Users

הפרמטר	טיפוס	חובה	המשמעות
roleId	String	✔	ה‑objectId של התפקיד

מחזיר את חברי התפקיד — objectId, name, email, username.

Add-Users-to-Role / Remove-Users-from-Role

הפרמטר	טיפוס	חובה	המשמעות
roleId	String	✔	התפקיד
userIds	Array<String>	✔	מזהי המשתמשים

JSON

{ "roleId": "RGgGEH4iIZ", "userIds": ["6uWdJUouOg", "d56ft3TglJ"] }

מבוססי מערך — קריאה אחת לכל תפקיד, עם כל המשתמשים. הוספת מי שכבר חבר, או הסרת מי שאינו, אינן מזיקות (מאומת). roleId שאינו קיים: Error: Object not found. (ב‑Get-Role-Users — מערך ריק). משתמש יכול להחזיק כמה תפקידים שרוצים.

---

הרשאות טבלה — CLP

Get-Table-Permissions

הפרמטר	טיפוס	חובה	המשמעות
table	String	✔	שם הטבלה

JSON

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

Set-Table-Permissions

הפרמטר	טיפוס	חובה	המשמעות
table	String	✔	שם הטבלה
classLevelPermissions	Object	✔	כל שש הפעולות — ראו מיד

שש מפתחות חובה בכל קריאה — כולל addField

הסכימה החיה מסמנת את כל שישה כ‑required: create, delete, update, find, get, addField. קריאה שמשמיטה מפתח נדחית בולידציה (גם דרך JSON‑RPC גולמי) — שום דבר לא נכתב ושום דבר לא מתאפס. addField הוא זה שהכי נשכח, והוא חייב להיות {} בדיוק — מפתחות בתוכו נדחים (Unrecognized key). ערך false נדחה גם הוא: רק true.

הכלי דורס את כל האובייקט — קוראים לפני שכותבים

אין endpoint של patch. הזרימה היחידה:

1. snapshot = Get-Table-Permissions({ table })
2. modified = עותק של snapshot.classLevelPermissions, עם השינוי שלכם
3. Set-Table-Permissions({ table, classLevelPermissions: modified })
4. Get-Table-Permissions({ table })   ← קריאה חוזרת. לא לסמוך על "OK"

קריאה שנועדה “רק להוסיף את Finance ל‑find” ומכילה רק את find — נדחית; את חמש הפעולות האחרות צריך לשלוח כפי שהן, מה‑snapshot. שימו לב: הקריאה החוזרת מראה את ה‑CLP החדש מיד, אבל האכיפה מתעדכנת באיחור של כמה שניות (מטמון סכימה) — בדיקת הרשאות מיד אחרי הכתיבה עלולה להראות את ההתנהגות הישנה. שמות תפקידים שאינם קיימים (role:NoSuchRole) מתקבלים בלי אזהרה.

תחביר בעל ההרשאה

כל פעולה היא אובייקט של בעל ההרשאה → true:

התבנית	למי זה מעניק
"role:<RoleName>"	כל חברי התפקיד. שם מדויק, רגיש לרישיות ולרווחים: role:Report Admin
"<userObjectId>"	משתמש בודד. מנגנון חריגים — השאירו נדיר
"requiresAuthentication"	כל משתמש מחובר
"*"	ציבורי, כולל אנונימי
{}	אף אחד דרך ה‑API הרגיל. רק Master Key או MCP

הערך הוא תמיד true. אין false — היעדר המפתח הוא ההיעדר.

הפעולה	המשמעות
find	שאילתה ורשימה — הגריד
get	רשומה בודדת לפי מזהה — פתיחת כרטיס. שמרו זהה ל‑find אלא אם יש סיבה מפורשת
create / update / delete	כתיבה
addField	הוספת שדה לסכימה מהלקוח. כמעט תמיד {}

תבניות CLP

התבנית	הצורה
טבלת CRM רגילה	CRM + Admin + Sales + Support בכל חמש הפעולות, addField: {} — הצורה של Accounts (ב‑Cases בלי Sales). זו לא ברירת המחדל של טבלה חדשה — ראו בהמשך
מכירות בלבד	להוריד את role:Support מכל הפעולות
תמיכה בלבד	להוריד את role:Sales
צופה בלבד	התפקיד ב‑find ו‑get בלבד
שיתוף בלי מחיקה	התפקיד בכל הפעולות מלבד delete — מכריח “בוטל” במקום מחיקה
חריג למשתמש בודד	"update": { "role:Support": true, "EkeJaH4t4W": true }
נעילה לאדמין	רק role:Admin בכל הפעולות — טבלאות קונפיגורציה וביקורת
טבלה שרק טריגר כותב אליה	קריאה לתפקידים; create/update/delete כולם {}
כל מי שמחובר	find/get: requiresAuthentication; כתיבה לאדמין
קריאה ציבורית	"*" ב‑find/get — רק לקטלוגים שנחשפים באתר, ובאישור הלקוח

JSON

// צופה פיננסי לקריאה בלבד
{ "table": "Invoices",
  "classLevelPermissions": {
    "find":   { "role:Admin": true, "role:Finance": true },
    "get":    { "role:Admin": true, "role:Finance": true },
    "create": { "role:Admin": true },
    "update": { "role:Admin": true },
    "delete": { "role:Admin": true },
    "addField": {}
  } }

"*" עובר ב‑API ונכשל בממשק

באג פלטפורמה שדווח בעבר: CLP עם {"*": true} מעביר קריאות API (מאומת 2026‑08‑23: שליפה אנונימית בלי session מחזירה שורות), אבל ה‑front‑end של ה‑CRM בודק בנוסף חברות בתפקיד — ומשתמשים מקבלים “אין הרשאות” בדפים שמבוססים על אותה טבלה (החלק הזה לא שוחזר בסביבת הבדיקות: אין בה משתמש נוסף עם חבילה). לכן: תמיד CLP מבוסס תפקידים בטבלאות שמשמשות בממשק. השתמשו בתבנית של Accounts ו‑Cases. ברירות המחדל של טבלה חדשה (מאומת): Create-Table יוצר find/get: requiresAuthentication, create/update/delete: role:Admin — כלומר כולם קוראים, רק Admin כותב; טבלה שנוצרה ב‑REST גולמי נולדת עם CLP ריק ({} בכל הפעולות — אף אחד חוץ מ‑Master). בשני המקרים Set-Table-Permissions הוא הצעד המיידי שאחריה.

CLP הוא ברמת הטבלה — אין הרשאה ברמת שדה

אי אפשר להסתיר שדה בודד מתפקיד מסוים דרך CLP. הפתרונות: דפים נפרדים לקהלים שונים (עם allowedRoles), או סינון ברמת שורה. וחוקי טופס הם לא פתרון לזה: hidden הוא UX, לא הרשאה.

הרשאות ברמת שורה

שכבה נוספת ונפרדת שקובעת אילו רשומות משתמש רואה, מעל ה‑CLP שקובע אילו פעולות מותרות. הסינון הוא לפי שדה Pointer — בדרך כלל OwnerId ל‑_User (“כל נציג רואה רק את העסקאות שלו”) — עם פטור לתפקידים מסוימים. הוא חל בכל מקום: טבלאות, דוחות, דשבורדים, גרפים וחיפוש.

אין לזה כלי MCP — בכלל

ההגדרה נעשית בממשק הניהול בלבד (Tables ← הטבלה ← הרשאות מתקדמות), ואין כלי שקורא או כותב אותה. סוכן שמנתח מערכת לא יראה את השכבה הזו ויכול להסיק מסקנות שגויות על “מי רואה מה”. כשאתם רואים משתמש שלא רואה רשומות שלפי ה‑CLP הוא כן אמור לראות — זו החשודה הראשונה, ובודקים אותה בממשק. ותנאי מקדים: חוק טופס שממלא OwnerId = currentUser (דפוס מוכר), אחרת רשומות עם שדה ריק נופלות בין הכיסאות.

---

חבילות ומושבים

Get-Packages

אין פרמטרים. מחזיר את החבילות שנרכשו ואת שיוך המשתמשים אליהן:

JSON

{
  "packages": [
    { "_id": "69bfd8149cbf3f5ed63463bb",
      "resellerPackageId": "5ae5986c9a2e78001af81715",
      "numberOfUsers": 8,
      "validUntil": "2027-04-05T00:00:00.000Z",
      "resellerPackageIdData": { "name": "Enterprise" } }
  ],
  "users": [
    { "parseId": "2b0QVKoigE", "email": "…", "relatedPackages": ["5ae5986c9a2e78001af81715"] }
  ]
}

השדה	המשמעות
numberOfUsers	תקרת המושבים. קשיחה
validUntil	תוקף. חבילה שפגה היא סיבה מוכרת לכשל התחברות
relatedPackages	לאילו חבילות המשתמש משויך

מושבים פנויים = numberOfUsers − מספר המשתמשים שה-relatedPackages שלהם כולל את המזהה הזה. ספרו לפני onboarding קבוצתי. בסנדבוקס בלי רישיון packages הוא [] ו‑relatedPackages ריק לכולם.

Set-Package-for-User

הפרמטר	טיפוס	חובה	המשמעות
userId	String	✔	ה‑objectId של Parse של המשתמש
resellerPackageId	String	✔	ראו האזהרה
action	Enum	✔	add · remove

resellerPackageId — ולא _id

לכל חבילה שני מזהים שנראים כמעט אותו דבר, והכלי מקבל דווקא את resellerPackageId:

השדה	מה זה	לכלי הזה
_id	מזהה רכישת החבילה במערכת הזו	✖
resellerPackageId	מזהה החבילה בקטלוג המשווק	✔

זו טעות שקשה לזהות כי שניהם מחרוזות 24 תווים. הדרך לוודא שלקחתם נכון: המזהה שבחרתם צריך להופיע גם ב‑relatedPackages של משתמשים שכבר משויכים לאותה חבילה.

JSON

{ "userId": "2b0QVKoigE", "resellerPackageId": "5ae5986c9a2e78001af81715", "action": "add" }

מעבר בין חבילות: remove מהישנה ואז add לחדשה — הסדר הזה מונע צריכת שני מושבים. כשאין מושב פנוי (או שהחבילה אינה של המערכת) הכלי מחזיר Error: Failed to set package for user … "cannot add more users to package".

---

שלוש הזרימות הסטנדרטיות

קליטת עובד

1. Create-or-Update-User({ name, username: <email>, password, active: true })   → userId
2. Get-Packages  → בוחרים resellerPackageId, מוודאים מושב פנוי
   Set-Package-for-User({ userId, resellerPackageId, action: "add" })
3. Get-Roles     → roleId
   Add-Users-to-Role({ roleId, userIds: [userId] })

יצירת המשתמש עצמה היא Create-or-Update-User. בקליטה קבוצתית: שולפים חבילות ותפקידים פעם אחת, יוצרים משתמשים ברצף, ומאגדים את שלב התפקיד לקריאה אחת לכל תפקיד עם כל המערך.

עזיבת עובד

1. Create-or-Update-User({ objectId, active: false })      חוסמים התחברות — לא מוחקים
2. Remove-Users-from-Role(...) לכל תפקיד                    היגיינה
3. Set-Package-for-User({ userId, resellerPackageId, action: "remove" })   משחררים מושב

אין מחיקת משתמש, וזה נכון. active: false משמר את createdBy, את הבעלות על רשומות ואת ההפניות בציר הזמן; מחיקה קשה הייתה מייתמת מאות Pointers. active: false נאכף גם ב‑REST: {"code":101,"error":"User is not active."} ב‑login.

שינוי תפקיד

Remove-Users-from-Role מהישן, Add-Users-to-Role לחדש, ואימות של שניהם ב‑Get-Role-Users.

צ’קליסט אימות

מה	איך
המשתמש נוצר	מופיע ב‑Get-all-Users
יש לו מושב	Get-Packages → users[].relatedPackages
יש לו תפקיד	Get-Role-Users על התפקיד
ה‑CLP נכון	קריאה חוזרת ב‑Get-Table-Permissions — לא לסמוך על תשובת הכתיבה

מגבלות

• Get-all-Users מוגבל ל‑100 הראשונים (mcp-data-05). בארגון גדול — REST על /users.
• Get-Schema("_Role") מחזיר {} — _Role היא מחלקת מערכת קבועה של Parse.
• אין מחיקת תפקיד ואין שינוי שם.
• הרשאות ברמת שורה אינן נגישות מ‑MCP — ביקורת ידנית בממשק.
• חיבור עם Application Id + API Key עוקף את הכול. הוא פועל כ‑Master ואינו כפוף לאף CLP. גבול הרשאות אמיתי דורש חיבור בהתחברות משתמש — ראו שרת ה‑MCP ו‑סוכן במצב קריאה בלבד — ובמערכת בלי חבילת מנוי החיבור הזה נדחה ב‑403 No permissions to access the MCP server (mcp-b-04).

המשך

• כלי משתמשים — יצירה, עדכון וניטרול משתמש
• כלי סכימה — טבלאות ושדות — הצעד שדורש CLP מיד אחריו
• הגדרות דף, קוד וגרסאות — שער הדף שמעל ה‑CLP
• חוקי טופס — למה hidden אינו הרשאה
• דוחות — role: ו‑editPermissions
• אימות והרשאות · אינדקס הכלים המלא