-
Notifications
You must be signed in to change notification settings - Fork 50
Feature/pass user from view to facilities #1269
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
base: dev
Are you sure you want to change the base?
Conversation
Also, attach the User instance to the Facility since the Facility will need it to get the User-specfic credentials from the Facility Profile.
Recent changes to instantiate the facility class only once per request cycle in `ObservationCreateView.dispatch` introduced issues with form creation, causing three tests to fail. This commit refactors the `get_form` method to correctly instantiate the form class directly with the necessary keyword arguments, including the user. It also handles potential `TypeError` for forms that do not accept a `user` argument, for backwards compatibility.
|
Ready for review -- Now with passing tests!! |
jchate6
left a comment
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.
minor things...
| kwargs['user'] = self.request.user | ||
| return kwargs | ||
|
|
||
| def post(self, request, *args, **kwargs): |
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 don't care for this as a method for handling this kind of error.
This feels like something we should be handling at the base form level or the get_form() method rather than trying to catch the exception here.
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 isn't a error handling change. This is where we attach the User instance to the form kwargs. We do that here b/c the View has the request and the request has the user.
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'm sorry, maybe my comment was confusing.
We shouldn't find ourselves in a situation where adding a user to the form_class throws a TypeError.
We shouldn't be checking for that in the form Post in the view. Obviously we need to add the specific user instance in the view, but we should do this check (and add the capability to accept a user if needed) in the base form or the get_form() method.
If you'd like to have a chat about this, let me know.
| kwargs['user'] = self.request.user | ||
| return kwargs | ||
|
|
||
| def post(self, request, *args, **kwargs): |
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'm sorry, maybe my comment was confusing.
We shouldn't find ourselves in a situation where adding a user to the form_class throws a TypeError.
We shouldn't be checking for that in the form Post in the view. Obviously we need to add the specific user instance in the view, but we should do this check (and add the capability to accept a user if needed) in the base form or the get_form() method.
If you'd like to have a chat about this, let me know.
This enhances the ObservationCreateView by
self.get_facility_class()()all over the place, we call it once at the beginning (indispatch()) and refer toself.facility_instancethroughout the View.These changes are prerequisites for