fix: refactor MakoService to allow specifying namespace per template

[bradenmacdonald]

Description

Currently, the "Manage Access" menu in Studio is not working consistently (sometimes it does work though), due to a template error:

This is not the first error we've had with the MakoService being unable to find mako templates, and the problem stems from different search paths for "LMS templates" vs "CMS templates", and the fact that the runtime has this internal state that determines which paths to search for any given template. As you can see, the CMS runtime is often using the wrong paths, resulting in this error.

I believe that the best fix for this issue that will keep it from happening in the future, as it has happened at least 3 or 4 times so far, is to change the MakoService API to allow specifying the search path along with the template name. You want to render a template that's in lms/templates/...? Great, now call render_lms_template(). Want to render one that's in cms/templates/...? Great, now call render_cms_template().

Of course mako templates are terrible and they should all be replaced with django templates or React UI, but that's a battle for another day.

Supporting information

One of the past bugs: #32895

Testing instructions

1. Create a course in Studio, set it's "Advanced Module List" to ["annotatable", "poll", "library_content", "lti_consumer"] .
2. Add to the course: one of every "Advanced" XBlock listed, one each of library content, problem, text, video, and discussion.
3. Make sure the studio_view ("Edit") and author view are working (for library content, configure a library then click "View >" - that's the author view; other blocks, the author view is just what you see in studio, and usually identical to the student view).
4. Publish the unit and view it in the LMS to make sure all the blocks are working there too.

Deadline

ASAP - CAT-2 issue

Other info

Private-ref: MNG-3884

[openedx-webhooks]

Thanks for the pull request, @bradenmacdonald! Please note that it may take us up to several weeks or months to complete a review and merge your PR.

Feel free to add as much of the following information to the ticket as you can:

• supporting documentation
• Open edX discussion forum threads
• timeline information ("this must be merged by XX date", and why that is)
• partner information ("this is a course on edx.org")
• any other information that can help Product understand the context for the PR

All technical communication about the code itself will be done via the GitHub pull request interface. As a reminder, our process documentation is here.

Please let us know once your PR is ready for our review and all tests are green.

[rayzhou-bit]

This looks good to me.

I tested each block in studio, library and lms with local devstack and do not see any issues.

[openedx-webhooks]

@bradenmacdonald 🎉 Your pull request was merged! Please take a moment to answer a two question survey so we can improve your experience in the future.

[kenclary]

I don't mind that this got merged, but I think the terminology is further obfuscating the problem.

This isn't about CMS vs LMS (in fact, it is only ever relevant to CMS). The namespace isn't being used as a namespace; it's being used as a switch between mako "engines," specifically between regular CMS and CMS "preview" (for authors previewing student views).

Basically I don't like the naming of these functions.

[bradenmacdonald]

@kenclary The only difference between those "engines" is the DIRS argument which determines whether to search LMS dirs or CMS dirs. They don't have any difference in behavior, other than one searches the LMS paths and the common paths, while the other searches the CMS paths and the common paths. (And I guess the "namespace" is different, but that's just used to distinguish the engines for some reason, and has no impact on template functionality.)

So I thought this naming would be most clear to developers, as it reflects the actual difference/goal (set which template paths get searched), and not the mechanism by which that happens or the confusing term used ("namespace"). What would you suggest instead?

This isn't about CMS vs LMS

Let's say you want to render visibility_editor.html. Which function/engine you need to use depends only on whether it is located in lms/templates/visibility_editor.html or cms/templates/visibility_editor.html. So isn't that CMS vs LMS?

[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.