היררכיה של הרשאות, עם אפשרות להרחבה ע"י משתמשים
שלום לכולם,
אני מנסה לבנות אתר בעל מבנה נתונים מסויים בדרופל 6. ניסיתי כמה מודולים של הרשאות שמצאתי ברשת, אבל אם השתמשתי בהם נכון הם לא מאפשרים בדיוק מה שחיפשתי, או מסורבלים מדי. אז הנה מבנה הנתונים שאני מחפש, בתקווה שמישהו יוכל להציע לי איך להתמודד עם הבעיה, עדיף עם מודול שקיים כבר:
נניח שיחידת המידע הבסיסית היא דף שמכיל מדיה מסויימת, למשל סרטון קצר של 10 דקות.
צריך לאפשר להגדיר כמה דפים כסידרה, כך שיווצר סרט מלא.
צריך לאפשר להגדיר כמה סרטים מלאים כנ"ל כסידרה, כך שתיווצר סידרה של סרטים שמטפלים בנושא מסויים.
צריך לאפשר לשייך סדרות של סרטים כנ"ל לבמאי (היחיד) שיצר אותם.
כלומר בכיוון מלמעלה למטה, המבנה הוא של עץ: אוסף במאים, לכל במאי יש אוסף סדרות, כל סדרת מורכבת מאוסף סרטים, כל סרט מורכב מאוסף של דפים שכל אחד מהם מכיל סרטון.
אני צריך משהו שיאפשר לי להגדיר הרשאות כך שלכל במאי תהיה אפשרות להוסיף כמה אברים שהוא רוצה בכל אחת משלוש השכבות של תת-העץ ששייך לו.
אבל במאי לא יוכל להוסיף מידע לתת-העץ של במאי אחר, אלא רק לצפות בתת-העץ של הבמאי האחר (כלומר בסרטונים שלו).
כל המודולים של ההרשאות שהצלחתי למצוא (למשל term_permissions) חייבו שהאדמין יבנה את תת העץ מראש עבור כל במאי, כלומר כל הוספה למשל של סרט לאוסף סרטים, חייבה עבודה של האדמין. הבמאי רק היה יכול להוסיף סרטונים לתת-העץ שקיבל מהאדמין. בנוסף הבמאי היה יכול טכנית להוסיף סרטון לכל שכבה בתת-העץ - לא דווקא לשכבת הסרטים, בעוד שמה שאני רוצה זה שבטופס בניית דף הסרטון הבמאי יהיה מחוייב לבחור אוסף סדרות (או ליצור חדש), ואז לבחור מתוכן אוסף סרטים (או ליצור חדש), ואז לבחור סרט (או ליצור חדש), ורק אז להוסיף סרטון לסרט ספציפי.
כמו כן לגבי ההרשאות, כל המודולים שמצאתי חייבו אותי להגדיר במפורש לכל איבר בתת-העץ של במאי מסויים שהגישת עריכה אליו שייכת רק לבמאי הזה (די הרבה עבודה). בעוד שמה שאני רוצה זה רק להגדיר זאת (ע"י האדמין) לשורש של תת-העץ, כך שהרשאות העריכה ירדו אוטומטית בירושה לאברים היותר נמוכים בתת-העץ.
מקווה שהבנתם :)
תודה מראש.
organic groups ? or if you
organic groups ?
or if you like coding then hook_node_access_records
yakoub abaya
אם הבנתי נכון, אז אולי הדבר
אם הבנתי נכון, אז אולי הדבר הבא יעבוד. עדיף להימנע מצורת מחשבה היררכית ולחשוב יותר אגרגציה.
הערה מקדימה: לא אמרתי האם במאי הוא משתמש במערכת או סוג תוכן. להלן אתייחס כמו היה הבמאי המשתמש עצמו.
א. הגדר את סוגי התוכן הבאים: 'סרט', 'קטעון' (fragment).
ב. בסוג סרט הוסף שדה node reference לסוג קטעון - ריבוי ערכים.
ג. הגדר את התפקיד 'במאי' ותן לו הרשאות יצירה + עריכה של פריטים שהוא יצר לשני סוגי התוכן (סרט וקטעון).
מבחינת תצוגה יש מספר אפשרויות, כאשר אחר מהן היא להציג ספר בתור היבט הכולל את כל הקטעונים הקשורים אליו. פה יהיה צריך קצת להשקיע עוד מחשבה, אבל אם מבנה הנתונים והיחסים נכון, זה מה שחשוב.
אמיר
נ.ב. ממליץ לך לצייר תרשים ישויות.
| פרקטיקול - בונים לך אתר דרופל | עזרה מידית בקבוצה שלנו בפייסבוק! | שיעורי דרופל דרך האינטרנט
תודה. בתשובה לשאלתך, במאי הוא
תודה.
בתשובה לשאלתך, במאי הוא גם קודם כל סוג מסויים של משתמש, אבל גם אמור להיות סוג תוכן שמייצג אותו (נראה לי). למשל משתמש רגיל, יכול להיכנס לדף שמציג ביוגרפיה של הבמאי ואת רשימת סדרות הסרטים של במאי מסויים.
קודם כל נראה לי שצריך גם להגדיר סוג תוכן מסוג "סידרת סרטים"? הרי לפי הגדרת מבנה הנתונים, מספר סרטים מתקבצים לתוך "סידרת סרטים".
לא ברורה לי הנקודה של איך בשלב הגדרת סוג תוכן חדש, אני מגדיר שיהיה לו שדה שהוא reference לקבוצה של סוג תוכן אחר. לא נראה לי שראיתי משהו כזה ב-GUI, אז זה משהו אלמנטרי שאין לי מושג איך לעשות בדרופל.
גם לא ברור לי למה התכוונת ב"מבחינת תצוגה יש מספר אפשרויות, כאשר אחר מהן היא להציג ספר בתור היבט הכולל את כל הקטעונים הקשורים אליו".
מה הכוונה בספר?
להלן תרשים ישויות:
לדעתי אתה מכניס מורכבות שאינה
לדעתי אתה מכניס מורכבות שאינה הכרחית.
כמו שהבנתי ממך, 'סרט' הנו מקבץ של קטעים ('קטעונים' במינוח שלי לעיל). בכל קטעון יהיה לך הטמעה של קובץ המציג חלק מהסרט. סרט יצביע על מספר קטעונים שהם למעשה החלקים המרכיבים את הסרט השלם. האם זה נכון? אם כן, לא צריך 'סדרת סרטים' אלא אם אתה מתכוון, למשל, לקבץ מספר סרטים שלמים כגון לשם טרילוגיה, וכדומה.
לגבי התרשים - מאמץ חביב, אך זה לא תרשים ישויות אלא שרטוט של ההיררכיה שאינה קשורה כלל למבנה הנתונים. אתה ההירכיה עשויה להיות קשורה לאופן התצוגה שהוא נפרד לחלוטין מאופן שמירת הנתונים. נסה את http://yuml.me - העתק לכאן את הסקריפט ואעזור לך לטייב את התרשים :) ואתה לא צריך לצייר את האדמין.
לגבי התצוגה אחר-כך, דיהּ לצרה בשעתהּ. מה שהכי חשוב זה מבנה הנתונים.
| פרקטיקול - בונים לך אתר דרופל | עזרה מידית בקבוצה שלנו בפייסבוק! | שיעורי דרופל דרך האינטרנט
אני לא תכננתי את המודל
אני לא תכננתי את המודל שבשרטוט, אלא לטוב או לרע זו המשימה ולכן לא ניתנת לשינוי. המטרה שלי היא לממש את המודל הזה בלי קשר ליעילות שלו או לקשר שלו למציאות (אני מסכים איתך שהקשר הזה רופף למדי).
המודל בשירטוט בהחלט לא פורמלי לפי הכללים של UML (מבחינת הצורות, סוג הקוים ואיך לבטא קשר 1-->N ודומיו) אבל נראה לי שלכל מי שעבר בחינה פסיכומטרית הוא מובן בצורה אינטואיטיבית. אז הבה נדלג על הדרישה ל UML פורמלי..
מה זאת אומרת לא קשור למבנה הנתונים? כך בדיוק הייתי מצייר אותו ומממש אותו בשפת תכנות. כל class החל מ-Director מכילה pointer לאוסף כלשהו של ה-class שמתחתיה. ה-admin באמת לא זקוק למימוש מפורש, בסה"כ הוספתי אותו כדי להדגיש שיש כמה במאים במערכת, והם מוגדרים ככאלה ע"י האדמין שלוקח משתמשים רשומים מסויימים ומשדרג להם את ה-role ל-director.
אז בגלל שהנקודה הזו ברורה עכשיו אפשר להתקדם הלאה...
בינתיים הבנתי עם מעט עזרה מידידי גוגל איך לממש את הקטע של ה-pointer עם משהו שנקרא node-reference, ואיך לסנן החוצה ע"י view שמופעל על ה-node-reference בנים שלא אני יצרתי.
**** הייתי שמח אם היה אפשר לעשות את ה- pointer דו-כיווני באופן אוטומטי, כלומר אם אני קובע ב-בן מצביע ל-אבא, אז שהמצביע ב-אבא יצרף לעצמו אוטומטית גם את הערך של מצביע ל-בן, האם יש דרך אלגנטית לעשות זאת?. כי אם אני משאיר את שני הכיוונים לקביעה בידי המשתמש (Director) הוא יכול להביא את המערכת למצב לא עקבי.
למה אני צריך שהאבא יציין במפורש מי הבנים שלו בדף הטופס ליצירת אבא? כי אני רוצה שלמורה יהיה ברור מי הבנים כשהוא נכנס לטופס של אבא. זה פשוט עוזר להבין מה המצב הנוכחי של האבא. זה גם מאפשר לעדכן את הקשר משני הכיוונים.