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
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.
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
Some system emails need to be manually reviewed before being sent. This
new action allows admins to see a preview of all Pending to be sent
Proposal Notification Digest messages.
Admins need to be able to see what a particular System Email looks like
with dummy data.
Also adding the first system email to be managed: the proposal
notification digest.
In case the current admin doesn't have any Notifications from
ProposalNotifications there will be a crash. We'll solve this in later
PR's with a system to "inject" sample text in email templates without
having to generate records in the database.
In the same fashion Newsletters is managed, with the only difference that
the preview is using the notification partial in the same way the index
of notifications.
* Delete all things related to banner images and styles (in code)
* Add a new test to check that the banner is showing correctly
* Update the specs accordingly to match the changes
Update dev_seed to set a random background_color and a font_color for banners (and remove everything about image and style)
Add a rake task to migrate the banner style to backgroun_color and font_color (so that the banners have the same colors than before)
Banner sections can be saved (one banner can appear in several sections)
If the hex color is changed in the textfield, the color of the color picker changes.
Add new routes for the proposal notifications edition and
abilities to let moderators edit it (mark as ignored, hide, etc.).
The notifications are not flaggable because they doesn't work like that,
but in a similar way. The moderator/administrator is in charge of hidding
them through the UI, so the normal users don't flag it as inappropriate.
New controller Moderation::ProposalNotification to manage the moderators
work.
