When visiting http://localhost:3000/admin/site_customization/information_texts?locale=fr
and creating a translation, other languages where storing translations in db with
the following values:
"<span class=\"translation_missing\" title=\"translation missing: es.debates.index.search_results.one\">One</span>">
With this commit we are not storing this translations
Note that this only happened when using a param[:locale] in the url at least for french
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
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
