✨ Courses Modal + Student Monitoring Page — Full Description and How They Connect
Part A — Courses Modal (Settings) — Full Description
A1) What the Courses Modal Is (Concept and Purpose)
The Courses Modal is the central administrative panel in Biz1 where an organization defines and manages its entire course structure. It is the single source of truth for all courses and sub-courses in the system.
This modal is not just a simple list — it is the foundation upon which student assignment, attendance tracking, reporting, and access control are built. Every course-related feature in Biz1 ultimately depends on the data created here.
Where it appears in the system
The Courses modal is opened from:
Dashboard → Admin → Settings → Courses
When the user clicks the Courses link, a responsive modal appears with:
-
Title: Courses
-
Help icon
-
Close (×) button
-
Clear step indicator (1/1)
-
Action buttons at the top
Technically, this modal exists in:
-
application/views/new-design/setting_modal.php(blockid="modal_courses")
It is only shown when the Courses List Module is enabled ($courses_lists_module == '1').
All actions inside this modal are handled by Setting.php controller methods such as:
-
add_courses_sub_course -
course_list_display -
sub_course_display -
edit_course_details -
edit_sub_course_list -
delete_course
So in simple terms:
Courses Modal = Admin defines courses → Student Monitoring uses them.
A2) What the User Sees (UI Experience)
When the modal opens, the user sees three main options at the top:
1. Add Courses (Main Course)
This is used to create a parent course, for example:
-
“English Level 1”
-
“Mathematics”
-
“Programming Basics”
The form asks for:
-
Courses English
-
Courses Hebrew
Once saved, this course appears in the main table.
2. Add Sub Courses
This is used to create child courses under a main course, for example:
-
Main Course: “English”
-
Sub-course: “English Beginners”
-
Sub-course: “English Advanced”
-
The user selects:
-
Parent Course (dropdown)
-
Sub Course English
-
Sub Course Hebrew
-
Team Members (multi-select)
Team members assigned here will later control who can see this course in Student Monitoring.
3. Add API Course
This opens a separate modal for integrating API-based courses with external systems.
Courses Table (Bottom Section of Modal)
At the bottom of the modal, the user sees a table listing all main courses:
Each row shows:
-
Course ID
-
Course Name
-
Edit button
-
Delete button
If the user clicks a course row, it expands and shows all related sub-courses underneath.
For each sub-course, the user can:
-
Edit the name
-
Change team members
-
Delete it
Deleting a main course automatically deletes all its sub-courses.
A3) Data and Database Structure
All courses are stored in a single table: courses
The structure works like this:
-
Main Course
-
parent_id = 0 -
Example: “English”
-
-
Sub-Course
-
parent_id = <main_course_id> -
Example: “English Beginners”
-
Each record also contains:
-
name_en -
name_he -
team_member_id(JSON list of user IDs who can access this course)
So the hierarchy is built entirely inside the courses table.
A4) How the Courses Modal Works (Process Flow)
-
Admin opens Settings → Courses
-
They add or edit main courses and sub-courses
-
Data is saved in the
coursestable -
Team members are assigned to sub-courses
-
This data becomes instantly available across the system
Part B — Student Monitoring Page — Full Description (Concept)
B1) What the Student Monitoring Page Is
The Student Monitoring Page is located at:
dashboard/student
This page is used to track:
-
Daily student attendance
-
Zoom attendance
-
Student In / Student Out times
-
Notes per student
-
Monthly summaries
-
Export to Excel
It is controlled by:
-
Student.phpcontroller -
View:
stuents_dashboard.php
The main tables used here are:
-
contactus→ Students -
students_timer→ Daily attendance records -
student_zoom_metting→ Zoom links per date
This page does NOT create courses — it only uses the courses defined in the Courses Modal.
Part C — How Courses Modal and Student Monitoring Are Connected
This is the most important section of your document.
C1) Shared Data Source — courses Table
The connection between the two modules is built on one single table:
- courses
-
The Courses Modal writes to this table
-
The Student Monitoring Page reads from this table
This means:
Courses Modal = Creator
Student Monitoring = Consumer
Every course and sub-course shown in Student Monitoring comes directly from the Courses Modal.
C2) How Student Monitoring Gets the Course List
When the Student Monitoring page loads:
-
The system fetches all main courses (
parent_id = 0) -
These appear in the Course dropdown
When the user selects a different course:
-
A request is sent to:
dashboard/my_users/change_cours_sub_cor_html
-
This returns all sub-courses belonging to that main course
-
The sub-course dropdown updates dynamically
So both the Courses Modal and Student Page use the same source — just via different controllers.
C3) How Students Are Linked to Courses (Key Connection)
This is the most critical link:
-
Students are stored in
contactus -
Each student has a field:
sub_courses -
This field contains a JSON list of sub-course IDs, for example:
["273","248"]
So when the user selects a sub-course in Student Monitoring:
-
The system finds all students in
contactuswhosesub_coursescontain that ID -
Those students appear in the Daily Attendance table
This means:
-
Course ID in Courses Modal = Same ID stored in student record
-
Same ID used in attendance (
students_timer) -
Same ID used in Zoom records (
student_zoom_metting)
If a sub-course is deleted in the Courses Modal:
-
It disappears from dropdowns
-
But old student records may still reference it (data cleanup may be needed)
C4) Team Members and Visibility
In the Courses Modal:
-
Admin assigns team members to each sub-course
In Student Monitoring:
-
If the user is an admin → they see all courses
-
If the user is a team member → they only see sub-courses assigned to them
So:
Courses Modal controls access
Student Monitoring respects that access
C5) Export and Reporting
When exporting attendance data:
-
The system groups students by course/sub-course
-
The names used in the export come from the same
coursestable -
This ensures consistency between Settings and Reports
C6) Zoom Link Per Date
On Student Monitoring:
-
The user can add a Zoom link for a specific date and course
-
This is saved in
student_zoom_mettingwith:-
course_id -
sub_course_id -
date -
zoom_link -
zoom_time
-
Again — these course IDs come from the Courses Modal.
Part D — End-to-End Connection Flow (Simple Explanation)
-
Admin creates courses in Settings → Courses Modal
-
Data saved in
courses
-
-
Students are assigned to sub-courses elsewhere in the system
-
Stored in
contactus.sub_courses
-
-
User opens Student Monitoring
-
Course dropdown reads from
courses -
Sub-course dropdown updates dynamically
-
Students are filtered based on
contactus.sub_courses
-
-
Attendance is recorded
-
Stored in
students_timerwith course/sub-course IDs
-
-
Zoom link is saved
-
Stored in
student_zoom_mettingwith course/sub-course IDs
-
-
Export uses same course structure
-
Ensures consistency across system
-
Final Summary (In One Paragraph)
The Courses Modal defines the official structure of all courses and sub-courses in Biz1 and controls which team members can access them. The Student Monitoring Page does not create or modify courses — it simply reads this structure, filters students based on their assigned sub-courses, records attendance and Zoom data against those same course IDs, and uses them for reporting and exports. Both modules are tightly connected through the shared courses table and the use of course/sub-course IDs across contactus, students_timer, and student_zoom_metting.
