כלי משתמשים

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

שיוך מושב רישוי אינו כאן

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

כשמתחברים עם Application Id + API Key (או Master Key) אין משתמש CRM מאחורי החיבור, והכלי מחזיר רשומה סינתטית:

JSON

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

ה‑objectId הוא המחרוזת Master ולא מזהה בן 10 תווים של _User, ו‑name נושא את המחרוזת User name not found. Get-all-Users באותו חיבור עובד כרגיל.

אי אפשר לגזור “מי אני” מחיבור מסוג זה לצורך שיוך בעלות; אל תשתמשו ב‑objectId: "Master" כ‑Pointer ל‑_User. סוכן שצריך לזקוף פעולות לאדם מסוים מקבל את ה‑objectId שלו במפורש, מאתר אותו ב‑Get-all-Users לפי username, או מתחבר בהתחברות משתמש. ראו שתי דרכי החיבור.

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 שלא נקבעו מעולם).

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

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

מגבלה ידועה — מוגבל ל‑100 המשתמשים הראשונים

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

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

“המשתמש לא מצליח להתחבר” נפתר לרוב באחד מארבעה: 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 מסמן משתמש חיצוני: לקוח שנכנס לפורטל השירות העצמי, סטודנט שצופה בציונים שלו.

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

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

אל תצפו למצוא מפתח isPortalUser ברשומת ה‑_User. היעדרו הוא ההתנהגות המתוכננת. הוא עדיין צריך תפקיד ו‑CLP מתאימים כדי לראות משהו.

כתיבה ישירה של הדגל ב‑REST אינה מקנה מעמד של משתמש פורטל

כתיבה ישירה של שדה isPortalUser על _User ב‑REST (PUT /parse/classes/_User/<objectId> עם Master Key) נשמרת טכנית, אבל אינה מקנה למשתמש קיים מעמד של משתמש פורטל במערכת הראשית.

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

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

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] }

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

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

המשך

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