Trial ≠ publication
Creating a trial timetable does not change the official timetable currently shown in the Teacher Portal.
Help Center · Teacher Portal
Publish only the applied and verified timetable to teachers.
The Teacher Portal makes the timetable selected by school administration available to each teacher together with their own weekly lessons and confirmed duty information on web and mobile devices.
Portal publishing logic
Keep four distinctions clear throughout publishing.
The applied timetable is authoritative
The portal source is the timetable explicitly selected by school administration as the applied timetable.
Teachers see their own data
The portal view is centered on each teacher’s personal timetable and duty information.
Verify after publishing
A successful publish message is not enough; sample teacher accounts should be checked for timetable and duty accuracy.
01
Check timetable status before publishing
Confirm that the timetable to be sent to the Teacher Portal has actually been selected as the applied timetable. A trial that is still being compared or quality-tested should not be promoted to the portal source.
02
Prepare teacher accounts
Portal users are derived from teacher records defined by the school. Each teacher should map to one correct account. If unexpected username or identity changes appear, stop bulk publishing and verify account uniqueness and identity-protection logic first.
03
Distribute credentials securely
Usernames and initial sign-in information should be distributed only by authorized school administration. If bulk PDF or spreadsheet outputs are used, treat them as sensitive because they contain access credentials.
04
Publish the applied timetable to teachers
After selecting the applied timetable in timetable history, start the teacher-publishing operation. The publishing flow transfers timetable data, teacher mappings and related portal data to the server. Published content should remain consistent with the selected timetable snapshot.
05
Verify the weekly teacher timetable
Day, lesson period, lesson name and class/section should display correctly in the Teacher Portal. Comparing lesson counts and periods teacher by teacher against the applied desktop timetable is the clearest publication-integrity check.
06
Check taught-class information
The portal should show classes taught by the teacher in a clear and consistent order. If class information is missing, appears as a technical identifier or is ordered incorrectly, review the published data and presentation layer separately.
07
Show duty day and location from the same active source
The duty day and location shown in the portal should come from the active duty source of the applied timetable. Do not read from legacy teacher fields or a trial timetable snapshot.
08
Keep trial timetables outside the portal
While new scenarios are being tested, the Teacher Portal should continue to show the current applied timetable. Trial publication data remains separate and becomes active only when that timetable is selected as applied.
09
Expose publication revision meaningfully
A source revision number can help trace synchronization between desktop and portal. Avoid exposing confusing internal technical revisions; show the source timetable/revision in a way school administrators can understand.
10
Balance persistent sessions with account security
Staying signed in can improve mobile usability, but persistent-session options should consider whether the device is personal. Users should be warned not to leave accounts signed in on shared devices.
11
Prioritize the daily flow on mobile
On a phone, teachers should immediately see today’s lessons, lesson periods and duty information where applicable. Weekly view can remain one step deeper; do not simply compress a desktop table onto a small screen.
12
Test with sample accounts after publishing
After publication, sign in to several teacher accounts with different lesson loads. Compare weekly lesson totals, class names, duty day/location and source revision against desktop data.
13
Separate portal problems into four layers
If information is missing in the portal, do not assume it is a front-end issue. Check the desktop source snapshot, data sent to the API, server-side record and portal presentation layer in order.
14
Treat account security as part of publishing
Account uniqueness, password security and unauthorized-access controls are part of the portal workflow. If username generation or account updates introduce unexpected suffixes or characters, stop publication and correct the identity-generation logic.
15
Re-verify when the applied timetable changes
If school administration selects a different timetable as applied, confirm which revision the portal moves to. The old timetable and old duty source should not remain active, and teacher-level views should be checked again.
Publishing chain
Data path from desktop to the teacher’s phone
Desktop
Applied timetable + teacher/duty snapshot
API
Receives and validates authorized publication data
Portal
Serves personal data through the teacher account
Teacher
Views weekly timetable and duty information
Portal information priority
The information a teacher needs should require as few steps as possible.
TodayToday’s lessons and periods
Weekly TimetableThe teacher’s full weekly schedule
DutyConfirmed duty day and location
My ClassesClasses taught by the teacher
Critical publishing mistake
Accidentally turning a trial timetable into the official portal source.
Generating a timetable and publishing a timetable are separate actions. The current official portal timetable and duty data should not change until school administration explicitly selects the applied timetable.
Next guide
v3.22 — Backup and Restore Guide
Portable .ddbackup, full backups, restore modes, migration to a new computer, data integrity and pre-restore safety checks will be covered next.
Help Center