Current State (before this commit):
Studio, as of today doesn't have a way to restrict a user to
create a course in a particular organization. What Studio
provides right now is a CourseCreator permission which gives
an Admin the power to grant a user the permission to create
a course.
For example: If the Admin has given a user Spiderman the
permission to create courses, Spiderman can now create courses
in any organization i.e Marvel as well as DC.
There is no way to restrict Spiderman from creating courses
under DC.
Purpose of this commit:
The changes done here gives Admin the ability to restrict a
user on an Organization level from creating courses via the
Course Creators section of the Studio Django administration
panel.
For example: Now, the Admin can give the user Spiderman the
privilege of creating courses only under Marvel organization.
The moment Spiderman tries to create a course under some
other organization(i.e DC), Studio will show an error message.
This change is available to all Studio instances that
enable the FEATURES['ENABLE_CREATOR_GROUP'] flag.
Regardless of the flag, it will not affect any instances that choose
not to use it.
BB-3622
Currently, if a learner manually loads a sequence page that would
normally be skipped for them because it is hidden-after-due, the
sequence renders anyway.
This commit tells the frontend when it should not show a sequence
because it's hidden.
AA-1000
* Add STUDENT_REGISTRATION_COMPLETED event after the user's registration
* Add SESSION_LOGIN_COMPLETED event after the user's login session
* Add COURSE_ENROLLMENT_CREATED event after the user's enrollment creation
In the PR https://github.com/edx/edx-platform/pull/10659 the outer_atomic decorator/context manager was created to prevent nested atomic blocks. This method received a boolean parameter read_committed to enforce read-committed MySQL isolation level. From Django 2, the default isolation level Django sets is read-committed, so the aforementioned parameter for outer_atomic can be removed
In the case where a server/course has both:
* YouTube deprecated (waffle flag: videos.deprecate_youtube = True)
* HLS enabled (ConfigModel: HLSPlaybackEnabledFlag, in video_config)
Prior to this commit, we would prefer the HLS source if one of the
HTML5 video sources specified a .m3u8 file. However it looks like this
file isn't always guaranteed to be produced.
This fix always prefers HTML5 video sources to YouTube if the server or
course is configured to deprecate YouTube, as long as at least one
non-YouTube source is found. TNL-8594.
Note that this may confuse users because we're essentially bypassing
their Studio-specified preferred primary source with a server-wide
setting.
- Removed manage_user and manage_group commands and their unit tests from edx-platform and added then to edx-django-utils.
- Modified User.post_save signal to ensure the user profile is created when manage_user management command is run to create a user.
- Added edx-django-utils to INSTALLED_APPS for LMS and Studio.
- Moved generate_password from openedx.core.djangoapps.user_authn.utils to edx_django_utils.user along with its unit test.
We add 'courserun_key' (aka "course_id" though that's technically a
misnomer) as an optional parameter to the /event endpoint url. If it
is not present, it will still be parsed out of the url, if the url is
of the right format.
Additionally, Logger.log() in js adds this parameter to its /event
call, pulling it from the $$course_id global.
This provides opportunity for MFEs to (separately) provide the key
without concern about url parsing.
TNL-7752
* MB-1192: [feat] Add course ended, not passing
If a student has not passed a course, the course has ended, and they have a verified seat, we want to show them a message at a glance on the
dashboard.
* refactor: Merge the openedx certs app with lms one
Move the certs API from openedx into the lms certificates app.
Functionally, this is a no-op. Cleanup will happen in a subsequent
commit. This is simply a move.
Beta testers can’t earn course certificates, so they should not see a “Request Certificate” button or other info describing how they can earn a cert.
MICROBA-992
* [feat] Add course over, not passing status to dash
If a student has not passed a course, the course has ended, and they
have a verified seat, we want to show them a message at a glance on the
dashboard.
Does 3 things:
(1) Use django for modulestore tests
(2) Use normal LMS settings for modulestore tests instead of openedx/tests/settings.py
(3) Simplify some TestCase subclasses by converting them to use ModuleStoreTestCase
Details and rationale:
(1) Currently parts of the modulestore test suite are designed to run "without django", although there is still a lot of django functionality imported at times, and many of the tests do in fact use django. But for the upcoming PR #27565 (moving split's course indexes from MongoDB to MySQL), we will need to always have Django enabled. So this commit paves the way for that change.
(2) The previous tests that did use Django used a special settings file, openedx/tests/settings.py which made some debugging confusing because those tests had quite different django settings than other tests. This change deletes that file and runs the tests using the LMS test settings.
(3) The test suite also contains many different ways of initializing and testing a modulestore, with significant differences in their configuration, and also a lot of repetition. I find this makes understanding, debugging and writing tests more difficult. So this commit also reduces the number of different "test case using modulestore" base classes:
* Simplifies MixedWithOptionsTestCase and MixedSplitTestCase by making them simple subclasses of ModuleStoreTestCase.
* Removes PureModulestoreTestCase.
Some actions in split modulestore record the user ID who requested the action. Currently, split modulestore doesn't care what data type you use for those user IDs. Most of the codebase uses integers, but some tests used username or email address strings.
My upcoming PR #27565 will move split modulestore's "course index" data from MongoDB into MySQL. In doing so, it requires that user IDs are always numeric. So this PR paves the way for that one by using numeric IDs consistently in all test cases. I believe the actual non-test code was already consistently using integer IDs.
