It's possible to create a newsletter or a proposed action with
<script> tags by filling in the body using a textarea instead of a
CKEditor. While we trust our administrators not to do so, it's better to
completely eliminate that possibility.
The name `html_safe` is very confusing, and many developers (including
me a few years ago) think what that method does is convert the HTML
contents to safe content. It's actually quite the opposite: it marks the
string as safe, so the HTML inside it isn't stripped out by Rails.
In some cases we were marking strings as safe because we wanted to add
some HTML. However, it meant the whole string was considered safe, and
not just the contents which were under our control.
In particular, some translations added by admins to the database or
through crowding were marked as safe, when it wasn't necessarily the
case.
Although AFAIK crowdin checks for potential cross-site scripting
attacks, it's a good practice to sanitize parts of a string potentially
out of our control before marking the string as HTML safe.
This way we can simplify the way we generate form fields. In some cases,
we also use the human attribute in table headers, which IMHO makes
sense.
I haven't moved all of them: for example, sometimes a label is
different depending on whether it's shown to administrators, valuators,
or users. And I haven't touched the ones related to devise, since I
wasn't sure about possible side effects.
Note I've also removed placeholders when they had the same text as their
labels, since they weren't helpful. On the contrary, the added redundant
text to the form, potentially distracting users.
We were monkey-patching FoundationRailsHelper::Formbuilder, which made
form customization difficult. We can inherit from it, which is the
standard way of extending what an existing class does, and make our form
the default one.
This is one of the most strange behaviours in ruby: if a variable
doesn't exist, assigning to itself will return `nil`.
So a line like:
mdmkdfm = ooops if mdmkdfm.respond_to?(:uiqpior)
Surprisingly will not raise any errors: the nonexistent `mdmkdfm`
variable will be evaluated to `nil`, `mdmkdfm.respond_to?(:uiqpior)`
will evaluate to `nil.respond_to?(:uiqpior)`, which will return `false`,
and then the line will be evaluated as `mdmkdfm = ooops if false`, which
will return `nil`.
Maybe in the future Ruby will change this behaviour. We hope CONSUL is
now in better shape if that ever happens :).
- 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"
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.
* Add to menu as a Settings sub-options
* Add translations for EN and ES locales
* Activate menu sub-option when user is at any LocalCensusRecords page
During any translatable resource edit, if you remove all translations
you will be redirected to same form with errors showing you one of
persisted but marked to destroy translations, without this patch
_destroy field value wil be true and you will no able to persist without
re-addding the same language through translation interface.
When a translation not exists yet we can mark them all for destruction
by default. They already should be initialized correctly from database
or via nested attributes.
Now we take into consideration locales persisted but marked for
destruction to complete some logic and to be able to show best
translations on different situations.
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>
When not yet exists I18nContentTranslation languages,
SiteCustomization::InformationText section render I18n.locale by
default. This was causing that `languages in use` description and
default selected language were incorrectly initialized.
- 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>
* Convert proposal form into translatable one.
* Adapt translatable shared spec to define an owner when running at
frontend feature specs.
* Remove old attributes from strong parameters.
