These browsers are very old, we don't support them, and, combined, their
usage is about 0.1%. We're still supporting IE 11 through the "last 1
version" option and many versions of Android and ios through the "last 7
years" option.
Thanks to this change, we no longer generate prefixes in flexbox
properties, making debugging in the browser easier. There are no
significant differences in the size of the compiled CSS in production
environments, though (with these changes, the file is about 2% smaller).
We're upgrading to this version in order because it's the first version
that works with our current version of execjs when running the
`autoprefixer:info` task. Since it's been such a long time since the
last time we upgraded autoprefixer-rails (version 8.2.0, which is the
version we were using, was released on March 2018), and we're getting a
warning when compiling the assets with the latest version, we're going
to do it gradually; version 10.2.5.1 was released on May 2021, so it
also seems like a reasonable middlepoint.
Note we're moving the `browserlist` file to `.browserlistrc` because
that's the expected locations in new versions of autoprefixer-rails.
Also note that we're changing this file so we support browsers released
in the last 7 years, so we still support more or less the same browsers
we supported before this change (about 98% of the browsers out there).
We might reduce it to 5 years in the future.
Bumps [autoprefixer-rails](https://github.com/ai/autoprefixer-rails) from 8.2.0 to 10.2.5.1
- [Changelog](https://github.com/ai/autoprefixer-rails/blob/master/CHANGELOG.md)
- [Commits](https://github.com/ai/autoprefixer-rails/compare/8.2.0...10.2.5.1
This rule was added in Rubocop version 1.57.0. Even if we were always
following it, we think it's useful.
Note this rule doesn't detect the fact that you can still write
multiline lambdas using `{}` as delimiters instead of `do...end`, which
we fixed in the previous commit. But at least it detects the opposite
case.
Since we've changed these scopes in the previous commit because of the
new rubocop version, we're also making them consistent with the other
scopes in the same file.
Since Foundation hasn't released a new gem for years, we haven't been
able to upgrade Foundation to its most recent version.
Thanks to this change, we'll be able to do so.
Note we're using motion-ui version 2.0.3 because version 2.0.5 (the
latest at the moment) requires Dart Sass.
The Bing sitemap submission was removed in sitemap_generator 6.3.0 [1],
and Google has also deprecated the ping and we're getting an error when
deploying:
```
Ping failed for Google: #<OpenURI::HTTPError: 404 Sitemaps ping is
deprecated.
```
Since those were the only two search engines we were pinging in the
past, we're removing the code that did so.
[1] Pull request 408 in https://github.com/kjvarga/sitemap_generator
There was only one different line between these two lines, and we really
want these two files to be as similar as possible, so testing on a
staging server we get the same results we'll get on production.
This duplication made it easy to forget to update the staging.rb file
when updating the production.rb, particularly when upgrading to a new
version of Rails, which automatically changes the production.rb file but
not the staging.rb one.
So, now that we're getting ready to upgrade to Rails 7.0, we're basing
the staging configuration on the production one, just like we based the
preproduction configuration on the staging one in commit 7b91adb16.
This was accidentally introduced in commit 64aa1ffe0. Pronto didn't
detect it because the line itself was fine; the problem lied in its
place within the file.
This is possible since audited 5.4.3, and IMHO it's useful because
audited has added a callback on touch, which could result in strange
behavior since we might use the `touch` method to expire the cache
without doing any changes.
While this doesn't affect our application because we're using the `on:`
option of the `audited` method in the budget investment model, it'll
make it easier to enable audited for other classes in custom
installations without having to worry about the (usually undesired)
touch callbacks.
All these types of tests have already been grouped together in the
comments_specs file which contains different factories including
budget_investments.
I don't think it is necessary to maintain these tests.
The test "display administrator id on public views" is not correct. The valuation comments
are not display never on public views. If we reload this admin page we can see that the
description is render instead of administrator_id as we can see at the upper test:
```
scenario "display administrator description on admin views"
```
The deleted test was passed because there is an error at the moment to render the comments.
As we can see in the file ´app/views/comments/create.js.erb:10´ we try render comment
without valuation value:
```
App.Comments.add_comment(parent_id, "<li><%= j(render @comment) %></li>");
```
That it is necessary to render correctly the description or the id.
By other hand the test "public users not see admin description" is already being checked
in the 'system/comments_specs'. However, we are going to add a new expectation to
make sure that the admin description does not appear on the public pages.
