feat: Added data_share_consent field to order fullfillment notes

[irfanuddinahmad]

Description

This PR adds a data sharing consent flag to the order fulfillment notes. The flag will record the learner's acceptance of the data sharing consent while registering for third party hosted course content. The PR also uses the LMS consent apis to record the data sharing consent by the learner.

Supporting information

Jira: ENT-6794

[saleem-latif]

Looks Good 👍

[bilaltahir21]

Looking Good 👍

[adamstankiewicz]

[clarification/curious] Say the create_enterprise_allocation API endpoint throws an exception below, after already successfully creating a new DSC record for the user/course here. It seems here appears we'd be keeping the newly created DSC record around in our system even though we failed to actually make the GEAG allocation/enrollment.

Curious on the rationale for creating the DSC record prior to a successful create_enterprise_allocation call to the GEAG API.

[irfanuddinahmad]

The assumption is that the consent api maybe more flaky than the GEAG api. Hence, if the consent fails to be recorded, we don't want the GEAG to be recorded as well.

[adamstankiewicz]

[curious] If we create a DSC record but then fail to create the GEAG enterprise allocation, could there exist a mechanism to attempt to remove the newly created DSC record (essentially garbage collect DSC record if allocation failed)? Either way, likely not something to invest too much time into given this code path will eventually be replaced by the APIs in the EMET system.

[aside] I'd also be curious to hear why you think the consent API might be more flaky than the GEAG API? 🤔

[muhammad-ammar]

Adam: I think issue can also happen if we first create the GEAG enrollment and then create consent record. Lets say consent errors out after successful GEAG enrollment. What to do in that case? Should we rollback the GEAG enrollment? I think consent is mandatory?

[muhammad-ammar]

My understanding is that if both the GEAG enrollment and consent record should be present then we should rollback transaction in case of error in any of the GEAG enrollment call or consent record call?

[adamstankiewicz]

Lets say consent errors out after successful GEAG enrollment. What to do in that case? Should we rollback the GEAG enrollment? I think consent is mandatory?

FWIW, I'm just clarifying the approach. I don't feel strongly that the DSC call needs to be after a successful GEAG allocation. Just asking for my own edification 😄

That said, when we call GEAG, we are already passing data_share_consent: true in the GEAG API payload, which from my understanding should be sufficient from GEAG's perspective. I had thought our LPR reporting will be relying on the data_share_consent: true passed to the GEAG enterprise allocation API, not so much an actual DSC record in our own database (this assumption may be incorrect).

Also, isn't consent conditionally required based on the enable_data_sharing_consent config flag on the EnterpriseCustomer?

[irfanuddinahmad]

Thanks @adamstankiewicz ... always much appreciate your insights. I think we did not want to change the LPR pipeline with flags from GEAG. Hence, this consent api call ... you are correct that DSC should be garbage collected at some point. The frontend MFE will ensure that the consent checkbox is only visible for those learners who have the enable_data_sharing_consent config flag on their EnterpriseCustomer.

[irfanuddinahmad]

@johnnagro @iloveagent57 I am not to familiar with the plan for GEAG<->DSC integration for LPR ... Can you review also?
We are currently creating the DSC records to enable LPR for these learners. However, api failure could result in a valid DSC without an associated allocation in GEAG. However, the DSC calls are idempotent ... so we expect to have the situation fixed whenever the allocation attempt is repeated.

[zubair-ce07]

LGTM 👍