פיצ'ר שכפול אירוע

תיאור כללי

פיצ’ר לשכפול של אירוע(ים)

מה ההצעה כוללת?

כפתור שבלחיצה ישכפל את אירוע שהכפתור מקושר אליו ויפתח חלון עריכה עם פרטי האירוע המשוכפל.
(אני רואה פה גם מקום להתרחב מעבר, אבל אני לא סגורה אם זה אמור להיות טיקט נוסף כבר)

כולל שינויים בקוד? אם כן, איפה?

יהיה צורך ליצור פונקציונאליות שקוראת נתונים של אירוע ויוצרת אירוע חדש לפיהם

האם יהיו שינויים במסד הנתונים? אם כן, איפה?

אין שינוי במבנה, רק הוספה של רשומות

האם יהיה שינוי ב־frontend? אם כן, איפה?

כן, כפתור Duplicate

אילו טסטים יגרמו לטיקט להיחשב כ"עובד", ויאפשרו לנו לסגור את הטיקט ולהגדיר את המשימה כהושלמה?

  • בדיקה כי בעמוד עריכת האירוע, הערכים הדיפולטים שווים לערכי האירוע המקורי
  • בדיקה ששינוי של הפרטים הדיפולטיים נשמרים כמו שצריך
8 לייקים

זה פיצ’ר חשוב, וכשאני חושב על זה שכפול נשמע לי כמו read ו־write.
יש מקרה שבו אנשים ירצו לעשות ממש duplicate של אירוע, כולל התאריך?
אם כן אשמח לשמוע, אם לא נראה לי ששווה אולי לשנות קצת את הטיקט ליצירת endpoint שמקבל מידע על האירוע, ויצירת endpoint שיוצר מידע על אירוע, וביניהם כפתור ב־frontend שמקשר מתוך אירוע A לדף של יצירת אירוע, כשהפרטים בדף יצירת האירוע הם הפרטים של אירוע A

אני לא סגורה שירדתי לסוף דעתך. תקן אותי אם הבנתי לא נכון:

  • יendpoint מקבל מידע על האירוע - route של /duplicate שמקבל מזהה של אירוע כפרמטר. הפונקציה של ה-route מפרסרת את פרטי האירוע לאובייקט ועושה get request עם הנתונים ל-endpoint יוצר אירוע
  • יendpoint יוצר אירוע - מניחה שכאן אצטרך להתאים את ה-route של יצירת איוונט (שמישהו אחר כבר בונה) שעבור get request יבדוק אם מועברים לו נתונים (פרמטרים) ואז יזין את הנתונים האלו למקומות המתאימים בטופס

יכול להיות שגם אפשר לצמצם את זה ככה שה-route של יצירת האירוע יקבל כפרמטר אופציונלי את המזהה של האיוונט שרוצים לשכפל וממנו בוחרים לאם לג’נרט עמוד עם נתונים דיפולטים או לא
אבל זה תלוי באיך מתכוונים לבנות את עמוד יצירת האירוע מלכתחילה :see_no_evil:

אני יכולה לראות מצבים שבו משכפלים אירוע כולל התאריך (נגיד אירוע שלא נוצר בחשבון שלך ואתה רוצה שכן יהיה החשבון שלך, משהו שאני עושה אם אני רוצה לזמן מישהו אחר בלי הרשאות זימון), אבל כמובן שהכוונה היא שיכולו לשנות את כל פרטי האירוע לפני שמירה.

אני חושב ש־endpoint של /event/id/5 ב־GET שמקבל מידע על האירוע ו־/event/id/5 ב־POST ששומר עליו מידע זה אחלה, ובצורה הזו אפשר גם לבצע שמירה של אירועים חדשים (אולי event/new בפוסט).

אפשר ליצור event/duplicate/N אבל אני חושב שעדיף שלא, כיוון שנצטרך כל פעם לשכפל את ההתנהגות מתוך event/new

לייק 1

ניסיתי לשרטט את הפלואו של מה שחשבתי כדי לעשות סדר. eventedit הוא בעצם ה-endpoint היחיד קורא ל-get_event_details אם הועבר לו id, ובוחר אם לעשות create (או new_event או מה שלא יהיה) אם לא מועבר לו id או מועבר לו duplicate, או update אם מועבר id

זה כמובן נוגע בפיצ’רים של @mbdi007 ו- @efratush, אז מה דעת כולם?

2 לייקים

מסכים בגדול,
כן אוסיף שבמקרה של יצירת אירוע חוזר אז יהיה צריך לייצר לולאה על הcreate ןלשנות את התאריכים ע"פ הנתון שיעבר.

אני מדבר על הפיצ’ר הזה

לייק 1

רק לוודא - הפיצ׳ר שלי מאושר, כן? :laughing:

כן, מוזמנת להתחיל לעבוד עליו :slight_smile:

לייק 1