הוספה של מיקום האירוע, קישור לשיחת ווידאו, זמנים ביום, קובץ
התאמת הפונקציה גם לעריכת אירוע קיים במידה ומועבר ID של אירוע
כולל שינויים בקוד? אם כן, איפה?
הוספה של עמודות בטבלת “events”
הוספה של פונקציה של יצירת אירוע חדש לקבלת הנתונים והזנתם בDB
הגדרת נתוני חובה ל"אירוע"
בנייה של דף HTML + CSS להזנת הנתונים ע"מ לא לנפח את המשימה אני אשמח אם מישהו ירצה לקחת את החלק של הפרונטאד.
האם יהיו שינויים במסד הנתונים? אם כן, איפה?
הוספת עמודות בטבלת “events”
אילו טסטים יגרמו לטיקט להיחשב כ"עובד", ויאפשרו לנו לסגור את הטיקט ולהגדיר את המשימה כהושלמה?
הזנה של כל הנתונים לטופס
הקפצת הודעת שגיאה במידה ולא מוזן מידע קריטי (יוזר יוצר, יום, שעה/יום מלא, שם אירוע)
בדיקה שניתן לשנות נתונים של אירוע קיים
נראה לי שזה בעצם “יצירת האיוונט” עצמו
זה נראה לי הדבר החשוב ביותר שאם אין אותו היום במערכת אז מן הסתם חייב שיהיה כי הרבה מאוד מההצעות עצמן מהתבססות על “אירוע” \ “פגישה” שכזו בלוז מן הסתם.
אני מציע להוסיף גם:
הגדרת האירוע כ"פרטי" כך למשל לא יהיה מוצג לאנשים אחרים המידע עליו. - הכוונה לא שזה יהיה “פרטי” בקטע של אני באירוע של השכנים. אלא פרטי בקטע שאם זה מוגדר כזה אז רק אני יכול לראות את המידע על האירוע הזה ולא אחרים (במקרים בהם יהיה בעתיד ניתן לשתף לוחות או לראות לוחות של אנשים אחרים)
פיצר של “מועדף” אן פריוריטי - במקרים בהם אני מזומן לשני דברים במקביל. שיהיה נגיד עדיפות (הפיצר הזה יותר רלוונטי למנהלי צוותים נגיד שצריכים להצטרף לפגישות של מי שתחתם. ואז יכול להיות שיש שני פגישות במקביל. במצב כזה אני יכול להגדיר לעצמי שפגישה מסויימת יש לה פריוריטי.
Ode
אני אשמח לעבוד איתך כדי ליצור את ה-front-end ליצירת איוונט
לדעתי אלו צריכים להיות פיצ’רים נפרדים היות והם מבוססים על האופציה לשתף לוחות שנה ויש להם הרבה נפח של אימות משתמשים
לייק 1
aviadamar
אכן ישתמשו בזה בפיצרים האחרים אבל חייב להיות קיים ביצירת האיוונט עצמו.
להגדיר משהו כפרטי למשל זה רק למלא רובריקה. וכבר יכול להיות בפורם עצמו (בפינטרסט למשל יש את זה)
מי שמממש את הדברים האחרים יוכל להשתמש בנתון הזה מתול הדאטאבייס
Ode
אין לי הרבה נסיון, אבל מרגיש לי שלבנות פיצ’רים ללא פונקציונאליות זה לא דבר שכדאי לעשות.
אני חושבת שיותר הגיוני שמי שבונה פיצ’ר של פרטיות אירוע, יוסיף את האלמנט בטופס, יוסיף את השדה ל-ORM וידאג שכל אירוע שכבר קיים, יקבע כ"פרטי" בתור ברירת מחדל. אחרת אנחנו יכולים ליצור אינסוף קלטים חסרי פונקציונליות ומשמעות
2 לייקים
imimouni
הוספתי הצעת פיֵצ׳ר לפרטיות מקווה שיתקבל עכשיו רואה את הטיקט הזה
לייק 1
aviadamar
מעולה עכשיו יהיה לזה שימוש
Ode
הסתכלתי קצת על איך העמודים של google cal בנויים ושמתי לב שבין אם יוצרים, עורכים או משכפלים אירוע, הם מעבירים אותך ל-eventedit. אם עושים עריכה לאיוונט הם משרשרים את מזהה האיוונט לעומת איוונט חדש שבו אין מזהה כלל.
לדעתי כדאי לפעול באותה צורה ולקרוא ל"יצירת איוונט" בפועל eventedit. כשיוצרים איוונט, אם לא מועבר מזהה קיים, המערכת תיצור ישות חדשה של איוונט.
אם כן מועבר מזהה, הוא יעדכן את ישות הקיימת (אולי זה יכול להיות טיקט נוסף, אבל זה יהיה חלק מה-route הזה).
ככה זה בעצם יצמצם לפונקציה אחת טיפול בהוספה וטיפול בעריכה של איוונט, שכנראה גם ככה יהיו פונקציות כמעט זהות, חוץ מהעברה של ערכים לטופס ושמירה של ערכים ל-DB
אם הבנתי נכון בהצעה שם נדב רוצה להוסיף תעדוף לאירוע ולקשר את אותו למשתמש.
אני מדבר על השיכבת בסיס יותר של הוספת נתונים לאירוע, ובניית ממשק ליצירת ועריכת אירועים
מוזמן להסתתכל בשירטוט היפה ש @Ode עשתה בשירשור הזה.
יש שם חפיפה מכיוון ששנינו מדברים על יצירת האירוע אבל אני מבין שאנחנו מכוונים שונה.
עובד על ERD ןMOCK אבל חשבתי שכדי לא לעכב אני אייצר פרונטאנד די בסיס ומי שירצה ישפר את זה ע"פ העיצוב הכללי, מקובל עליך?
Yam
@nadav – תוכל לחדד את מה ההצעה שלך מביאה ואם יש התנגשות בין הטיקטים?
nadav
בעיקרון הרעיון שלי היה לאפשר לאנשים נוספים להשתתף באירוע:
להזמין אנשים לאירוע
משתתפים יכולים להתעלם/לדחות/אולי משתתפים/מגיעים
תוך כדי הרעיון שלאירוע יכול להיות חשיבות - חובה/רשות וכו…
לא יודע להגיד אם יש התנגשות
Yam
בנתיים נשמע שיש התנגשות, אלא אם אני מבין משהו לא נכון. אודה לכם אם תדברו ביניכם ותתאמו מה כל אחד עושה
mbdi007
דיברנו בפרטי וסיכמנו על החלוקה הזאת - אני בונה את היצירה של אירוע חדש כולל דף פרונט בסיס ונדב מרחיב את האירוע הקיים לזימון של עוד אנשים…
עכשיו רואה את הטיקט הזה
