4fa462a9f8
Related to - https://github.com/mastodon/mastodon/pull/35458 - which added a batch base class, and to - https://github.com/mastodon/mastodon/pull/35872 - which envisions a world where form objects tell the view what to do. Background here... - The `Form::AccountBatch` form object is used in a few different places, for somewhat varied purposes - The user relationships view uses it on a show page, which does a PUT to update, and uses the `follow`, `unfollow`, `remove_from_followers`, and `remove_domains_from_followers` "actions" of the form model - The admin accounts view shows a form on index view, does POST to batch action, uses the `suspend`, `approve` and `reject` actions. - The admin relationships view (for admins only) also has a form on index and does a POST back to that same spot - The admin/follow_recommendations page has a form on show and does PUT to update, using the `suppress_follow_recommendation` and `unsuppress_follow_recommendation` actions So, while these are all related in that they supply an `accounts_ids` array, the actual things that they "bulk update" are Follow (from relationships), FollowRecommendationSuppression (from follow recs) and Account (from accounts). This is a little inconsistent with other of the "batch form model" classes, which tend to update the same domain concept (ie, CustomEmojiBlock, IpBlockBatch, EmailDomainBlockBatch, etc) that they are named after (and in some cases that a "filter" class is named after). All that said, the changes here: - Pull out `Form::FollowRecommendationBatch` and `Form::RelationshipBatch` classes, which more closely align with the domain concept they are bulk updating (open to naming suggestions here) - Mark both of these as `persisted?` true so that their form views will infer correct HTTP action - Add some missing coverage to existing class, and coverage for new classes as well It would be pretty straightforward to chop this up into smaller pieces, if any of "just the coverage first", "just the boolean attribute", "one new batch class at a time", etc - were more appealing. Possible follow-up: - In the existing `Form::AccountBatch`, use attributes API for boolean `select_all_matching` value, remove query method - Convert the relationships controller spec to mix of request/system specs, round out coverage - Most (all maybe?) of the "batch actions" are doing a `POST` to a `batch` action on the controller of whatever they are related to. Might be worth looking at what the diff would look like to move these all to nested controllers where they did a `PUT to */batches#update` with restful routing, etc. |
||
|---|---|---|
| .devcontainer | ||
| .github | ||
| .husky | ||
| .rubocop | ||
| .storybook | ||
| .yarn | ||
| app | ||
| bin | ||
| chart | ||
| config | ||
| db | ||
| dist | ||
| docs | ||
| lib | ||
| log | ||
| public | ||
| spec | ||
| streaming | ||
| vendor | ||
| .annotaterb.yml | ||
| .browserslistrc | ||
| .buildpacks | ||
| .dockerignore | ||
| .editorconfig | ||
| .env.development | ||
| .env.production.sample | ||
| .env.test | ||
| .env.vagrant | ||
| .foreman | ||
| .gitattributes | ||
| .gitignore | ||
| .haml-lint.yml | ||
| .nvmrc | ||
| .prettierignore | ||
| .prettierrc.js | ||
| .rspec | ||
| .rubocop_todo.yml | ||
| .rubocop.yml | ||
| .ruby-gemset | ||
| .ruby-version | ||
| .slugignore | ||
| .watchmanconfig | ||
| .yarnrc.yml | ||
| app.json | ||
| Aptfile | ||
| AUTHORS.md | ||
| CHANGELOG.md | ||
| CODE_OF_CONDUCT.md | ||
| config.ru | ||
| CONTRIBUTING.md | ||
| crowdin.yml | ||
| docker-compose.yml | ||
| Dockerfile | ||
| eslint.config.mjs | ||
| FEDERATION.md | ||
| Gemfile | ||
| Gemfile.lock | ||
| ide-helper.js | ||
| jsconfig.json | ||
| LICENSE | ||
| lint-staged.config.js | ||
| package.json | ||
| priv-config | ||
| Procfile | ||
| Procfile.dev | ||
| Rakefile | ||
| README.md | ||
| scalingo.json | ||
| SECURITY.md | ||
| stylelint.config.js | ||
| tsconfig.json | ||
| Vagrantfile | ||
| vite.config.mts | ||
| vitest.config.mts | ||
| vitest.shims.d.ts | ||
| yarn.lock | ||
Note
Want to learn more about Mastodon? Click below to find out more in a video.
Mastodon is a free, open-source social network server based on ActivityPub where users can follow friends and discover new ones. On Mastodon, users can publish anything they want: links, pictures, text, and video. All Mastodon servers are interoperable as a federated network (users on one server can seamlessly communicate with users from another one, including non-Mastodon software that implements ActivityPub!)
Navigation
- Project homepage 🐘
- Donate to support development 🎁
- Blog 📰
- Documentation 📚
- Official container image 🚢
Features
Part of the Fediverse. Based on open standards, with no vendor lock-in. - the network goes beyond just Mastodon; anything that implements ActivityPub is part of a broader social network known as the Fediverse. You can follow and interact with users on other servers (including those running different software), and they can follow you back.
Real-time, chronological timeline updates - updates of people you're following appear in real-time in the UI.
Media attachments - upload and view images and videos attached to the updates. Videos with no audio track are treated like animated GIFs; normal videos loop continuously.
Safety and moderation tools - Mastodon includes private posts, locked accounts, phrase filtering, muting, blocking, and many other features, along with a reporting and moderation system.
OAuth2 and a straightforward REST API - Mastodon acts as an OAuth2 provider, and third party apps can use the REST and Streaming APIs. This results in a rich app ecosystem with a variety of choices!
Deployment
Tech stack
- Ruby on Rails powers the REST API and other web pages.
- PostgreSQL is the main database.
- Redis and Sidekiq are used for caching and queueing.
- Node.js powers the streaming API.
- React.js and Redux are used for the dynamic parts of the interface.
- BrowserStack supports testing on real devices and browsers. (This project is tested with BrowserStack)
- Chromatic provides visual regression testing. (This project is tested with Chromatic)
Requirements
- Ruby 3.2+
- PostgreSQL 13+
- Redis 7.0+
- Node.js 20+
This repository includes deployment configurations for Docker and docker-compose, as well as for other environments like Heroku and Scalingo. For Helm charts, reference the mastodon/chart repository. A standalone installation guide is available in the main documentation.
Contributing
Mastodon is free, open-source software licensed under AGPLv3. We welcome contributions and help from anyone who wants to improve the project.
You should read the overall CONTRIBUTING guide, which covers our development processes.
You should also read and understand the CODE OF CONDUCT that enables us to maintain a welcoming and inclusive community. Collaboration begins with mutual respect and understanding.
You can learn about setting up a development environment in the DEVELOPMENT documentation.
If you would like to help with translations 🌐 you can do so on Crowdin.
LICENSE
Copyright (c) 2016-2025 Eugen Rochko (+ mastodon authors)
Licensed under GNU Affero General Public License as stated in the LICENSE:
Copyright (c) 2016-2025 Eugen Rochko & other Mastodon contributors
This program is free software: you can redistribute it and/or modify it under
the terms of the GNU Affero General Public License as published by the Free
Software Foundation, either version 3 of the License, or (at your option) any
later version.
This program is distributed in the hope that it will be useful, but WITHOUT
ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS
FOR A PARTICULAR PURPOSE. See the GNU Affero General Public License for more
details.
You should have received a copy of the GNU Affero General Public License along
with this program. If not, see https://www.gnu.org/licenses/