ob3ron ā changed the visibility of the branch 3531918-drupal-lms-fill to hidden.
ob3ron ā changed the visibility of the branch 3531918-drupal-lms-fill to active.
ob3ron ā changed the visibility of the branch 3531918-drupal-lms-fill to hidden.
Personally I would love to be able to free tag each activity, then filter by taxonomy when adding to lessons. The same when adding lessons to courses.
Fixed in š± Proposal for course revisioning strategy Active ?
Docs have been brought up to date, and added to the module description. Anyone is free and welcome to make edits and improvements to any of the guides.
Changed Group Membership Request module requirement to LMS Membership Request
Add reference to Theming page in Developer's Guide
Refactored to reflect plugin changes: SelectBase and WithFeedbackPluginTrait
Updated with the new feedback trait, improved code examples
Expanded example plugin code, other minor text edits
Updated Select plugins to reflect their integration
Updated with current SDC structure and theming instructions
Extensive clarifications of the descriptions of various entity types
Fixed paths to some files, especially to the new LMS Classes submodule components
Updated to reflect recent module changes, especially with classes
Multiple updates to reflect recent module changes, especially revisioning.
Add link to course-level "Allow to revisit finished course" setting.
Added lesson reuse to top list of lesson features
Changed scoring for lesson total from sum to percentage, other minor text updates and expansion
Added revisioning and pedagogical flexibility to comparison tables
Integrated "General settings" page as previous page.
Updated the Select Answer(s) plugin instructions to reflect latest updates
Updated and expanded text including making classes optional via submodule.
Minor content updates including optional classes via sub-module.
Added all errors to feedback area.
Added minimum character validation in the AJAX callback, hopefully final fixes.
ob3ron ā created an issue.
Feedback incorporated!
Fixed in š± Proposal for course revisioning strategy Active
Tricky to get all four feedback plugins to work with a common trait, but we got there eventually!
Any terminology is configurable using translation. But I also think there must be a better name that we can use by default.
What "class" refers to here is the group of people who are signed up to receive the content of a course. There are different ways to express that, but how about "audience"?
So instead of "You have been added to the "Class 2X" class." we would have:
"You have been added to the [course_name] course audience."
ob3ron ā created an issue.
For the revisioning UI, what if the edit forms have radio buttons, with no default selection, instead of a revision checkbox? So editors have to make a conscious choice of which option they want. They could be labelled with some detail, like:
ā Update current version. Apply these changes immediately for all current students. Recommended for minor edits, such as typo corrections, that don't affect the overall meaning or scoring.
ā Create new revision. This version will only be shown to new students; existing students will remain on the previous revision. Recommended for any major changes.
Add note about VBO being required for student mgmt features
I apologize for the late reply, I've been in a meditation retreat this week. And I'm very sorry for your update issues -- you're an early pioneer with Drupal LMS, you're at the start of something great and there are probably going to be some teething issues along the way, but still, it shouldn't happen and I feel bad for the extra work you've had to do.
Due to your failed update, there was a necessary setting that didn't get changed. If you go to /admin/group/types/manage/lms_course/display you should see an entry for the start_link component. That needs to be changed from "Plain text" to "LMS Component". That should resolve your Enroll button issue.
You can certainly change the name of Classes, see the draft documentation at https://www.drupal.org/docs/extending-drupal/contributed-modules/contrib... ā
We've had some debate about the way classes are named, if you'd like to chime in on the discussion, please feel free to comment on this issue: https://www.drupal.org/project/lms/issues/3525100 š UI/UX Improvements Active
Remove course card custom fields and replace with hook
@buzzbee did you use the quickstart setup from https://github.com/graber-1/drupal_lms_ddev ? The group settings and relationships have to be set in a very specific way to work correctly.
Students need to be in classes for course access. When a student clicks on the 'Enroll' button, they are automatically added to the class associated with the course. If you want to manually add students, use the Students tab on a course, for example: /group/1/students -- that will give them the necessary group membership and permissions to view and take the course.
Also make sure your User 1 admin account has the LMS Admin role if you're using that to set up courses, otherwise you'll get some unexpected results.
Addressed all review comments. Reinstated hook_update_N to set the field display format of the start_link component, which is necessary for all sites, but it does not install the updated /courses view.
Bouncing back for review after incorporating all feedback.
Add note to assign LMS Admin role to site admin accounts
ob3ron ā created an issue.
What is the expected functionality of a blank filling -- is there one exact correct answer? Or is a near match acceptable?
If we do drag-n-drop, that simplifies grading. Is it maybe worth starting from a drag-n-drop mindset, which could then be expanded into other purposes beyond fill-in-the-blanks, like sorting, matching, and sequencing?
@graber do you mean we should create a new ecosystem module for lms_answer_plugins?
Documentation for configuring the course cards added at https://www.drupal.org/docs/extending-drupal/contributed-modules/contrib... ā
Add instructions for course card display settings
@garchris can you create a feature request for a Fill in the Blanks plugin in the Drupal LMS issue queue ā ? I'm also interested in that being included.
To clarify the architectural changes:
StartLinkFieldItemList was both building and rendering the start_link component. That led to context-dependent fatal errors when a form was rebuilt via an AJAX call (like adding a lesson to a new course), and when displaying a start_link component from within a views plugin like our new
So the building and rendering responsibilities were separated:
StartLinkFieldItemList now only calculates the component props and stores them as a serialized string. It gets its context directly from the entity it is attached to.
A new field formatter LmsComponentFormatter calls the field's view() method, which takes the serialized props, unserializes them, and builds the component render array.
CourseStartLink no longer needs the getRenderable() method. Attributes were added for styling of each of the start_link statuses.
Latest changes from 1.0.x included, and hard dependency on media module removed.
The start_link component needed to be refactored to work in all contexts.
Can we start off by adding *_vid fields to CourseStatus, LessonStatus, and Answer entities and run an initial update hook, then transition to Entity Reference Revisions when we're ready to migrate the Course.lessons and Lesson.activities fields? Seems like that could make the updates less monolithic.
Drupal Commerce has a similar need...Iām not sure if they solve this by revisions.
Turns out Commerce copies the current product data into an order item. Same need but not really a transferable solution.
I think [the revision checkbox] is a bit too subtle to expect course authors to understand the implications of or get right all the time even if they do
The revision checkbox could have explicit instructions marked "IMPORTANT". Or we could alter the form to have two submit buttons, one for a minor live update, the other for a new version. Either way I agree it's hard to make it foolproof. Needs good documentation.
something like adding a lesson at the end of a course where no-one has reached it yet, you might want everyone to take that lesson
The "Freshest Unaccessed Content" feature would address this. It adds some complexity to the lock-in timing, but seems worthwhile for long courses.
We could make a global setting so the site owner can choose if students take the course / lesson versions from the moment of starting or current
If set to "current" then we'd lose consistency with evaluation & revisits, unless we associate revision lists with uid. The revision schema updates add a BC layer, so not sure if this would add more complication than it's worth.