fix: add should_display_status_to_user method and status_changed field to VerificationAttempt model

[ilee2u]

Ticket: https://2u-internal.atlassian.net/browse/COSMO-499

Description

This PR fixes a bug where the IDVerificationService was accessing methods and fields of the platform VerificationAttempt model that didn't exist:

should_display_status_to_user

This method is called by:

• the IDVerificationStatus.user_status method
• other parts of the platform use the user_statusmethod and the should_display value
• the check_verify_status_by_course method

Note for self: Updating this may not be as straightforward as returning a hardcoded boolean like the other verify_student models do. For example, SSOVerification instances return True, but ManualVerification instances return False. Because the platform VerificationAttempt model is intended to be vendor and implementation agnostic, consider whether this belongs as a field on the model instead.

status_changed (comes from the StatusModel that IdVerificationAttempt inherits from but VerificationAttempt does not)

This field is referenced by

• the IDVerificationStatus.user_status method
• other parts of the platform use user_status field and the status_date value

Relevant Docs: Add Extensibility Mechanisms to IDV to Enable Integration of New IDV Vendor Persona · Issue #367 · openedx/platform-roadmap

Environment

Useful information to include:

• Which edX user roles will this change impact? Common user roles are "Learner", "Course Author",
  "Developer", and "Operator".
• Include screenshots for changes to the UI (ideally, both "before" and "after" screenshots, if applicable).
• Provide links to the description of corresponding configuration changes. Remember to correctly annotate these
  changes.

Supporting information

Link to other information about the change, such as Jira issues, GitHub issues, or Discourse discussions.
Be sure to check they are publicly readable, or if not, repeat the information here.

Testing instructions

Please provide detailed step-by-step instructions for testing this change.

Deadline

"None" if there's no rush, or provide a specific date or event (and reason) if there is one.

Other information

Include anything else that will help reviewers and consumers understand the change.

• Does this change depend on other changes elsewhere?
• Any special concerns or limitations? For example: deprecations, migrations, security, or accessibility.
• If your database migration can't be rolled back easily.

[ilee2u]

Zach helped me come up with this param/var, which we could add to the api function as such.

[MichaelRoytman]

This looks good to me so far! I had several questions to better understand your approach.

The status_changed field is one thing that I'm not understanding, so I'd like to see that address before you merge, please!

[ilee2u]

NOTE: We had an issue where inheriting from both StatusModel and TimeStampedModel produced two created fields in the VerificationAttempt model. We ended up deciding to use a custom created_at and updated_at fields (instead of trying to override the save() function to make a custom version of status_changed from the StatusModel) in order to match the pattern of the other models.

[schenedx]

👍

[MichaelRoytman]

If possible, could you squash these migrations, please? It keeps things tidy.

[ilee2u]

Done!

[edx-pipeline-bot]

2U Release Notice: This PR has been deployed to the edX staging environment in preparation for a release to production.

[edx-pipeline-bot]

2U Release Notice: This PR has been deployed to the edX production environment.

[edx-pipeline-bot]

2U Release Notice: This PR has been deployed to the edX production environment.