Ability to reject applicants #110
Labels
enhancement
Adds or suggests a new feature, rewrite, or other enhancement to the codebase
high priority
Milestone
Comments
ajliu
added
enhancement
|
We'll end up sending all waitlisted applicants a rejection email once all of our spots fill up. Probably won't be relevant till October |
|
This more along the lines of "mark a waitlisted applicant as reviewed" so that applicants that have not been looked at be hoisted to the front. |
|
ahh ok covering that in #117 so this should be an actual rejection |
petschekr
added
medium priority
high priority
and removed
low priority
medium priority
labels
ehsanmasdar
added a commit
that referenced
this issue
May 12, 2018
When we accept a user we assign them to a specific confirmation branch (and only one confirmation branch). Each confirmation branch is an option in the state dropdown. Instead of sending an acceptance email for the application branch, we send a pre-confirm email for the confirmation branch. This allows us to alter the message text for each branch. Waitlist/Rejected edge cases: Waitlist can operate as a normal confirmation branch if we have people confirm their spot on the waitlist. Rejected can be implemented by a simple no-op confirmation branch that does not require any user action (this is also necessary for supporting the walk-up feature). A flag on each branch can indicate if this confirmation represents "success" or "failure", for the purposes of ensuring we only check-in accepted students. The only reduction in functionality here is that users can no longer choose from multiple confirmation branch. In my opinion, this isn't necessary for us and only lead to confusion when different confirmation branches had different deadlines.
Merged
rahulrajus
pushed a commit
that referenced
this issue
Jul 22, 2021
When we accept a user we assign them to a specific confirmation branch (and only one confirmation branch). Each confirmation branch is an option in the state dropdown. Instead of sending an acceptance email for the application branch, we send a pre-confirm email for the confirmation branch. This allows us to alter the message text for each branch. Waitlist/Rejected edge cases: Waitlist can operate as a normal confirmation branch if we have people confirm their spot on the waitlist. Rejected can be implemented by a simple no-op confirmation branch that does not require any user action (this is also necessary for supporting the walk-up feature). A flag on each branch can indicate if this confirmation represents "success" or "failure", for the purposes of ensuring we only check-in accepted students. The only reduction in functionality here is that users can no longer choose from multiple confirmation branch. In my opinion, this isn't necessary for us and only lead to confusion when different confirmation branches had different deadlines.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Differentiate pending applicants and rejected applicants so rejected applicants can be filtered out
The text was updated successfully, but these errors were encountered: