Skip to content

feat: New delete confirmation modal [FC-0083] #1906

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
wants to merge 7 commits into
base: master
Choose a base branch
from

Conversation

ChrisChV
Copy link
Contributor

@ChrisChV ChrisChV commented May 2, 2025

Description

  • A new warning message about units is added when deleting a component.
  • Uses the units dict on the search document to verify the new state of the delete confirmation modal.
  • Which edX user roles will this change impact? "Course Author".

Image

Image

Supporting information

Testing instructions

  • Go to the library home of a library
  • Create 3 components and 2 units.
  • Add one component to one unit
  • Add another component to both units.
  • From the component card in the library home, try to delete the component that is not in any unit. Verify the delete confirmation modal.
  • Try to delete the component that is in one unit. Verify the delete confirmation modal.
  • Try to delete the component that is in both units. Verify the delete confirmation modal.
  • Do the same in the component sidebar and in the block list on the units.

Other information

N/A

@openedx-webhooks openedx-webhooks added the open-source-contribution PR author is not from Axim or 2U label May 2, 2025
@openedx-webhooks
Copy link

openedx-webhooks commented May 2, 2025

Thanks for the pull request, @ChrisChV!

This repository is currently maintained by @bradenmacdonald.

Once you've gone through the following steps feel free to tag them in a comment and let them know that your changes are ready for engineering review.

🔘 Get product approval

If you haven't already, check this list to see if your contribution needs to go through the product review process.

  • If it does, you'll need to submit a product proposal for your contribution, and have it reviewed by the Product Working Group.
    • This process (including the steps you'll need to take) is documented here.
  • If it doesn't, simply proceed with the next step.
🔘 Provide context

To help your reviewers and other members of the community understand the purpose and larger context of your changes, feel free to add as much of the following information to the PR description as you can:

  • Dependencies

    This PR must be merged before / after / at the same time as ...

  • Blockers

    This PR is waiting for OEP-1234 to be accepted.

  • Timeline information

    This PR must be merged by XX date because ...

  • Partner information

    This is for a course on edx.org.

  • Supporting documentation
  • Relevant Open edX discussion forum threads
🔘 Get a green build

If one or more checks are failing, continue working on your changes until this is no longer the case and your build turns green.


Where can I find more information?

If you'd like to get more details on all aspects of the review process for open source pull requests (OSPRs), check out the following resources:

When can I expect my changes to be merged?

Our goal is to get community contributions seen and reviewed as efficiently as possible.

However, the amount of time that it takes to review and merge a PR can vary significantly based on factors such as:

  • The size and impact of the changes that it introduces
  • The need for product review
  • Maintenance status of the parent repository

💡 As a result it may take up to several weeks or months to complete a review and merge your PR.

@ChrisChV ChrisChV marked this pull request as draft May 2, 2025 21:36
@github-project-automation github-project-automation bot moved this to Needs Triage in Contributions May 2, 2025
@ChrisChV ChrisChV changed the title Chris/fal 4099 new delete confirmation modal feat: New delete confirmation modal [FC-0083] May 2, 2025
Copy link

codecov bot commented May 2, 2025

Codecov Report

Attention: Patch coverage is 95.45455% with 1 line in your changes missing coverage. Please review.

Project coverage is 93.82%. Comparing base (8c3fab3) to head (28e5cf4).

Files with missing lines Patch % Lines
src/library-authoring/components/ComponentMenu.tsx 50.00% 1 Missing ⚠️
Additional details and impacted files
@@           Coverage Diff            @@
##           master    #1906    +/-   ##
========================================
  Coverage   93.82%   93.82%            
========================================
  Files        1147     1147            
  Lines       23973    23990    +17     
  Branches     5054     5167   +113     
========================================
+ Hits        22492    22508    +16     
- Misses       1413     1414     +1     
  Partials       68       68            

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:
  • ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
  • 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

@ChrisChV ChrisChV marked this pull request as ready for review May 2, 2025 22:11
Copy link
Contributor

@rpenido rpenido left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM 👍
Thank you for your work, @ChrisChV!

  • I tested this using the instructions from the PR
  • I read through the code
  • I checked for accessibility issues
  • Includes documentation

I left one non-blocking comment about moving some things around.
Let me know what you think!

Comment on lines 150 to 162
const { client, indexName } = useContentSearchConnection();
const {
hits: componentHit,
} = useContentSearchResults({
client,
indexName,
searchKeywords: '',
extraFilter: [`usage_key IN ["${usageKey}"]`],
limit: 1,
enabled: true,
skipBlockTypeFetch: true,
});

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What do you think about creating a useComponentUnits hook for this?
Also, I believe that if you move the fetch call to the ComponentDeleter, you will not need to replicate this on the LibraryUntiBlocks.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I added the useComponentsFromSearchIndex in 917421d.

About moving the fetch all to the ComponentDeleter, I think I would add more calls, in the case of the card component, that information is already available from the search index, and if we add it to the ComponentDeleter, it would be called again

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@ChrisChV Can we move the call inside of ComponentMenu while still accepting units prop and only fetch if the prop is not passed?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Or another solution would be to put it inside the ComponentDeleter and change to render it conditionally, like {isConfirmingDelete && <ComponentDeleter usageKey={usageKey} isConfirmingDelete={isConfirmingDelete} cancelDelete={cancelDelete} />}.
That way, the component is only rendered when the dialog opens, saving the extra calls.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Refactored here: 6291f67

@mphilbrick211 mphilbrick211 moved this from Needs Triage to In Eng Review in Contributions May 6, 2025
@mphilbrick211 mphilbrick211 added the FC Relates to an Axim Funded Contribution project label May 6, 2025
Comment on lines 195 to 198
<ComponentMenu
usageKey={usageKey}
unitsData={(componentHit as ContentHit[])?.[0]?.units}
/>
Copy link
Contributor

@navinkarkera navinkarkera May 7, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@ChrisChV It would be simpler to call useComponentsFromSearchIndex inside of ComponentMenu or ComponentDeleter (preferably former) component instead of passing through props.

Edit: Ahh, I missed the comment from @rpenido above.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Refactored here: 6291f67

@ChrisChV
Copy link
Contributor Author

ChrisChV commented May 8, 2025

@navinkarkera This is ready for another review. I asked Product about the final design: #1685 (comment)

Copy link
Contributor

@navinkarkera navinkarkera left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@ChrisChV Looks good 👍

  • I tested this: (Verified units info in delete component)
  • I read through the code
  • I checked for accessibility issues
  • Includes documentation

@ChrisChV
Copy link
Contributor Author

@bradenmacdonald This is ready for your review as CC

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
FC Relates to an Axim Funded Contribution project open-source-contribution PR author is not from Axim or 2U
Projects
Status: In Eng Review
Development

Successfully merging this pull request may close these issues.

5 participants