We were performing an AJAX request and then a "normal" request without
checking the AJAX request had finished. Sometimes it resulted in the
normal request finishing because the AJAX request did, causing the test
to fail.
We're getting a failure on Travis in one of these tests. Debugging shows
the AJAX request rendering the first page (after clicking the "Previous"
link) takes too long and sometimes it exceeds Capybara's timeout.
After running the test thousands of times, the only way I've found to
clearly reduce the number of times the test fails is to reduce the
number of records shown on the first page. Other experiments, like
adding an `includes(:author)` to the query getting the proposals in the
controller, or adding `author: user` to the `create_list` part of the
test (so only one author needs to be fetched when rendering the
proposals) show inconsistent results regarding performance.
Note we still need at least 10 proposals for the test for several users,
to guarantee two users will never get the same records during the test
(or at least the probability they get the same records is one in
millions).
This number was not the important one; the important one is the one
given by the recounts.
Note we're also removing the votes by date, since they're also system
votes.
System count isn't a relevant number because the important one is the
number of votes counted by poll officers. We're still maintaining it for
a month in case poll officers would like to review the results.
When clicking the button "Search", the link "newest" is already present,
so capybara might click the "newest" link before the "Search" request is
finished, leading to unexpected results.
Checking the page to make sure the "Search" request has finished before
clicking the "newest" link solves the problem.
The `type: :feature` is automatically detected by RSpec because these
tests are inside the `spec/features` folder. Using `feature` re-adds a
`type: :feature` to these files, which will result in a conflict when we
upgrade to Rails 5.1's system tests.
Because of this change, we also need to change `background` to `before`
or else these tests will fail.
We're also adding a rubocop rule so we dont' accidentally add these
keywords again.
- Add :date_of_birth and :postal_code
- Only display new fields when aplication has configured the Remote
Census API and contains values for fields. Check with Setting Class
methods:
- force_presence_date_of_birth?
- force_presence_postal_code?
- Add new translations on SignatureSheet show page.
Changes:
-> "document number" to "sigantures"
-> "documents" to "users"
- Remove unused translations from the others yml
- In the previous version, each signature was equivalent to a document
and we separated them by commas.
Now each signature may also need the fields birth date and postal code.
So we separated each signature with a semicolon and separated each of
its fields by commas.
Example old version: "12345678X, 87654321Y"
Example new version:
"12345678X, 31/12/1980, 28001; 87654321Y, 31/12/1981, 28002"
- Update translations:
"Write the numbers separated by commas (,)" to
"Write the numbers separated by semicolons (;)"
This new functionality will allow to retrieve in the signature sheet
the document number, the date of birth and the postal code.
So we renamed :document_numbers to :required_fields_to_veriry to
clarify and adjust the name to its use.
- Add :date_of_birth and :postal_code
- Only display new fields when aplication has configured the
custom census API and contains alias values for fields. Add 2
class Setting methods to check this feature:
- force_presence_date_of_birth?
- force_presence_postal_code?
Currently after each update of any Settings is redirected to the first
tab by default.
As this new tab remote_census_configuation has a lot of fields to fill
in it is a bit uncomfortable to have to go back to the tab after each
update.
- Add hidden field :tag to set current tag value
- After update add tag value to request.referer
- To avoid errors when partial call has not param :tag, add the "define?"
method on hidden_field value.
When we reuse the partial '_setting_table' to render the 3 types
of remote census settings, we need customize setting_name key by
default to clarify the information to render.
- Add new param 'setting_name' to partial '_setting_table'
- Create new setting helper method to use new setting_name param
to display a more clarify setting name on table.
According to the feature setting["remote_census"]:
- Display info to enable tab when remote_census feature is disabled.
- Display all related setting to remote_census when feature is enabled
* Create admin controller and routes
* Add pagination
* Add search by document_number
* Add EN and ES translations
* Add index specs
* Add missing model specs
We understand languages management as the ability to add new languages
or remove existing ones. When no option is passed it will allow language
manipulation by default.
There are 3 special places where we want block languages management:
- admin legislation processes homepage
- admin legislation processes milestones summary
- proposals retired form
Co-Authored-By: Sebastia <sebastia.roig@gmail.com>
This spec fails if we remove the attribute `name` from `poll_params` in
the `Admin::Poll::PollsController`, which we would usually remove
because it's a translatable attribute.
- Add remote_translation_button partial to layout
- Only display button when we have remote_translations and if current
locale is include on available locales from remote translations service.
- Recover available locales from remote translations service.
Use daily_cache to detect every day if remote translation service has
added new available locale.
Co-Authored-By: alessandro <agileontheweb@gmail.com>
* Adapt translatable spec helper method to work with budget investments
* Remove old attributes from strong parameters
* Add missing locales to admin.yml and budgets.yml
* Change SpendingProposal.title_max_length and
SpendingProposal.description_max_lenght to Budget::Investment methods
* Add budget investment translatable attribute translations
