relied on the old configuration values and old way of validating
passwords. Also improved registration page by always showing error
messages rather than hiding them on leaving the field.
the old validate password method and configuration values in favor of
AUTH_PASSWORD_VALIDATORS, a list of validators to use to check a
password. These include some that come straight from Django and some
that were written according to Django's specifications. This work also
included maintaining the current messaging as instruction text and
passing along restrictions for the password field.
We were doing many individual SQL queries for certificates when
awarding program certs. It's possible this was contributing to
high SQL load. Instead, let's bundle those queries up into a larger
one.
LEARNER-6490
Stop displaying the template in CMS.
This has no effect on already-existing components; it merely prevents
new components from being created with this template.
All functionality has been replaced by the XBlock version [1][2].
Backstory:
This was written by Stanford, circa 2013; it was always a bit of
a hack. While it masquerades as if it were an XBlock/XModule, it's
really a YAML template for the HTML module. It depends on JS/CSS
that is embedded as a first-class citizen of the platform. This has
all caused confusion. Worse, it's a pain to edit/configure/update,
since it uses none of the XBlock infrastructure.
Nearly two years ago, we XBlock-ified the component and have
been running it ever since [1][2]. As such, we no longer support
this "component" and would suggest edX follow suite. Consider this
a request-for-comments on the path forward.
Process:
Deprecation of this module would follow a few steps:
1. Prevent new components from being added in Studio with this template.
- This PR represents step 1.
- This is backward compatible; it will have no effect on
existing components.
2. (optional) Install the XBlock version.
- This allows new ImageModal components to be added, now via the
XBlock.
3. (optional) Identify and convert existing HTML modules to XBlocks [3].
- We have enough of the legacy components in use that we can't
just break support by removing this feature; we need a
conversion process.
- Because these are really just HTML modules with special
contents, we have to query based on file contents (see, I told
you this thing was hacky!):
- All such components must contain an HTML anchor tag with
the class `modal-content`.
- Beyond the query, we don't intend to automate the actual
conversion. Our use of the original component is limited
enough that it's probably not worth converting from one module
type to the other. Exacerbating the situation, because it's
HTML, other changes could have been made to the module that
would prevent automatic parity. As such, we'll work with our
CoureOperations team to convert these manually at Stanford.
4. Remove all references.
- At this point, we can safely remove all supporting static
assets like CSS, JS, etc.
5. Enjoy less technical debt.
[1] https://github.com/Stanford-Online/xblock-image-modal
[2] https://pypi.python.org/pypi/xblock-image-modal/
[3] The one saving grace of the legacy component is that it was designed
to degrade gracefully. Specifically, the HTML itself is just an
image inside a link. The extra platform JavaScript progressively
enhances the display, if the relevant CSS classes are found. As
such, even if you removed all supporting CSS/JS from the platform
tomorrow, existing legacy components would simply render as an image
that links to a larger copy of itself. This is deemed an acceptable
failure mode; graceful degradation FTW!
From edx-drf-extensions:
1. EnsureJWTAuthSettingsMiddleware: Ensures proper JWT auth settings
for endpoints.
2. JwtAuthCookieMiddleware: Combines the JWT auth cookie parts into a
JWT auth cookie.
ARCH-233
