כלי משתמשים

שלושה כלים נוגעים בזהות: אחד אומר מי אני, אחד אומר מי קיים, ואחד יוצר או מעדכן.

שיוך מושב רישוי אינו כאן — וזו טעות שעולה יום עבודה

Create-or-Update-User יוצר משתמש. הוא אינו נותן לו רישיון ואינו נותן לו תפקיד.

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

הכלים לשני השלבים האחרים — Get-Packages, Set-Package-for-User, Get-Roles, Add-Users-to-Role — נמצאים בחבילת ההרשאות והחבילות, לא כאן. ראו אינדקס הכלים.

Get-Current-User

בלי פרמטרים. מיועד להחזיר את פרטי הזהות שמאחורי החיבור הנוכחי — objectId, username (= האימייל), name, phone, status ומזהה האפליקציה — בהתחברות משתמש (OAuth) זו רשומת המשתמש; בחיבור Master / API Key זו רשומה סינתטית בשם Master (ראו למטה).

זהו הכלי שממנו לוקחים את ה‑objectId בשני מצבים נפוצים:

1. בניית Pointer ל‑_User — כשכותבים OwnerId או כל שדה אחראי:

JSON

{ "table": "Tasks",
  "data": { "Name": "מעקב",
            "OwnerId": { "__type": "Pointer", "className": "_User", "objectId": "2b0QVKoigE" } } }

2. הקשרי currentUser — במקומות שבהם המערכת מקבלת את המילה "currentUser" במקום מזהה (תנאי טריגר, ערך סטטי בפעולת טריגר, כלל טופס). כשצריך לדעת מי זה יהיה בפועל — שואלים את הכלי הזה.

בחיבור Master / API Key חוזרת זהות סינתטית Master — לא משתמש CRM (mcp-data-04, השתנה 23.08.2026)

כשמתחברים עם Application Id + API Key (או Master Key), אין משתמש CRM מאחורי החיבור. עד הצהריים של 23.08.2026 הכלי החזיר Error: User name not found (HTTP 200); מאז עדכון השרת באותו יום (אומת מול tools/list מ‑19:13 שעון ישראל) הוא מחזיר רשומה סינתטית:

JSON

{ "objectId": "Master", "username": "Master", "name": "User name not found",
  "appId": "<Application Id>", "email": "<אימייל ה‑owner של המערכת>" }

שימו לב: ה‑objectId הוא המחרוזת Master (לא מזהה בן 10 תווים של _User), ו‑name נושא את טקסט השגיאה הישן — שריד קוסמטי. Get-all-Users באותו חיבור עובד כרגיל. המשמעות לא השתנתה: אי אפשר לגזור “מי אני” מחיבור מסוג זה לצורך שיוך בעלות — אל תשתמשו ב‑objectId: "Master" כ‑Pointer ל‑_User. אם הסוכן צריך לזקוף פעולות לאדם מסוים, יש להעביר לו את ה‑objectId שלו במפורש (או לאתר אותו ב‑Get-all-Users לפי username), או להתחבר בהתחברות משתמש. ראו שתי דרכי החיבור. אותה סיבה עומדת מאחורי currentUser בטריגרים שרצים מ‑MCP (mcp-a-02).

Get-all-Users

בלי פרמטרים. מחזיר את רשימת המשתמשים במערכת, ולכל אחד:

השדה	המשמעות
objectId	המזהה — זה מה שמשתמשים בו ב‑Pointer, בשיוך תפקיד ובשיוך חבילה
username	מזהה ההתחברות. תמיד כתובת אימייל
email	האימייל
name	שם התצוגה (בעברית)
active	false = חסום מהתחברות
job	תפקיד בארגון (טקסט חופשי — לא התפקיד ההרשאתי)
phone / extension	טלפון ושלוחה
status	מצב הנוכחות של המשתמש (Pointer ל‑UserStatuses)
profile_image	תמונת פרופיל
last_success_login	ההתחברות המוצלחת האחרונה
emailVerified, createdBy, updatedBy, createdAt, updatedAt	שדות המערכת הרגילים

שדות ריקים פשוט חסרים ברשומה (למשל active או job שלא נקבעו מעולם).

מגבלה ידועה — התשובה כוללת שדות פנימיים של מנגנון הסיסמאות (mcp-a-05)

לצד שדות הפרופיל, הכלי מחזיר לכל משתמש גם ACL, _failed_login_count, _account_lockout_expires_at (כשקיים) ו‑_password_history — מערך של hash‑ים (bcrypt) של סיסמאות קודמות. אל תעבירו את התשובה הגולמית הלאה (לתמלול, ליומן, לכרטיס משימה); סננו לשדות שאתם צריכים.

מגבלה ידועה — מוגבל ל‑100 המשתמשים הראשונים (mcp-data-05)

הכלי מחזיר את 100 המשתמשים הראשונים בלבד, בלי עימוד ובלי חיפוש (נמדד: 106 משתמשים במערכת ⇒ 100 בתשובה, בלי nextCursor, בלי total, בלי שגיאה). בארגון גדול מזה, משתמש שאתם מחפשים פשוט לא יופיע — ובלי שגיאה.

בארגון עם יותר מ‑100 משתמשים: חיפוש דרך /parse/users ב‑REST עם where ו‑regex. בסוכן — אל תסיקו “המשתמש לא קיים” מהיעדרו ברשימה; זו מסקנה שגויה שגררה כבר יבוא נתונים שלם עם בעלים שגויים.

last_success_login הוא גם כלי אבחון: “המשתמש לא מצליח להתחבר” נפתר לרוב באחד מארבעה — active: false (ההתחברות נדחית עם User is not active.), emailVerified: false (User email is not verified.), חבילה שפג תוקפה, או נעילה זמנית אחרי כמה כישלונות רצופים (Your account is locked due to multiple failed login attempts. Please try again after 30 minute(s)). השדות _failed_login_count ו‑_account_lockout_expires_at נראים ברשומה — נבדק: המונה עולה בכל כישלון, ואחרי הנעילה גם הסיסמה הנכונה נדחית עד לפקיעת הנעילה.

Create-or-Update-User

יוצר משתמש חדש, או מעדכן קיים. נוכחות objectId היא מה שמבדיל בין שני המצבים.

הפרמטר	טיפוס	מתי	המשמעות
objectId	String	לעדכון	מזהה משתמש קיים. נוכח ⇒ עדכון; נעדר ⇒ יצירה
username	String	ליצירה	מזהה ההתחברות — חייב להיות האימייל
password	String	ליצירה	ראו מדיניות למטה
name	String		שם תצוגה. עברית תקינה
job	String		תפקיד בארגון (טקסט)
phone	String		טלפון
extension	String		שלוחה
active	Boolean		false = חסום מהתחברות
emailVerified	Boolean		ברירת מחדל true (אומת). false חוסם התחברות: User email is not verified.
isPortalUser	Boolean	ליצירה	הנחיית יצירה — לא שדה שנשמר על הרשומה. ראו ההסבר למטה

אין שדות חובה בסכימה — ויש חובה בפועל

הסכימה החיה לא מסמנת אף פרמטר כחובה. בפועל: יצירה דורשת username + password — בלעדיהם Error: Username and password are required — ועדכון דורש objectId (מזהה שאינו קיים ⇒ Error: Object not found.). username חייב להיות כתובת אימייל תקינה (Error: Email address format is invalid.), ויחיד (Error: Account already exists for this username.). האחריות על הקורא.

JSON

// יצירה
{ "username": "dana@example.co.il", "password": "Kayitz2026",
  "name": "דנה לוי", "job": "נציגת מכירות",
  "phone": "0501234567", "active": true }

// עדכון — רק מה שמשתנה
{ "objectId": "6uWdJUouOg", "phone": "0509876543", "job": "מנהלת מכירות" }

ערכי החזרה (אומתו): ביצירה — objectId, createdAt ו‑sessionToken; בעדכון — objectId ו‑updatedAt. המשתמש החדש מתחבר מיד (POST /login ⇒ 200), ו‑username נשמר גם ב‑email.

ה‑sessionToken שחוזר ביצירה הוא אישור התחברות

הוא מאפשר לפעול בשם המשתמש שנוצר. אל תרשמו אותו ליומן, לתשובת סוכן או לכרטיס משימה. אם אין לכם שימוש מיידי בו — התעלמו ממנו.

מדיניות הסיסמאות — נאכפת בשרת

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

Password must be at least 8 characters long
Password must contain at least one uppercase letter, one lowercase letter, and one number

הביטוי הרגולרי שבתיאור הסכימה שגוי

תיאור הפרמטר בסכימה החיה מציג (?=.*d)(?=.*[a-z])(?=.*[A-Z]).{8,}. שימו לב ל‑(?=.*d) — חסר לוכסן הפוך; כפי שנכתב, זה דורש את האות d. הכוונה היא (?=.*\d) — ספרה, וכך השרת אכן בודק (נבדק: Abcdefgh — עם האות d, בלי ספרה — נדחה). אל תעתיקו את הביטוי מהתיאור לוולידציה בצד שלכם.

איפוס סיסמה בידי מנהל = עדכון עם password חדש (אומת: ההתחברות עם הסיסמה החדשה עובדת מיד, והישנה נכנסת ל‑_password_history). איפוס ביוזמת המשתמש הוא זרימה אחרת לגמרי, ב‑REST.

מנטרלים משתמש — לא מוחקים אותו

אין כלי למחיקת משתמש, וזה מכוון

משתמש הוא היעד של מאות Pointers: בעלות על לקוחות, על מכירות ועל משימות, שורות ב‑_Timeline, createdBy על כל רשומה שיצר. מחיקה קשה הייתה מייתמת את כולם.

הדפוס הנכון:

JSON

{ "objectId": "6uWdJUouOg", "active": false }

זה חוסם התחברות ({"code":101,"error":"User is not active."}) ושומר על שלמות ההיסטוריה. החזרה לעבודה — active: true. את המושב עצמו משחררים בנפרד, עם Set-Package-for-User ופעולת remove, אחרת הרישיון ממשיך להיתפס.

isPortalUser

true מסמן משתמש חיצוני — לקוח שנכנס לפורטל השירות העצמי, סטודנט שצופה בציונים שלו.

הפרמטר הוא הנחיית יצירה, לא שדה שנשמר על רשומת המשתמש (הבהרת צוות הפלטפורמה, 26.08.2026). תפקידו: לקבוע האם ליצור את המשתמש — האימייל והחיבור לטננט — גם במערכת הראשית. משתמש פורטל (isPortalUser: true) אינו נוצר במערכת הראשית, ומכאן שתי ההשלכות:

• חיוב — משתמש פורטל אינו נספר לצורכי חיוב, ואי אפשר לשייך לו חבילת רכש (Set-Package-for-User).
• התחברות — הוא אינו מתחבר במסלול ההתחברות הראשי של המערכת; הכניסה שלו היא דרך הפורטל בלבד.

לכן אל תצפו למצוא מפתח isPortalUser ברשומת ה‑_User — היעדרו אינו באג, אלא ההתנהגות המתוכננת.

היסטוריה — עד 26.08.2026 תואר כאן כמגבלה ידועה (mcp-a-03, נסגר by-design)

הדוח mcp-a-03 תיעד ש“הכלי משמיט את הפרמטר בשקט” והמליץ לכתוב את הדגל ישירות ב‑REST (PUT /parse/classes/_User/<objectId> עם Master Key). לאחר הבהרת צוות הפלטפורמה הדוח נסגר כ‑by-design: הפרמטר אינו אמור להישמר על הרשומה. כתיבה ישירה של שדה isPortalUser על _User ב‑REST אמנם נשמרת טכנית, אבל אינה מקנה למשתמש קיים מעמד של משתמש פורטל במערכת הראשית — אל תסתמכו עליה.

מה שלא משתנה: הוא עדיין צריך תפקיד ו‑CLP מתאימים כדי לראות משהו. פורטל בלי תכנון הרשאות הוא פורטל ריק — או, גרוע יותר, פורטל שמראה יותר מדי.

שימו לב: ההגבלה “אינו מתחבר במסלול הראשי” נוגעת למסלול ההתחברות של המערכת הראשית (הממשק). ‏POST /parse/login של ה‑API בטננט הנפיק sessionToken גם למשתמש שנוצר עם isPortalUser: true (נבדק 25.08.2026); מנגנון ההתחברות של הפורטל הספציפי נמצא מחוץ לטווח של עמוד זה — אל תבטיחו זרימת התחברות ללקוח בלי לאמת מול הפורטל שלו.

תהליך קליטת עובד — שלושת השלבים

1. Create-or-Update-User { name, username: <email>, password, job, phone, 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] }

שלב 1 כאן; שלבים 2 ו‑3 בחבילת ההרשאות. בלי שלב 2 אין התחברות. בלי שלב 3 אין מה לראות.

עזיבה — בסדר ההפוך: active: false, הסרה מתפקידים, ואז שחרור המושב.

ומשתמש שאין לו רישיון בכלל? במערכת ללא חבילה (Get-Packages ⇒ "packages": []) משתמשים חדשים נוצרים ומתחברים ב‑POST /parse/login כרגיל (ראו core-api-13) — המושב אינו נאכף בשכבת ה‑API; ההתחברות לממשק עצמו לא נבדקה כאן.

המשך

• אינדקס הכלים המלא
• סוכן במצב קריאה בלבד — למה Create-or-Update-User הוא כלי משנה מסוכן במיוחד
• משתמשים וסשנים ב‑REST — חיפוש מעבר ל‑100, איפוס סיסמה, /users/me
• אימות והרשאות