These tests don't work without JavaScript. They were passing because the
`within` method always passes in component tests.
This reverts most of commit 822140a14.
In component tests, the `within` method is actually an alias to RSpec's
`be_within` matcher, which is used to test numeric ranges. That meant
the tests always passed, even when there were bugs on the page.
In order to use `within` in component tests, we have to use
`page.within`. However, that also fails, since there's no such method
for `Capybara::Node::Simple'` objects, which are used in component
tests.
So we're using `page.find` instead.
See also pull request 945 in https://github.com/github/view_component
We were executing SQL queries searching for translations even for
records which were not persisted in the database and therefore had no
translations.
So we're now only looking for translations when the record is persisted.
Note that, when the record isn't persisted, we're using `I18n.translate`
instead of the `t` method. That's because the `t` method would also
perform database queries since we overwrite the `t` method in the
`i18n_translation` initializer.
On tabs with many records, like the proposals tab, requests are now up
to three times faster on production environments.
Tests related to this part of the application were failing sometimes
because requests took longer than `Capybara.default_max_wait_time`.
After these changes, the custom information texts pages load about 30%
faster when running the tests.
This way it's easier to test; changing it will also be easier.
During my experiments I made a mistake which wasn't covered by the test
suite. We're adding a test for this case.
Note we're using `i18n_content` in the component instead of `content`
because there's already a `content` method provided by ViewComponent.
When we try to register with omniauth and the email or username already exists,
we use the finish_signup and do_finish_signup actions to allow the user to choose
another email or username.
The do_finish_signup action of the registration controller calls the
send_oauth_confirmation_instructions method which is responsible for sending the
confirmation email.
In this method we were only validating the case that the email is duplicated. Now
we add one more condition that allows us to send the instructions for the case in
which we have had to change our username.
The integration between Airbrake/Errbit and DelayedJob wasn't working
because we require our dependencies in alphabetic order, and so by the
time `airbrake` was required, `delayed_job` wasn't loaded.
So we're manually requiring the integration.
We weren't showing the details of answers without a description, even if
they had images, videos or documents. Some users found that behavior
unexpected since the description isn't a mandatory field and so they
left it blank, but they added images to that answer and they didn't
appear on the poll page.
Note we had a condition not to show the title of an answer when it had
no description. I think that condition was redundant because answers
without a description weren't loaded in the first place. Anyway, that
condition doesn't make sense anymore because we're displaying answers
with images but no description.
Adding the error to the translation means Rails will automatically show
the error message in the view.
We're also adding a test to make sure the error message is correctly
displayed.
We now have duplication in the validation rules, however. Validating
translatable attributes is still a bit of mess.
As mentioned in commit b7f6c4c43:
> [In Internet Explorer] the `flex: 1` property doesn't work so well
> when `flex-direction` is set to `column`. We're replacing it with
> `flex-grow: 1`. No need to set other `flex-basis` nor `flex-shrink`
> since in this case the default values will work just fine.
This column wasn't used in any released Consul version since it was only
used during development. For the same reason, the task to migrate the
information in the `link` column to the `links` table isn't needed
either.
It was never used and its data is based on Madrid's requirements for
successful proposals. It was written during the development of the
dashboard, probably for testing purposes.
In commit baaec3a29 we started using the JavaScript driver in tests
dealing with the user menu, and made all tests pass.
However, we didn't update some officing tests that were also passing
when there was a bug in the code. That's because now that these tests
use a JavaScript driver, the link to "Polling officers" is never present
before pressing the "Menu" item. So tests checking the link isn't
present when loading the page always pass.
We were already doing so for debates and investments.
We probably never noticed because this is an edge case that requires
enabling a feature, people adding comments, and then disabling the
feature.
It could be argued that seeing which proposals a user follows is a good
indicator of which proposals a user has supported, since we're
automatically creating follows for supported proposals since commit
74fbde09f. So now, we're extending the `public_interests` funcionality,
so it only shows elements users are following if they've enabled it.
This is an improvement over using the `public_activity` attribute in two
ways:
* The `public_interests` attribute is disabled by default, so by default
other users won't be able to see what a user is following
* Who has created proposals/debates/investments/comments is public
information, while who is following which elements is not; so enabling
`public_activity` shouldn't imply potentially private information should
be displayed as well
We've considered removing the `public_interests` attribute completely
and just hiding the "following" page for everyone except its owner, but
keeping it provides more compatibility with existing installations.
The `click_link` part did nothing other than scrolling to the element,
since in these cases we've got a same-page link and the element it links
to is already on the page. Programmers reading the test would expect the
link to load the page or change to a different tab and would think the
element it links to wasn't there before clicking the link (at least I
did).
We had similar conditions many times and some duplication, particularly
between the code getting records and the code counting records. We can
remove it by returning a generic scope and calling the `count` method to
count the records and the `order` and `page` methods when we want to
pass the records to the view. And, since we only display one partial per
request, we can simplify the code to render all the partials. There's
one minor disadvantage to this approach: searching the code for the
place where these partials are rendered is now a bit harder since
searching the code for something like "render (.+) budget_investments"
won't return any results.
We're also writing conditions about a certain filter just once, by
setting `valid_filters`. This greatly simplifies the logic, although
again there's one minor disadvantage: we have to implement the
`current_filter` method, duplicating the logic already defined in the
`HasFilters` concern.
