The course_visiblity field can have one of three values:
1. private (default): This keeps the standard access rules.
2. public_outline: Allows unenrolled and anonymous users access to the outline.
3. public: Allows unenrolled and anonymous users access to both outline and
course content.
When an unenrolled user accesses course content, instead of student_view(),
public_view() is used. A default implementation is provided for XBlocks
which do not implement this view. The public_view() must not have any
functionality which assumes the presence of a valid User and should show
a readonly only interface for the XBlock content.
Content Type Gating: Xblocks that have a graded component cannot be
accessed by audit track users.
- Caveats:
- In studio, instructors can set certain xblocks to be available to
all users, but graded components will default to not being
available for audit users
- If a course does not have a verified mode option, all users will
have access to graded content.
The Waffle Flag: The waffle flag is of for now.
It's name is: ```content_type_gating.debug```
This Commit Does NOT Include: Displaying for a user WHY they do not have
access to a specific piece of content. That change will be part of
another PR.
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!
- New exported courses include course run information in:
- `url_name` of root course node
- file name of root node in course folder
- root key name in policy.json
- directory name inside policies folder
- when imported via management command, the OLX will overwrite an
available existing course with the same course key (i.e. same org,
course number and course run)
- if there is no matching course, one will be created
- when imported via the studio web ui (or import API), the OLX will
replace the current course (no change in behavior)
- courses exported with this commit have been tested to import via
management command and studio web UI in hawthorn and ginkgo releases.
They should also work in prior releases, but have not been tested.
