סמי גינדיק | BIM Professional Services Manager
30.08.26
מבוא
ניהול נכון של ההרשאות Permissions הוא קריטי לעבודה רציפה בכל פרויקט. מטרת טיפ זה היא להבהיר ולפרט את אפשרויות ניהול הרשאות בפרויקט.
בשלב זה נדון בהרשאות תחת Forma Data Management (Docs)
יסודות
Project Administrators – מנהלי פרויקט: בעלי הרשאה הגבוהה ביותר בפרויקט
Companies & Roles-חברות ובעלי תפקידים: ניתן ומומלץ לנהל הרשאות ברמת החברות או בעלי התפקידים ולא ברמת ה Project Members
Project Members – חברי פרויקט: שאינם מנהלי פרויקט, יקבלו הרשאה סלקטיבית
Folders- תיקיות: מנהלי פרויקט ובעלי הרשאת Manage יכולים לתת הרשאות לתיקיה
Packages – קבוצת קבצים: מנהלי פרויקט יכולים לתת הרשאה ל Members ליצור ולנהל Packages
Issues – סוגיות ומשימות: הרשאות מתנהלות במנגנון עצמאי
Reviews – תהליכי אישור: הרשאות מתנהלות במנגנון עצמאי
Project Administrators
• מנהלי פרויקט הם בעלי הרשאה:
להוסיף ולהסיר Members
לשייך ל Members Company, Roles
להגדיר רמת גישה לפרויקט: Project Administrator או Member
• מנהלי פרויקט יכולים:
לערוך את הגדרות הפרויקט
להגדיר Email Notifications
להגדיר Locations
מומלץ שיהיה יותר מ Project Administrator אחד על מנת לחלק את האחריות, יחד עם זאת אם הוספתם מישהו כ-Project Administrator לצרכי לווי או תמיכה לתקופה מוגבלת, תשימו לכם תזכורת להסיר אותו.
Roles
הגדרת Roles (בעלי התפקידים) מתבצעת ברמת ה-Hub על ידי ה-Hub Admin
עם הגדרת Role נקבע גם Default access level. האפשרויות הן:
• Project Administrator
• Project Member
בדוגמה מטה, ניתן לראות שמוגדר Role בשם BIM Manager
כל Member שיקבל את ה Role BIM Manager יקבל גישה לפרויקט כ-Project Administrator **
** הערה: אם יסירו מה-Member את ה-Role שמקנה לו Project Administrator הוא עשוי לחזור להיות Project Member.
המלצה: אם מסירים Role מאחד ה-Members בפרויקט וודאו כי Access Level שקיבל מתאים לתפקיד.
הרשאות ברמת תיקייה
זהו מנגנון האבטחה המרכזי של המערכת. באמצעותו ניתן:
• להגביל גישה לתיקיות מסוימות
• להעניק גישה מבוקרת למידע
• להפריד בין דיסציפלינות שונות
המלצות:
• להחיל הרשאה מינימלית ברמת התיקיה העליונה ( Project Files ) וככל שיורדים ברמת התיקיות לתת הרשאה גבוהה יותר לפי הצורך
• לתת הרשאות לתיקיה על פי ה Roles או Companies ולא על פי ה-Members בצורה זו מנהל הפרויקט יכול להוסיף Member לפרויקט, לשייך לו Role וכך הוא יקבל את על ההרשאות המתאימות
גישה לקבצים
הרשאות מתנהלות ברמת התיקייה ולא ברמת הקבצים. הרשאות לתיקיות לפי הפרוט הבא:
הרשאות ל-Issues
מנגנון האבטחה עבור Issues מבוסס Roles כברירת מחדל.
אם ל-Member לא משויך Role, הוא יקבל הרשאה מינימלית
רמות ההרשאה עבור Issues:
המלצה: אל תתנו הרשאות ל-Issues ברמת ה-Member. זה יקשה עליכם לנהל את ההרשאות
מי יכול לראות Issues?
• מי שפתח את ה-Issue
• מי שהוקצה לו Issue (Assign to)
• מי שמופיע כצופה (Watcher)
הערה: אם מי שפתח את ה Issue מעביר אותו מ-Publish ל-Unpublish רק הוא יראה את ה-Issue
זה אומר שגם Project Admin לא יראה את ה-Issue (אלא אם הוא זה שפתח אותו או הוקצה אליו)
הרשאות ל-Reviews
על מנת לפתוח Review (תהליך אישור) נדרש לבחור Workflow (Review Template)
רק בעלי הרשאה של Project Admin יכולים ליצור ולערוך Workflows
מי רשאי לפתוח Review על בסיס Workflow מסוים?
רק Member שמופיע כ-Initiator. ה-Member יכול להופיע ישירות או כחלק מ-Role או כחלק מ-Company
לדוגמה: אני מגדיר שה-Review יכול להיפתח על ידי בעלי Role בשם Engineer
בפרויקט זה יש 3 Members שיכולים לפצוח תהליך אישור זה (גם Project Admin יכול)
תהליך האישור מורכב מכמה שלבים, לפי המוגדר ב Workflow כאשר בכל שלב של Review יש Reviewers
בדוגמה מטה בשלב הראשון (Initial Review) יש מספר Reviewers ובשלב הבא (Final Review) יש אחד
ההרשאות בכל שלב, לפי התפקיד ב-Review מפורטות בקישור
אם יש לכם שאלות בנושא אתם מוזמנים לפנות אליי
סמי גינדיק
[email protected]
