* Update Financial Assistance logic
Use the zendesk proxy app instead of the unsupported zendesk library.
* Move to pre-fetching the group IDs.
Rather than making extra requests to zendesk to list all groups and find
a specific group ID. Just make a pre-filled list of group IDs for the
groups we care about. When a group name is passed in, it is checked
against this list and the ticket is created in the correct group so the
right people can respond to it.
* Remove old performance tests that we haven't been running.
As far as I can tell, these tests to capture HAR files were created 5
years ago and not being run as a part of our suite? They capture HAR
data that we do nothing with so even if they were running we should
remove them until we're ready to care about consuming this kind of
information.
* Update password test unicode string.
* Add ugettext translation helper function.
* Fix lambda syntax that is not valid in python 3.
* Fix ur raw strings which his not valid in python 3
* Use edx_six.get_gettext instead of ugettext.
* Fix a few other encoding issues.
* Don't use old form of sorted funciton.
This form which uses a 'cmp' method is not available in python 3.
Usernames containing unicode characters were
reportedly not showing up correctly in the
registration form when registered with MOE/SAML,
FB and Google.
This change fixes the issue by overriding the
django setting SOCIAL_AUTH_CLEAN_USERNAMES to
disable the default username check that wasn't
allowing non-ascii values.
This type of email is just a transactional message
and should not be crediting revenue to email. Removed
UTM parameters and added ?track=pwreset query param.
PROD-482
Push notifications was only ever setup to connect to Parse.com a service
that has been discontinued. Since we haven't replaced the functionality
for a few years now, remove this dead code.
In cms/templates/js/course_info_update.underscore we're allowing content
to not be escaped because this is by design according to the tests.
Long term there should be a better fix for this but for now this is
intended behavior.
A popular convention is to have user accounts stored in a separate authentication
database. This change add support for configuring edx-platform to work with
such a setup.
The enrollmentStatusHash cookie value was created in commit f0030334
as an optimization, in order to determine whether the marketing site
needs to refresh the list of a student's enrolled courses with a
call to the LMS. To ensure that this value was kept up to date,
commit d7a7bcc1 reset the user's cookies every time they go to the
learner dashboard page (which used to be the next page loaded after
you enrolled in a course). This didn't just reset the
enrollmentStatusHash though -- it recalculated all the cookie
values, as if you had just logged in.
A number of things have changed since then:
1. Enrolling in a course now goes to that course's info/navigation
page, rather than going to the student dashboard.
2. It doesn't appear that the value of enrollmentStatusHash is
actually being examined anywhere -- it's set in a cookie on the
LMS and read/written by the edX marketing front end code, but
the value is never looked at to make any decisions.
3. The introduction of add_email_marketing_cookies (which triggers
off of the CREATE_LOGON_COOKIE signal) has made cookie resets
far more expensive, as there is a blocking call to Sailthru if
you have that enabled in EmailMarketingConfiguration (which
edx.org does). This can add over two seconds to the server
processing time for the student dashboard at certain times of
day.
Given this, I'm removing both the call to resetting the cookie on
the student dashboard page, as well as setting the value for
enrollmentStatusHash.
Currently, enrollment support tool is only allowing support members
to change course enrollment only one of the two modes i.e. audit and
verified.To move a learner other than these modes,they need to ping
devops.To broaden the scope of enrollment support tool,changes have
been done so that enrollment would be changed to other modes as well.
PROD-305
