This way we write the tests from the user's point of view: users can see
(for example) a proposal with the title "Make everything awesome", but
they don't see a proposal with a certain ID.
There are probably dozens, if not hundreds, of places where we could
write tests this way. However, it's very hard to filter which ones are
safe to edit, since not many of them have an HTML class we can use in
the tests, and adding a class might generate conflicts with CSS styles.
So, for now, I'm only changing the ones allowing us to cleanly remove
useless assignements while maintaining the code vertically aligned.
When we were inserting a row or replacing an existing one (just like we
do when we click the link to select an investment), we were entering a
row containing all columns, and all of them were displayed even if they
had been excluded using the column selector.
This caused the table to move in a strange way, which sometimes made the
investment selection tests fail.
We accidentally removed the `count` option in commit 55fb14ac, which
made the translation return a hash.
The test is a bit hacky, which makes me think changing the user
interface would probably be a better solution.
Internet Explorer 9 was released eight years ago. Besides that, we don't
really support IE8 anyway, since we show a popup to IE8 users saying
we don't support it, we haven't maintained the IE8-specific CSS file for
years, and we don't test our JavaScript against IE8.
The label text was always in English, and it wasn't associated with any
input field.
The `SecureRandom` part is a quick hack so we don't get duplicate IDs.
Using "your_answer_#{question.id}" might work as well, but right now I'm
not sure if the form is sometimes rendered twice for the same question.
Not wrapping the editor in a `.ckeditor` div made it change height when
the editor was loaded. That caused a weird effect for users, and also
made some tests fail sometimes since the position of the "Add new
document" link might change right when capybara is clicking it.
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.
- 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
- Display help text and example text according to
remote census configuration:
Examples with expecte results:
* With remote census without :date_of_birth and :postal_code:
-> "To verify a user, your application needs: Document number"
-> "Required fields for each user must be separated by commas and
each user must be separated by semicolons."
-> "Example: 12345678Z; 87654321Y"
* With remote census with :date_of_birth required:
-> "To verify a user, your application needs: Document number,
Day of birth (dd/mm/yyyy)"
-> "Required fields for each user must be separated by commas and
each user must be separated by semicolons."
-> "Example: 12345678Z, 01/01/1980; 87654321Y, 01/02/1990"
* With remote census with :date_of_birth and :postal_code required:
-> "To verify a user, your application needs: Document number,
Day of birth (dd/mm/yyyy) and Postal Code"
-> "Required fields for each user must be separated by commas and
each user must be separated by semicolons."
-> "Example: 12345678Z, 01/01/1980, 28001; 87654321Y, 01/02/1990, 28002"
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.
In these cases "setting" is the value expected by the new helper method for
everything to continue rendering in the usual way.
Note:
All the new calls to _setting_table partial will need add setting_name param.
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
- Render remote census configuration content on settings index.
- Update type method from Setting
On Admin::SettingsController#index we are using 'all_settings' to
group all settings by 'type' method.
'type' method return the first part of key when split by '.'
To allow use by example: all_settings["remote_census.general"]
and recover only settings related with this key we have added new
'elsif' on 'type' method.
