because it may causes flicker on the conversation when it contains blocked/muted user's status.
We use `/api/v1/statuses/{id}/context` to obtain status ids in the
conversation which filters blocked/muted user, but also uses internal
cache constructed from `in_reply_to_id` by `normalizeStatus()` in
`reducers/timelines.js` on each status loading which doesn't filter.
So statuses appears in conversation if those are cached, even those
statuses are from blocked/muted user. Then context cache will be updated
with the result of the context API and those statuses will be removed.
I have left the `normalizeStatus()` function itself which is called many
functions in the file as a placeholder for now, but maybe it should be
removed completely.
In single user mode, visitors are redirected to the single user's
profile page. So, if you are the owner without a session, you start
from that page, click the login button and authenticate yourself
expecting you'll soon get started with the home page, but in reality
you'll get redirected back to where you started from -- your own
profile page.
This fixes the behavior by redirecting you home after login if you
have started from your own profile page.
I've found this issue when I clicked replies to muted user on the timeline.
Properties I've removed in here were added with lazy loading using
IntersectionObserver (8e4d1cba), but those statuses are not need to be
tracked anyway because it will be rendered as only empty div.
There are many spots throughout the codebase which are showing as covered by
specs in the simplecov output -- but which are not actually run, because they
are on the same line as a guard clause.
I plan on fixing some of these issues, but don't want to keep triggering this
rubocop style violation.
My preference would be that we use the PR review process to identify places
where a guard clause might be appropriate, but that we leave this cop turned off
by default.
This will reduce requests on who have only few statuses.
- Use next link header to detect more items from first request
- Omit next link header if result items are fewer than requested count
(It had omit it only if result was empty before)
* @object is not needed
* Remove unneeded dependencies
* Do not call private method
* Prefer #respond_to_missing? over #respond_to?
`#respond_to?` doesn't support `User.settings.method(:method_name)`
* Use find_or_initialize_by instead of
* Add load more button for large screens
* Fix `next` state value on the first loading
* Don't load if `isLoading || !hasMore`
* Start load on near the bottom
Link headers in following/followers API should include follow_id as max_id/since_id.
However, these API use current_user's account_id instead of follow_id from #3167.
This causes irrelevant result on loading more users.
- Increase coverage to exercise all parts of each action
- Move into namespace to share common code
- Misc refactor of each action for smaller methods, simpler code
* Nanobox Support
- Added support for running Mastodon using Nanobox, both for local development, and for deployment to production
- Dev mode tested and is working properly
- Deployment is undergoing test as of this writing. If it works, this line will be amended to state success; if not, one or more subsequent commits will provide fixes.
* [nanobox] Resolve Deploy Issues
Everything seems to work except routing to the streaming API. Will investigate with the Nanobox staff and make fix commits if needed.
Changes made:
- Also need `NODE_ENV` in production
- Node runs on `:4000`
- Use `envsubst` to commit `.env.production` values, since `dotEnv` packages don't always support referencing other variables
- Can't precompile assets after `transform` hook, but do this locally so it only has to be done once.
- Rails won't create `production.log` on its own, so we do this ourselves.
- Some `start` commands run from `/data/` for some reason, so use absolute paths in command arguments
* [nanobox] Update Ruby version
* [nanobox] Fix db.rake Ruby code style issues
* [nanobox] Minor Fixes
Some minor adjustments to improve functionality:
- Fixed routing to `web.stream` instances
- Adjust `.env.nanobox` to properly generate a default `SMTP_FROM_ADDRESS` via `envsubst`
- Update Nginx configs to properly support the needed HTTP version and headers for proper functionality (the streaming API doesn't work without some of these settings in place)
* [nanobox] Move usage info to docs repo
* [nanobox] Updates for 1.2.x
- Need to leave out `pkg-config` since Nanobox deploys without Ruby's headers - create a gem group to exclude the gem during Nanobox installs, but allow it to remain part of the default set otherwise
- Update cron jobs to cover new/updated Rake tasks
- Update `.env.nanobox` to include latest defaults and additions
* [nanobox] Fix for nokogumbo, added in 1.3.x
Apparently, nokogumbo (pulled in by sanitize, added with `OEmbed Support for PreviewCard` (#2337) - 88725d6) tries to install before nokogiri, despite needing nokogiri available to build properly. Instruct it to use the same settings as nokogiri does when building nokogiri directly, instead of via bundler.
* [nanobox] Set NODE_ENV during asset compile
The switch to WebPack will rely on the local value of the NODE_ENV evar, so set it to production during asset compilation.
* [nanobox] Rebase on master; update Nginx configs
- `pkg-config` Gem no longer causes issues in Nanobox, so revert the Gemfile change which allowed excluding it
- Update Nginx configuration files with latest recommendations from production documentation
- Rebase on master to Get This Merged™
Everything should be golden!
unarist