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

Add the default enrollment start date on course creation #30954

Merged

Conversation

dyudyunov
Copy link
Contributor

@dyudyunov dyudyunov commented Sep 7, 2022

Problem

Course is visible in the main page right after creation. So anonymous users can see them and access course about page for the courses without valid data (e.g. they will see default course overview)

Root cause

When courses list filtering processed it checks the see_exists permission for the anonymous user.
Actually, see_exists means can_load OR can_enroll.

can_load is False in our case because course start is in the future.

But can_enroll returns True because course's enrollment_start and enrollment_end dates are blank:

enrollment_start = courselike.enrollment_start or datetime.min.replace(tzinfo=UTC)
enrollment_end = courselike.enrollment_end or datetime.max.replace(tzinfo=UTC)
if enrollment_start < now < enrollment_end:
    debug("Allow: in enrollment period")
    return ACCESS_GRANTED

Fix

Set the enrollment_start the same as a course start by default

Known Issues:

Notes

  • this fix will work for the course catalog page when the course discovery is disabled (FEATURES['ENABLE_COURSE_DISCOVERY'] = False)
  • I wonder why DEFAULT_START_DATE is hardcoded (1 Jan 2030)? How and when is it updated?
  • The proposed behavior is togglable and is disabled by default. To enable it - update your settings.FEATURES for cms:
    FEATURES['CREATE_COURSE_WITH_DEFAULT_ENROLLMENT_START_DATE'] = True

@openedx-webhooks openedx-webhooks added the open-source-contribution PR author is not from Axim or 2U label Sep 7, 2022
@openedx-webhooks
Copy link

openedx-webhooks commented Sep 7, 2022

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

@dyudyunov dyudyunov force-pushed the fix-main-page-course-visibility branch 9 times, most recently from 7faad23 to 00a98c0 Compare September 7, 2022 12:45
@dyudyunov
Copy link
Contributor Author

@natabene this one is ready for the review

@nedbat
Copy link
Contributor

nedbat commented Oct 31, 2022

📣 💥 Heads-up: You must either rebase onto master or merge master into your branch to keep passing required checks.

We added a new required check, "Tests Successful," that this PR does not yet run. Rebasing will get it started.

If you have any questions, please reach out to the Architecture team (either #architecture on Open edX Slack or #external-architecture on edX internal Slack).

@dyudyunov dyudyunov force-pushed the fix-main-page-course-visibility branch from 00a98c0 to f3149f5 Compare November 2, 2022 12:30
@dyudyunov
Copy link
Contributor Author

@nedbat rebase is done

@mariajgrimaldi
Copy link
Member

I can take this one :)

@mariajgrimaldi mariajgrimaldi self-assigned this Nov 17, 2022
@mphilbrick211
Copy link

Hi @dyudyunov! Your CLA check looks stuck - would you mind rebasing to see if that helps it go through?

Also, friendly ping @mariajgrimaldi for review :)

Copy link
Member

@mariajgrimaldi mariajgrimaldi left a comment

Choose a reason for hiding this comment

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

This looks pretty good! I just left a question.

Also, I had the same question regarding the DEFAULT_START_DATE constant, and maybe this is the reason. I was going to suggest changing it, but maybe that should be part of another effort.

xmodule/tests/test_course_module.py Outdated Show resolved Hide resolved
@mariajgrimaldi
Copy link
Member

@mphilbrick211: thanks for the reminder :)

@mphilbrick211 mphilbrick211 added the waiting on author PR author needs to resolve review requests, answer questions, fix tests, etc. label Dec 16, 2022
@mariajgrimaldi
Copy link
Member

I tested before and after this PR:

Before
course-schedule-before-pr-30954

After
course-schedule-after-pr-30954

The course was still visible when accessing the main listing page, but the enrollment was closed for an anonymous user. I first thought the course would be removed from the main page listing. Is this the behavior you expected? If yes, we should change the PR name since it suggests we're fixing the main page listing instead of the enrollment for brand-new courses.

@dyudyunov
Copy link
Contributor Author

dyudyunov commented Dec 19, 2022

@mariajgrimaldi no, it's not the expected behaviour

Please, confirm that:

  • your COURSE_CATALOG_VISIBILITY_PERMISSION setting is set to see_exist (the default one)
  • you have cleared the cache after your change in course dates or removed the @cache_if_anonymous() decorator for the view

@dyudyunov dyudyunov force-pushed the fix-main-page-course-visibility branch from f3149f5 to d659f87 Compare December 19, 2022 13:11
@openedx-webhooks openedx-webhooks removed the waiting on author PR author needs to resolve review requests, answer questions, fix tests, etc. label Dec 19, 2022
@dyudyunov dyudyunov force-pushed the fix-main-page-course-visibility branch from d659f87 to b4b1977 Compare December 19, 2022 13:28
@mariajgrimaldi
Copy link
Member

@dyudyunov: it's not working for me, the course is still visible in the course listing. I'll be researching what's wrong with my setup.

@mariajgrimaldi
Copy link
Member

I'll review this during the week! Thanks

@mariajgrimaldi mariajgrimaldi self-requested a review July 24, 2023 15:25
@mariajgrimaldi
Copy link
Member

Sorry - it's been crazy lately. This is on my review queue! Thanks for your patience.

@dyudyunov
Copy link
Contributor Author

It would be great to create a backport PR to Palm. I'm going to do so as soon as this one will be accepted

Copy link
Member

@mariajgrimaldi mariajgrimaldi left a comment

Choose a reason for hiding this comment

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

Thanks again for the contribution, @dyudyunov! I tested this again by ensuring the default enrollment start date was used as default if the flag was turned on.

I'll post a message in the edx-platform CC slack channel so people know about this change! See you there.

Copy link
Contributor

@robrap robrap left a comment

Choose a reason for hiding this comment

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

Just added some comments about the toggle. Thank you.

# .. toggle_implementation: SettingDictToggle
# .. toggle_default: False
# .. toggle_description: When enabled the newly created courses will have the enrollment_start_date
# set to DEFAULT_START_DATE.
Copy link
Contributor

Choose a reason for hiding this comment

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

Could you add something like: "The default behavior, when this is disabled, is ...".

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Done, please check

# set to DEFAULT_START_DATE.
# .. toggle_use_cases: open_edx
# .. toggle_creation_date: 2023-06-22
# .. toggle_target_removal_date: None
Copy link
Contributor

Choose a reason for hiding this comment

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

You should drop this annotation altogether.

Suggested change
# .. toggle_target_removal_date: None

In the future, another annotation will make it clear that this is a permanent toggle, but for now, you could something like: "This is intended to be a permanent option."

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Replaced with the proposed description

@@ -57,6 +58,17 @@
COURSE_VIDEO_SHARING_PER_VIDEO = 'per-video'
COURSE_VIDEO_SHARING_ALL_VIDEOS = 'all-on'
COURSE_VIDEO_SHARING_NONE = 'all-off'
# .. toggle_name: FEATURES['CREATE_COURSE_WITH_DEFAULT_ENROLLMENT_START_DATE']
Copy link
Contributor

Choose a reason for hiding this comment

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

No change is being requested in this comment.

[inform] There has been an unofficial move away from using the FEATURES dict. We should probably have a DEPR to at least discuss it.
FYI: @feanil

Copy link
Contributor

Choose a reason for hiding this comment

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

[inform] I created #33026 to discuss this topic. Again, no request for change.

@dyudyunov dyudyunov force-pushed the fix-main-page-course-visibility branch from f15f6e2 to 4eb68c7 Compare August 16, 2023 07:11
Copy link
Contributor

@robrap robrap left a comment

Choose a reason for hiding this comment

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

Thanks @dyudyunov. I added some comments about the toggle annotations. Hopefully they are clear. Please don't be blocked on any re-review by me unless you wish to. I am not adding an approval simply because I didn't review anything other than this annotation. Thanks for your updates.

Comment on lines 64 to 66
# .. toggle_description: The default behavior, when this is disabled, is that newly created course has no
# enrollment_start date set. When the feature is enabled - the newly created courses will have the
# enrollment_start_date set to DEFAULT_START_DATE.
Copy link
Contributor

Choose a reason for hiding this comment

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

  1. I fixed a typo and moved the the sentence about it being a permanent option to the description.
Suggested change
# .. toggle_description: The default behavior, when this is disabled, is that newly created course has no
# enrollment_start date set. When the feature is enabled - the newly created courses will have the
# enrollment_start_date set to DEFAULT_START_DATE.
# .. toggle_description: The default behavior, when this is disabled, is that a newly created course has no
# enrollment_start date set. When the feature is enabled - the newly created courses will have the
# enrollment_start_date set to DEFAULT_START_DATE. This is intended to be a permanent option.
  1. My understanding is that this toggle was added because some orgs (2U) did not want this toggled on. I do not know much about this, and if I were an operator, I would wonder why I should choose one option over the option:
    i. What is the consequence of having no start date set? Without knowing anything, that seems like it would be bad, but somehow it works for 2U. Why?
    ii. I think I read that DEFAULT_START_DATE is intended to be a date in the distant future so courses will not appear. Is that accurate, or only if you are using this toggle? Is the default used for other things? Maybe you could speak to that a bit more here?

Please update my first point, because it is simple. Regarding my second point, I am not the owner of this particular area of the code, so this is just a suggestion. You can decide how much you update the toggle docs, but I personally would rather longer docs that help me understand more completely what it is really for. That said, if you think most operators would know all of these things, maybe you've provided enough.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Thanks for the detailed review

What is the consequence of having no start date set?

The toggle has no effect on the start date but only on the enrollment start date, but I've got your point, I'll think about how to describe the toggle behavior with more details

I think I read that DEFAULT_START_DATE is intended to be a date in the distant future so courses will not appear. Is that accurate, or only if you are using this toggle? Is the default used for other things? Maybe you could speak to that a bit more here?

I just reused the DEFAULT_START_DATE constant. It was originally used only as a default value for the course start date and no changes were made there

# enrollment_start_date set to DEFAULT_START_DATE.
# .. toggle_use_cases: open_edx
# .. toggle_creation_date: 2023-06-22
# .. toggle_target_removal_date: This is intended to be a permanent option.
Copy link
Contributor

Choose a reason for hiding this comment

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

Apologies that I wasn't clear. This annotation should not be used for permanent options. The sentence I added in the description is to help make the permanence of this toggle more explicit.

Suggested change
# .. toggle_target_removal_date: This is intended to be a permanent option.

In the future, openedx/edx-toggles#284 proposes atoggle_permanent_justification annotation, that would make this explicit.

The course is visible on the main page right after creation.

So anonymous users can see them and access the course about page
for the courses without valid data (e.g. they will see the default
course overview)

When courses list filtering is processed it checks the `see_exists`
permission for the anonymous user.
Actually, `see_exists` means `can_load` OR `can_enroll`.

`can_load` is False in our case because the course start in the future.

But `can_enroll` returns True because the course's enrollment_start
and enrollment_end dates are blank:
```
enrollment_start = courselike.enrollment_start or datetime.min.replace(tzinfo=UTC)
enrollment_end = courselike.enrollment_end or datetime.max.replace(tzinfo=UTC)
if enrollment_start < now < enrollment_end:
    debug("Allow: in enrollment period")
    return ACCESS_GRANTED
```

Set the enrollment_start the same as a course start by default

- this fix will work for the course catalog page when the course
discovery is disabled (FEATURES['ENABLE_COURSE_DISCOVERY'] = False)
- I wonder why DEFAULT_START_DATE is hardcoded (1 Jan 2030)?
How and when is it updated?
@dyudyunov dyudyunov force-pushed the fix-main-page-course-visibility branch from 45da7b9 to a581223 Compare August 16, 2023 14:45
@dyudyunov
Copy link
Contributor Author

@mariajgrimaldi hi 👋

Is there something else blocking us from merging?)

@mariajgrimaldi
Copy link
Member

I'll be merging this now!

@mariajgrimaldi mariajgrimaldi merged commit 4340a83 into openedx:master Aug 22, 2023
42 checks passed
@openedx-webhooks
Copy link

@dyudyunov 🎉 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
Copy link
Contributor

2U Release Notice: This PR has been deployed to the edX staging environment in preparation for a release to production.

@edx-pipeline-bot
Copy link
Contributor

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

mehedikhan72 pushed a commit to mehedikhan72/edx-platform that referenced this pull request Aug 24, 2023
* fix: main page course listing

The course is visible on the main page right after creation when the feature toggle `CREATE_COURSE_WITH_DEFAULT_ENROLLMENT_START_DATE` is on.

So anonymous users can see them and access the course about page
for the courses without valid data (e.g. they will see the default
course overview)

When courses list filtering is processed it checks the `see_exists`
permission for the anonymous user.
Actually, `see_exists` means `can_load` OR `can_enroll`.

`can_load` is False in our case because the course start in the future.

But `can_enroll` returns True because the course's enrollment_start
and enrollment_end dates are blank:
```
enrollment_start = courselike.enrollment_start or datetime.min.replace(tzinfo=UTC)
enrollment_end = courselike.enrollment_end or datetime.max.replace(tzinfo=UTC)
if enrollment_start < now < enrollment_end:
    debug("Allow: in enrollment period")
    return ACCESS_GRANTED
```

Set the enrollment_start the same as a course start by default
@mariajgrimaldi
Copy link
Member

@dyudyunov: let us know when you have the backport PR ready :)

dyudyunov added a commit to raccoongang/edx-platform that referenced this pull request Sep 1, 2023
This is a backport from the master branch:
openedx#30954

The course is visible on the main page right after creation.

So anonymous users can see them and access the course about page
for the courses without valid data (e.g. they will see the default
course overview)

When courses list filtering is processed it checks the `see_exists`
permission for the anonymous user.
Actually, `see_exists` means `can_load` OR `can_enroll`.

`can_load` is False in our case because the course start in the future.

But `can_enroll` returns True because the course's enrollment_start
and enrollment_end dates are blank:
```
enrollment_start = courselike.enrollment_start or datetime.min.replace(tzinfo=UTC)
enrollment_end = courselike.enrollment_end or datetime.max.replace(tzinfo=UTC)
if enrollment_start < now < enrollment_end:
    debug("Allow: in enrollment period")
    return ACCESS_GRANTED
```

Set the enrollment_start the same as a course start by default
if the CREATE_COURSE_WITH_DEFAULT_ENROLLMENT_START_DATE
feature toggle is enabled (default is False).
mariajgrimaldi pushed a commit that referenced this pull request Sep 5, 2023
This is a backport from the master branch:
#30954

The course is visible on the main page right after creation.

So anonymous users can see them and access the course about page
for the courses without valid data (e.g. they will see the default
course overview)

When courses list filtering is processed it checks the `see_exists`
permission for the anonymous user.
Actually, `see_exists` means `can_load` OR `can_enroll`.

`can_load` is False in our case because the course start in the future.

But `can_enroll` returns True because the course's enrollment_start
and enrollment_end dates are blank:
```
enrollment_start = courselike.enrollment_start or datetime.min.replace(tzinfo=UTC)
enrollment_end = courselike.enrollment_end or datetime.max.replace(tzinfo=UTC)
if enrollment_start < now < enrollment_end:
    debug("Allow: in enrollment period")
    return ACCESS_GRANTED
```

Set the enrollment_start the same as a course start by default
if the CREATE_COURSE_WITH_DEFAULT_ENROLLMENT_START_DATE
feature toggle is enabled (default is False).
shURenZHOUluxun pushed a commit to EduTrigger/edx-platform that referenced this pull request Jan 3, 2024
…dx#33150)

This is a backport from the master branch:
openedx#30954

The course is visible on the main page right after creation.

So anonymous users can see them and access the course about page
for the courses without valid data (e.g. they will see the default
course overview)

When courses list filtering is processed it checks the `see_exists`
permission for the anonymous user.
Actually, `see_exists` means `can_load` OR `can_enroll`.

`can_load` is False in our case because the course start in the future.

But `can_enroll` returns True because the course's enrollment_start
and enrollment_end dates are blank:
```
enrollment_start = courselike.enrollment_start or datetime.min.replace(tzinfo=UTC)
enrollment_end = courselike.enrollment_end or datetime.max.replace(tzinfo=UTC)
if enrollment_start < now < enrollment_end:
    debug("Allow: in enrollment period")
    return ACCESS_GRANTED
```

Set the enrollment_start the same as a course start by default
if the CREATE_COURSE_WITH_DEFAULT_ENROLLMENT_START_DATE
feature toggle is enabled (default is False).
bra-i-am pushed a commit to eduNEXT/edunext-platform that referenced this pull request Apr 16, 2024
This is a backport from the master branch:
openedx/edx-platform#30954

The course is visible on the main page right after creation.

So anonymous users can see them and access the course about page
for the courses without valid data (e.g. they will see the default
course overview)

When courses list filtering is processed it checks the `see_exists`
permission for the anonymous user.
Actually, `see_exists` means `can_load` OR `can_enroll`.

`can_load` is False in our case because the course start in the future.

But `can_enroll` returns True because the course's enrollment_start
and enrollment_end dates are blank:
```
enrollment_start = courselike.enrollment_start or datetime.min.replace(tzinfo=UTC)
enrollment_end = courselike.enrollment_end or datetime.max.replace(tzinfo=UTC)
if enrollment_start < now < enrollment_end:
    debug("Allow: in enrollment period")
    return ACCESS_GRANTED
```

Set the enrollment_start the same as a course start by default
if the CREATE_COURSE_WITH_DEFAULT_ENROLLMENT_START_DATE
feature toggle is enabled (default is False).
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
open-source-contribution PR author is not from Axim or 2U product review PR requires product review before merging
Projects
Archived in project
Development

Successfully merging this pull request may close these issues.

9 participants