| Age | Commit message (Collapse) | Author |
|---|
|
And add `created_at` to encrypted message serializer
|
|
|
|
* Add remote only to public timeline
* Fix code style
|
|
Fixes #13612
|
|
|
|
|
|
* Fix 404 and 410 API errors being silently discarded in WebUI
Fixes #13278
* Return more appropriate error when user replies to a deleted toot
* Please CodeClimate
* Fix 404/410 errors on fetching account timelines & identity proofs
* Refactor error handling
* Move error message string to statuses.errors
|
|
* Change ActivityPub follower/following collections to not link first page
* Add support for hiding followers and following of remote users
* Switch to using a single `hide_collections` column
* Address code style remarks
|
|
(#13210)
Fix #9106
|
|
|
|
|
|
|
|
|
|
Fix OEmbed preview API leaking existence of private statuses (see #12930)
|
|
* Change meaning of /api/v1/announcements/:id/dismiss to mark an announcement as read
* Change how unread announcements are counted in UI
* Add unread marker to announcements and mark announcements as unread as they are displayed
* Fixups
|
|
|
|
* Add announcements
Fix #11006
* Add reactions to announcements
* Add admin UI for announcements
* Add unit tests
* Fix issues
- Add `with_dismissed` param to announcements API
- Fix end date not being formatted when time range is given
- Fix announcement delete causing reactions to send streaming updates
- Fix announcements container growing too wide and mascot too small
- Fix `all_day` being settable when no time range is given
- Change text "Update" to "Announcement"
* Fix scheduler unpublishing announcements before they are due
* Fix filter params not being passed to announcements filter
|
|
|
|
Fix #3804, Fix #5776
|
|
* Hide blocked, muted, and blocked-by users from toot favourite lists
* Hide blocked, muted, and blocked-by users from toot reblog lists
* Hide blocked, muted, and blocked-by users from followers/following (API)
* Fix tests
* Hide blocked, muted, and blocked-by users from followers/following on public pages
|
|
network hidden (#12716)
Fix #12510
|
|
Fix #12551
Fix #12547
|
|
* Add follow_request notification type
The notification type already existed in the backend but was never pushed
to the front-end. This also means translation strings were also available
for the backend, from the notification mailer.
Unlike other notification types, these are off by default, to match what
I remember of Gargron's view on the topic: that follow requests should not
clutter notifications and should instead be reviewed at the user's own
leisure in the dedicated column.
Since follow requests have their own column, I've deemed it unnecessary to
add a specific tab for them in the notification quick filter.
* Show follow request link in single-column if there are pending requests, even if account isn't locked
* Push follow requests from notifications to the follow_requests list
* Offer to accept or reject follow request from the notification
* Redesign follow request notification
|
|
|
|
* Support min_id-based pagination for bookmarks
* Fix spec
|
|
* make it not return http 400 when passing and empty source argument
* create a spec for the empty source hash bug
* compact checks for nil, empty? parameters
* use nil.blank? instead checking for nil
|
|
* Add backend support for bookmarks
Bookmarks behave like favourites, except they aren't shared with other
users and do not have an associated counter.
* Add spec for bookmark endpoints
* Add front-end support for bookmarks
* Introduce OAuth scopes for bookmarks
* Add bookmarks to archive takeout
* Fix migration
* Coding style fixes
* Fix rebase issue
* Update bookmarked_statuses to latest UI changes
* Update bookmark actions to properly reflect status changes in state
* Add bookmarks item to single-column layout
* Make active bookmarks red
|
|
Change the behaviour of remotable concern. Previously, it would skip
downloading an attachment if the stored remote URL is identical to
the new one. Now it would not be skipped if the attachment is not
actually currently stored by Paperclip.
|
|
|
|
Fetching statuses from all followed accounts at once takes too long
within Postgres. Fetching them one by one and merging in Ruby
could be a lot less resource-intensive
Because the query for dynamically fetching the home timeline is so
heavy, we can no longer offer it when the home timeline is missing
|
|
For approval-required registrations mode
|
|
Make it so normal search returns even unreviewed matches, but
autosuggestions do not.
Fix #11960
|
|
* Change silenced accounts to require approval on follow
* Also require approval for follows by people explicitly muted by target accounts
* Do not auto-accept silenced or muted accounts when switching from locked to unlocked
* Add `follow_requests_count` to verify_credentials
* Show “Follow requests” menu item if needed even if account is locked
* Add tests
* Correctly reflect that follow requests weren't auto-accepted when local account is silenced
* Accept follow requests from user-muted accounts to avoid leaking mutes
|
|
|
|
Use `GET /api/v2/search` instead
|
|
(#11802)
Fixes #11289
|
|
Fix #11669
|
|
Change all account actions except "none" to resolve all unresolved reports
Refactor `SuspendAccountService` to be more readable
|
|
Fixes #11747
|
|
* Add featured tags API
* Remove show and update, change scope, fix code style
|
|
Fix #4093
|
|
|
|
|
|
* Add profile directory to web UI
* Add a line of bio to the directory
|
|
* Add soft delete for statuses to allow them to appear instant
* Allow reporting soft-deleted statuses and show them in the admin UI
* Change index for getting an account's statuses
|
|
The reason for unattaching media instead of removing it is to support
delete & redraft functionality, but remote or staff-removed statuses
will never be redrafted, so the media should be deleted immediately
|
|
(#11539)
Regression from #8657
|
|
Fix #10227
|
|
Fix #271
Add back the `GET /api/v1/trends` API with the caveat that it does
not return tags that have not been allowed to trend by the staff.
When a hashtag begins to trend (internally) and that hashtag has
not been previously reviewed by the staff, the staff is notified.
The new admin UI for hashtags allows filtering hashtags by where
they are used (e.g. in the profile directory), whether they have
been reviewed or are pending reviewal, they show by how many people
the hashtag is used in the directory, how many people used it
today, how many statuses with it have been created today, and it
allows fixing the name of the hashtag to make it more readable.
The disallowed hashtags feature has been reworked. It is now
controlled from the admin UI for hashtags instead of from
the file `config/settings.yml`
|
|
|
