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
We were seeing a timeout when queuing the 300.000+ emails to be
delivered
With this commit we are dealing asynchronously with this creations and
responding promptly, to avoid the web timeout of 30 seconds
