[1624] Add option to disable requests #1625
Conversation
|
Can we rebase this before review? |
esoterik
force-pushed
the
1624_disable_requests_option
branch
from
92c57bc to
435ba14
Compare
|
Rebased! |
| @@ -0,0 +1,60 @@ | |||
| # frozen_string_literal: true | |||
| <div id="content" class="col-md-9"> | ||
| <% unless @errors.empty? %> | ||
| <p> | ||
| <h3><i class="fa fa-exclamation-triangle warning-icon"></i> Would you like to resolve the following error(s)?</h3> |
There was a problem hiding this comment.
This should probably read Please resolve the following error(s): since they can't be overriden by the student.
| override && !cart_errors.blank? | ||
| end | ||
|
|
||
| def valid_override? |
There was a problem hiding this comment.
Do we really need to extract this separately? I feel like we have a bunch of little methods that aren't strictly necessary. For example, the only time it's used (L31 - override? && !(override? && !notes.blank?)), is equivalent to override? && notes.blank? (if I'm expanding correctly).
I guess I see how this is useful in making the code easier to read, but I think what's bothering me is the use of override? inside valid_override? when it's just cancelled out in the override? necessarily. This also applies to valid_request?. Thoughts?
| before do | ||
| allow_any_instance_of(described_class).to \ | ||
| receive(:cart).and_return(cart) | ||
| allow_any_instance_of(described_class).to receive(:fix_cart_date) |
There was a problem hiding this comment.
Yeesh these smell a bit to me, but it's definitely out of scope for this issue.
| current_user: current_user, | ||
| **attrs) | ||
| results = creator.create! | ||
| expect(results[:result]).to be_truthy |
There was a problem hiding this comment.
Do we need to make assertions about the value of results[:result] since it's used when processing the successful result in the controller?
There was a problem hiding this comment.
I think so -- this is also a part of the move away from controller tests (though Reservations might not really make it all the way there)
There was a problem hiding this comment.
Wait, I feel like this discussion wasn't resolved. I think was asking if we should also be asserting against the actual value of results[:results], not just whether or not it's truthy. Am I missing something?
| @@ -28,7 +28,11 @@ | |||
| describe UserMailer, type: :mailer do | |||
| before(:each) do | |||
| @ac = mock_app_config(admin_email: '[email protected]', | |||
| disable_user_emails: false) | |||
| disable_user_emails: false, | |||
There was a problem hiding this comment.
Where did all of these come from and why did we only run into this now?
There was a problem hiding this comment.
Oh wait, is it from switching from spy to instance_spy? Do you remember why we did this?
There was a problem hiding this comment.
I'm pretty sure it's from switching to instance_spy which is safer because it only lets you stub out things that exist in the real class.
esoterik
force-pushed
the
1624_disable_requests_option
branch
from
38f1ec7 to
5da4f10
Compare
|
refactored the service object a bit and rebased! |
Resolves #1624 - Adds a Service Object for reservation creation
esoterik
force-pushed
the
1624_disable_requests_option
branch
from
5da4f10 to
bfe944e
Compare
| <%= render partial: 'new_reservation' %> |
There was a problem hiding this comment.
I'm not sure why we need partials for this if we now have independent views for each of the different cases that are rendered independently - can we just move the partial content into the full views?
There was a problem hiding this comment.
I think it's necessary for how the reservation_form JS works
There was a problem hiding this comment.
Yea fair enough. I feel like there might be a way to improve this but it's really not critical.
| end | ||
|
|
||
| def needs_notes? | ||
| (request? || override?) && notes.blank? |
There was a problem hiding this comment.
Isn't request? || override? equivalent to !cart_errors.blank?, since request? is true if override is falsey and override? is true if override is truthy?
There was a problem hiding this comment.
This would eliminate the need for the override? method, I believe.
| flash[:error] = 'Please give a short justification for this reservation' | ||
| @notes_required = true | ||
| @request_text = if AppConfig.get(:request_text).empty? | ||
| 'Please give a short justification for this '\ |
There was a problem hiding this comment.
this is a little out of scope but it seems like we should just set this as a default value for request_text rather than having this live in the controller
There was a problem hiding this comment.
Yea... that's a great point. I'll open up an issue.
|
pushed an update |
| current_user: current_user, | ||
| **attrs) | ||
| results = creator.create! | ||
| expect(results[:result]).to be_truthy |
There was a problem hiding this comment.
Wait, I feel like this discussion wasn't resolved. I think was asking if we should also be asserting against the actual value of results[:results], not just whether or not it's truthy. Am I missing something?
Blocking on #1586.
Resolves #1624