Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Anonymous application submission doesn't always reenable submit button #209

Closed
petschekr opened this issue Mar 10, 2018 · 0 comments · Fixed by #214
Closed

Anonymous application submission doesn't always reenable submit button #209

petschekr opened this issue Mar 10, 2018 · 0 comments · Fixed by #214
Assignees
@bunsenmcdubbs
Labels
bug good first issue A great first issue to tackle if you're new to the registration codebase medium priority
Milestone
Midsummer HackGT 5

Comments

@petschekr
Copy link
Member

Can be reproduced by entering a duplicate email when anonymously applying. The correct error message will pop up but the submit button isn't reenabled when the dialog is closed like it should (and does elsewhere in registration)
@petschekr petschekr added bug medium priority good first issue A great first issue to tackle if you're new to the registration codebase labels Mar 10, 2018
ehsanmasdar added a commit that referenced this issue May 8, 2018
@ehsanmasdar
Various fixes for walk-up registration, including #209/#208, and simp…
2669fcd 
…lification of redirection logic #206
@ehsanmasdar ehsanmasdar mentioned this issue May 8, 2018
Merged
ehsanmasdar added a commit that referenced this issue May 12, 2018
@ehsanmasdar
Rewrite of core confirmation logic #211, #209, #117 #110
718422e 
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.
@ehsanmasdar ehsanmasdar modified the milestones: HackGT 5 Updates, HackGT 5, Midsummer HackGT 5 May 15, 2018
@petschekr petschekr removed the pending review This PR is pending review by a maintainer label Jun 29, 2018
rahulrajus pushed a commit that referenced this issue Jul 22, 2021
@ehsanmasdar
Various fixes for walk-up registration, including #209/#208, and simp…
d23cde3 
…lification of redirection logic #206
rahulrajus pushed a commit that referenced this issue Jul 22, 2021
@ehsanmasdar
Rewrite of core confirmation logic #211, #209, #117 #110
fa5c30a 
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
Assignees

@bunsenmcdubbs bunsenmcdubbs

Labels
bug good first issue A great first issue to tackle if you're new to the registration codebase medium priority
Projects
None yet
Milestone
Midsummer HackGT 5
Development

Successfully merging a pull request may close this issue.

Confirmation refactor HackGT/registration
3 participants
@bunsenmcdubbs @petschekr @ehsanmasdar