UI Modal for Flagging ContentNodes

[vkWeb]

Summary

This PR --

• Adds a Flag content option to the contentnode three-dot menu.
• Introduces a UI Modal upon click of Flag content option that shows checkboxes for reporting a node.

TO DO --

• Implement handleSubmit() method. Can only be done after Implement feedback object hierarchy #4373 is merged.

Manual verification steps performed

Manual verification mainly revolves around checking when and when not Flag content option is shown. So let's divide it into two parts -- first for normal users and second for admins.

For normal non-admin users

Flag option should show only when these three conditions meet -- AI feature flag is enabled for user, node is not of topic kind and user does not have edit permissions on the channel, that is, all public channels that user have not created themselves.

So to test the above conditions follow the below steps --

1. Log in as admin.
2. Enable ai feature flag for a normal user e.g. for [email protected]
3. Create a channel with two nodes -- a topic node and a video file node.
4. Publish that channel and make that channel public.
5. Logout & login as user now.
6. Go to content library and open that public channel.
7. Click on three-dot menu of topic contentnode, Flag content option should not be there.
8. Click on three-dot menu of video contentnode, Flag content option should be there.
9. Done!

For admin users

Flag option should show in ALL channels when -- AI feature flag is enabled for admin and node is not of topic kind.

So to test the above conditions follow the below steps --

1. Log in as a normal user.
2. Create a channel with two nodes -- a topic node and a video file node.
3. Log out and login as admin.
4. Enable ai feature flag for admin.
5. Go to administration -> channels.
6. Visit that unpublished channel.
7. Click on three-dot menu of topic contentnode, Flag content option should not be there.
8. Click on three-dot menu of video contentnode, Flag content option should be there.
9. Done!

Screenshots (if applicable)

1. Flag content option UI

2. Flag modal UI

---

Reviewer guidance

Performing manual verification steps should make us confident about the changes.

References

Closes #4367.
Closes #4365.

---

Contributor's Checklist

PR process:

• If this is an important user-facing change, PR or related issue the CHANGELOG label been added to this PR. Note: items with this label will be added to the CHANGELOG at a later time
• If this includes an internal dependency change, a link to the diff is provided
• The docs label has been added if this introduces a change that needs to be updated in the user docs?
• If any Python requirements have changed, the updated requirements.txt files also included in this PR
• Opportunities for using Google Analytics here are noted
• Migrations are safe for a large db

Studio-specifc:

• All user-facing strings are translated properly
• The notranslate class been added to elements that shouldn't be translated by Google Chrome's automatic translation feature (e.g. icons, user-generated text)
• All UI components are LTR and RTL compliant
• Views are organized into pages, components, and layouts directories as described in the docs
• Users' storage used is recalculated properly on any changes to main tree files
• If there new ways this uses user data that needs to be factored into our Privacy Policy, it has been noted.

Testing:

• Code is clean and well-commented
• Contributor has fully tested the PR manually
• If there are any front-end changes, before/after screenshots are included
• Critical user journeys are covered by Gherkin stories
• Any new interactions have been added to the QA Sheet
• Critical and brittle code paths are covered by unit tests

---

Reviewer's Checklist

This section is for reviewers to fill out.

• Automated test coverage is satisfactory
• PR is fully functional
• PR has been tested for accessibility regressions
• External dependency files were updated if necessary (yarn and pip)
• Documentation is updated
• Contributor is in AUTHORS.md

[bjester]

Instead of embedding the modal in each content node list item, having the component emit an event to a common place in the UI, makes more sense.

[vkWeb]

I don't remember why I did this way 🤔

@ozer550 will you be willing to refactor this and take this forward?

[bjester]

Yeah no worries @vkWeb! I talked to @ozer550 about this. Happy to make the update too

[vkWeb]

Sounds good :D

Btw upon trying to remember, my mind trace says that --

Most probably I did this because Vue allows emmiting events from a parent to a direct child only. So I had to catch the event on contentnode list item, I was not able to catch the event anywhere else.

The workaround for this was to utilise an event bus. So to keep things simple I might have done this.