Skip to content
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

feat: Add support for showing and hiding parts of the progress page #36

Open
wants to merge 5 commits into
base: opencraft-release/palm.1
Choose a base branch
from

Conversation

xitij2000
Copy link
Member

@xitij2000 xitij2000 commented Oct 8, 2024

This PR adds support for hiding or showing components on the progress page based on configuration stored in other_course_settings.

These settings can be toggled with: open-craft/frontend-app-authoring#71

Private-ref: BB-9200

Copy link
Member

@Agrendalath Agrendalath left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@xitij2000, please see the following recording. We cannot have this kind of delay when hiding the elements on the page:
Screencast_20241008_182416.webm

I just noticed that there is already a model with a per-course Progress page configuration that's used by the Course Home API. If we would need to add artificial delays to rendering the interface until the Course Blocks API gives us the response, maybe extending this configuration would actually be better?

Also, a note about the Pages & Resources - the options should either:

  1. Default to True.
  2. Be "Hide the component" instead of "Show the component".

Otherwise, visiting the "Configure progress" modal and pressing "Save" changes the Progress page configuration, which is confusing.

@xitij2000
Copy link
Member Author

@Agrendalath Sure, I think it makes sense to hide by default. I did intend in the code to default an undefined value to true, but I guess that didn't work? The logic should be to hide till the value is known, but have an undefined value equate to true so that if this isn't configured, then the component is shown by default.

The issue isn't with extending that configuration, it's with extending it in a way that is upstream-friendly. Making a change to an existing model is asking for trouble during upgrades when we need to cherrypick migrations etc.

If upstream is okay with having this feature, then we can move this to the man course structure and return it with the existing API.

@Agrendalath
Copy link
Member

@xitij2000,

Sure, I think it makes sense to hide by default. I did intend in the code to default an undefined value to true, but I guess that didn't work? The logic should be to hide till the value is known, but have an undefined value equate to true so that if this isn't configured, then the component is shown by default.

What are the next steps here?

The issue isn't with extending that configuration, it's with extending it in a way that is upstream-friendly. Making a change to an existing model is asking for trouble during upgrades when we need to cherrypick migrations etc.

If needed, we can backport this change only for this client and handle it during the upgrade. It won't be upstream-unfriendly this way.

@xitij2000
Copy link
Member Author

@Agrendalath

What are the next steps here?

I've hopefully already fixed this issue in the latest commit.

The issue isn't with extending that configuration, it's with extending it in a way that is upstream-friendly. Making a change to an existing model is asking for trouble during upgrades when we need to cherrypick migrations etc.

If needed, we can backport this change only for this client and handle it during the upgrade. It won't be upstream-unfriendly this way.

I think I miswrote. It maybe is upstream friendly, but it isn't upgrade-friendly. Maintaining diverging migration histories is not a good idea, I feel.

Also, that config is derived from StackedConfigurationModel which will make it unnecessarily complex. The StackedConfigurationModel allows overriding values on a global, site, org or course, or course run level, so you could have a page disabled globally, enabled for the site, disabled for the org, then enabled again for the course, and disabled again for the course run, and it will follow that hierarchy and give you the closest matching status. That level of complexity isn't needed here and won't be supported by the GUI. Stacked configs are generally only applied via the django admin and not interacted with by APIs. So I don't see this ever being upstream-friendly, which means it's likely to be a permanent drift, or an expensive rollback and change later.

It would be better to add a separate model for this if needed, but in that case, it won't be part of course reruns or import-export, which might be OK.

Copy link
Member

@Agrendalath Agrendalath left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@xitij2000, the problem with disappearing elements is resolved, but there are some more issues:

  1. There is no way to hide the "Course completion" section.
  2. When the grades are hidden, an empty .grades.raised-card node is still visible.
  3. The CertificateStatus option is not implemented in this PR. The [data-testid=certificate-status-component] node is always visible.
  4. The second part of this comment is still not addressed.

@xitij2000
Copy link
Member Author

@xitij2000, the problem with disappearing elements is resolved, but there are some more issues:

1. There is no way to hide the "Course completion" section.

This is a feature that already existed for the progress page, it's called "Enable progress graph"

2. When the grades are hidden, an empty `.grades.raised-card` node is still visible.

I've changed it, so the entire component is hidden now.

3. The `CertificateStatus` option is not implemented in [this PR](https://github.com/open-craft/frontend-app-authoring/pull/71). The `[data-testid=certificate-status-component]` node is always visible.

I seems that got dropped during some rebase, I've added it back.

4. The second part of [this comment](https://github.com/open-craft/frontend-app-learning/pull/36#pullrequestreview-2355013586) is still not addressed.

Fixed as well.

Copy link
Member

@Agrendalath Agrendalath left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@xitij2000, after the most recent change, the "Show grades" toggle does not do anything. The "Show Grade Breakdown" toggle hides the entire .grades.rounded node.

This is a feature that already existed for the progress page, it's called "Enable progress graph"

I see. I cherry-picked openedx#1194 into your branch,so that we can use it in Palm. I also opened open-craft/edx-platform#698 to backport the backend changes.

@xitij2000
Copy link
Member Author

@Agrendalath Not sure why the show grades toggle is doing nothing. I think I'll fix up my palm devstack since right now I'm not able to test this myself.

@xitij2000
Copy link
Member Author

xitij2000 commented Oct 18, 2024

@Agrendalath Not sure why the show grades toggle is doing nothing. I think I'll fix up my palm devstack since right now I'm not able to test this myself.

I fixed up my palm devstack and the show grades toggle is working fine for me? It shows and hides the "Grades" widget. Could check again? Are you using tutor or is this a different setup?

@Agrendalath
Copy link
Member

@xitij2000, ah, sorry. I forgot we're hiding this section with the branding package. Everything's good here. Please add the description to the PR and link the related PRs and tickets so that we can easily navigate between all related work.

@xitij2000
Copy link
Member Author

@Agrendalath Done!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants