Wgu jesse stewart/instructor dashboard certificates bulk

[wgu-jesse-stewart]

feat: add bulk certificate exceptions endpoint and stabilize JWT tests

Description

Adds a new v2 instructor API endpoint for granting certificate exceptions in bulk via CSV upload, and refactors the JWT test module to avoid a stale-timestamp issue.

New endpoint: BulkCertificateExceptionsView

POST /api/instructor/v2/courses/{course_id}/certificates/exceptions/bulk

Accepts a multipart form upload with a file field containing a CSV. Each row is username_or_email[,notes]. The view:

• Validates that the upload is present and named *.csv.
• Decodes with utf-8-sig so Excel-exported files with a BOM work without the user having to think about it.
• Skips empty rows.
• Resolves all identifiers via _resolve_learners_to_users and validates them via _validate_learners_for_certificate_exceptions before any writes — same helpers used by the single-learner path, so behavior stays consistent.
• Calls certs_api.create_or_update_certificate_allowlist_entry for each valid learner and aggregates results into a single { "success": [...], "errors": [...] } payload.
• Logs each grant with the acting instructor, target user, and course key for audit traceability.

Errors during a single row are caught and reported in errors rather than aborting the batch — partial success is the expected mode for CSV imports.

Permission checks reuse permissions.InstructorPermission and CERTIFICATE_EXCEPTION_VIEW, matching the existing single-exception endpoint.

Test stabilization: test_jwt.py

The module previously computed test_now = int(time()) once at import and reused it across every test, along with a module-level expected_full_token dict built from that timestamp. That makes the suite sensitive to import-vs-execution timing and to test reordering — and means any test that mutates expected_full_token would leak into others.

Replaced both module-level constants with two helpers:

• get_test_now() — returns the current time when the test runs.
• get_expected_full_token(test_now) — returns a fresh expected payload bound to that timestamp.

Each test now grabs its own test_now at the top and builds its expected payload from it. No behavior change to the JWT code itself.

User roles impacted

• Course staff / instructors: gain a bulk-upload path for certificate exceptions. The existing single-learner flow is unchanged.
• Developers: new endpoint to wire into the instructor dashboard MFE / any frontend that drives certificate management.
• Operators: no config or migration changes.

Supporting information

• Builds on the existing v2 instructor API surface and the _resolve_learners_to_users / _validate_learners_for_certificate_exceptions helpers introduced earlier in the v2 redesign.
• Mirrors the request/response shape used by other bulk CSV endpoints in the instructor API for consistency.

Testing instructions

Bulk certificate exceptions endpoint

1. Bring up devstack / Tutor with a course that has at least three enrolled learners.
2. Authenticate as a user with instructor permissions on that course.
3. Prepare a CSV (exceptions.csv):

   learner1@example.com,Manual review approved
   learner2,
   nonexistent@example.com,Should fail
   

4. POST it:

   curl -X POST \
     -H "Authorization: JWT <token>" \
     -F "file=@exceptions.csv" \
     https://<lms-host>/api/instructor/v2/courses/<course_id>/certificates/exceptions/bulk
   

5. Verify the response is 200 with success containing the two valid learners and errors containing the unknown email with a clear message.
6. Confirm in Django admin (or via the single-exception GET) that allowlist entries exist for the two valid learners with the supplied notes.
7. Negative cases to verify return 400:
   • No file field in the request.
   • File without a .csv extension.
   • Empty CSV / CSV containing only blank lines.
8. Verify a non-instructor user receives 403.
9. Tail the LMS logs and confirm one Certificate exception granted ... info line per successful row, naming the acting instructor.

JWT tests

Run the affected module:

pytest openedx/core/lib/tests/test_jwt.py -v

All tests should pass. Optionally re-run several times in a row, or with -p no:randomly reversed (random order), to confirm there's no ordering sensitivity.

Deadline

None.

Other information

• No database migrations.
• No new settings or feature flags — the endpoint is gated by the same instructor permission as the existing certificate exception endpoints.
• The BulkCertificateExceptionsView follows the same broad-except pattern as neighboring views in api_v2.py (with pylint: disable=broad-except) so per-row failures don't abort the batch. Each caught exception is logged via log.exception with the user and course key.
• CSV is read fully into memory (uploaded_file.read()); for very large rosters this may want a streamed parser later, but matches the existing bulk-CSV endpoints in this module.
• No frontend changes in this PR — consumer MFE work will land separately.

[openedx-webhooks]

Thanks for the pull request, @wgu-jesse-stewart!

This repository is currently maintained by @openedx/wg-maintenance-openedx-platform.

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.

Details

---

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:

• Overview of Review Process for Community Contributions
• Pull Request Status Guide
• Making changes to your pull request

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.