Add bulk bulk_action_parent_id field to modlog table by EduardoLZevallos · Pull Request #6352 · LemmyNet/lemmy

EduardoLZevallos · 2026-02-21T02:36:58Z

This is for issue #6323

each bulk child entry now stores a foreign key back to the modlog row that triggered it

Closes LemmyNet#6323 Adds a new `bulk` boolean column to the modlog table so that bulk actions (e.g. removing all content when banning a user) can be distinguished from individual mod actions in the frontend.

Nothing4You · 2026-02-21T19:01:11Z

wouldn't it make more sense to store the parent id instead? non-bulk/parents could have this set to NULL, and for others it will then also allow determining the initial action that resulted in this.
clients could then also display all the actions that were triggered by the current action.

EduardoLZevallos · 2026-02-22T03:53:50Z

wouldn't it make more sense to store the parent id instead? non-bulk/parents could have this set to NULL, and for others it will then also allow determining the initial action that resulted in this. clients could then also display all the actions that were triggered by the current action.

I think this makes sense. just to make sure I follow completely, for example

The ban entry is inserted into modlog first → gets id = 36 , parent_id = NULL (it's a root action, nobody triggered it)
Every post/comment removal that results from that ban is inserted with parent_id = 36

bulk actions are therefore anything where the parent_id is not null
actions that triggered the ban? search based on the parent_id
to determine the removal look for the row with id equal to the particular parent id

One thing is that I'll likely need to ensure this works on the federated path since parent_id requires the parent row to exist first.parent_id requires the parent row to exist first.

Thanks for the feedback @Nothing4You let me know if I'm understanding your feedback fully.

Nutomic · 2026-02-23T11:28:45Z

I agree that it makes sense to include the parent id, so they can be grouped together in the UI. To be more explicit I would call it bulk_action_parent_id. Your description how to implement this sounds reasonable.

It would also make sense to change ModlogView to hide bulk items by default, and then add a new api parameter bulk_action_id or similar, which returns all child actions corresponding to that one.

dessalines

I don't know if it makes sense to include the parent_id, because we already have modlog filters for post_id, comment_id, community_id.

Because if we did add parent_id, I'd prefer that to reference which type of id it would be (IE parent_post_id, parent_community_id) , and that could get pretty complicated. The filters above should already work good enough, and having a simple is_bulk to GetModlog should be enough.

Another way to put it, is that the modlog table already stores things like target_post_id, target_community_id, etc. So adding another target_parent_id would be redundant.

dessalines · 2026-02-23T19:22:27Z

crates/api/api/src/site/mod_log.rs

        ModlogView {
          modlog: Modlog {
            is_revert: true,
+            is_bulk: true,


All these should also be false.

dessalines · 2026-02-23T19:24:21Z

crates/db_views/modlog/src/impls.rs

+    .list(pool)
+    .await?
+    .items;
+    assert_eq!(1, modlog.len());


Also be sure to add tests for when bulk removal is true.

Nothing4You · 2026-02-23T21:06:04Z

Another way to put it, is that the modlog table already stores things like target_post_id, target_community_id, etc. So adding another target_parent_id would be redundant.

It's not redundant to have data that clearly links the two actions.
If a user and their content get banned from a community, the post gets removed as bulk action.
If a user gets banned from the instance, the post gets removed as bulk action.
The modlog doesn't track whether a ban was with content removal, so it cannot be reliably determined which of the bans triggered the removal. At best, a client could try to correlate these actions based on the timestamp.

From UI/client perspective, I think the following would be useful:

instance modlog should only show non-bulk actions by default
community modlog should always show community bans and unbans by default, otherwise only non-bulk actions
being able to tell whether a modlog parent has any children, to avoid needlessly needing to query for children of all returned items individually

Additionally, having explicit modlog child records are useful when reversing a ban, by being able to selectively undo e.g. post/comment removals from a community ban. A moderator could click an undo button on a community ban modlog entry and this could restore all posts that were removed as part of the ban, without restoring posts that may have been removed for unrelated reasons.

dessalines · 2026-02-23T21:46:07Z

If a user and their content get banned from a community, the post gets removed as bulk action.
If a user gets banned from the instance, the post gets removed as bulk action.

It does make sense to link them, but then we'll at least need bulk_parent_post_id, bulk_parent_community_id, bulk_parent_instance_id , to link the parent level it was bulk removed at. I think that's all of them.

community modlog should always show community bans and unbans by default, otherwise only non-bulk actions ...

I think in that case it makes sense to add the bulk_...id filters (instead of a simple bulk: boolean) to GetModlog, so that people can explicitly filter for the bulk actions at each of those levels. Front ends can use their own logic to determine which bulk ones they want.

Nothing4You · 2026-02-23T22:09:24Z

If a user and their content get banned from a community, the post gets removed as bulk action.
If a user gets banned from the instance, the post gets removed as bulk action.

It does make sense to link them, but then we'll at least need bulk_parent_post_id, bulk_parent_community_id, bulk_parent_instance_id , to link the parent level it was bulk removed at. I think that's all of them.

the parent would refer to another modlog entry. i'm not quite sure why we would need to split the references by type? a single modlog entry should only have a single parent, and they'd all refer to another row in the same table.

EduardoLZevallos · 2026-02-24T02:26:08Z

If a user and their content get banned from a community, the post gets removed as bulk action.
If a user gets banned from the instance, the post gets removed as bulk action.

It does make sense to link them, but then we'll at least need bulk_parent_post_id, bulk_parent_community_id, bulk_parent_instance_id , to link the parent level it was bulk removed at. I think that's all of them.

the parent would refer to another modlog entry. i'm not quite sure why we would need to split the references by type? a single modlog entry should only have a single parent, and they'd all refer to another row in the same table.

"a single modlog entry should only have a single parent, and they'd all refer to another row in the same table." this makes the most sense to me. I want to confirm this is the approach we'd like to move forward with before implementing again.

I'll call it bulk_action_parent_id

dessalines · 2026-02-24T05:10:19Z

That seems fine.

I think on the API side, we'll still just need a show_bulk: boolean anyway (in addition to bulk_parent_id), because someone looking at the modlog might just want a simple checkbox showing all the bulk operations, and not want to have to know parent ids before seeing all the entries.

Instead of a boolean flag, store a reference to the parent modlog entry that triggered bulk content removal (e.g. the ban that caused all of a user's posts to be removed). NULL means an individual action; non-null means a bulk action triggered by the referenced entry.

Nutomic · 2026-02-25T10:43:17Z

You need to format the code with cargo +nightly fmt --all. And generally check the CI output to see whats missing (https://woodpecker.join-lemmy.org/repos/129/pipeline/19131/9). See .woodpecker.yml for the commands it runs.

EduardoLZevallos · 2026-02-25T23:19:05Z

You need to format the code with cargo +nightly fmt --all. And generally check the CI output to see whats missing (https://woodpecker.join-lemmy.org/repos/129/pipeline/19131/9). See .woodpecker.yml for the commands it runs.

thanks . Will check through that now

Nutomic · 2026-02-26T09:53:21Z

migrations/2026-02-19-120000-0000_add_bulk_to_modlog/up.sql

+ALTER TABLE modlog
+    ADD COLUMN bulk_action_parent_id int REFERENCES modlog (id) ON DELETE SET NULL;
+
+CREATE INDEX idx_modlog_bulk_action_parent_id ON modlog (bulk_action_parent_id);


Can use where bulk_action_parent_id is not null to use less storage space.

i think over time the majority of rows will probably have this set, so i don't think this will long term be saving a significant amount of space.
it would exclude the index from being usable for non-bulk queries. i'm not sure if would make a noticeable difference in practice. an index scan for published would happen first and then i'd expect a sequential scan to rule out rows that were retrieved from the published index but have the bulk column null. for large bulk operations this could result in hundreds to thousands of rows being read and skipped from the sequential scan.

it might make sense to generate some synthetic data and look at query plans.

crates/db_views/modlog/src/impls.rs

crates/api/api_utils/src/utils.rs

crates/apub/activities/src/block/block_user.rs

crates/apub/activities/src/block/undo_block_user.rs

crates/api/api/src/site/mod_log.rs

crates/api/api_utils/src/utils.rs

crates/apub/activities/src/block/undo_block_user.rs

crates/db_views/modlog/src/api.rs

crates/db_views/modlog/src/impls.rs

migrations/2026-02-19-120000-0000_add_bulk_to_modlog/up.sql

EduardoLZevallos · 2026-02-27T03:53:08Z

thanks for the feedback all. Will address it this weekend

mod_remove_comment constructor functions - Pass Some(id) at bulk call sites (utils.rs) and None at individual mod action sites (api_crud, apub deletion/undo_delete) - Fix ModlogQuery to skip IS NULL guard when bulk_action_parent_id filter is provided (was making the eq filter unreachable)

…odlog # Conflicts: # crates/api/api_crud/src/comment/remove.rs # crates/api/api_crud/src/post/remove.rs # crates/api/api_utils/src/utils.rs # crates/apub/activities/src/deletion/delete.rs # crates/apub/activities/src/deletion/undo_delete.rs # crates/db_views/modlog/src/impls.rs # crates/db_views/notification/src/tests.rs

dessalines

Only 1 major thing having to do with bulk comment removals. Everything else is minor:

crates/api/api/src/community/ban.rs

crates/api/api_utils/src/utils.rs

crates/apub/activities/src/block/block_user.rs

crates/apub/activities/src/block/undo_block_user.rs

crates/db_views/modlog/src/impls.rs

…lk_action_parent_id as well. Also moved parent_id into varsper pr feedback

dessalines

Excellent job, thx!

EduardoLZevallos · 2026-03-05T02:55:31Z

Excellent job, thx!

sorry got busy with work. Thanks for all the feedback all! my first contribution to this project.

Add bulk boolean field to modlog table

f685b3a

Closes LemmyNet#6323 Adds a new `bulk` boolean column to the modlog table so that bulk actions (e.g. removing all content when banning a user) can be distinguished from individual mod actions in the frontend.

EduardoLZevallos requested review from Nutomic, SleeplessOne1917, dessalines, dullbananas and phiresky as code owners February 21, 2026 02:36

Rename bulk to is_bulk, add individual modlog test

10a8ca0

EduardoLZevallos force-pushed the add-bulk-field-to-modlog branch from 881d6d8 to 10a8ca0 Compare February 21, 2026 02:52

Merge branch 'main' into add-bulk-field-to-modlog

068dc97

dessalines reviewed Feb 23, 2026

View reviewed changes

fix: formatting and index slicing

370a04f

Nutomic reviewed Feb 26, 2026

View reviewed changes

crates/db_views/modlog/src/impls.rs Outdated Show resolved Hide resolved

Nutomic reviewed Feb 26, 2026

View reviewed changes

crates/api/api_utils/src/utils.rs Outdated Show resolved Hide resolved

Nutomic reviewed Feb 26, 2026

View reviewed changes

crates/apub/activities/src/block/block_user.rs Outdated Show resolved Hide resolved

Nutomic reviewed Feb 26, 2026

View reviewed changes

crates/apub/activities/src/block/undo_block_user.rs Outdated Show resolved Hide resolved

dessalines reviewed Feb 26, 2026

View reviewed changes

eduardo added 2 commits March 1, 2026 18:48

fix tests missing Option<ModlogId>

3c9efc8

EduardoLZevallos force-pushed the add-bulk-field-to-modlog branch from 09b8f09 to 5e4b075 Compare March 2, 2026 00:55

eduardo added 5 commits March 1, 2026 20:00

Fix formatting

2f97775

Fix argument count mismatches in modlog comment removal helpers

162e3be

Fix missing community_id arg in modlog test

5578fd3

Fix remaining mod_remove_comment missing None arg

2dbb1ea

unwrap fix in impls.rs

7cffec4

dessalines reviewed Mar 2, 2026

View reviewed changes

create_modlog_entries_for_removed_or_restored_comments now accepts bu…

3eff47e

…lk_action_parent_id as well. Also moved parent_id into varsper pr feedback

Nutomic changed the title ~~Add bulk boolean field to modlog table~~ Add bulk bulk_action_parent_id field to modlog table Mar 3, 2026

Nutomic approved these changes Mar 3, 2026

View reviewed changes

dessalines approved these changes Mar 3, 2026

View reviewed changes

dessalines merged commit 01e1f0e into LemmyNet:main Mar 3, 2026
2 checks passed

Uh oh!

Conversation

EduardoLZevallos commented Feb 21, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Nothing4You commented Feb 21, 2026

Uh oh!

EduardoLZevallos commented Feb 22, 2026

Uh oh!

Nutomic commented Feb 23, 2026

Uh oh!

dessalines left a comment • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

dessalines Feb 23, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

dessalines Feb 23, 2026

Choose a reason for hiding this comment

Uh oh!

Nothing4You commented Feb 23, 2026

Uh oh!

dessalines commented Feb 23, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Nothing4You commented Feb 23, 2026

Uh oh!

EduardoLZevallos commented Feb 24, 2026

Uh oh!

dessalines commented Feb 24, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Nutomic commented Feb 25, 2026

Uh oh!

EduardoLZevallos commented Feb 25, 2026

Uh oh!

Nutomic Feb 26, 2026

Choose a reason for hiding this comment

Uh oh!

Nothing4You Feb 26, 2026

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

EduardoLZevallos commented Feb 27, 2026

Uh oh!

dessalines left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

dessalines left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

EduardoLZevallos commented Mar 5, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

EduardoLZevallos commented Feb 21, 2026 •

edited

Loading

dessalines left a comment •

edited

Loading

dessalines Feb 23, 2026 •

edited

Loading

dessalines commented Feb 23, 2026 •

edited

Loading

dessalines commented Feb 24, 2026 •

edited

Loading