It turns out it is not necessary to downcase and underscore
locale names to use the globalize-accessor gem. The gem
will automatically underscore the locale name when defining and
calling the accessor methods.
I've moved the method to the User model in order to make it easier to
test. I'm not sure where it belongs, though.
There was already a failing spec in `spec/features/management_spec.rb`,
but it passed if run standalone because it only failed if previous tests
had already created nine users or more.
After creating a translation in spanish, it was also displaying it when selecting
the english locale.
This was due to the code picking the first translation available
With this commit, we are checking for an existing translation in the current locale
and displaying it if it exists
When visiting, for example, /admin/site_customization/information_texts?locale=fr
we were getting an `UncaughtThrowError: uncaught throw :exception`
With the following payload
```
File "/aytomad/app/participa/participacion/releases/20180726231929/app/views/admin/site_customization/information_texts/_form_field.html.erb" line 5
File "/aytomad/app/participa/participacion/releases/20180726231929/app/helpers/globalize_helper.rb" line 35 in block in globalize
```
Substituting this line seems to solve it
Note that we had to remove the portuguese local too, as it was giving a different
exception due to this change. This problem, has been solved in the original
globalization PR
In the admin section of the application, a new page
has been added so that the admins are able to manage
the selected texts for translate.
The texts have been divided in different "sections",
depending on the nature of themselves (budgets, polls,
proposals, management, etc.). Each section has become a tab
with a form associated to edit all the texts for her.
When a language is added, it's added for ALL the texts in the
application. That means that, if an admin adds french for debates,
the french form will appear for the rest of the texts. That doesn't
mean that they need to fill all the texts, only that the languages
work for all of them instead of individually.
With this commit we are logging which emails have already received the
newsletter
This could be important if something goes wrong sending the newsletter,
to be able to identify which users have already received the newsletter
and be able to skip them
We’ve had to add a new action to the Activity model (email) and add
paranoia features to be able to deal gracefully with the default
`with_hidden` scope in Activities[1]
[1]
https://github.com/AyuntamientoMadrid/consul/blob/master/app/models/acti
vity.rb#L2
We were seeing an exception when sending some emails due to having
invalid format
With this commit we are skipping this invalid formatted emails when
sending the newsletter
Notifications usually link to the associated notifiable, but the new
AdminNotifications have a link attribute that may be empty or contain an
external or internal url.
Also changed the name of the param to `min_total_supports`, which is more descriptive on what it actually does.
Backport of 75f20d5 and 07f0806 from AyuntamientoMadrid/consul fork
We were getting a validation error when skipping user verification and
creating proposals
This was due to the responsible_name being empty for unverified users
As skipping user verification is a temporary setting used until Census
integration is configured, we can safely skip this validation when this
setting is active
