Skip to content

Admin Dashboard Campus Event Creation - #320

Open
ambers7 wants to merge 5 commits into
masterfrom
as4288/admin-event-creation
Open

Admin Dashboard Campus Event Creation#320
ambers7 wants to merge 5 commits into
masterfrom
as4288/admin-event-creation

Conversation

@ambers7

@ambers7 ambers7 commented Apr 27, 2026

Copy link
Copy Markdown
Contributor

Summary

This pull request is implements creating campus events in the admin dashboard. Admins can create or edit an event by filling out a form with information, approve/reject an event, and delete an event.

  • added "Campus Event' to the sidebar which leads to the Campus Event page
  • create a form with required fields title, description, start time, end time, location name, latitude/longitude (via MapEntryForm), categories and optional fields image URL, all-day toggle (default false), address, check-in radius (default 100m), tags, organizer name, organizer email, check-in method dropdown, points for attendance (default 10), featured toggle (default false), registration URL
  • once the form is filled out, the campus event is created in the backend with the given information
  • admins can approve/reject/archive events. If an event is rejected, a rejection reason must be filled out.
  • wired a onUpdateCampusEventData listener so an update to one event updates the list without re-requesting the whole list

Remaining TODOs:

  • check that rejection reasons are required when rejecting an event

@dti-github-bot

Copy link
Copy Markdown
Member

[diff-counting] Significant lines: 771.

@gselina

gselina commented May 3, 2026

Copy link
Copy Markdown
Contributor

Great work Amber! One thing I noticed is that the use of hardcoded form indices could potentially break validation if the fields were to change in the future. But otherwise the implementation looks good!

@jiminkim214 jiminkim214 closed this May 5, 2026
@jiminkim214

Copy link
Copy Markdown
Contributor

Great work Amber! One thing I noticed is that the use of hardcoded form indices could potentially break validation if the fields were to change in the future. But otherwise the implementation looks good!

I agree with this. The logic around form[18] and form[19] works right now, but it feels a bit fragile since adding, removing, or reordering fields could silently break the approval/rejection behavior. It might be worth using helper accessors so it is less dependent on array position. Other than that, the overall flow looks solid!

@jiminkim214 jiminkim214 reopened this May 5, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants