Crowdin is sending Norwegian (Norway) translations to
`config/locales/nn` folder using the `nn`locale code inside files
and we do not have any other Norwegian dialect active at Crowdin
application so those files seem to not to be needed.
Consul uses two variants of Serbian: Serbian (Cirylic), and
Serbian (Latin) so wee need to use different locale codes for each of
them to avoid collisions.
The folder names of both languages were correct but the locale code within
the files was the same for both languages "sr" so translations were mixed.
This commit changes the locale code within Serbian (Latin) translations
files to "sr-CS", also adds a new language mapping to the Crowdin config
file so next ConsulBot commits with Serbian (Latin) translations will be
done using the locale code defined at new language mapping.
I realized Crowdin suddenly started to change Portuguese-Brazilero locale
codes so i asked for Crowdin support and they fixed the problem by configuring
an internal post-processor for this project so the reason seems to be some
change on the Crowdin side. I tested it successfully by making a dummy update
on one translation to see if next commits for this language will come with the
right locale ... and it worked nice!
Following locales are now available by default:
* "bg" (Bulgarian): 98,5% translated
* "ca" (Catalan): 100 % translated
* "es-PE" (Spanish from Perú): 64,8% translated
* "eu" (Euskara): 67,8% translated
* "ka" (Georgian): 98,9% translated
* "oc" (Occitan): 98,9% translated
* "ro" (Romanian): 99,1% translated
Spanish and Euskara were enabled becuase both are near the 70% and its
fallback language (Spanish) is complete.
Add custom fallbacks:
* Catalan (ca) => Español (es).
* Español de Perú (es-PE) => Español (es).
* Euskara (eu) => Español (es).
* Portuguese-Brazilero (pt-BR) => Español (es).
* Occitan (oc) => French (fr)
In commit 74083df1 we added the possibility to assign administrators and
valuators to budgets, so they would only manage the budgets they're
assigned to.
However, when filtering projects, we were still showing all
administrators and valuators as options to filter investments. It makes
more sense to only show the valuators and administrators assigned to the
current budget.
Note this change only affects the view, and so malicious users could
technically send any other administrator or valuator ID. In this case,
they would get empty results since those administrators/valuators
wouldn't have any investments assigned, so taking this case into account
is not necessary.
We had helper methods all over the place which were only used in one
view. Since we're going to change some of them to use the budget as a
parameter, they don't belong in those helpers anymore.
Note the method `budget_heading_select_options` is used in more places,
so we're keeping it where it was.
It was removed in commit 128a8164 because we hadn't reviewed it nor
tested it properly. We're now adding it again, fixing the issues we've
found while reviewing.
This way we can simplify the HTML and easily apply font awesome icons to
any element.
Note the mixin uses `extend`, which we generally try to avoid. It's OK
in this case, since `fa-` classes only have one rule, affecting the
content of its `::before` pseudo-element. Unfortunately we can't use
`include fa-content($fa-var-#{$icon})` because it's not valid SCSS. We
could make the mixin accept an icon instead of an icon name, and call it
using `has-fa-icon(r, $fa-var-plus-square)`. However, IMHO that would
make the code a bit more complex with no real benefit.
After merge "Bump paperclip from 5.2.1 to 6.1.0 #3905" as indicated in
the release_notes columns type for attachments are changed from integer
to bigint.
For this reason we edit old migrations so that they continue to
generate integer as before.
Legislation Processes created through the admin form were getting the default color.
However, Legislation processes created by other means (like the `db:dev_seed` rake task) were not getting these default values.
This feature was originally implemented when we were using Rails 4.
With Rails 5, we can provide default values to all new Legislation processes
and simplify the code at the same time thanks to its `attribute` method.
Related commit:
https://github.com/consul/consul/pull/4080/commits/0b83be6
According to the jQuery upgrade guide:
> It is almost always a mistake to use .removeAttr("checked") on a DOM
> element. The only time it might be useful is if the DOM is later going
> to be serialized back to an HTML string. In all other cases,
> .prop("checked", false) should be used instead.
It worked differently after upgrading to jQuery 3. According to the
jQuery upgrade guide:
> It is almost always a mistake to use .removeAttr("checked") on a DOM
> element. The only time it might be useful is if the DOM is later going
> to be serialized back to an HTML string. In all other cases,
> .prop("checked", false) should be used instead.
We've had to add a couple of hacks in order to make jQuery UI datepicker
work with Turbolinks, and one of our tests is failing because the
datepicker changes its height when changing from a month with 5 weeks to
a month with 6 weeks.
We could add a workaround so the test still passes (jQuery UI doesn't
provide a configuration option to always displays 6 weeks in the
datepicker), but I think it's easier to just use the HTML5 native date
input field, which also allows us to simplify the code a bit and IMHO it
improves the user experience, particularly when using mobile phones.
Since date fields are not supported in Safari and Internet Explorer,
we're still using the jQuery UI datepicker on those browsers (and on any
other browser not supporting date fields).
Due to these changes, we're moving the tests checking datepicker's
behaviour to the dashboard. I've choosing not to change the public pages
because I'm not 100% sure everybody would like this change (some people
prefer the datepicker because we can configure the way it looks).
Since some people hosting errbit might be using it as an internal tool
with a self signed certificate, we need to patch Airbrake so it accepts
these certificates.
With Errbit, you can set up your own server and host the information
regarding your exceptions there. You can also hire Airbrake's hosting
services or easily setup Errbit on Heroku.
We're still including the rollbar gem so we don't harm CONSUL users who
are using rollbar.
Note Errbit requires an old version of Airbrake which forced users to
configure the gem. So we're adding the current environtment to
`ignore_environments` when the project id isn't defined; this way the
application won't crash in this case.
