mergeDeep also merges columns, but it should be replaced simply.
So in the new function, first apply mergeDeep except columns, and set default columns if columns unset.
* Make Pubsubhubbub::DistributionWorker handle both single stream entry
arguments, as well as arrays of stream entries
* Add BatchedRemoveStatusService, make SuspendAccountService use it
* Improve method names
* Add test
* Add more tests
* Use PuSH payloads of 100 to have a clear mapping of
1000 input statuses -> 10 PuSH payloads
It was nice while it lasted
* Add form for account deletion
* If avatar or header are gone from source, remove them
* Add option to have SuspendAccountService remove user record, add tests
* Exclude suspended accounts from search
* Fix#2619 - When redis feed is empty, fall back to database
* Use redis value to return feed from database only while RegenerationWorker
hasn't finished running
* Fix specs
* Replace usage of reject!
TagManager.local_url? was sometimes called with an URI with a nil host,
leading to a crash in TagManager.local_url?. This fixes moves the
already-existing uri.host.blank? check in front to avoid this case.
* Move ancestors/descendants out of timelines reducer
* Refactor timelines reducer
All types of timelines now have a flat structure and use the same
reducer functions and actions
* Reintroduce some missing behaviours
* Fix wrong import in reports
* Fix includes typo
* Fix issue related to "next" pagination in timelines and notifications
* Fix bug with timeline's initial state, expandNotifications
```
DEPRECATION WARNING: The behavior of `attribute_changed?` inside of after callbacks will be changing in the next version of Rails. The new return value will reflect the behavior of calling the method after `save` returned (e.g. the opposite of what it returns now). To maintain the current behavior, use `saved_change_to_attribute?` instead. (called from block in <class:Account> at /Users/rene/Workspace/personal/ruby/mastodon/app/models/account.rb:60)
DEPRECATION WARNING: The behavior of `attribute_changed?` inside of after callbacks will be changing in the next version of Rails. The new return value will reflect the behavior of calling the method after `save` returned (e.g. the opposite of what it returns now). To maintain the current behavior, use `saved_change_to_attribute?` instead. (called from block in <class:Account> at /Users/rene/Workspace/personal/ruby/mastodon/app/models/account.rb:60)
DEPRECATION WARNING: The behavior of `attribute_changed?` inside of after callbacks will be changing in the next version of Rails. The new return value will reflect the behavior of calling the method after `save` returned (e.g. the opposite of what it returns now). To maintain the current behavior, use `saved_change_to_attribute?` instead. (called from block in <class:Account> at /Users/rene/Workspace/personal/ruby/mastodon/app/models/account.rb:60)
DEPRECATION WARNING: The behavior of `attribute_changed?` inside of after callbacks will be changing in the next version of Rails. The new return value will reflect the behavior of calling the method after `save` returned (e.g. the opposite of what it returns now). To maintain the current behavior, use `saved_change_to_attribute?` instead. (called from block in <class:Account> at /Users/rene/Workspace/personal/ruby/mastodon/app/models/account.rb:61)
DEPRECATION WARNING: The behavior of `attribute_changed?` inside of after callbacks will be changing in the next version of Rails. The new return value will reflect the behavior of calling the method after `save` returned (e.g. the opposite of what it returns now). To maintain the current behavior, use `saved_change_to_attribute?` instead. (called from block in <class:Account> at /Users/rene/Workspace/personal/ruby/mastodon/app/models/account.rb:62)
DEPRECATION WARNING: The behavior of `attribute_changed?` inside of after callbacks will be changing in the next version of Rails. The new return value will reflect the behavior of calling the method after `save` returned (e.g. the opposite of what it returns now). To maintain the current behavior, use `saved_change_to_attribute?` instead. (called from block in <class:Account> at /Users/rene/Workspace/personal/ruby/mastodon/app/models/account.rb:63)
```
Here's PR describing changes to Dirty API https://github.com/rails/rails/pull/25337
When case insensitivity is enabled via devise's `config.case_insensitive_keys` then `.find_for_authentication` method needs to be used instead of `.find_by` because second mentioned returns `nil` when valid email with different cases is passed.
More info https://github.com/plataformatec/devise/wiki/How-To:-Use-case-insensitive-emails
- Use plaintext
- Strip out URLs
- Strip out mentions
- Strip out hashtags
- Strip out whitespace from "overall" count
- Consistent between JS and Ruby
* Improve default language decision
This change allows to takes account of accepted language determined by
the user agent even if the custom default locale of the instance is
configured.
* Cover Localized more
* Fix code style
Each of mute, favourite, reblog has been updated to:
- Have a separate controller with just a create and destroy action
- Preserve historical route names to not break the API
- Mild refactoring to break up long methods
* Add specs for api statuses routes
* Update favourited_by and reblogged_by api routes
* Move methods into new controllers
* Use load_accounts methods to simplify index actions
* Clean up load_accounts methods
* Clean up link header generation
* Check for link headers in specs
* Remove unused actions from api/v1/statuses controller
* Remove specs for moved actions
* Move ApiController to Api/BaseController
* API controllers inherit from Api::BaseController
* Add coverage for various error cases in api/base controller
* Coverage for rate limit headers
* Move rate limit headers methods to concern
* Move throttle check to condition on before_action
* Move match_data variable into method
* Move utc timestamp to separate method
* Move header setting into smaller methods
* specs cleanup
Steps to reproduce the original issue:
1. Have two remote accounts, A that you don't follow, and B that you follow.
2. Have A post a toot and reply to it.
3. Boost A's reply from remote account B.
This used to cause the local instance to get A's reply but fail to link it to
the original post.
* Add regex filter on the community timeline and the public timeline
* correcting
* Adjust the height of header buttons
* Remove trailing spaces
* Remove trailing spaces
* Solve some code duplication
* reset the state of the locale files in app/javascript/mastodon/locales
* adjust to upstream
* adjust to upstream
* change keys of locale settings
* Sort results by the name
* Switch search method to simple `LIKE` matching instead of tsvector/tsquery
Previously we used scores from ts_rank_cd() to sort results, but it didn't work
because the function returns same score for all results. It's not for calculate
similarity of single words. Sometimes this bug even push out exact matching tag
from results.
Additionally, PostgreSQL supports prefix searching with standard btree index.
Using it offers simpler code, but also less index size and some speed.
* Try fixing ThreadResolveWorker calls
From my understanding of ActiveRecord, a transaction is commited as soon as
the exit of the outmost ActiveRecord.transaction block. However, inner
transaction blocks will exit without the transaction being commited.
In this case, ThreadResolveWorker were fired *within* a transaction block,
so moving the call out of it should do the trick. However, this is somewhat
fragile, as this whole codepath could be called within yet another transaction.
* Set status thread within the transaction block if it is immediately available from database
* Add a StatusFilter class to identify visibility of statuses by accounts
* Extract StatusThreadingConcern from Status
* Clarify purpose of checking for nil account
* Redirect to streaming_api_base_url
When Rails receives a request to streaming API, it most likely
means that there is another host which is configured to respond
to it. This is to redirect clients to that host if
`STREAMING_API_BASE_URL` is set as another host.
* Use the new Ruby 1.9 hash syntax
* i18n Update : Add preference setting for delete toot modal
Adding a line for "Add preference setting for delete toot modal"
* i18n update for pin/unpin
Update to add two more translations
* i18n update to have the dates in plain occitan
* Removed the blank line
* %{selft} back in the translation
* Do not fall back to StreamEntry if object_type is unavailable in TagManager
Since 24c77e57b2, when Status, the only model
with stream_entry, and StreamEntry got its own logic in uri_for and
url_for, the purpose of the fallbacks to activity_type of StreamEntry
became unclear.
This commit removes the fallbacks. When adding another model with
stream_entry in future, consider to update uri_for and url_for.
* Cover TagManager more
* Do not default the format in ProviderDiscovery
The format should be determined when discovering, as it is in the current
implementation, and it is a flaw if it is not determined.
* Spec ProviderDiscovery
* Allow mounting arbitrary columns
* Refactor column headers, allow pinning/unpinning and moving columns around
* Collapse animation
* Re-introduce scroll to top
* Save column settings properly, do not display pin options in
single-column view, do not display collapse icon if there is
nothing to collapse
* Fix one instance of public timeline being closed closing the stream
Fix back buttons inconsistently sending you back to / even if history exists
* Getting started displays links to columns that are not mounted
* Add redis key "subscribed:timeline:#{account.id}" to indicate active streaming API listeners exists.
* Add endpoint for notification only stream.
* Run PushUpdateWorker only for users uses Streaming API now.
* Move close hander streamTo(Http/Ws) -> stream(Http/Ws)End (Deal with #3370)
* Add stream type for stream start log message.
* zh-cn.json: "additional info" -> "more info"
This commit changes the "extended info" (about/more) text to something that translates to "more info", as "additional info" in zh can sound like appending things to the (ugh) navbar, I guess.
Or should I just change it to "about this site" (关于本站)?
* zh-cn.json: navbar.info -> "about this site"
* zh-臺灣.json: navbar.info -> "about this site"
Eugen Rochko