-
-
Notifications
You must be signed in to change notification settings - Fork 72
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.
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
Enforce membership code on instructor training application #2544
Enforce membership code on instructor training application #2544
Conversation
@karenword a couple of questions for you about member code validation on the instructor training application. You don't need to look at the code changes in this PR. ValidationInitially we discussed having a "soft" validation where the user is prompted to check their code is correct, but will still be allowed to submit an invalid code. However, this turns out to be difficult to implement in the Django code framework that we use, and I'd prefer not to do it if we can avoid it. Here's how I've currently implemented the validation for different reasons for the invalid code:
What are your thoughts on this? Is this too restrictive? I noticed that the application form currently says at the top "If you do not have a registration code, please enter the name of the institution you are joining through." Is this still accurate and expected, or should preapproved trainees always now have a code? If this statement is still true, we can't do the validation as I've described and will have to figure out the softer way. Error messageHere's the error message I've written:
I used the phrase "site contact" because it's at the top of the form too, but I haven't seen it elsewhere - if we have a more commonly used term for member-contact-from-trainee's-perspective, let me know. This is a bit different to Maneesha's original suggestion as the validation style is changed. Let me know any feedback you have. |
thanks for the heads up @elichad -- this is definitely a significant change and will take some thought. I will ping @Talishask and @klbarnes20 for feedback as well as putting this on our team meeting agenda for discussion next Tuesday. |
My first impression is that this will lead to a lot of people being unable to submit (and thus a lot of confused emails). I regularly get messages that codes are expired or have already used all their seats when I'm connecting training requests to trainings. But definitely interested in what @Talishask has to say as well. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The changes look good to me.
@@ -88,6 +90,7 @@ class Meta: | |||
} | |||
|
|||
def __init__(self, *args, **kwargs): | |||
self.request_http = kwargs.pop("request", None) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This name is a little bit off. Usually it was named self.request
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I did this to avoid ambiguity between the http request and the training request that this form describes. I'm not entirely happy with the break from convention but I think it might prevent future confusion
Summary of conversation with @karenword and @Talishask:
Sentence at the top of the application form: If you do not have a registration code, please enter the name of the institution you are joining through.
Error message phrasing options:
I am going to merge this PR after addressing @pbanaszkiewicz's recommendations, as there is code here that lays useful groundwork for further development. However, things will be changed on the validation side in future PRs according to the summary above. |
Fixes #2379.
Adds code enforcement to the instructor training application in a similar way to workshop requests.
I changed the
group_name
field tomember_code
for consistency betweenTrainingRequest
andCommonRequest
, and because I think it's much clearer given the terminology we're using currently.