Page Comparison

...

1. Update the CourseOverview table to include a new field for marketing_url under the course-catalog metadata section.
   1. Note: there is already a social_sharing_url field in this table.  That seems to have been added by the Solutions team, but seems distinct from the CMU since it can be specified by course-teams in the Advanced settings of the course (but only if SOCIAL_SHARING_SETTINGS and CUSTOM_COURSE_URLS feature flags are enabled).
   2. Make sure to inform edx/devops on the PR for this change so the migration can be monitored when it goes through stage and prod.
2. Create a django management command (update_catalog_data) that:
   1. Calls the Catalog services's course-marketing URL API to get a paginated response of CMUs for all courses in the CourseOverview table.
      1. Explicitly set the page size to a reasonable amount (the current default is only 20), given the Catalog service's SLA.
      2. Make the page size a configurable setting, possibly as an input parameter to the command.  Check with edx/devops on the best way to dynamically configure this setting.
   2. Sets the found CMUs in the new marketing_url field in the CourseOverview table.
   3. Logs to splunk:
      1. when the management command begins and ends
      2. simple statistics, such as the number of courses retrieved from the API
      3. whenever there are any failures in connecting with the Catalog service
3. Create an Ansible task? a Jenkins job (LMS_update_catalog_data) and a Jenkins job to  to run the new management command.
   1. Will need to consult with edx/devops to implement this.
4. Fix the implementation of get_lms_link_for_about_page (it currently returns the incorrect value for edx.org), which is used by the Mobile API.
   1. Update the method to take in a CourseOverview  object (already available to the Mobile API).

   2. Have it return course_overview.social_sharing_url or course_overview.marketing_url or reverse('about_course', course_overview.id), in that priority order.

...

• Pagination tuning. The default page size of 20 will result in an unnecessary large number calls to the Catalog API since production currently has over 3200 courses in the CourseOverview table.  Will need to determine a good approach to find the ideal value.  Making the page size dynamically configurable (e.g., via django admin) will help with tweaking this number.  (Note that ECOM-6834 will allow the page size to be changed dynamically, per-request.)
• CCX courses. It's unclear whether the Catalog service's course-marketing URL API will return the correct value for CCX courses.  If it doesn't, the management command will have to explicitly get the parent course of each CCX course before sending the request to the API.  Handling CCX courses can be implemented as an iterative change and need not be included as part of the initial rollout of this change, but should be handled.
• Inter-team dependencies. An early conversation and support with an edx/devOps member and ECOM is recommended to help this project go faster.
• Pagination bug (fix in progress). Currently, the LMS has not done a bulk query of the Catalog service in production.  We found a pagination issue in our previous attempt at this feature, that is now being fixed by ECOM.
• Mobile enrollment API performance (orthogonal bug created). In writing this document, I noticed that the Mobile enrollment API is currently not making bulk SQL queries where it should.  So the expected SLA of under 2-seconds is not being met (NewRelic link).  However, this is an orthogonal issue and should be fixed separately.

...