- Cleanup Translatable module (`translation_params` method too large)
- Move globalize_helpers partial to admin folder
- Use any class for method translation_params
- Helpers in `GlobalizeHelpers` make sure all are in use and see if they can be more legible
- Review js name clases and methods see if they can be more legible
- Refactor milestone views into partials with nice spacing between attributes
There was a problem with the portuguese locale.
The locale was pt-BR, but `globalize_accessors` gem
doesn't allow the creation of methods using locales
with that format.
To avoid transforming pt-BR to pt and lose the distinction
of the different variations of the language, a function has
been added to transform pt-BR into pt_br (without changing
the locale itself). That way, when globalize uses the locales,
all of them will have a valid format (downcased and underscored)
AND they will be always the same (comparing pt-BR with pt_br
doesn't work).
When the locale changes the corresponding tab is
highlighted automatically.
When a language is added to the milestone, the tab
is highlighted automatically.
To delete a translation, a link has been added. This
link works for the selected language. It hides all the
things related to a language (the tab and the text_area)
and empties the text area, so that the value is blank
in the param hash. A variable called `delete_translations[]`
is changed.
e.g. If admin wants to remove English language,
delete_translations[:en] will be 1; if not, it will be 0.
When the milestone is updated, there is a before_action
callback that cleans the selected languages for deletion
(looking the delete_translations[] variable).
Because of the deleted translations are blank in param hash,
them won't be saved in DB.
When there are no budgets we were seeing an exception in the budgets’
index
There are two parts to take into account here:
1) Making sure there is a current_budget present, otherwise we display
the “no budgets” message
2) The map helper is called from the controller, so we need to make
sure current_budget is present there too
Note: We could have added a bunch of `try` statements in the budgets’s
index, instead of using a conditional, however there are quite a few
`current_budget` calls so it seems more appropriate to use a conditional
Now that we have the option of voting in multiple headings per group,
the method of voting in a “different heading assigned” has become
deprecated and thus removed
ApplicationHelper#format_price and Budget#formatted_amount has the same
objective and code, but the Budget#formatted_amount method also uses the
currency of the Budget to correctly give currencies format.
By replacing usage of format_price with formatted_amount we can remove
format_price and have a single location for currency format logic.
Why:
The logic to construct the link to a heading (if it exists) is in three
different places, this is a clear candidate for a helper method.
How:
Just checking at the helper method if `assigned_heading` and `budget`
has values and composing the link if so.
Clear instance variable names help understand what's going around when
you're deep 2 or 3 partials. In this case @budget is only used to carry
around the current_budget so @current_budget is more descriptive.
Using `current_budget` directly around would be an alternative, but
maybe not as maintainable in case we want to change which budget is
being shown (for example the drafting one if you're admin).
We only need finished budget's at budget's index "Finished budgets"
section. So we add the `finished` scope to @budgets variable, and rename
it so its clear what it contains.
Also avoid showing the "Finished budgets" section if there is none
