We only want to render the account link and login items in the header.
And we want only render the Multitenancy and Administrators sections in
the admin sidebar.
We include the administrators management so it's possible to give
permissions to other users to manage tenants.
In order to restrict access to other sections by typing the URL or
following a link, we're only enabling the rest of the routes when we
aren't in the multitenancy management mode.
In order to the display a warn text on the last attempt
before the account is locked, we need update
config.paranoid to false as the devise documentation
explains.
Adding "config.paranoid: false" implies further changes
to the code, so for now we unncomment the default value
"config.last_attempt_warning = true" and update it to false.
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
DEPRECATION WARNING: Using positional arguments in functional tests
has been deprecated, in favor of keyword arguments, and will be
removed in Rails 5.1.
Deprecated style:
get :show, { id: 1 }, nil, { notice: "Flash message" }
New keyword style:
get :show, params: { id: 1 }, flash: { notice: "Flash message" }
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.
