feat: Turnitin API workflow test with openedx XBlock

[nandodev-net]

Turnitin API test xblock

this xblock describes the Turnitin API workflow to generate de similarity report and online viewer.

this workflow has 7 steps (handlers) with self explanatory names:

1. get_eula_agreement
   with a given eula_version, request EULA html text to Turnitin API.

2. accept_eula_agreement
   with a given eula_version and user_id, accept EULA agreement to Turnitin API.

3. 1 . create_turnitin_submission_object
   with a user and submission data payload, create a submission object in Turnitin. Response: submission_id.

3. 2 . upload_turnitin_submission_file
   with submission_id upload the document assessment.

4. get_submission_status
   with submission_id get the uploaded document status {CREATED - PROCESSING - COMPLETE - ERROR}

5. generate_similarity_report
   if the submission_status is COMPLETE, with submission_id generate the similarity report in Turnitin.

6. get_similarity_report_status
   with submission_id get the similarity report status {PROCESSING - COMPLETE}.

7. create_similarity_viewer
   if similarity report status is COMPLETE, with submission_id get the Viewer URL.

Testing

Follow the workflow gif ahead... Secret Key on basecamp

[BryanttV]

Please format the code, maybe you could use black 🤔, and don't forget the docstring when everything is ready.

[mariajgrimaldi]

If this is ready for review, please use an adequate name for the PR. Thanks!

[mariajgrimaldi]

what do these settings mean? should we have a plugin setting called TURNITIN_SIMILARITY_REPORT_SETTINGS for this?

[nandodev-net]

@mariajgrimaldi Yes... we should define each parameter from the optional settings that Turnitin offers to obtain the result we expect from them.

[nandodev-net]

@mariajgrimaldi The only issue is that there are nested variables throughout the request structure. So in order to create the settings variable, we have to check the docs to create many variables as need and put them throughout the request structure. We need more time and owner's review to do this

[mariajgrimaldi]

Instead of having a method_map, you could pass directly the method:
turnitin_api_handler(requests.get, ...)

[nandodev-net]

Hmm... I believe it would be better to create the method_map within a separate function. This way, we can modify the method conditionals based on a list of strings, rather than a list of methods. This approach:
if request_method.lower() in ["post", "put", "patch"]
is more elegant than this:
if request_method in [requests.patch, request.post,....]
and certainly cleaner than a series of:
if request_method == requests.post: ... elif ... : ... else: ...

[mariajgrimaldi]

url = f"{TII_API_URL}/api/v1/{url_prefix}"
request_load = {
 "headers": headers
}
if params:
   request_load["params"] = params
if data:
   request_load["data"] = data
response = method_func(url, **request_load) 

When using get, the caller send params as an argument. When using the rest the caller sends data. What do you think?

[nandodev-net]

I like it :)
I propose this

args = {
    "headers": headers,
    "json" if request_method.lower() in ["post", "put", "patch"] else "params": data
}

response = method_func(f"{TII_API_URL}/api/v1/{url_prefix}", **args)

[mariajgrimaldi]

should this be response.json()?

[nandodev-net]

there's a couple of endpoints in a different format, that's why I use .json() in some @XBlock.json_handler methods, and not in the turnitin_api_handler method

[mariajgrimaldi]

What we'll use for the integration looks good! Thank you

[Ian2012]

@mariajgrimaldi please let me know if we can merge this one