* fix RuboCop error
RuboCop doesn't work by following error.
```
$ rubocop
Error: The `Style/TrailingCommaInLiteral` cop no longer exists. Please use `Style/TrailingCommaInArrayLiteral` and/or `Style/TrailingCommaInHashLiteral` instead.
(obsolete configuration found in .rubocop.yml, please update it)
```
it comes from RuboCop 0.53.0 [\[Fix #3394\] Separate Array & Hash Literal Comma configuration by garettarrowood · Pull Request #5307 · bbatsov/rubocop](https://github.com/bbatsov/rubocop/pull/5307)
* ci(CodeClimate): specify RuboCop version 0.54
* https://docs.codeclimate.com/docs/rubocop#section-using-rubocop-s-newer-versions
* [RuboCop 0.55.0 is not available yet](https://github.com/codeclimate/codeclimate-rubocop/issues/121) on CodeClimate rubocop channel
Also add an apply_to_mentions attribute on Glitch::KeywordMute, which is
used to calculate scope. Next up: additions to the test suite to
demonstrate how scoping works.
Old statuses and statuses from Pawoo, which runs a modified version of
Mastodon, may not have been marked sensitive even if spoiler text is
present.
Such statuses are still not marked sensitve if they are local or
arrived before version upgrade. Marking recently fetched remote status
sensitive contradicts the behavior.
Considering what people expected when they authored such statuses, this
change removes the sensitivity enforcement.
This has a couple of advantages over the regex approach:
- Keywords are individually addressable, which makes it easier to gather
statistics (#363)
- Keywords can be individually applied to different feeds, e.g. skipping
mentions (#454)
It *does* end up creating many more Regexp objects. I'm not yet sure if
the difference is significant.
Conflicts:
app/javascript/mastodon/locales/en.json
app/javascript/mastodon/locales/ja.json
app/javascript/mastodon/locales/pl.json
The above conflicts appear to be a text conflict introduced by
glitch-soc's additional level of columns (i.e. moving a bunch of columns
under the Misc option). They were resolved via accept-ours.
* Update babel-eslint to version 8.2.3
* Update eslint to version 4.19.1
* Update eslint-plugin-promise to version 3.8.0
* Update eslint-plugin-react to version 7.8.2
* Upgrade eslint-plugin-jsx-a11y to version 6.0.3
* yarn test:lint --fix
* Wrong exception class: ActiveRecord::RecordNotUnique, not PG::UniqueViolation
It's completely not obvious but PG::UniqueViolation is just a string inside the exception message, not the actual class of the exception
* Favourite does not have target_account_id
* Improve account index migration
- Display more progress in stdout
- Catch PG::UniqueViolation when re-attributing favourites
- Skip callbacks and validations when re-attributing other relationships
* Use in_batches to reduce table lock-up during account merge
* Use #say_with_time to benchmark each deduplication
* Remove Collapsable and use CSS instead
* Put the CW field between the toot we are replying to and the toot field
* Use same spacing between all fields in the composing column
So far, glitch-soc used history.length to decide whether to call `goBack()` or
go to / in order to not leave the webUI. This made clicking the “Back” button
go to the “Getting started” column instead of going back in the browser's
history when such an action would leave the web UI, but also when:
- The WebUI is refreshed (F5)
- A tab is restored
- The history length reaches its maximum (e.g., 50 in Firefox)
This commit fixes these shortcomings by checking `window.history.state`.
Indeed, we only want to go back in the browser's history when the current
location has been reached from within the WebUI, which only happens via
`pushState` as far as I know. Since browser store the serialized state in
the browser history, this also survives page reload and session restoration.
This is a bit hackish. The best way would simply to somehow
use Mastodon's ApplicationController with `use_pack 'error'` from
the Rake task, but I'm not sure how to do that.
