* Fixing post_view largest community prefetch.
- Fixes#5621
* Cache the largest community result.
* Fixing community largest cache.
* Use cache duration
* Use 1-day cache for largest community
Clients exposing the NSFW setting to users will typically do so by providing a
checkbox, which is either checked or unchecked, but there is no third option
to let the server decide. As a result, virtually all posts created through
user interfaces will have a bool value for NSFW, so this logic likely is used
only for posts created by scripts/bots.
In #5310 the behavior for new posts was changed to default the NSFW flag to
the community's NSFW setting, but it only did so as a default if no value was
provided when creating a post via API.
This changes the logic to force all new posts created via API or received from
federation to be NSFW if the community they're posted in is marked NSFW,
otherwise use the value provided by the creator, with a default of false if
nothing is provided.
It also ensures that this logic is used for filtering out NSFW posts on
instances blocking NSFW content.
* Fix can_mod comparison with null and admin creator check
* Rename local user join helper
---------
Co-authored-by: Dessalines <dessalines@users.noreply.github.com>
Prior to #5515, when a user was purged, a function was called to ensure that
in addtition to the site ban, purges of remote users would result in
individual community bans for each local local community being federated out,
as this was an intermediate solution to address the lack of federated content
removal otherwise.
As proper handling of banned users was implemented in that PR, the logic for
federating out community bans was changed to federate directly as a site ban.
This logic already existed in the user purge function, resulting in
duplication.
The first instance of the ban is kept rather than the second one to ensure
that federation happens even if any of the later local DB writes run into
issues, as those will be more likely to be caught by the admin performing the
purge, so they can just repeat the request to resolve that.
* created new table post_keyword_block related to a person and corresponding functions in diesel
* created corresponding api functions
* converted like to ilike in filter
* Fixxed errors for adding keywords for blocking posts
* Fixxed errors in diesel migrations
* Removed debug print
* #3710: Fixxed errors caused by cargo check
* #3710: added up and down scripts for diesel
* added tmp.schema to gitignore
* updated tests
* fixxed test
* fixxed error from rebasing
* Added max number of block tags and modified max length of block tags
* formatted code
* added migration to restrict block keyword length
* #3710: Added check if Blocked keyword is already existing
* #3710: Removed deprecated any
* #3710: Updated keyword length
* #3710: Fixxed errors from master merge
* #3710: Formatting
* #3710: Removed api to block keywords for post from v3 and changed of api path in v4
* #3710: Renamed post_keyword_block table to user_post_keyword_block and replaced id as primary key with the composed key person_id and keyword. Also now use update function which updates the blocked keywords for an user with a new list instead keyword by keyword.
* #3710: Formatted code
* #3710: Removed unnecessary parts for the block API in post as this will be done over the user settings
* #3710: Modified data structure for blocking keywords to reference local user and added update function which will update at all keywords for a local user at once
* #3710: Modified code so updating blocked keywords is now done over user settings
* #3710: Fixxed merging error
* #3710: Fixxed filter query
* #3710: Formatted Code
* #3710: Added suggested changes from review: keyword block update now does delete and then insert, postview uses read from LocalKeywordBlock, and validation with min_length_check and max_length_check
* #3710: formatted code
* c
* #3710: removed BlockKeywordForPost struct
* #3710: formatted code
* #3710: formatted code
* #3710: formatted code
* Adding admin image deletion endpoint.
- Also moving the list media endpoints, since these can go under a
common heading.
- Fixes#5563
* Changing list_all to list
* Fixing api tests.
* Delete all aliases.
* Fixing comment.
* Updating lemmy-js-client.
* Move db schema file to new crate
* db schema compiling
* wip
* db views
* compiling
* cleanup
* clippy
* fix path
* move some more files to new crate
* fixes
* fix
* fix
* Receive and store remote site bans (fixes#3399)
* db schema changes, handly expiration
* partial federation changes
* add column `mod_ban.instance_id`
* remove unused
* wip: remove person.banned
* fix down migration
* fmt, keep banned status
* fixes
* simplify
* update post removed
* fix api tests
* ban from local instance
* banned() helpers
* cleanup undo_block_user
* remove order by
* cache SiteView::read_local, add instance
* use local instance id for PersonView
* add helper function person_with_instance_actions
* use exists
* comments update removed
* remove method is_mod_or_admin
* fix tests
* no unwrap
* change local_instance_person_join
* remove LocalSite::read
* wip: home_instance_actions
* add home_instance_actions to all structs
* fixes
* fix tests
* fmt
* Starting to work on site person ban fixes.
* Starting to work on comment_view
* Adding a few more views.
* Cleaning up a few more views.
* Finishing up a few more.
* Fixing unit tests.
- Also fixes#5502
* Fixing merge 2.
* Adding a creator_banned field
---------
Co-authored-by: Felix Ableitner <me@nutomic.com>
* Remove git-tracked paths from .dockerignore
Since #5470 added automatic git version tags builds will include a `-modified`
version suffix if they have uncommitted changes in the Git repository.
The final container images are not copying any files from the local directory,
so none of the files copied into the builder stage will end up in the final
image.
Fixes#5589
* change .dockerignore to symlink to .gitignore
This commit removes various cases in which Lemmy would purge images from
pictrs, which would in many cases not be what admins intended.
pict-rs provides aliases on upload, which allows deduplicating multiple uploads
of the same file in the backend, while still providing unique URLs for uploads.
As Lemmy used pictrs' purge API, this meant that not only the image alias
referring to removed content was deleted, all other aliases were invalidated as
well.
Additionally, even alias deletion would not appropriate in many of these cases,
as they were lacking validation that they were exclusively used by the content
they were supposed to get removed with.
This implements the following changes:
1. Purging a community no longer purges the community banner or icon from
pict-rs.
2. Purging a community no longer purges all images referenced in post URLs and
post thumbnails within the community from pict-rs.
3. Banning a user with content removal no longer purges their profile avatar or
banner from pict-rs.
4. Banning a user with content removal no longer purges images referenced in
post URLs and post thumbnails for all posts they created from pict-rs.
5. Banning a user with content removal no longer purges the community banners
or icons for all communities they're the top mod of from pict-rs.
6. Banning a user with content removal now deletes all media they uploaded.
7. Purging a user no longer purges their profile avatar, banner, or images
referenced in post URLs and post thumbnails for all posts they created from
pict-rs. All media linked to their user account will still get deleted, which
was already explicitly the case in the past.
8. On an NSFW-disabled instance, receiving a post update via federation, which
changes the post from not NSFW to NSFW no longer purges post URL and thumbnail
from pict-rs.
Some of the mentioned actions will still remove references to image URLs from
the database, such as purging a community will still set its icon and banner to
`NULL` in the db, but the associated images will no longer be purged from
pict-rs.
As this stops erasure of thumbnails, #5564 has been created to ensure tracking
the person that triggered the creation of thumbnails, which will allow removing
them like other images.
The only remaining option to purge images attached to a post is now purging an
individual post, which still erases the post URL and thumbnail from pict-rs
entirely, including any other aliases. Purging and banning users with content
removal will remove all aliases associated with them, which will end up
deleting those images entirely when there are no other alias remaining.
fixes#5560
