We were expecting translation parameters in legislation processes
`update` action. However, those parameters aren't sent when we get to
that action through the "proposals" tab.
By doing so and including it in ActionDispatch::Routing::UrlFor, we make
it available in controllers, helpers and specs, and so we can remove the
duplication we had there with methods dealing with the same problem.
Even if monkey-patching is ugly, using a different module and executing
ActionDispatch::Routing::UrlFor.send(:include, MyModule) wouldn't make
the method available in the controller.
Dashboard routes have been refactored. Now instead of having resources
for dashboard and routes inside a dashboard namespace the proposal
routes contain a dashboar singleton containing everything related to it.
Previously, action as requesting some action from administrators by
default. Now this flag is false by default when a new proposed
action/resource is created.
FIxed issue in last commit: supports controller were not correctly
filling the holes without data.
Fixed duplication in supports and successful supports controller using a
concer.
Successfull supports controller will fill the holes without data in the
same way that supports controller does.
Supports controller now fill the holes in the results: When there are no
supports collected for one interval it takes the accumulated value from the
previous one.
Data starts in the publication date.
If we ignore all params that are blank, there is no way to
"remove" an attribute (i.e. change its value to blank)
On the other hand, we don't want to create new translations
where all fields are empty, so the new code keeps only the
blank fields which belong to existing translations.
* Added missing specs
* Removed models that were refactored previously
* Added simplecov when executing specs locally
* Fixed bug in poll model validation that was causing an 500 error.
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.
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
