MST-861. The Django admin page for IntegritySignature only displays
the user and course_key for a signature. This adds the created and modified
fields, and will order signatures by the modified field.
Code in ./common/lib/xmodule/xmodule should
be imported as `from xmodule`, since `xmodule`
is a locally-installed package.
This is weird, but as long as it is the case,
we should be consistent.
(In BOM-2584, I propose moving the files to
./xmodule, which would quell this confusion.)
* build: Removed the diff-quality step
Applied lint-amnesty on all the warnings
Removed pylint thresholds comparison code and related tests
Co-authored-by: Usama Sadiq <usama.sadiq@arbisoft.com>
In order to upgrade to Django > 2.2.20, we can't continue to use
absolute paths in the block_structure's data FileField. This used to
work for S3, but it will not work going forward due to a security fix
in Django 2.2.21.
This data migration will remove the starting '/' from any paths in the
block_structure table. The resulting locations in S3 should be
unaffected.
The edx-platform codebase already includes quite a few type annotations, but
they were not regularly checked. This may cause problems, when the annotations
themselves include errors (as we found out in some of the learning_sequences
annotations). So here, we add mypy as a dev requirement and introduce a make
command to run mypy regularly. Mypy runs on a very small portion of the total
edx-platform, as configured in mypy.ini. Our hope is that developers will add
more and more modules to this configuration file, until we can eventually run
mypy on the full code base.
See discussion: https://discuss.openedx.org/t/dev-notes-running-mypy-on-edx-platform/4860
[refactor] change backfill date task to long running task
Change from a task that spins off multiple other tasks to a single long
running task. This will hopefully be way less heavy when this is ran in
production.
* [refactor] Move backfill_date_for_all_course_runs to Tasks.py
In order for celery to register this task, it needs to be in the right
file. duh!
* fix imports
* fix more imports
* [feat] Management command to populate credentials availability date
This is a command to populate the new CredentialsCertificate model's
available_date for every existing course_run.
If all generated usernames using an integer range are already consumed by existing
users, the loop stuck in an infinite loop. Fixed by using a for loop instead of
while with an upper limit.
This commit refactors the way the Account MFE is activated in the
platform. The main objective is to control the global
activation/deactivation of the MFE through the
account.redirect_to_microfrontend waffle flag and use the Site
Configurations to control MFE activation/deactivation with per-site
granularity. Notice that the Site Configuration object will have
precedence over the waffle flag value.
Since the classic Account Django view will be most likely supported
during Lilac, the expiration of this temporary waffle flag was
extended till the end of 2021
With this commit:
- There's no need to create a Site Configuration object to get the MFE
activated. Setting the waffle flag to True is enough.
- It helps multisite installations to better handling granular
per-site activation/deactivation.
BREAKING CHANGE:
For operators of multisite installations, the activation of the waffle
flag will now activate the MFE for all sites, unless explicitly
disabled on a per-site basis.
Otherwise, this is a backwards-compatible change, since the MFE will
remain activated for installations where this is already enabled.
* [feat] calling course certificates api from LMS
Now that CourseCertificates in credentials have a field for the
available_date, we need to make sure we are always updating that field
when it changes in studio. This PR adds a call to a new Credentials API
that will update the field each time the date change signal fires.
We squashed migrations in the student djangoapp a while back.
This is the followup work to remove the migrations that were
squashed and to convert the squashed migration into a 'normal'
migration.
ARCHBOM-1177
This change causes the activation link that’s emailed to a newly-registered user
to utilize a next query parameter. The impetus for this change is an edX Enterprise use-case:
we'd like newly registered Enterprise Customer admins and learners
to be directed to the Enterprise Learner Portal (or Admin Portal) upon account activation.
This is likely a broad enough use case to be valuable in other endeavors.
