This is enabled by default in Rails 5.2 applications.
Note this change will cause all fragment caching to expire. We consider
it acceptable considering the page where caching is most important
(stats) is barely affected by this change, since this change only
affects the view, and the time-consuming operations are cached in the
model.
Comments are actually affected, though, and pages with thousands of
comments might take a few extra seconds to load the first time they're
accessed after this change. We don't think this is going to be an issue
on existing CONSUL installations.
This is the default encryption for cookies in Rails 5.2 applications.
The reason it isn't enabled automatically for existing applications is
these cookies are not compatible with running the application on several
servers when some of them use Rails 4. Since this isn't our case (we
don't support using different versions of CONSUL on different servers),
and existing cookies are still read correctly, we can safely enable it.
We were manually adding forgery protection to all our controllers, but
in Rails 5.2 there's an option (enabled by default for new applications)
which adds this protection to all controllers.
Even if we don't use form_with, it makes sense to configure it to behave
the same way form_for does.
This is the default option in Rails 5.2 applications. IMHO it should
have been the default option for Rails 5.1 too, since generally form
inputs need an ID so they can easily be associated with a label.
All the code in the `bin/` and the `config/` folder has been generated
running `rake app:update`, except the `escape_javascript_fix` file,
which we've removed since the code there is already included in Rails
5.2.
We're not replacing `form_for` with `form_with` for now, and even if we
did, most of our forms are not remote, so making them remote by default
would be inconvenient.
This is the default in Rails 5.1 applications. If we want to use an
asset in the public folder, we need to add the `public_folder: true`
option, making it clear that we don't expect the asset to be in the
asset pipeline.
Since we don't use `asset_path` to reference assets in the public
folder, we can safely disable the `unknown_asset_fallback` option.
This option was added by Rails 4 new application generator. However, the
`assets.digest` option is set to true by default, and recent Rails
versions don't even add this option to the environment files.
Changing it would mean reviewing and changing all our existing models,
and some of them might be tricky (like our Document and Image models,
which only validate certain associations in some cases), so we're
keeping it the way it's been until now.
The default options (which apply when `force_ssl` is set, which is the
default in CONSUL) are `{ hsts: { subdomains: true } }`, which means we
tell browsers to apply our SSL settings to subdomains as well [1].
CONSUL installations implementing multitenancy with subdomains will
benefit from this change.
[1] https://api.rubyonrails.org/classes/ActionDispatch/SSL.html
Quoting the Rails DateAndTime::Compatibility module:
> With Ruby 2.4+ the default for +to_time+ changed from
> converting to the local system time, to preserving the offset
> of the receiver. For backwards compatibility we're overriding
> this behavior
We don't need backwards compatibility in our application because we
aren't converting any time objects to the local system timezone but use
the application timezone all the time instead.
This is the default in Rails 5 applications.
This option is not enabled by default in existing applications because
it would break applications running on several domains and doing POST
requests between them or running a reverse proxy that rewrites the Host
header. Since those aren't our cases, it's safe to enable it.
This is the default for new Rails application, and adds an extra layer
of security since now the token will only be valid for its action, and
so attackers managing to change the form action will not do any harm
since the CSRF token will not work for the attackers' action.
Note that we've had InvalidAuthenticityToken exceptions for years; if we
keep getting them, chances are this change is *not* related.
The goal here is to have a notion on what the defaults are in a Rails 5
application, know why our application is working in a different way
(it's because these defaults aren't loaded in an application which was
originally developed using Rails 4), and have an explicit list of things
we are overwriting.
Furthermore, running the `app:update` rake task to upgrade to Rails 5.2
will by default add the line loading default options for Rails 5.0, so
by adopting those default options we prevent accidental mistakes when
upgrading.
We'll have to review these items and see which ones can be changed to
their default values for Rails 5 applications.
The 2.0.0 release of capistrano-bundler creates a configuration file
under `.bundle/config`. It was creating a new configuration file for
each release because we weren't using a shared folder.
Besides, quoting the capistrano-bundler README [1]:
> In order for Bundler to work efficiently on the server, its project
> configuration directory (<release_path>/.bundle/) should be persistent
> across releases. You need to add it to the linked_dirs Capistrano
> variable
[1] https://github.com/capistrano/bundler/blob/v2.0.1/README.md
Add translations files for two new languages: Indonesian and
Tagalog.
Change Serbian (Cyrillic) folder from `sr-SP` to `sr`, this is a
preference of us so we can run i18n-tasks without having to
rename the folder first.
We were checking tho project_id but not the project_key. However, in our
example secrets file we actually include a project_id but not a
project_key, and so new CONSUL installations would crash in production
environments.
Although technically the application doesn't crash if no host is
defined, we're also ignoring the current environment if no host is
defined, since errbit/airbrake is unlikely to work in this scenario.
We were getting an error when restarting Puma after upgrading Ruby. Even
if the restart command was sent successfully, Puma silently crashed and
the log had the following error:
/home/deploy/.rvm/rubies/ruby-2.4.9/lib/ruby/site_ruby/2.4.0/bundler/spec_set.rb:91:in
`block in materialize': Could not find rake-13.0.1 in any of the sources
(Bundler::GemNotFound)
So it looks like the crash happens because Puma was started when the
application used Ruby 2.4 and now when it's restarted it still tries to
use Ruby 2.4, even if the application now uses Ruby 2.5.
I haven't found a proper way to configure Puma so we can avoid this, so
as a workaround I've added the `puma:start` task after restarting Puma.
If Puma was successfully restarted, `puma:start` will do nothing; if
Puma crashed, `puma:start` will start it.
To guarantee the tasks will be executed in the proper order, the tasks
introduced by capistrano3-delayed_job and capistrano3-puma are cleared,
and then we configure the order so first we restart Puma, then restart
the Delayed Jobs processes (so there's enough time for Puma to crash if
Ruby was upgraded) and then start Puma.
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)
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.
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.
When skipping verification, we cannot apply the validation rule saying
the document number and document type must be unique, because they'll be
`nil` in many cases. So we were skipping the rule, but that makes it
possible for the same user to vote several times (for instance, once in
a booth and once via web).
So we're changing the scope of the uniqueness rule: instead of being
unique per document number, voters are unique per user. The reason we
made them unique per document number was that back in commit 900563e3
(when we added the rule), we hadn't added the relation between users and
poll voters yet.
This is the reason why this feature was implemented in the first
place: it's easy to open the editor, make some changes, close it, and
continue without realizing the changes have not been saved.
In the rest of the forms, this functionality is quite lacking. For
starters, some forms warn if there are unsaved changes, while some forms
don't, which is highly inconsistent and disorients users.
Furthermore, we were having problems with this feature after upgrading
Turbolinks, particularly in forms using CKEditor. In these cases, a lot
of hacking needs to be done in order to make this feature work properly,
since CKEditor adds some formatting automatically, and if this is done
after the form is serialized, we'll get some unexpected behavior. On the
other hand, comparing the value of a textarea against its `defaultValue`
property will work on every edge case, including using the browser's
back button or reloading the page.
Finally, users are used to the way web forms work, and aren't used to be
asked for confirmation when they change their mind and decide to leave
the page without saving the changes. Asking them for confirmation will
be annoying in most cases. Besides that, if they accidentally leave the
page, they can use the browser's back button and they'll recover the
unsaved changes.
It's true this won't happen it they accidentally close the browser's
window, but our WatchFormChanges functionality didn't work in this case
either. Using the "beforeunload" event adds more problems than it
solves, since it doesn't support custom messages (or, to be more
precise, modern browsers ignore custom messages), and it doesn't get
along with turbolinks.
Co-Authored-By: Senén Rodero Rodríguez <senenrodero@gmail.com>
We're passing the amount as a paramenter to the "remaining" text, so it
makes sense to pass it to the "amount spent" text as well.
Here we're also changing the I18n key to the text saying users can
change their vote, so it's easier to note the text is about changing
their vote, and not about the projects they have voted so far.
We were writing the same code twice, with the only difference being the
text "Sign up" in the sign_up action, and "Sign in" in the sign_in
action.
Note we're renaming the `omniauth.info_*` I18n keys so we don't need to
add new exceptions to the `ignore_unused` list, and so it's consistent
with all the other keys under the `omniauth` key.
