9a7681b75f
As mentioned in commits likea586ba806,a7664ad81,006128da5,b41fbfa52andc480cdd91, accessing the database after starting the browser with the `visit` method sometimes results in database corruption and failing tests on our CI due to the process running the test accessing the database after the process running the browser has started. In this case, we were hiding a proposal after starting the process running the browser to check what happens when accessing a notification for a hidden proposal. We can avoid database access in the middle of the test by hidding a proposal before starting the browser. The process to create a notification using the browser is already tested in other specs, so we don't need to do it here as well. Note that, to simplify the test, we're extracting the `notify_users` method. I wonder whether this method should be called in an `after_create` callback instead... That's a topic for another time, though.
36 lines
926 B
Ruby
36 lines
926 B
Ruby
class ProposalNotificationsController < ApplicationController
|
|
load_and_authorize_resource except: [:new]
|
|
|
|
def new
|
|
@proposal = Proposal.find(params[:proposal_id])
|
|
@notification = ProposalNotification.new(proposal_id: @proposal.id)
|
|
authorize! :new, @notification
|
|
end
|
|
|
|
def create
|
|
@notification = ProposalNotification.new(proposal_notification_params)
|
|
@proposal = Proposal.find(proposal_notification_params[:proposal_id])
|
|
if @notification.save
|
|
@proposal.notify_users(@notification)
|
|
|
|
redirect_to @notification, notice: I18n.t("flash.actions.create.proposal_notification")
|
|
else
|
|
render :new
|
|
end
|
|
end
|
|
|
|
def show
|
|
@notification = ProposalNotification.find(params[:id])
|
|
end
|
|
|
|
private
|
|
|
|
def proposal_notification_params
|
|
params.require(:proposal_notification).permit(allowed_params)
|
|
end
|
|
|
|
def allowed_params
|
|
[:title, :body, :proposal_id]
|
|
end
|
|
end
|