[rahulkanneri-2u]

Description

Certificate access checks only read legacy edx-proctoring records, so learners on LTI proctoring courses (proctoring_provider == lti_external, e.g. Proctorio) could reach a certificate despite a submitted, errored or rejected attempt in edx-exams.

This PR makes the certificate proctoring block also read attempt status from edx-exams for those courses, behind a new waffle switch certificates.certificate_proctoring_review_block_exams (default off).

• New read-only client lms/djangoapps/certificates/exams_client.py.
• rejected blocks on this path with the new reason proctoring_rejected and learner messaging on the dashboard and blocked-certificate page.
• Never-started legacy records no longer block on LTI courses.
• Fails closed on edx-exams errors, unknown statuses and overview lookup failures.
• New settings: EXAMS_SERVICE_URL, EXAMS_SERVICE_USERNAME, EXAMS_SERVICE_REQUEST_TIMEOUT.

Roles impacted: Learner, Operator.

Supporting information

Requires the edx-exams certificate_proctoring status endpoint. edx/edx-exams#447

Testing instructions

pytest lms/djangoapps/certificates/tests/test_proctoring_block.py lms/djangoapps/certificates/tests/test_exams_client.py

Manual: enable both switches, set the course provider to lti_external, then set the learner's edx-exams attempt to submitted, rejected and verified and check the dashboard message.

Deadline

None

Other information

• No migrations. No behavior change until the new switch is enabled.

[abhalsod-sonata]

Approved: this blocks safely on every failure path, which is the right default for a certificate integrity check, and the legacy refactor reads much better. Two things for the rollout and one design question:

1. LMS needs EXAMS_SERVICE_URL before the switch goes on. Today only the CMS deployment config sets it, so the LMS uses the default http://localhost:18740/api/v1. With certificate_proctoring_review_block_exams enabled, every lookup would fail and, because failures block, every learner on an LTI proctoring course would lose certificate access. Worth adding it to the LMS config first and saying so in the toggle annotation (suggestion inline).

2. Cost on list pages. get_certificates_for_user (via _format_certificate_for_user) and the dashboard run this check once per downloadable certificate, sequentially. On LTI courses each check loads the service user, mints a JWT and makes an HTTP call with a (3.05, 5) timeout, so a learner with several LTI certificates pays that several times per page, and an edx-exams slowdown turns into a slow dashboard on top of blocked certificates. Could we cache a successful status briefly (for example 60 s in TieredCache, keyed by user and course)? Access would still be restored within a minute of review, and an outage would not multiply across pages.

3. Minor reuse: _get_exams_api_client is the same code as cms/djangoapps/contentstore/exams.py. LMS code can't import from CMS, so that's fine for now, but a shared helper under openedx/core would be a good follow-up.