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: Make courseware URLs more human-readable #28174

Closed
wants to merge 63 commits into from

Conversation

KristinAoki
Copy link
Member

@KristinAoki KristinAoki commented Jul 13, 2021

Description

Describe what this pull request changes, and why. Include implications for people using this change.
Design decisions and their rationales should be documented in the repo (docstring / ADR), per
OEP-19, and can be
linked here.

This change impacts the Learner.

Before:

After:

Supporting information

Jira issue: TNL-8511

Testing instructions

  • Navigate to the home page of a course.
  • Click on the "Start Course"/"Resume Course" button.
  • The page will fully load.
  • The URL in the address bar should follow this pattern:
  • Navigate back to the home page.
  • Click on a specific section from the outline.
  • The page will fully load.
  • The URL should match the same formatting as above.
  • In the unit view, click on the bookmark button.
  • The bookmark saves.
  • Navigate back to the home page.
  • Click on the bookmark page.
  • All bookmarks are seen, even the one just added.
  • Navigate back to the previous unit.
  • Click on the bookmark button.
  • The bookmark is removed.
  • Go back to the bookmark page.
  • The removed bookmark is no longer listed.

Deadline

August 11, 2021: Must be completed before the end of the internship

Other information

This change is dependent on Frontend-App-Learning PR-540

@KristinAoki KristinAoki changed the title Update current feat: Make courseware URLs more human-readable Jul 26, 2021
@KristinAoki KristinAoki marked this pull request as draft July 30, 2021 17:57
@kdmccormick
Copy link
Member

@KristinAoki I played around with this change on my devstack, and I'm psyched to see the short URLs working! 🔥 Your progress here is great, but I want to adjust your direction a bit so that it'll be easier for us to merge and enable this confidently.

I notice that in several places, your PR swaps out unit/sequences usage keys with their hashes, in-place. For instance, it modifies the path_to_location function to return hashes for units and sequences when ENABLE_SHORT_MFE_URL is toggled on, but return normal old usage keys otherwise. Since your PR modifies Python APIs and REST APIs that are used in several different places and which are built to expect usage keys, I fear that enabling this feature could break other existing features.

To get a feel for the impact of your current changes, you might temporarily ENABLE_SHORT_MFE_URL to True and see what tests fail. My guess it that it might break lot of code--many of those failures would be false-positives, but I believe at least some of them would represent code that actually fails because a hash is returned instead of a usage key.

Given that, my advice is actually to build the backend of this feature so that it doesn't actually check the value of feature flag, other than to pass the value of the flag to the frontend. In other words, see if you can make the flag frontend-only (although it's fine to keep it defined in common.py, just in case I'm wrong and you do need to check the value on the backend).

Why? Because I believe that you can pass the new data you need to the frontend (that is: (1) block's hash and (2) whether the feature is enabled) by only adding fields to existing APIs responses, instead of modifying fields that are already in use. So, if an API has a block_id field in its response or expects a block_id in the URL, don't change either of those aspects; just add a new hash field. If you're able to do this, then you shouldn't need to look at the feature flag on the backend, because the new hash data won't be disruptive.

The upsides of this approach would be:

  • You know that the unit tests are in fact testing the full surface area of your backend changes, since the new code paths aren't behind a feature flag.
  • You would be able to merge this without first merging the frontend changes (remember - your PRs cannot be released at the same time. The way we release code, one will always go out before the other, and you can't count on the time difference between release to be small)
  • Toggling the feature flag on will be less risky, since we know it's only really impacting the frontend.
  • Your change should touch fewer parts of edx-platform and will likely have a smaller linecount. These things will make it easier for your reviewers to understand your changes and feel confident that they're correct.

I hope that makes sense! Let me know if it doesn't, or if you think I'm missing a critical piece here.

Comment on lines +2456 to +2466
############# Shorten MFE URL ##########################
# .. toggle_name: enable_short_mfe_url
# .. toggle_implementation: DjangoSetting
# .. toggle_default: False
# .. toggle_description: Flag would be used to hash block_ids and shorten the MFE url
# .. toggle_use_cases: temporary
# .. toggle_tickets: https://github.com/edx/edx-platform/pull/28174/
# .. toggle_creation_date: 2021-08-03
# .. toggle_target_removal_date: 2022-01-01
ENABLE_SHORT_MFE_URL = False

Copy link
Member

Choose a reason for hiding this comment

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

do we still need the CMS setting, or can we drop this?

Copy link
Member Author

Choose a reason for hiding this comment

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

I am not sure, when I didn't have it before some of the cms tests failed, but that was also before I refactored the code.

common/lib/xmodule/xmodule/modulestore/search.py Outdated Show resolved Hide resolved
Comment on lines 243 to 257

if 'blocks' in response.data:
blocks = response.data['blocks']
else:
blocks = response.data

for block in blocks:
current_block = block
if isinstance(blocks, dict):
current_block = blocks[block]
if 'children' in current_block:
new_child_ids = [get_usage_key_hash(child) for child in current_block['children']]
current_block['hash_children'] = new_child_ids
current_block['hash_key'] = get_usage_key_hash(current_block['id'])

Copy link
Member

Choose a reason for hiding this comment

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

does the frontend code still need the course_blocks API response to be modified to contain the hash_key, or are the changes to the sequence metadata API sufficient?

Copy link
Member Author

Choose a reason for hiding this comment

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

It needs it for when it is calls normalizeBlocks in api.js

@@ -3,6 +3,7 @@
"""

from django.utils.translation import ngettext
from django.conf import settings
Copy link
Member

Choose a reason for hiding this comment

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

Am I correct that you're adding the hash_key to the URLs here so that the course outline can use them in their links?

If so, you might want to leave those links unchanged for now, and leave the course_home_api as-is. The old links should be fine to stay on the outline page for now, as they'll redirect to the new ones.

Copy link
Member Author

Choose a reason for hiding this comment

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

I think that is why I am adding them. Not 100%.

@@ -522,8 +536,18 @@ def get(self, request, usage_key_string, *args, **kwargs): # lint-amnesty, pyli
"""
Return response to a GET request.
"""
if settings.ENABLE_SHORT_MFE_URL:
Copy link
Member

Choose a reason for hiding this comment

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

You should be able to revert the changes to this file and rebase upon my PR

@@ -125,6 +125,15 @@ class CourseLearningSequenceData:
learning sequences in Courses vs. Pathways vs. Libraries. Such an object
would likely not have `visibility` as that holds course-specific concepts.
"""

Copy link
Member

Choose a reason for hiding this comment

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

The changes to this file can be replaced with the model persistence in my PR

@edx-status-bot
Copy link

Your PR has finished running tests. There were no failures.

@feanil
Copy link
Contributor

feanil commented Jun 5, 2024

Closing since it looks like this stalled 3 years ago. Please re-open if it's still relevant.

@feanil feanil closed this Jun 5, 2024
@feanil feanil deleted the KristinAoki/TNL-8511 branch June 5, 2024 12:53
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.

4 participants