Open pre-registration for the first UG semester, and name the calendar event a window needs - #1962
Merged
vikrantwiz02 merged 1 commit intoAug 20, 2026
Conversation
…r event a window needs Pre-registration is keyed by the semester being registered into, so a student in the first semester needs an event named "Pre Registration 2 <year>" while add, drop, replace and PG registration all key on the semester the student is in. The office reasonably named the event after the current semester, and the window stayed shut with no way to tell why. Two changes follow from that. An event named "Pre Registration 0 <year>" now opens pre-registration for UG students in their first semester, and its own from and to times govern. It applies to nothing else: any other cohort, and any non-UG student, keeps the existing key, and when that event does not exist nothing changes. Every registration window -- add, drop, replace, swayam, PG, PhD as well as pre-registration -- now names the event it looked for when none is found, so "date is not yet decided" is accompanied by the exact description the calendar is missing instead of leaving the office to guess at the convention. Separately, the login-credentials mail and the two password-reset pages linked to the portal over http; they now use https.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Pre-registration stayed shut for the first semester
A registration window is looked up by an exact academic-calendar description. Pre-registration is keyed by the semester being registered into, so a student in semester 1 needs an event named
Pre Registration 2 <year>— while add, drop, replace and PG registration all key on the semester the student is in. The office named the event after the current semester, which reads perfectly sensibly, and the page answered "Pre Registration date is not yet decided" with nothing to say which name it wanted.An event named
Pre Registration 0 <year>now opens pre-registration for UG students in their first semester, with that event's own from/to times governing. It is scoped to exactly that case:Pre Registration 0 <year>Pre Registration 2 <year>Pre Registration 2 <year>Every window now names the event it looked for. Add, drop, replace, swayam, PG and PhD registration share the same helper, so a missing event reports the exact description the calendar lacks alongside the existing message, rather than leaving the convention to be guessed:
The calendar's description field is free text with no hint of the convention, so this is the difference between a five-minute fix and an afternoon of guessing.
Portal links over http
The login-credentials mail and the two password-reset pages linked to the portal as
http://. They now usehttps://; nohttp://fusionreference remains in the backend or its templates.Checks
Verified against real records with the calendar event created and rolled back: a first-semester UG student's window opens once the event exists, a non-UG student in the same semester is unaffected, and later semesters keep their existing key.
manage.py checkclean, no migrations.