-
-
Notifications
You must be signed in to change notification settings - Fork 263
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
False positive in Rails/ActionControllerFlashBeforeRender
when using multiple flashes + conditions
#1269
Comments
I've started having this issue in the newly released 2.26.0 # frozen_string_literal: true
class PagesController < ApplicationController
def update
if @page.update(page_params)
flash[:success] = t('.flash.success')
if redirect_to_index?
redirect_to pages_path
else
redirect_to page_path(@page)
end
else
flash.now[:alert] = t('.flash.error')
render :edit, status: :unprocessable_entity
end
end
end
WorkaroundRemove nested conditions
|
I see similar regression in 2.26.0 -- when the flash is set in a def batch
@status_filter_batch_action = Form::StatusFilterBatchAction.new(status_filter_batch_action_params.merge(current_account: current_account, filter_id: params[:filter_id], type: action_from_button))
@status_filter_batch_action.save!
rescue ActionController::ParameterMissing
flash[:alert] = I18n.t('admin.statuses.no_status_selected')
ensure
redirect_to edit_filter_path(@filter)
end
|
We also have a false positive here def user_not_authorized
if remote_request? || sandbox?
if current_user.nil?
# rubocop:disable Rails/RenderInline
render status: :unauthorized,
inline: 'You are not authorized to view this page.'
# rubocop:enable Rails/RenderInline
else
head :forbidden
end
elsif current_user.nil?
redirect_to sign_in_path
else
flash[:alert] = I18n.t('errors.no_rights') # rubocop:disable Rails/ActionControllerFlashBeforeRender
if request.referer.present? && URI.parse(request.referer).host == request.host
redirect_to(request.referer)
else
redirect_to(root_path)
end
end
end |
@Earlopain Yes, I agree to revert that PR. To be honest, I think this Cop is inherently difficult for static linting to detect properly. Considering the numerous false positives and negatives, I believe removing the Cop altogether is an option worth considering. |
…Render` from issue rubocop#1269 This cop would need to do control flow analysis which it just doesn't do. RuboCop also has no mechanism for that. So just reverting this for now to fix the newly introduces false positives
…Render` from issue rubocop#1269 This cop would need to do control flow analysis which it just doesn't do. RuboCop also has no mechanism for that. So just reverting this for now to fix the newly introduces false positives
Thanks for your reply, I openend to revert #1344. I agree with your opinion, that cop has plenty to do to work correctly. The approach it currently takes is too simplistic. |
…FlashBeforeRender` tests from issue rubocop#1269 This reverts commit 0f703db, reversing changes made to 0f63f00. This cop would need to do control flow analysis which it just doesn't do. RuboCop also has no mechanism for that. So just reverting this for now to fix the newly introduces false positives
Having a similar issue with false positives from this cop. |
Expected behavior
This code should be valid:
Actual behavior
Rubocop says to use
flash.now
before render, which I think is wrong:Steps to reproduce the problem
Spec passes if I change the example code to use
return redirect_to root_path
inside the offending condition so I suspect it's related to the usage ofredirect_to ... and return
. However, the spec will pass when usingredirect_to root_path and return
if I remove the code starting withif other_condition
through the end of the Rails action.RuboCop version
bundle exec rubocop -V
1.63.1 (using Parser 3.3.0.5, rubocop-ast 1.31.2, running on ruby 3.1.4) [arm64-darwin22]
The text was updated successfully, but these errors were encountered: