feat: make hide from TOC a visibility section setting

[mariajgrimaldi]

Description

This PR exposes the hide_from_toc xblock attribute so course authors can configure it as a section visibility option in Studio. Before this change, the Hide from TOC functionality was mainly used by OLX components. Hence, it wasn't available for configuration through the Studio UI. Still, its implementation existed in the platform and could be used by setting the attribute: hide_from_toc=true as part of the OLX definition.

So we could use the hide_from_toc attribute in the Studio UI making it configurable for sections and their children, we did the following:

• Add hide_from_toc to the CMS Xblock handlers, serializers, and data classes so it can be recognized when setting the new visibility state option
• Add it to the inheritance mixin so the sections' children recognize the configuration option
• Make it available in the backbone frontend for course authors to configure as in visible_to_staff_only

Supporting information

These changes are part of the effort made to implement feature enhancement proposal: Hide sections from course outline

Testing instructions

1. Move into this branch
2. Collect statics by running: tutor dev exec lms openedx-assets build --env=dev
3. Enable TOC UI by setting: FEATURES["ENABLE_HIDE_FROM_TOC_UI"] = True in your CMS environment, this will allow course staff to configure the hide from toc option from the Studio UI.
4. Given the error explained in the Other information section, please use: CELERY_ALWAYS_EAGER = True in both of your environments (LMS/CMS).
5. Go to a sections' course, click the configuration gear > Visibility > Hide in course outline
6. As an instructor, you should be able to see the hidden section with its children
7. As a student, you should be able to see the hidden subsections/units with the URL from the blocks' View Live option

Screencast.from.15-02-24.15.27.32.mp4

Deadline

This effort is part of the Spanish consortium project, so it'd be ideal to merge this before the end of the project.

Other information

After deploying these changes to a tutor nightly remote installation, we found that the changes weren't reflected on the Course Outline after saving the new visibility changes for the 1st time. Now, the second time we save the changes are triggered. We don't have an explanation for it yet, but we're actively working on it. Here's a video of the behavior:

Screencast.from.19-12-23.12.08.56.mp4

Update: This was solved by #34020, which is already under review.

[openedx-webhooks]

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

[mariajgrimaldi]

Note to reviewer: there are better ways to resolve this warning than this, but this PR is complex enough. So, I'll open a new PR proposing a refactoring change so this quality failure is not raised anymore. I'll attach the PR in this thread when it's ready.

[felipemontoya]

I think this function and the file are already plenty complex. This feature is not making it better. However having a different PR that is a requirement for this I think is the wrong approach.

If you are planning to extract this for in a "private" helper function at the top of the file or something with a similar complexity I suggest to do it already in this PR as a new commit and leave it at that.

[mariajgrimaldi]

Thanks for the suggestion, but I can't entirely agree. I don't think it is a good idea to introduce more changes to this PR, adding more tests and points of failure, so I'd prefer disabling the pylint rule. Maybe we should consider the refactor an enhancement instead of a requirement.

[mariajgrimaldi]

Hi there, @MaferMazu @felipemontoya @BryanttV: could you help me with a review here? Please feel free to add yourselves as reviewers if you have the time. Thanks!

[mariajgrimaldi]

@johnvente, all comments addressed! Could you check again? Thanks!

[MaferMazu]

Thanks for this, @mariajgrimaldi. The functionality works as expected, the code looks good to me, and I think it is sustained well by the proposal and all the discussion before the implementation.

@itsjeyd, don't the proposal and the previous discussion apply as a product review? If this needs a product review, can you help us tag the person who could help us with the product review? Thanks.

[itsjeyd]

@MaferMazu I suppose you're asking because I recently applied the product review label to this PR? :)

That's a permanent label for PRs whose review process includes getting approval from members of one or more product teams. (I.e., we don't remove it after product review is complete). The fact that it hadn't been added to this PR yet it was simply an oversight.

In the context of managing OSPRs, we've been using feature tickets on the platform roadmap to track status of product discussions. The feature ticket for this PR (as well as all other PRs related to Feature Enhancement Proposal: Hide Sections from course outline) is openedx/platform-roadmap#301.

Santiago confirmed product approval for the proposal there last week.

CC @mphilbrick211

[MaferMazu]

Oh, I wasn't aware of that. Thank you for the explanation, @itsjeyd.

[itsjeyd]

@MaferMazu No problem!

For future reference, the Pull Request Status Guide provides info on statuses and labels that you might see on OSPRs.

--

@mphilbrick211 It might make sense to update the definition of the product review label to explicitly mention that it's a permanent label.

Also, we're no longer using the Scheduled for Eng Review status so it would be worth removing it from the list at some point.

CC @sarina

[felipemontoya]

I think this function and the file are already plenty complex. This feature is not making it better. However having a different PR that is a requirement for this I think is the wrong approach.

If you are planning to extract this for in a "private" helper function at the top of the file or something with a similar complexity I suggest to do it already in this PR as a new commit and leave it at that.

[felipemontoya]

I should have added with my review that I tested the code and it works just as the description explains. It is in line with the product definition in confluence so the feature is good to continue. The inline comments are more an engineering review.

[felipemontoya]

Thanks for the fixes @mariajgrimaldi no more comments. I tested this again and all is working as it should.

[openedx-webhooks]

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

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

[edx-pipeline-bot]

2U Release Notice: This PR has been deployed to the edX production environment.