- Adds `blockType` and `is_modified` to the `showXBlockLibraryChangesPreview` iframe message.
- Add title to the `xblock_iframe`
- Add `is-modified` to `studio_xblock_wrapper`
- Add `disable_staff_debug_info` as a query param in `render_xblock`
- `downstream_is_modified` added to ComponentLink and ContainerLink
Block structures are meant to be an optimization for the LMS, meaning
that they should always be collecting from the published branch of
modulestore. This is what happens by default when it's run from the LMS
celery process, but this code is sometimes invoked from a Studio worker
(e.g. development mode celery, running in immediate in-proc mode).
---------
Co-authored-by: Peter Pinch <pdpinch@mit.edu>
Rationale: The instructor may create short labels that are longer than
3 characters, and they can be hard to work with in the mobile UI. Thus,
on mobile, it was decided to add short labels to the api response by
getting them from section breakdown, which ensures they are consistent
with the labels the user sees in the Grading section.
This was added in a newer version of django-webpack loader to be used in
CI. Previously we had some monkey patches to deal with this but they
could break when changes happen to the upstream django-webpack-loader
library.
This should be a more robust solution to keep CI working and to reduce
complexity on future upgrades.
- This will force the use of the new v2 forum's APIs for Threads & Comment.
- Update params for get_user_subscription function. It uses the same structure as we have in the get_user_threads.
* feat: automatically follow post while createing comments/responses
* feat: follow post when a comment or response is created
* test: updated tests
---------
Co-authored-by: Ayesha Waris <ayesha.waris@192.168.10.28>
Co-authored-by: Muhammad Adeel Tajamul <muhammadadeeltajamul@hotmail.com>
There was problem in filter_discussion_xblocks_from_response(). This
function was breaking the list response for the BlocksInCourseView by
returning a dict instead of list.
Currently the LTI provider implementation auto-creates a random user when
logging in, however, the LTI launch can include relevant user details such as
their email, full name and even a username. This change makes the LTI code
use the provided details if the "Use lti pii" setting is set in the Django
admin.
