Redesign the plugin for a new way of importing/requesting courses - #31
Open
TamaroWalter wants to merge 8 commits into
Open
Redesign the plugin for a new way of importing/requesting courses#31TamaroWalter wants to merge 8 commits into
TamaroWalter wants to merge 8 commits into
Conversation
This introduces an interface that is to be implemented by an LSF and SAP-SLcM connection class. Currently only one function from lib_his.php was added to the interface but eventually every necessary function in lib_his.php relevant to both LSF and SAP-SLcM should be abstracted and added to this interface.
Add a sample implementation of the campus_management interface for HIS-LSF. Note that this implementation of courses_of_teacher() does not respect the max_import_age admin setting. This needs to be fixed.
Add three tables that will be used in the new plugins structure: - courses: stores an abstraction of courses of any cms - course_requests: stores requests for a new course that was done on behalf of a teacher - imported_courses: stores courses that were imported into moodle
The backend has a new classes structure with different substructures: - local/cms: An interface structure with classes that can access a course management systems database and fetch data - local/models: An implementation of the new datatable entities to make the work with it easier - local/dto: data transfer objects that get transferred to the frontend - route/api: A complete REST api for a new frontend that can handle different requests to import a course or to save a course request for a teacher - route/schema: Only description on how the data looks like that is being transferred on the REST api
A new react frontend is introduced to the plugin. A short summary: - dashboard.php: new entrypoint for the user to access lsf_unification. Only calls the react component - js/Dashboard.tsx: A new dashboard that shows courses that were imported or requested from an cms to moodle - js/services: A service that connects the frontend to the backend rest api - js/wizard: A "Step Wizard" that guides the user through the workflow or either importing an own course or to request a course on behalf of a teacher.
TamaroWalter
force-pushed
the
redesign/courserequest
branch
from
July 31, 2026 15:03
ad11c4c to
7d3a9b4
Compare
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
🔀 Purpose of this PR:
📝 Description:
This PR redesign the whole process of importing and requesting courses with a completely new backend structure and a modern react component frontend.
Backend:
Base for the new structure is a
campus_managementinterface, that serves as API to specific course management systems (cms) outside of moodle. Class implementations (like his_lsf.php and sap.php) access a specific Database and read from them. They are the only place where the plugin connects to outer systems.Three new Databatables where added that are the new main thing the plugin works with:
local_lsf_unification_courses: An abstracted course from any cms. Is used as a layer between a cms course and a moodle course, where attributes can be edited and saved without accessing the other two layers.local_lsf_unification_course_requests: saves courses that had a course requests on behalf of a teacherlocal_lsf_unification_imported_courses: lookup table for courses that were imported to moodleTwo new service classes manage the
campus_management-classes. They provide the main logic/core functions, obscure the exact cms for the plugin, makes CRUD-operations on the new datatables.cms_service: Calls cms functions, provides function to add requests and to import coursesdashboard_service: Functions for read-only data for the frontendREST API:
A REST controller was added that takes calls from the frontend, validates if every required data is there and then calls the right service. It serves as the main layer between frontend and backend.
Frontend:
The new frontend has two parts: a dashboard that only shows imported/requested courses and a step wizard that replaces the old flow of importing/requesting courses. It guides the user through the process, while a "cache" object is getting build in the background. On a submission, this cache gets send to the Rest Api and the service. The cache holds:
Note on categories: The old "helptable" for matching lsf categories to moodle categories is not used. The teacher needs to manually assign the course to an existing moodle category in the import process.
📋 Checklist
Please confirm the following (check all that apply):
phpunitand/orbehattests that cover my changes or additions.var_dump()orvar_exportor any other debugging statements (or commented out code) thatshould not appear on the productive branch.
db/upgrade.phpandupdated the
version.php.🔍 Related Issues
🧾📸🌐 Additional Information (like screenshots, documentation, links, etc.)