Currently the application does not send any email to confirm the
account for already confirmed users. But we show a notice message
that may look like you will recive one:
"If your email address exists in our database, you will receive
an email with instructions for how to confirm your email address
in a few minutes."
In this commit we keep the original message, but send an email to
the user informing them that their account is now registered.
This way no one can know if someone else's account is confirmed and
we don't have to worry about GDPR either.
Co-Authored-By: taitus <sebastia.roig@gmail.com>
When customizing CONSUL, one of the most common actions is adding a new
field to a form.
This requires modifying the permitted/allowed parameters. However, in
most cases, the method returning these parameters returned an instance
of `ActionController::Parameters`, so adding more parameters to it
wasn't easy.
So customizing the code required copying the method returning those
parameters and adding the new ones. For example:
```
def something_params
params.require(:something).permit(
:one_consul_attribute,
:another_consul_attribute,
:my_custom_attribute
)
end
```
This meant that, if the `something_params` method changed in CONSUL, the
customization of this method had to be updated as well.
So we're extracting the logic returning the parameters to a method which
returns an array. Now this code can be customized without copying the
original method:
```
alias_method :consul_allowed_params, :allowed_params
def allowed_params
consul_allowed_params + [:my_custom_attribute]
end
```
Sometimes we define URLs for POST requests which are not defined for GET
requests, such as "/residence", so redirecting to it after signing out
results in a routing error.
So instead of using the request referer, we're using the stored location
devise uses, and we're not storing locations in POST requests.
We were inconsistent on this one. I consider it particularly useful when
a method starts with a `return` statement.
In other cases, we probably shouldn't have a guard rule in the middle of
a method in any case, but that's a different refactoring.
We were very inconsistent regarding these rules.
Personally I prefer no empty lines around blocks, clases, etc... as
recommended by the Ruby style guide [1], and they're the default values
in rubocop, so those are the settings I'm applying.
The exception is the `private` access modifier, since we were leaving
empty lines around it most of the time. That's the default rubocop rule
as well. Personally I don't have a strong preference about this one.
[1] https://rubystyle.guide/#empty-lines-around-bodies
Having exceptions is better than having silent bugs.
There are a few methods I've kept the same way they were.
The `RelatedContentScore#score_with_opposite` method is a bit peculiar:
it creates scores for both itself and the opposite related content,
which means the opposite related content will try to create the same
scores as well.
We've already got a test to check `Budget::Ballot#add_investment` when
creating a line fails ("Edge case voting a non-elegible investment").
Finally, the method `User#send_oauth_confirmation_instructions` doesn't
update the record when the email address isn't already present, leading
to the test "Try to register with the email of an already existing user,
when an unconfirmed email was provided by oauth" fo fail if we raise an
exception for an invalid user. That's because updating a user's email
doesn't update the database automatically, but instead a confirmation
email is sent.
There are also a few false positives for classes which don't have bang
methods (like the GraphQL classes) or destroying attachments.
For these reasons, I'm adding the rule with a "Refactor" severity,
meaning it's a rule we can break if necessary.
In general, we always use relative URLs (using `_path`), but sometimes
we were accidentally using absolute URLs (using `_url`). It's been
reported i might cause some isuses if accepting both HTTP and HTTPS
connections, although we've never seen the case.
In any case, this change makes the code more consistent and makes the
generated HTML cleaner.
DEPRECATION WARNING: before_filter is deprecated and will be removed in
Rails 5.1. Use before_action instead. (called from
<class:RegistrationsController> at
/home/travis/build/consul/consul/app/controllers/users/registrations_con
troller.rb:3)
We were getting a 500 Internal Server Error because `find_by` returned
`nil`, but the code assumed it returned an object responding to
`encrypted_password`. In this case, maybe some other status code (like
400 or 401) might be more appropriate, but I've kept 404 because it was
easier to implement and I wasn't sure which one was better.
Also note ideally we would test the controller using:
expect(response).to have_http_status(:not_found)
However, we would need to configure the test to show exceptions and not
to consider all requests local. I haven't been able to do so for
controller tests, and doing so for feature/request specs seems to
require changes in the test environment configuration which would affect
other tests.
Not sure how this error creeped in 😕 probably a new gem version or
other conflicting code
The problem was we were getting an `unpermitted param email` when
updating a user’s email address
This stackoverflow solution seems to work nicely 😌https://stackoverflow.com/questions/17384289/unpermitted-parameters-addi
ng-new-fields-to-devise-in-rails-4-0#answer-19036427
Keep a blank line before and after private
Keep a blank line before and after protected
Remove extra empty line at class body end
Remove extra blank line
Add final newline
Use 2 (not 3) spaces for indentation
Use 2 (not 4) spaces for indentation
Remove space before comma
Add space after comma
Remove trailing whitespaces
Remove unnecessary spacing
Use snake_case for variable names
Do not use then for multi-line if
Remove unused block argument - i
Use the new Ruby 1.9 hash syntax
Remove unused assignment to variable
Indent when as deep as case
Align attributes
Align end with def
