feat: [FC-0031] Add new endpoint CourseInfoDetailView

[oksana-slu]

Description

Add a new mobile endpoint that is based on the CourseDetailView endpoint
but extends it with information about user enrolment.

Supporting information

This contribution is done as a part of the project FC-0031

Testing instructions

GET /api/mobile/v3/course_info/{course_key}/info

See that "is_enrolled" is present in the response

[openedx-webhooks]

Thanks for the pull request, @oksana-slu! 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.

[feanil]

@oksana-slu given that the existing CourseDetailView already can take a username as an optional parameter. Why not simply enhance that endpoint to provide enrollment data if a username is passed in? That seems reasonable and more robust than to make a whole new endpoint just for mobile that is highly coupled to that endpoint anyway.

[GlugovGrGlib]

Hi @feanil, when discussing the solution, we considered these two main options: customize CourseDetailView or extend it in mobile APIs application. I agree that is_enrolled option could be better added directly in the CourseDetailView, but because the About page is very frequently extended with custom parameters in the community on the web, we decided to introduce a separate mobile endpoint with a separate URL. We believe it will allow the community provider to easily extend it via Serializer override or override this new URL to introduce customizations for About page for mobile apps only.

What do you think, is it a fair trade-off?

[feanil]

@GlugovGrGlib so the idea would be that if you wanted to have a custom course about page, you would override the serializer for the Mobile endpoint we are adding and it would not impact the other course detail endpoint? I would think that if you are customizing the mobile view you might also want to customize the non-mobile view of the same info, is that not often the case? It seems like this would introduce drift between what data is available to the mobile app vs the web app which is something I would think we want to reduce.

[GlugovGrGlib]

@feanil
Currently, when customizing About Course page on the web, there is no need to modify this REST API at all because the About Course page is still rendered on the backend.

Also, (AFAIK) the main use case for CourseDetailView is to expose an external API to fetch the course data, the data we want to provide to synchronize backend rendered web and mobile views may be redundant in some cases. Of course, it's not the case if operator creates own frontend to completely replace About Course, but I'm not sure how popular that may be.

Furthermore, according to the issue #31620, there isn't a decision for transitioning this page into MFE. So it's not clear whether the future MFE page would exist and if it will be decided to use exclusively CourseDetailView to load data.

[feanil]

@GlugovGrGlib long term, everything will become an MFE so whatever API we end up using for mobile will hopefully also work for that future MFE. In that future, I would assume the mobile access pattern here wouldn't be too different from the MFE access pattern. Also, having the names CourseDetailView and a CourseInfoDetailView are confusing names. We're how would you know when to use one over the other? I still don't understand why using this is better than using the existing optional username parameter to populate additional data in the existing view. It sounds like the concern might be that we'll break something? Is it that? Something else?

[GlugovGrGlib]

@feanil we are working on the suggested long term appropriate solution with extending CourseDetailView, so the response for this view will be extended if an optional parameter username is passed. We will close this PR and open a new PR with the respective changes, thank you.

[openedx-webhooks]

@oksana-slu Even though your pull request wasn’t merged, please take a moment to answer a two question survey so we can improve your experience in the future.

[openedx-webhooks]

@oksana-slu Even though your pull request wasn’t merged, please take a moment to answer a two question survey so we can improve your experience in the future.