chinwagsocial/spec/requests/api/v1/statuses_spec.rb

311 lines
9.7 KiB
Ruby
Raw Normal View History

# frozen_string_literal: true
require 'rails_helper'
describe '/api/v1/statuses' do
context 'with an oauth token' do
let(:user) { Fabricate(:user) }
let(:client_app) { Fabricate(:application, name: 'Test app', website: 'http://testapp.com') }
let(:token) { Fabricate(:accessible_access_token, resource_owner_id: user.id, application: client_app, scopes: scopes) }
let(:headers) { { 'Authorization' => "Bearer #{token.token}" } }
describe 'GET /api/v1/statuses?id[]=:id' do
let(:status) { Fabricate(:status) }
let(:other_status) { Fabricate(:status) }
let(:scopes) { 'read:statuses' }
it 'returns expected response' do
get '/api/v1/statuses', headers: headers, params: { id: [status.id, other_status.id, 123_123] }
expect(response).to have_http_status(200)
expect(body_as_json).to contain_exactly(
hash_including(id: status.id.to_s),
hash_including(id: other_status.id.to_s)
)
end
end
describe 'GET /api/v1/statuses/:id' do
subject do
get "/api/v1/statuses/#{status.id}", headers: headers
end
let(:scopes) { 'read:statuses' }
let(:status) { Fabricate(:status, account: user.account) }
it_behaves_like 'forbidden for wrong scope', 'write write:statuses'
it 'returns http success' do
subject
expect(response).to have_http_status(200)
end
Revamp post filtering system (#18058) * Add model for custom filter keywords * Use CustomFilterKeyword internally Does not change the API * Fix /filters/edit and /filters/new * Add migration tests * Remove whole_word column from custom_filters (covered by custom_filter_keywords) * Redesign /filters Instead of a list, present a card that displays more information and handles multiple keywords per filter. * Redesign /filters/new and /filters/edit to add and remove keywords This adds a new gem dependency: cocoon, as well as a npm dependency: cocoon-js-vanilla. Those are used to easily populate and remove form fields from the user interface when manipulating multiple keyword filters at once. * Add /api/v2/filters to edit filter with multiple keywords Entities: - `Filter`: `id`, `title`, `filter_action` (either `hide` or `warn`), `context` `keywords` - `FilterKeyword`: `id`, `keyword`, `whole_word` API endpoits: - `GET /api/v2/filters` to list filters (including keywords) - `POST /api/v2/filters` to create a new filter `keywords_attributes` can also be passed to create keywords in one request - `GET /api/v2/filters/:id` to read a particular filter - `PUT /api/v2/filters/:id` to update a new filter `keywords_attributes` can also be passed to edit, delete or add keywords in one request - `DELETE /api/v2/filters/:id` to delete a particular filter - `GET /api/v2/filters/:id/keywords` to list keywords for a filter - `POST /api/v2/filters/:filter_id/keywords/:id` to add a new keyword to a filter - `GET /api/v2/filter_keywords/:id` to read a particular keyword - `PUT /api/v2/filter_keywords/:id` to edit a particular keyword - `DELETE /api/v2/filter_keywords/:id` to delete a particular keyword * Change from `irreversible` boolean to `action` enum * Remove irrelevent `irreversible_must_be_within_context` check * Fix /filters/new and /filters/edit with update for filter_action * Fix Rubocop/Codeclimate complaining about task names * Refactor FeedManager#phrase_filtered? This moves regexp building and filter caching to the `CustomFilter` class. This does not change the functional behavior yet, but this changes how the cache is built, doing per-custom_filter regexps so that filters can be matched independently, while still offering caching. * Perform server-side filtering and output result in REST API * Fix numerous filters_changed events being sent when editing multiple keywords at once * Add some tests * Use the new API in the WebUI - use client-side logic for filters we have fetched rules for. This is so that filter changes can be retroactively applied without reloading the UI. - use server-side logic for filters we haven't fetched rules for yet (e.g. network error, or initial timeline loading) * Minor optimizations and refactoring * Perform server-side filtering on the streaming server * Change the wording of filter action labels * Fix issues pointed out by linter * Change design of “Show anyway” link in accordence to review comments * Drop “irreversible” filtering behavior * Move /api/v2/filter_keywords to /api/v1/filters/keywords * Rename `filter_results` attribute to `filtered` * Rename REST::LegacyFilterSerializer to REST::V1::FilterSerializer * Fix systemChannelId value in streaming server * Simplify code by removing client-side filtering code The simplifcation comes at a cost though: filters aren't retroactively applied anymore.
2022-06-28 17:42:13 +10:00
context 'when post includes filtered terms' do
let(:status) { Fabricate(:status, text: 'this toot is about that banned word') }
before do
user.account.custom_filters.create!(phrase: 'filter1', context: %w(home), action: :hide, keywords_attributes: [{ keyword: 'banned' }, { keyword: 'irrelevant' }])
end
it 'returns filter information', :aggregate_failures do
subject
expect(response).to have_http_status(200)
expect(body_as_json[:filtered][0]).to include({
Revamp post filtering system (#18058) * Add model for custom filter keywords * Use CustomFilterKeyword internally Does not change the API * Fix /filters/edit and /filters/new * Add migration tests * Remove whole_word column from custom_filters (covered by custom_filter_keywords) * Redesign /filters Instead of a list, present a card that displays more information and handles multiple keywords per filter. * Redesign /filters/new and /filters/edit to add and remove keywords This adds a new gem dependency: cocoon, as well as a npm dependency: cocoon-js-vanilla. Those are used to easily populate and remove form fields from the user interface when manipulating multiple keyword filters at once. * Add /api/v2/filters to edit filter with multiple keywords Entities: - `Filter`: `id`, `title`, `filter_action` (either `hide` or `warn`), `context` `keywords` - `FilterKeyword`: `id`, `keyword`, `whole_word` API endpoits: - `GET /api/v2/filters` to list filters (including keywords) - `POST /api/v2/filters` to create a new filter `keywords_attributes` can also be passed to create keywords in one request - `GET /api/v2/filters/:id` to read a particular filter - `PUT /api/v2/filters/:id` to update a new filter `keywords_attributes` can also be passed to edit, delete or add keywords in one request - `DELETE /api/v2/filters/:id` to delete a particular filter - `GET /api/v2/filters/:id/keywords` to list keywords for a filter - `POST /api/v2/filters/:filter_id/keywords/:id` to add a new keyword to a filter - `GET /api/v2/filter_keywords/:id` to read a particular keyword - `PUT /api/v2/filter_keywords/:id` to edit a particular keyword - `DELETE /api/v2/filter_keywords/:id` to delete a particular keyword * Change from `irreversible` boolean to `action` enum * Remove irrelevent `irreversible_must_be_within_context` check * Fix /filters/new and /filters/edit with update for filter_action * Fix Rubocop/Codeclimate complaining about task names * Refactor FeedManager#phrase_filtered? This moves regexp building and filter caching to the `CustomFilter` class. This does not change the functional behavior yet, but this changes how the cache is built, doing per-custom_filter regexps so that filters can be matched independently, while still offering caching. * Perform server-side filtering and output result in REST API * Fix numerous filters_changed events being sent when editing multiple keywords at once * Add some tests * Use the new API in the WebUI - use client-side logic for filters we have fetched rules for. This is so that filter changes can be retroactively applied without reloading the UI. - use server-side logic for filters we haven't fetched rules for yet (e.g. network error, or initial timeline loading) * Minor optimizations and refactoring * Perform server-side filtering on the streaming server * Change the wording of filter action labels * Fix issues pointed out by linter * Change design of “Show anyway” link in accordence to review comments * Drop “irreversible” filtering behavior * Move /api/v2/filter_keywords to /api/v1/filters/keywords * Rename `filter_results` attribute to `filtered` * Rename REST::LegacyFilterSerializer to REST::V1::FilterSerializer * Fix systemChannelId value in streaming server * Simplify code by removing client-side filtering code The simplifcation comes at a cost though: filters aren't retroactively applied anymore.
2022-06-28 17:42:13 +10:00
filter: a_hash_including({
id: user.account.custom_filters.first.id.to_s,
title: 'filter1',
filter_action: 'hide',
}),
keyword_matches: ['banned'],
})
end
end
context 'when post is explicitly filtered' do
let(:status) { Fabricate(:status, text: 'hello world') }
before do
filter = user.account.custom_filters.create!(phrase: 'filter1', context: %w(home), action: :hide)
filter.statuses.create!(status_id: status.id)
end
it 'returns filter information', :aggregate_failures do
subject
expect(response).to have_http_status(200)
expect(body_as_json[:filtered][0]).to include({
filter: a_hash_including({
id: user.account.custom_filters.first.id.to_s,
title: 'filter1',
filter_action: 'hide',
}),
status_matches: [status.id.to_s],
})
end
end
Revamp post filtering system (#18058) * Add model for custom filter keywords * Use CustomFilterKeyword internally Does not change the API * Fix /filters/edit and /filters/new * Add migration tests * Remove whole_word column from custom_filters (covered by custom_filter_keywords) * Redesign /filters Instead of a list, present a card that displays more information and handles multiple keywords per filter. * Redesign /filters/new and /filters/edit to add and remove keywords This adds a new gem dependency: cocoon, as well as a npm dependency: cocoon-js-vanilla. Those are used to easily populate and remove form fields from the user interface when manipulating multiple keyword filters at once. * Add /api/v2/filters to edit filter with multiple keywords Entities: - `Filter`: `id`, `title`, `filter_action` (either `hide` or `warn`), `context` `keywords` - `FilterKeyword`: `id`, `keyword`, `whole_word` API endpoits: - `GET /api/v2/filters` to list filters (including keywords) - `POST /api/v2/filters` to create a new filter `keywords_attributes` can also be passed to create keywords in one request - `GET /api/v2/filters/:id` to read a particular filter - `PUT /api/v2/filters/:id` to update a new filter `keywords_attributes` can also be passed to edit, delete or add keywords in one request - `DELETE /api/v2/filters/:id` to delete a particular filter - `GET /api/v2/filters/:id/keywords` to list keywords for a filter - `POST /api/v2/filters/:filter_id/keywords/:id` to add a new keyword to a filter - `GET /api/v2/filter_keywords/:id` to read a particular keyword - `PUT /api/v2/filter_keywords/:id` to edit a particular keyword - `DELETE /api/v2/filter_keywords/:id` to delete a particular keyword * Change from `irreversible` boolean to `action` enum * Remove irrelevent `irreversible_must_be_within_context` check * Fix /filters/new and /filters/edit with update for filter_action * Fix Rubocop/Codeclimate complaining about task names * Refactor FeedManager#phrase_filtered? This moves regexp building and filter caching to the `CustomFilter` class. This does not change the functional behavior yet, but this changes how the cache is built, doing per-custom_filter regexps so that filters can be matched independently, while still offering caching. * Perform server-side filtering and output result in REST API * Fix numerous filters_changed events being sent when editing multiple keywords at once * Add some tests * Use the new API in the WebUI - use client-side logic for filters we have fetched rules for. This is so that filter changes can be retroactively applied without reloading the UI. - use server-side logic for filters we haven't fetched rules for yet (e.g. network error, or initial timeline loading) * Minor optimizations and refactoring * Perform server-side filtering on the streaming server * Change the wording of filter action labels * Fix issues pointed out by linter * Change design of “Show anyway” link in accordence to review comments * Drop “irreversible” filtering behavior * Move /api/v2/filter_keywords to /api/v1/filters/keywords * Rename `filter_results` attribute to `filtered` * Rename REST::LegacyFilterSerializer to REST::V1::FilterSerializer * Fix systemChannelId value in streaming server * Simplify code by removing client-side filtering code The simplifcation comes at a cost though: filters aren't retroactively applied anymore.
2022-06-28 17:42:13 +10:00
context 'when reblog includes filtered terms' do
let(:status) { Fabricate(:status, reblog: Fabricate(:status, text: 'this toot is about that banned word')) }
before do
user.account.custom_filters.create!(phrase: 'filter1', context: %w(home), action: :hide, keywords_attributes: [{ keyword: 'banned' }, { keyword: 'irrelevant' }])
end
it 'returns filter information', :aggregate_failures do
subject
expect(response).to have_http_status(200)
expect(body_as_json[:reblog][:filtered][0]).to include({
Revamp post filtering system (#18058) * Add model for custom filter keywords * Use CustomFilterKeyword internally Does not change the API * Fix /filters/edit and /filters/new * Add migration tests * Remove whole_word column from custom_filters (covered by custom_filter_keywords) * Redesign /filters Instead of a list, present a card that displays more information and handles multiple keywords per filter. * Redesign /filters/new and /filters/edit to add and remove keywords This adds a new gem dependency: cocoon, as well as a npm dependency: cocoon-js-vanilla. Those are used to easily populate and remove form fields from the user interface when manipulating multiple keyword filters at once. * Add /api/v2/filters to edit filter with multiple keywords Entities: - `Filter`: `id`, `title`, `filter_action` (either `hide` or `warn`), `context` `keywords` - `FilterKeyword`: `id`, `keyword`, `whole_word` API endpoits: - `GET /api/v2/filters` to list filters (including keywords) - `POST /api/v2/filters` to create a new filter `keywords_attributes` can also be passed to create keywords in one request - `GET /api/v2/filters/:id` to read a particular filter - `PUT /api/v2/filters/:id` to update a new filter `keywords_attributes` can also be passed to edit, delete or add keywords in one request - `DELETE /api/v2/filters/:id` to delete a particular filter - `GET /api/v2/filters/:id/keywords` to list keywords for a filter - `POST /api/v2/filters/:filter_id/keywords/:id` to add a new keyword to a filter - `GET /api/v2/filter_keywords/:id` to read a particular keyword - `PUT /api/v2/filter_keywords/:id` to edit a particular keyword - `DELETE /api/v2/filter_keywords/:id` to delete a particular keyword * Change from `irreversible` boolean to `action` enum * Remove irrelevent `irreversible_must_be_within_context` check * Fix /filters/new and /filters/edit with update for filter_action * Fix Rubocop/Codeclimate complaining about task names * Refactor FeedManager#phrase_filtered? This moves regexp building and filter caching to the `CustomFilter` class. This does not change the functional behavior yet, but this changes how the cache is built, doing per-custom_filter regexps so that filters can be matched independently, while still offering caching. * Perform server-side filtering and output result in REST API * Fix numerous filters_changed events being sent when editing multiple keywords at once * Add some tests * Use the new API in the WebUI - use client-side logic for filters we have fetched rules for. This is so that filter changes can be retroactively applied without reloading the UI. - use server-side logic for filters we haven't fetched rules for yet (e.g. network error, or initial timeline loading) * Minor optimizations and refactoring * Perform server-side filtering on the streaming server * Change the wording of filter action labels * Fix issues pointed out by linter * Change design of “Show anyway” link in accordence to review comments * Drop “irreversible” filtering behavior * Move /api/v2/filter_keywords to /api/v1/filters/keywords * Rename `filter_results` attribute to `filtered` * Rename REST::LegacyFilterSerializer to REST::V1::FilterSerializer * Fix systemChannelId value in streaming server * Simplify code by removing client-side filtering code The simplifcation comes at a cost though: filters aren't retroactively applied anymore.
2022-06-28 17:42:13 +10:00
filter: a_hash_including({
id: user.account.custom_filters.first.id.to_s,
title: 'filter1',
filter_action: 'hide',
}),
keyword_matches: ['banned'],
})
end
end
end
describe 'GET /api/v1/statuses/:id/context' do
let(:scopes) { 'read:statuses' }
let(:status) { Fabricate(:status, account: user.account) }
2016-09-16 08:27:09 +10:00
before do
Fabricate(:status, account: user.account, thread: status)
end
2016-09-16 08:27:09 +10:00
it 'returns http success' do
get "/api/v1/statuses/#{status.id}/context", headers: headers
expect(response).to have_http_status(200)
end
2016-09-16 08:27:09 +10:00
end
describe 'POST /api/v1/statuses' do
subject do
post '/api/v1/statuses', headers: headers, params: params
end
let(:scopes) { 'write:statuses' }
let(:params) { { status: 'Hello world' } }
it_behaves_like 'forbidden for wrong scope', 'read read:statuses'
context 'with a basic status body' do
it 'returns rate limit headers', :aggregate_failures do
subject
expect(response).to have_http_status(200)
expect(response.headers['X-RateLimit-Limit']).to eq RateLimiter::FAMILIES[:statuses][:limit].to_s
expect(response.headers['X-RateLimit-Remaining']).to eq (RateLimiter::FAMILIES[:statuses][:limit] - 1).to_s
end
end
context 'with a safeguard' do
let!(:alice) { Fabricate(:account, username: 'alice') }
let!(:bob) { Fabricate(:account, username: 'bob') }
let(:params) { { status: '@alice hm, @bob is really annoying lately', allowed_mentions: [alice.id] } }
it 'returns serialized extra accounts in body', :aggregate_failures do
subject
expect(response).to have_http_status(422)
expect(body_as_json[:unexpected_accounts].map { |a| a.slice(:id, :acct) }).to eq [{ id: bob.id.to_s, acct: bob.acct }]
end
end
context 'with missing parameters' do
let(:params) { {} }
it 'returns rate limit headers', :aggregate_failures do
subject
expect(response).to have_http_status(422)
expect(response.headers['X-RateLimit-Limit']).to eq RateLimiter::FAMILIES[:statuses][:limit].to_s
end
end
context 'when exceeding rate limit' do
before do
rate_limiter = RateLimiter.new(user.account, family: :statuses)
RateLimiter::FAMILIES[:statuses][:limit].times { rate_limiter.record! }
end
it 'returns rate limit headers', :aggregate_failures do
subject
expect(response).to have_http_status(429)
expect(response.headers['X-RateLimit-Limit']).to eq RateLimiter::FAMILIES[:statuses][:limit].to_s
expect(response.headers['X-RateLimit-Remaining']).to eq '0'
end
end
context 'with missing thread' do
let(:params) { { status: 'Hello world', in_reply_to_id: 0 } }
it 'returns http not found' do
subject
expect(response).to have_http_status(404)
end
end
context 'when scheduling a status' do
let(:params) { { status: 'Hello world', scheduled_at: 10.minutes.from_now } }
let(:account) { user.account }
it 'returns HTTP 200' do
subject
expect(response).to have_http_status(200)
end
it 'creates a scheduled status' do
expect { subject }.to change { account.scheduled_statuses.count }.from(0).to(1)
end
context 'when the scheduling time is less than 5 minutes' do
let(:params) { { status: 'Hello world', scheduled_at: 4.minutes.from_now } }
it 'does not create a scheduled status', :aggregate_failures do
subject
expect(response).to have_http_status(422)
expect(account.scheduled_statuses).to be_empty
end
end
end
end
2016-03-19 22:13:47 +11:00
describe 'DELETE /api/v1/statuses/:id' do
subject do
delete "/api/v1/statuses/#{status.id}", headers: headers
end
let(:scopes) { 'write:statuses' }
let(:status) { Fabricate(:status, account: user.account) }
it_behaves_like 'forbidden for wrong scope', 'read read:statuses'
it 'removes the status', :aggregate_failures do
subject
expect(response).to have_http_status(200)
2023-02-17 23:45:27 +11:00
expect(Status.find_by(id: status.id)).to be_nil
end
end
describe 'PUT /api/v1/statuses/:id' do
subject do
put "/api/v1/statuses/#{status.id}", headers: headers, params: { status: 'I am updated' }
end
let(:scopes) { 'write:statuses' }
let(:status) { Fabricate(:status, account: user.account) }
it_behaves_like 'forbidden for wrong scope', 'read read:statuses'
it 'updates the status', :aggregate_failures do
subject
expect(response).to have_http_status(200)
expect(status.reload.text).to eq 'I am updated'
end
end
end
context 'without an oauth token' do
context 'with a private status' do
let(:status) { Fabricate(:status, visibility: :private) }
describe 'GET /api/v1/statuses/:id' do
Spelling (#17705) * spelling: account Signed-off-by: Josh Soref <jsoref@users.noreply.github.com> * spelling: affiliated Signed-off-by: Josh Soref <jsoref@users.noreply.github.com> * spelling: appearance Signed-off-by: Josh Soref <jsoref@users.noreply.github.com> * spelling: autosuggest Signed-off-by: Josh Soref <jsoref@users.noreply.github.com> * spelling: cacheable Signed-off-by: Josh Soref <jsoref@users.noreply.github.com> * spelling: component Signed-off-by: Josh Soref <jsoref@users.noreply.github.com> * spelling: conversations Signed-off-by: Josh Soref <jsoref@users.noreply.github.com> * spelling: domain.example Clarify what's distinct and use RFC friendly domain space. Signed-off-by: Josh Soref <jsoref@users.noreply.github.com> * spelling: environment Signed-off-by: Josh Soref <jsoref@users.noreply.github.com> * spelling: exceeds Signed-off-by: Josh Soref <jsoref@users.noreply.github.com> * spelling: functional Signed-off-by: Josh Soref <jsoref@users.noreply.github.com> * spelling: inefficiency Signed-off-by: Josh Soref <jsoref@users.noreply.github.com> * spelling: not Signed-off-by: Josh Soref <jsoref@users.noreply.github.com> * spelling: notifications Signed-off-by: Josh Soref <jsoref@users.noreply.github.com> * spelling: occurring Signed-off-by: Josh Soref <jsoref@users.noreply.github.com> * spelling: position Signed-off-by: Josh Soref <jsoref@users.noreply.github.com> * spelling: progress Signed-off-by: Josh Soref <jsoref@users.noreply.github.com> * spelling: promotable Signed-off-by: Josh Soref <jsoref@users.noreply.github.com> * spelling: reblogging Signed-off-by: Josh Soref <jsoref@users.noreply.github.com> * spelling: repetitive Signed-off-by: Josh Soref <jsoref@users.noreply.github.com> * spelling: resolve Signed-off-by: Josh Soref <jsoref@users.noreply.github.com> * spelling: saturated Signed-off-by: Josh Soref <jsoref@users.noreply.github.com> * spelling: similar Signed-off-by: Josh Soref <jsoref@users.noreply.github.com> * spelling: strategies Signed-off-by: Josh Soref <jsoref@users.noreply.github.com> * spelling: success Signed-off-by: Josh Soref <jsoref@users.noreply.github.com> * spelling: targeting Signed-off-by: Josh Soref <jsoref@users.noreply.github.com> * spelling: thumbnails Signed-off-by: Josh Soref <jsoref@users.noreply.github.com> * spelling: unauthorized Signed-off-by: Josh Soref <jsoref@users.noreply.github.com> * spelling: unsensitizes Signed-off-by: Josh Soref <jsoref@users.noreply.github.com> * spelling: validations Signed-off-by: Josh Soref <jsoref@users.noreply.github.com> * spelling: various Signed-off-by: Josh Soref <jsoref@users.noreply.github.com> Co-authored-by: Josh Soref <jsoref@users.noreply.github.com>
2022-03-07 08:51:40 +11:00
it 'returns http unauthorized' do
get "/api/v1/statuses/#{status.id}"
expect(response).to have_http_status(404)
end
end
describe 'GET /api/v1/statuses/:id/context' do
before do
Fabricate(:status, thread: status)
end
Spelling (#17705) * spelling: account Signed-off-by: Josh Soref <jsoref@users.noreply.github.com> * spelling: affiliated Signed-off-by: Josh Soref <jsoref@users.noreply.github.com> * spelling: appearance Signed-off-by: Josh Soref <jsoref@users.noreply.github.com> * spelling: autosuggest Signed-off-by: Josh Soref <jsoref@users.noreply.github.com> * spelling: cacheable Signed-off-by: Josh Soref <jsoref@users.noreply.github.com> * spelling: component Signed-off-by: Josh Soref <jsoref@users.noreply.github.com> * spelling: conversations Signed-off-by: Josh Soref <jsoref@users.noreply.github.com> * spelling: domain.example Clarify what's distinct and use RFC friendly domain space. Signed-off-by: Josh Soref <jsoref@users.noreply.github.com> * spelling: environment Signed-off-by: Josh Soref <jsoref@users.noreply.github.com> * spelling: exceeds Signed-off-by: Josh Soref <jsoref@users.noreply.github.com> * spelling: functional Signed-off-by: Josh Soref <jsoref@users.noreply.github.com> * spelling: inefficiency Signed-off-by: Josh Soref <jsoref@users.noreply.github.com> * spelling: not Signed-off-by: Josh Soref <jsoref@users.noreply.github.com> * spelling: notifications Signed-off-by: Josh Soref <jsoref@users.noreply.github.com> * spelling: occurring Signed-off-by: Josh Soref <jsoref@users.noreply.github.com> * spelling: position Signed-off-by: Josh Soref <jsoref@users.noreply.github.com> * spelling: progress Signed-off-by: Josh Soref <jsoref@users.noreply.github.com> * spelling: promotable Signed-off-by: Josh Soref <jsoref@users.noreply.github.com> * spelling: reblogging Signed-off-by: Josh Soref <jsoref@users.noreply.github.com> * spelling: repetitive Signed-off-by: Josh Soref <jsoref@users.noreply.github.com> * spelling: resolve Signed-off-by: Josh Soref <jsoref@users.noreply.github.com> * spelling: saturated Signed-off-by: Josh Soref <jsoref@users.noreply.github.com> * spelling: similar Signed-off-by: Josh Soref <jsoref@users.noreply.github.com> * spelling: strategies Signed-off-by: Josh Soref <jsoref@users.noreply.github.com> * spelling: success Signed-off-by: Josh Soref <jsoref@users.noreply.github.com> * spelling: targeting Signed-off-by: Josh Soref <jsoref@users.noreply.github.com> * spelling: thumbnails Signed-off-by: Josh Soref <jsoref@users.noreply.github.com> * spelling: unauthorized Signed-off-by: Josh Soref <jsoref@users.noreply.github.com> * spelling: unsensitizes Signed-off-by: Josh Soref <jsoref@users.noreply.github.com> * spelling: validations Signed-off-by: Josh Soref <jsoref@users.noreply.github.com> * spelling: various Signed-off-by: Josh Soref <jsoref@users.noreply.github.com> Co-authored-by: Josh Soref <jsoref@users.noreply.github.com>
2022-03-07 08:51:40 +11:00
it 'returns http unauthorized' do
get "/api/v1/statuses/#{status.id}/context"
expect(response).to have_http_status(404)
end
end
end
context 'with a public status' do
let(:status) { Fabricate(:status, visibility: :public) }
describe 'GET /api/v1/statuses/:id' do
it 'returns http success' do
get "/api/v1/statuses/#{status.id}"
expect(response).to have_http_status(200)
end
end
describe 'GET /api/v1/statuses/:id/context' do
before do
Fabricate(:status, thread: status)
end
it 'returns http success' do
get "/api/v1/statuses/#{status.id}/context"
expect(response).to have_http_status(200)
end
end
end
end
end