[DEPR]: edx-proctoring-proctortrack and create_zendesk_tickets

[kdmccormick]

RFC Start Date

2025-03-05

Target Plan Accepted Date

2025-03-19

Target Transition Unblocked Date

2025-07-23

Earliest Breaking Changes Unblocked Date

2024-08-04

Ulmo - 2025-10

Rationale

• These packages (one Python package, one JS package) are specific to a paid vendor: Vereficient Proctortrack
• It is not clear from the repository how Open edX site operators are to use it.
• It hosted in personal GitHub repository for somebody that we have no contact with rather than the openedx org.
• The Python package has been installed into github.in for 2 years, in direct violation of the comments in that file. That is causing two problems:
  • It slows down image building for every single Open edX site operator.
  • It blocks improvements like PEP 508 adoption, which would give us the flexibility to use faster build tools like uv.
• The JS package is the only prod JS requirement being installed from github

Transition Steps

Please note: Some of these breaking changes will be implemented by 2U and others will be implemented by Axim through an FC. Please see "Tasks" for division of labor.

BREAKING CHANGE:: The option to create_zendesk_tickets for suspicious Proctored exam attemps will be removed from all courses.

BREAKING CHANGE: Previously, Studio required authors to provide an escalation email for proctored exams using the Proctortrack backend. Now, rather than validation this for Proctortrack exams in particular, Studio will now enforce it for any proctored exam whose backend is configured with requires_escalation_email: True. In order to retain the validation behavior for Proctortrack exams, operators will need to provide this configuration value in their Proctortrack backend, like this:

PROCTORING_BACKENDS = {
    "proctortrack": {
        "base_url": "<redacted>",
        ...,
        "requires_escalation_email": True,  # <-- New setting! Defaults to False.
    },
    ...,
}

BREAKING CHANGE: Previously, Studio would show a "Review Rules" field a part of proctoring configuration for all providers except Proctotrack; for Proctotrack in particular, it would show the Review Rules field iff the studio.show_review_rules CourseWaffleFlag was set to True. In order to remove Proctortrack-specific logic from the platform, we will remove the studio.show_review_rules Waffle flag, and add a new show_review_rules option to provider configuration dictionary. This will default to True, which will be a no-op for most providers. However, for users of Proctortrack, they will want to ensure that the show_review_rules option is set correctly. Pleasenote: this removes the ability to toggle review rules on a per-course basis.

PROCTORING_BACKENDS = {
    "proctortrack": {
        "base_url": "<redacted>",
        ...,
        "show_review_rules": False,  # <-- New setting! Default to True.
    },
    ...,
}

BREAKING CHANGE: edx-proctoring-proctortrack will be removed from github.in and thus removed from edx-platform's base requirements. Operators using Proctortrack should pip-install this package into their instance as an extra.

BREAKING CHANGE: edx-proctoring-proctortrack will be removed from package.json. Operators using Proctortrack should npm-install this package into their instance as an extra.

Replacement

The edx-proctoring-proctortrack plugin package continues to be maintained by 2U, but operators must install it separately rather than counting on it as a core requirement.

We may transfer this package into the openedx organization if 2U is willing to contribute and maintain it.

Existing technical discovery

2U did a discovery spike a few months ago when we first opened this ticket, which contains a lot of helpful information: https://docs.google.com/document/d/17-J1Nc15MkLLvv5sG6QIoQgj_Z1Lml2YHOiQIZI8XPQ/edit?tab=t.0#heading=h.gpsdcgbix0sd

Please note that the tasks and division of labor in that document are out-of-date. This ticket contains the most up-to-date plan.

Task List

2U Tasks

• Privately install edx-proctoring-proctortrack into edX's deployment of edx-platform.
• Uninstall edx-proctoring-proctortrack from edx-platform.
• Remove any Proctortrack specific documentation from the Open edX Platform, including developer docs and others.
• Remove create_zendesk_tickets and related logic and dependencies.

Axim FC Tasks

• Introduce a requires_escalation_email option to the backends within the PROCTORING_BACKENDS Django setting, defaulting to False. Wherever Proctortrack is referenced in order to decide whether an escalation email is required, check requires_escalation_email instead. Update tests and documentation as appropriate.
• Introduce a show_review_rules option to the backends within the PROCTORING_BACKENDS Django setting, defaulting to True. Wherever Proctortrack and/or the SHOW_REVIEW_RULES_FLAG Waffle flag is referenced in order to decide whether to show the Review Rules proctoring form field, check show_review_rules instead. Remove the existing SHOW_REVIEW_RULES_FLAG Waffle flag. Update tests and documentation as appropriate.
• Remove or modify comments and display strings that reference Proctortrack to become generic. These comments and strings exist in edx-platform, edx-proctoring, and frontend-app-authoring.
• Search for and remove any remaining Proctortrack references or dependencies in the openedx GitHub organization that were not already caught in this technical specification.

[kdmccormick]

Communicated: https://discuss.openedx.org/t/deprecation-removal-edx-proctoring-proctortrack/15168

[pdpinch]

MIT is a customer of Verificient Proctortrack. Is this repo necessary to use Proctortrack proctoring in open edX?

[UsamaSadiq]

Noticing the author's lack of response on this package for past one and a half year, I've decided to maintain a fork of this package in preparation for the upcoming Django 5.0 upgrade instead of requesting the author for maintenance again.
The github hash was used to have Django 4.2 support because the author didn't publish a new release despite multiple requests on the PR

I was going to create a separate issue to switch the dependency in edx-platform to my forked package but seems like it can be discussed here.

[kdmccormick]

Great question @pdpinch . I think the answer is yes. @michaelroytman , would you be able to confirm or deny that?

Thanks @UsamaSadiq . If this package must remain in edx-platform for some reason, then we'll want to move your fork into the openedx org and publish it to pypi. On the other hand, if this package could be converted to an optional requirement, that would be ideal. In this case, we could either (1) find a maintainer for it and move it into the openedx org anyway, or (2) allow operators like MIT ODL and 2U to maintain their own forks of the package.