* Reenabling this since the renames on the schedules table are completed
* Reverting regex change that caused migration to be generated for userprofile
We sometimes update preexisting SAML SSO providers to configure them
to automatically create SSO identity verification (IdV) records when a
learner links an account via that provider. Turning that configuration
from off to on does make it such that when learners log back in via
their linked account, a new IdV record will be created for them. But
it's possible we'd want this process to happen more automatically and
seamlessly, for which this management command will be helpful.
Note that this does not help with removing SSO verification records
for a provider for which this configuration has been turned off.
JIRA:EDUCATOR-4947
- ensure logic for displaying reset dealines banner in courseware
is behind the relative dates waffle flag, only shows if the
course is self paced, and handles the situation where no
sequentials exist.
* MICROBA-253 add phone number field api for coaching plugin
* Remove hardcoded value
* Requested changes
* Add logger to models_api.py for student
* Import model with underscore to prevent exporting
* Moved return outside of try/catch block
* Add docstring
* whitespace
If the user is not logged in, the ExperimentWaffleFlag code was
raising an exception when trying to send an event to segment.
This is a quick fix to ignore anonymous users.
This is an unused-as-of-yet utility function to generate a bunch
of ics files for a user's course schedule. Will be used as part
of the calendar_sync feature package.
AA-37
This includes an optimization to the get_bundle_version_files_cached method, which is used very often when loading blockstore data; it was previously being cached only in a process-local cache (lru_cache). My hunch is that in production, with many appservers and LMS workers and frequent deployments and a large number of bundles, the process-local cache is not being hit very often.
I also increased the MAX_BLOCKSTORE_CACHE_DELAY from 60s to 300s; this reduces the frequency with which we check if either (A) an external system modified the blockstore bundle and/or (B) we have a cache invalidation bug somewhere. I am increasing it because that check is more expensive than I thought (calling blockstore API to ascertain latest version of a particular bundle), and I haven't seen any cache invalidation errors that this would help to work around. (Plus, increasing this will make such bugs more obvious.)
