-
Notifications
You must be signed in to change notification settings - Fork 15
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
TC_AUTHOR_133: STUDIO: SETTINGS: ADVANCED: Course visibility in catalog #164
Comments
label: testing nutmeg |
I was trying to debug this, and I think simliar issue was raised in tutor forum before1. However in the forum thread, it was resolved by disabeing the discovery service, where in nutmeg demo discovery is enabled. And I guess one should assume that using discovery service shouldn't stop course author/admin from being able to hide the course However I wasn't sure if the "Course visibility in catalog" affects discovery service? I couldn't find any documentation about that explicitly. @regisb do you have any though on this? Footnotes |
Also to confirm what @DeanJayMathew have repoted:
The first case it worked becasuse the result wasn't retrived by discovery/search service while second failed because it gets from discovery service |
Thank you for debugging this, well noted. The Discovery service is an important service we use in almost all our separate instances. So for me it's a high priority. I will speak to my colleagues for their input too since they are experienced in this discovery service. Let's aim to resolve this ticket this week. |
When discovery service is enabled, then the /courses page in LMS will not be filled with courses **initially**, so that a frontend script will send XHR request to fetch courses using POST /search/course_discovery/, the LMS then will proxy the request to edx-search. The probelm is when a course is hidden using advance setting, in studio, the edx-search is not affected or is not concern with that setting. So here I am adding an edge case, where if in the search request the 'catalog_visibility' is not set, it will default to 'both' meaning, by default it will *only* return courses that are suppose to be visible in the catalog. This fixes openedx/wg-build-test-release/issues/164.
When discovery service is enabled, then the /courses page in LMS will not be filled with courses **initially**, so that a frontend script will send XHR request to fetch courses using POST /search/course_discovery/, the LMS then will proxy the request to edx-search. The probelm is when a course is hidden using advance setting, in studio, the edx-search is not affected or is not concern with that setting. So here I am adding an edge case, where if in the search request the 'catalog_visibility' is not set, it will default to 'both' meaning, by default it will *only* return courses that are suppose to be visible in the catalog. This fixes openedx/wg-build-test-release/issues/164.
This adds a plugin to override edx-search in order to fix openedx/wg-build-test-release/issues/164 also for more context the upstream PR openedx/edx-search/pull/124
This adds a plugin to override edx-search in order to fix openedx/wg-build-test-release/issues/164 also for more context the upstream PR openedx/edx-search/pull/124
This adds a plugin to override edx-search in order to fix openedx/wg-build-test-release/issues/164 also for more context the upstream PR openedx/edx-search/pull/124
@DeanJayMathew I'm not sure if this question can be resolved by next week, or even whether it's an actual issue at all. Let me refer to my answer to that forum topic : https://discuss.overhang.io/t/catalog-visibility-in-tutor-deployed-open-edx/214/6?u=regis
In other words, the "course visibility in catalog" does NOT refer to the listing in the /courses page. It's very weird, but that's the way it has been since, well forever. If you ask me, I think that this advanced setting should indeed govern the course listing in /courses. We should simply be aware that this would not classify as a "bug fix" but a "breaking change feature". |
When discovery service is enabled, then the /courses page in LMS will not be filled with courses **initially**, so that a frontend script will send XHR request to fetch courses using POST /search/course_discovery/, the LMS then will proxy the request to edx-search. The probelm is when a course is hidden using advance setting, in studio, the edx-search is not affected or is not concern with that setting. So here I am adding an edge case, where if in the search request the 'catalog_visibility' is not set, in filter or or exculde it will default, to exculde 'none' and 'about' meaning only courses with 'catalog_visibility' set to 'both' will be returned or visbile in the /courses page This fixes openedx/wg-build-test-release/issues/164
This partialy fixes #openedx/wg-build-test-release/issues/164 The flag would make it possible to hide courses in the /courses page when ENABLE_COURSE_DISCOVERY is true. For more context check the forum thread: https://discuss.openedx.org/t/request-for-feedbak-breaking-changes-for-course-visibility/7341
Hi @ghassanmas !!!! do we have any update regarding this issue? Thanks in advance |
@NeOneSoft Yes I will comment below the summary of the finding. I will just re post what I already repoted in the forum the forum.
Given the above finding, tutor was changed to use that flag by default. Note using that flag, would enable to hide the course if the settings is "none" only. It won't work for "about". |
Thank you so much @ghassanmas for your update here!!! |
Steps to reproduce:
Go to https://studio.nutmeg.demo.overhang.io/home with staff credentials
Go to Advanced Settings: Course Visibility in Catalog
Set to "none":
Expected result:
Go to https://nutmeg.demo.overhang.io and the course should NOT be visible.
Go to https://nutmeg.demo.overhang.io/courses and the course should NOT be visible.
Actual result:
Course is NOT visible on https://nutmeg.demo.overhang.io <-- this is good
Course is still visible on https://nutmeg.demo.overhang.io/courses <-- this is the bug
The text was updated successfully, but these errors were encountered: