feat: Update pendo IIFE handling to evaluate configured IIFE

[j0mc]

The pendo feature now evaluates the IIFE passed in via the MFE configuration, and passes it two arguments, first is the base URL of the lms in lmsUrl, and the second is the username in username. Note that no error handling is provided for the IIFE, any exceptions within the IIFE will be passed up to the browser. This assists in debugging issues with the IIFE but risks causing errors for end users in the MFE if the IIFE does not catch exceptions.

We use the Function() constructor here as it's safer than eval(), but does not pass scope into the function so we must pass any needed data as arguments. Currently passing the LMS base URL as well as the username to assist in fetching user data.

The IIFE should fetch whatever data necessary and return the dictionary that will be set into local storage with the key specified by the MFE config's PENDO_VISITOR_KEY. An example IIFE that can be set in the MFE config entry PENDO_VISITOR_IIFE which fetches from the LMS user api:

"(async function (lmsUrl, username) {\
    let resp = await fetch(`${lmsUrl}/api/user/v1/accounts/${username}`,    { method: \"GET\", credentials: \"include\" });\
    let json = await resp.json();\
    return JSON.stringify({USERID: json[\"email\"]})\
  })(lmsUrl, username).catch(() => { return null; })"

Overview

1. Edit the Site Configuration on the LMS setting the following values under MFE_CONFIG:

• ENABLE_PENDO: true,
• CUSTOM_PENDO: true,
• PENDO_VISITOR_KEY: "currentPerson",
• Set PENDO_VISITOR_IIFE from the IIFE snippet above

2. Load a course through the MFE and check that the currentPerson key in the browser's local storage is set with a dictionary containing the user's email address

Checklist

⚠️ Please make sure to fill this checklist before asking for reviews.

• Code is correctly formatted and linted
• Unit tests are updated and are passing
• PR title follows conventional commits:
  i.e. feat(CUR-###): Feature title
• PR Title aligns to Semantic-Release supported prefixes (NOTE: prefixes are case sensitive, keep lower-case):

 feat() - Feature (0.X.0)
 fix() - Patch (0.0.X)
 docs() - Patch (0.0.X), will only scope to README changes
 refactor() - Patch (0.0.X)
 revert() - Patch (0.0.X)
 style() - Patch (0.0.X)

• Check for unused files
• Check work before asking for reviewers
• Fix any linting errors
• SECURITY: No secrets where commited to the repo
• COMPLIANCE: Commited code is not propietary and adheres to Open Source licensing

[rodmgwgu]

Please target a release instead of main (like palm.master or quince.master)

[j0mc]

@rodmgwgu, I targeted main since Academy is building images from the main branch, but it seems like we probably want to change that if we're updating main for Quince. Should I switch the Academy builds to target palm.master and target this PR to palm.master ?

[rodmgwgu]

@j0mc yes, you should target the specific version that Academy is running, (palm.master if you are running palm).

main I think is not even updated to palm, it's still on olive I think

[j0mc]

Thanks @rodmgwgu , I have a PR on the devops repo to allow us to configure the MFE branch, rebased this branch on palm master and set the base here to palm.master.

I also created #87 to pull the changes from #83 into the palm.master branch, since we'll need both in palm.master