Implement bulk moderation actions

[dhruvkb]

Fixes

Fixes #3840 by @stacimc
Fixes #3841 by @stacimc

Partially addresses #3842 by @stacimc
Partially addresses #3843 by @stacimc

Description

This PR

• enables sensitive and deleted media models to make bulk calls to ES
• adds bulk moderation actions to the Django admin with a confirmation page to view the summary of the changes and provide an explanation
• makes some UX improvements to the Django admin
• fixes some typos and tightens more permissions

Testing Instructions

Note that while the instructions only say images, the same steps can be taken for audio models.

Permissions

We must test that bulk moderation actions are only visible to moderators and not to other staff members.

• Create a new test user from the API shell.
  • Open the shell using just api/ipython
  • Create the new staff user and give it view/delete perms.

    from django.contrib.auth.models import Permission, Group, User
    from django.db.models import Q
    
    test = User.objects.create_user(username="test", password="deploy")
    test.is_staff = True
    test.save()
    
    for perm in Permission.objects.filter(Q(name__contains="view") | Q(name__contains="delete")):
        perm.user_set.add(test)

• Visit the following pages.
  • image list: http://localhost:50280/admin/api/image/?pending_record_count=all
  • sensitive-image list: http://localhost:50280/admin/api/sensitiveimage/
  • deleted-image list: http://localhost:50280/admin/api/deletedimage/
• See the options in the "Action" dropdown menu. You should not see the bulk moderation operations.

Marking sensitive

• Go to the image list page: http://localhost:50280/admin/api/image/?pending_record_count=all
• Select a bunch of images, and note their IDs.
• From the "Action menu" chose "Mark selected images as sensitive" and press "Go".
• Note that all your IDs are listed for confirmation.
• Enter a message and press "Yes, I’m sure". You will be taken back to the list with a banner on the top linking to the new decision.
• Click the link, go to the decision details and verify the decision is created correctly.
• Visit the sensitive-image list page: http://localhost:50280/admin/api/sensitiveimage/. The IDs should be listed there.
• Visit the detail page of the selected IDs: http://localhost:50280/v1/images/. The field "mature" should be true.

Re-marking sensitive

• Go to the image list page: http://localhost:50280/admin/api/image/?pending_record_count=all
• Select a bunch of images, including some overlapping from the previous step, and note their IDs.
• From the "Action menu" chose "Mark selected images as sensitive" and press "Go".
• Note that only the new, non-overlapping IDs are listed for confirmation and that existing sensitive image are excluded from this operation.

Deindexing

• Go to the image list page: http://localhost:50280/admin/api/image/?pending_record_count=all
• Select a bunch of images, including some overlapping sensitive images, and note their IDs.
• From the "Action menu" chose "Deindex selected images (sensitive)" and press "Go".
• Note that all your IDs are listed for confirmation.
• Enter a message and press "Yes, I’m sure". You will be taken back to the list with a banner on the top linking to the new decision.
• Click the link, go to the decision details and verify the decision is created correctly.
• Visit the image list page: http://localhost:50280/admin/api/image/?pending_record_count=all. The media models corresponding to the IDs should be gone.
• Visit the detail page of the selected IDs: http://localhost:50280/v1/images/. You should see a 404 page.
• Visit the deleted-image list page: http://localhost:50280/admin/api/deletedimage/. The IDs should be listed there.

Unmarking sensitive

• Go to the sensitive-image list page: http://localhost:50280/admin/api/sensitiveimage/
• Select some sensitive images, including some that have subsequently been deindexed, and note their IDs.
• From the "Action menu" chose "Unmark selected sensitive images as sensitive" and press "Go".
• Note that all your IDs are listed for confirmation.
• Enter a message and press "Yes, I’m sure". You will be taken back to the list with a banner on the top linking to the new decision.
• Click the link, go to the decision details and verify the decision is created correctly.
• Visit the sensitive-image list page: http://localhost:50280/admin/api/sensitiveimage/. The IDs should be gone from there.
• Visit the detail page of the selected IDs: http://localhost:50280/v1/images/. The field "mature" should be false.
• Visit the detail page of the deindexed IDs: http://localhost:50280/v1/images/. You should see a 404 page.

Reindexing

• Go to the deleted-image list page: http://localhost:50280/admin/api/deletedimage/
• Select some deleted imaged, and note their IDs.
• From the "Action menu" chose "Reindex selected deleted images" and press "Go".
• Note that all your IDs are listed for confirmation. Also note the warning explaining the actual effect of reindexing.
• Enter a message and press "Yes, I’m sure". You will be taken back to the list with a banner on the top linking to the new decision.
• Click the link, go to the decision details and verify the decision is created correctly.
• Visit the deleted-image list page: http://localhost:50280/admin/api/deletedimage/. The IDs should be gone from there.
• Visit the image list page: http://localhost:50280/admin/api/image/?pending_record_count=all. The media models corresponding to the IDs should still be gone.
• Visit the detail page of the reindexed IDs: http://localhost:50280/v1/images/. You should still see a 404 page.

History

• Visit the image-decision list page: http://localhost:50280/admin/api/imagedecision/. See all the bulk moderations made so far are listed there and paint a clear picture of the events.
• Check the following field.
  • The moderator should be you.
  • The notes should be the content entered on the confirmation page.
  • The affected media items should include all IDs regardless of whether the media item exists or has been deindexed. Those that exist should be links.

Checklist

• My pull request has a descriptive title (not a vague title likeUpdate index.md).
• My pull request targets the default branch of the repository (main) or a parent feature branch.
• My commit messages follow best practices.
• My code follows the established code style of the repository.
• I added or updated tests for the changes I made (if applicable).
• I added or updated documentation (if applicable).
• I tried running the project locally and verified that there are no visible errors.
• I ran the DAG documentation generator (ov just catalog/generate-docs for catalog
  PRs) or the media properties generator (ov just catalog/generate-docs media-props
  for the catalog or ov just api/generate-docs for the API) where applicable.

Developer Certificate of Origin

Developer Certificate of Origin

Developer Certificate of Origin
Version 1.1

Copyright (C) 2004, 2006 The Linux Foundation and its contributors.
1 Letterman Drive
Suite D4700
San Francisco, CA, 94129

Everyone is permitted to copy and distribute verbatim copies of this
license document, but changing it is not allowed.


Developer's Certificate of Origin 1.1

By making a contribution to this project, I certify that:

(a) The contribution was created in whole or in part by me and I
    have the right to submit it under the open source license
    indicated in the file; or

(b) The contribution is based upon previous work that, to the best
    of my knowledge, is covered under an appropriate open source
    license and I have the right under that license to submit that
    work with modifications, whether created in whole or in part
    by me, under the same open source license (unless I am
    permitted to submit under a different license), as indicated
    in the file; or

(c) The contribution was provided directly to me by some other
    person who certified (a), (b) or (c) and I have not modified
    it.

(d) I understand and agree that this project and the contribution
    are public and that a record of the contribution (including all
    personal information I submit with it, including my sign-off) is
    maintained indefinitely and may be redistributed consistent with
    this project or the open source license(s) involved.

[dhruvkb]

I bumped up the priority to 🟧 high because the issue it resolves (#3840) is blocking three others.

[zackkrida]

@dhruvkb all of the core moderation actions worked as described 🎉. This is awesome! As a future moderator I can see this being really useful.

I found one thing, the "Resolved" filtered view, which seems broken.

Also, I do not feel completely qualified to evaluate the python code for performance or for being idiomatic with Django. You might want to ping another reviewer for those concerns. But I am happy to approve this once you clarify the "Resolved" filtered view. Thanks!

[krysal]

Great work here. There are a ton of things happening, so it's incredible to see the view workflows going smoothly.

As the test user you provided in the instructions, I couldn't see the bulk moderation operations as expected ✔️ So for trying the bulk actions I assume the user must be granted the specific permissions, right?

I was able to mark images as sensitive and deindex them in bulk with the original deploy user. I have yet to try the other actions, but given the many complex operations involving ES, groups of media, and specific user permissions, it seems this requires some automated testing. At the very least, it would be prudent to test the critical bulk functions.

Aside from that, this looks promising! I'll come back to this later.

[krysal]

This is a surprise to me, I didn't think the IP defined this like this (I must admit I have to read it carefully). Sounds like a lot of manual work that could be taken out of the moderators 🤔

[dhruvkb]

Yes, this is a bit of manual work that can be automated if we auto-close reports. However, there are two main issues preventing that.

The main case we need to avoid that I can think of is if we marked an image as sensitive based on one report, but another report (that gets closed for having the same reason) actually contains information or context which would lead us to deindex the image.
— @zackkrida

Also need to keep in mind reversing a bulk action — if creating one results in reports being resolved, reversing it ought to reopen them
— @stacimc

With this limitation in mind, I decided to keep the reports unchanged for now and potentially revisit this in the future.

[zackkrida]

Ideally, with moderation happening regularly, the need to triage multiple concurrent reports of a single work will be very infrequent.

[dhruvkb]

Does that mean we should implement report closing functionality as a part of bulk moderation? It can be pretty complex in terms of logic so I would ideally like that to be a different issue-PR pair to avoid complicating this PR further.

[krysal]

I agree that it would increase complexity, and this PR is already well-rounded. Good to know there was a previous consensus 👍

[dhruvkb]

I found one thing, the "Resolved" filtered view, which seems broken.

@zackkrida I just confirmed that it works as I expect. To check that view, open a media item from the "All" view, create a report for it and create a decision for that report. Now that media item will appear in "Resolved".

[dhruvkb]

So for trying the bulk actions I assume the user must be granted the specific permissions, right?

@krysal, yes, the bulk moderation capability is available only to members of the "Content Moderators" group. It is determined by whether they have the "Can add image decision" and "Can add audio decision" permissions.

it seems this requires some automated testing

I agree with you there. I have added unit tests for the ES bulk update code in ede4e38 and for the perform_moderation util in 1945a08. These tests cover all the bulk moderation actions and should be sufficient to establish confidence.

[zackkrida]

Approving based on the functionality, and the test logic looks good. Again, I don't feel the most qualified to speak to the specific code patterns or Django best practices.

[krysal]

This is working like a charm! I tested all the cases, and the only thing I noticed is that, when marking as sensitive, the media gets a value in "unstable__sensitivity" of ["user_reported_sensitivity"] when that didn't come from a user report, but that is a minor thing that can be addressed separately.

Excellent work 💯

[krysal]

I agree that it would increase complexity, and this PR is already well-rounded. Good to know there was a previous consensus 👍