# Daneshyar Two-Person Role Connection Test Plan This plan is for two people testing two logged-in panels at the same time. It covers every unique pairing between these five roles: - Student (`student`) - Teacher (`teacher`) - Moaven / Vice Principal (`moaven`) - Modir Madrese / School Owner (`owner`; the application also supports `principal`) - Super Admin (`super_admin`) Five different roles produce **10 unique role pairs**. All 10 are covered below, including pairs that intentionally have no direct messaging connection. ## 1. Test accounts All seeded demo passwords are `Demo@1234`. | Role | Username | Recommended use | School | |---|---|---|---| | Super Admin | `admin` | System-side tests | No school | | Modir Madrese | `modir1` | Main school manager | Dabirestane Daneshyar | | Moaven | `naeb1` | Main vice principal | Dabirestane Daneshyar | | Teacher | `teacher1` | Math teacher for both school-1 classes | Dabirestane Daneshyar | | Student | `ali.rezaei` | Student in Haftom Alef, taught by `teacher1` | Dabirestane Daneshyar | | Other-school manager | `modir2` | School-isolation tests only | Dabestane Imam Reza | | Other-school teacher | `teacher4` | School-isolation tests only | Dabestane Imam Reza | | Other-school student | `p.nouri` | School-isolation tests only | Dabestane Imam Reza | Use `teacher1` with `ali.rezaei` for Teacher–Student tests. They are connected through the same classroom, so homework, exams, grades, attendance, news, and online-class tests are meaningful. ## 2. How the two testers should work 1. Tester A opens a normal browser profile. 2. Tester B uses a different browser, a separate browser profile, or an incognito window. Two tabs in the same browser profile are **not** enough because they share the login session. 3. Both testers confirm the displayed name, username, role, and school before starting. 4. Create test data with this subject/title prefix so it is easy to find and remove: ```text [PAIR-ROLE1-ROLE2-YYYYMMDD-HHMM] ``` Example: `[PAIR-STUDENT-TEACHER-20260717-1430]` 5. For normal pages, Tester B may need to refresh to see Tester A's change. The internal online classroom is the real live/two-person test and synchronizes automatically. 6. Record each result as `PASS`, `FAIL`, `BLOCKED`, or `N/A`. A missing module is `BLOCKED`, not `PASS`. 7. Take a screenshot and copy the URL for every failure. Also record which account performed the action. ### Before changing system settings Record these baseline values so they can be restored: - Enabled modules for Dabirestane Daneshyar - School active/inactive status and licence date - SMS wallet balance and pending requests - Permissions currently granted to `naeb1` and `teacher1` - Any grade, announcement, class, exam, or homework record that will be edited Do not reset the password, archive the school, delete a real user, delete student history, close the school year, or run database cleanup during this test. Those actions are not needed to prove a panel connection. ## 3. Complete pairing matrix | # | Tester A | Tester B | Main connections to test | |---:|---|---|---| | 1 | Student | Teacher | Messages, news, homework, exam, grade, attendance, internal online class | | 2 | Student | Moaven | Messages, targeted news/announcement, grade approval, objection, absence excuse, voting | | 3 | Student | Modir Madrese | Messages, targeted news/announcement, grade approval, objection, attendance, voting | | 4 | Teacher | Moaven | Messages, news, grade approval/rejection, attendance oversight, homework report, online class | | 5 | Teacher | Modir Madrese | Messages, news, grade workflow, teacher assignment, permissions, oversight | | 6 | Moaven | Modir Madrese | Messages, targeted news, delegated permissions, school-setting boundaries, audit/activity | | 7 | Modir Madrese | Super Admin | Support ticket, SMS charge request, owner alert, modules, school status/licence | | 8 | Student | Super Admin | No direct conversation; module/status impact and strict access-boundary tests | | 9 | Teacher | Super Admin | No direct conversation; module/permission impact and strict access-boundary tests | | 10 | Moaven | Super Admin | Support ticket, module/permission impact, and no-direct-message boundary | ## 4. Checks required for every pair Run these checks before the pair-specific scenarios. - [ ] **GEN-01 — Independent sessions:** refreshing either browser keeps each tester in the correct account. - [ ] **GEN-02 — Correct landing panel:** `/dashboard` redirects each account to its own role dashboard. - [ ] **GEN-03 — Session isolation:** logging out in one browser does not log out the other browser. - [ ] **GEN-04 — Direct URL security:** copy one role-only URL into the other role's browser. An unauthorized account receives `403`, `404`, or a safe redirect; it never sees protected data. - [ ] **GEN-05 — School scope:** no school-1 account sees a school-2 person or record in contacts, lists, selectors, search, messages, or reports. - [ ] **GEN-06 — Write then read:** after Tester A creates a tagged record, Tester B sees exactly one correct record after the expected refresh. - [ ] **GEN-07 — Reply/action:** after Tester B replies or changes status, Tester A sees the correct updated state without duplicated records. - [ ] **GEN-08 — Persian/UI quality:** names, dates, status labels, validation errors, and success messages render correctly on both panels. - [ ] **GEN-09 — Authorization on POST/PUT/PATCH/DELETE:** hiding a button is not sufficient; manually opening or submitting an unauthorized route must still be rejected. - [ ] **GEN-10 — Refresh/idempotency:** refreshing after a successful action must not repeat the action or create a duplicate. - [ ] **GEN-11 — Notification destination:** when an action creates a notification, clicking it opens the recipient's authorized role-specific page and never sends a Student to a school-admin URL (or the reverse). ## 5. Pair 1 — Student versus Teacher Use Student `ali.rezaei` and Teacher `teacher1`. ### Direct messages - [ ] **ST-T-01:** Student opens **Messages** (`/student/messages`), sees `teacher1` as a contact, and sends a tagged message. - [ ] **ST-T-02:** Teacher opens **Messages** (`/school/messages`), sees the correct sender, subject, body, time, and unread state. - [ ] **ST-T-03:** Teacher replies in the same thread. Student sees one thread containing both messages, not two unrelated threads. - [ ] **ST-T-04:** Teacher starts a new message to the student. Student sees it and the unread state clears after opening it. - [ ] **ST-T-05:** Student must not be able to select a teacher from another school, such as `teacher4`. - [ ] **ST-T-05A:** Click the new-message notification on both panels. Each link opens that recipient's own message page and the unread badge/count becomes correct. ### Teacher-to-student learning workflow - [ ] **ST-T-06 — Dashboard news:** Teacher creates a tagged dashboard-news item for `ali.rezaei` or Haftom Alef. Student sees it on the dashboard; an unrelated student/class does not. - [ ] **ST-T-07 — Homework:** Teacher creates a tagged homework for Haftom Alef. Student sees the title, subject, description, deadline, and upload rules. - [ ] **ST-T-08 — Submission:** Student submits text and, if enabled, a small safe file. Teacher sees the correct student, content, file, and submission time. - [ ] **ST-T-09 — Edit:** Student edits the submission. Teacher sees the new version only once. - [ ] **ST-T-10 — Exam:** Teacher creates a short tagged exam, adds at least one multiple-choice and one written question, sets it active, and verifies only the intended class can see it. - [ ] **ST-T-11 — Exam result:** Student answers and submits. Teacher reviews/scores it; Student sees the final result and cannot submit a second time unless the exam settings explicitly allow it. - [ ] **ST-T-12 — Grade visibility:** Teacher records a tagged grade for the student. Student receives the grade notification. Verify whether the product intentionally shows it before approval; an approved grade must appear in grades/report card. - [ ] **ST-T-13 — Attendance:** Teacher records Student as absent or present. Student sees the same date, class/subject, and status in Attendance. ### Internal online classroom — primary live connection test - [ ] **ST-T-14:** Teacher creates an **internal** online class for Haftom Alef and starts it. - [ ] **ST-T-15:** Student joins from the student dashboard. Both browsers show the other participant as online. - [ ] **ST-T-16:** Public chat works in both directions and does not duplicate messages. - [ ] **ST-T-17:** Student raises a hand; Teacher sees the hand/order and lowers it. - [ ] **ST-T-18:** Student sends a reaction; both browsers display it. - [ ] **ST-T-19:** Teacher draws and clears the board; Student sees both operations. - [ ] **ST-T-20:** Teacher uploads a safe small file; Student can download the correct file. - [ ] **ST-T-21:** Teacher opens a poll; Student votes once; both see the updated count; Teacher closes it. - [ ] **ST-T-22:** Teacher disables student chat, mutes/unmutes the Student, and verifies the server rejects disallowed messages. - [ ] **ST-T-23:** Student leaves and rejoins. Attendance/join logs contain the correct student and do not create corrupt duplicate attendance records. - [ ] **ST-T-24:** Teacher ends the class. Student sees the ended state and cannot continue protected actions. ## 6. Pair 2 — Student versus Moaven Use Student `ali.rezaei` and Moaven `naeb1`. - [ ] **ST-MV-01 — Messages A→B:** Student can select `naeb1`, send a tagged message, and Moaven receives it in `/school/messages`. - [ ] **ST-MV-02 — Messages B→A:** Moaven replies, then starts a separate message to Student. Student sees the correct threads and unread behavior. - [ ] **ST-MV-03 — News:** Moaven sends tagged dashboard news to the Student role or directly to `ali.rezaei`. Student sees it; Teacher does not see a student-only item. - [ ] **ST-MV-04 — Announcement:** Moaven publishes a tagged students-only announcement. Student sees and dismisses it; the dismissal survives refresh only for that Student. - [ ] **ST-MV-05 — Grade approval:** Moaven approves one submitted grade belonging to Student. Student sees the approved state/value; a different student's grade is unchanged. - [ ] **ST-MV-06 — Grade rejection boundary:** If Moaven rejects a submitted grade, Student must not see it as approved. Record the displayed behavior. - [ ] **ST-MV-07 — Objection:** Student submits an objection against an eligible approved grade. Moaven sees the exact student, subject, score, and text, then resolves it. Student sees the resolution. - [ ] **ST-MV-08 — Absence excuse:** Student submits an excuse request for an absence. Moaven approves or rejects it; Student sees the final attendance status/reason. - [ ] **ST-MV-09 — Voting:** Moaven creates and publishes a tagged vote for Student's grade/class. Student votes once; a second vote is blocked; result visibility follows the configured policy. - [ ] **ST-MV-10 — Scope:** Moaven cannot use a changed ID/URL to resolve a grade, objection, attendance record, or vote from another school. ## 7. Pair 3 — Student versus Modir Madrese Use Student `ali.rezaei` and Manager `modir1`. - [ ] **ST-MD-01 — Messages:** Test new messages in both directions, reply threading, unread/read state, and correct sender identity. - [ ] **ST-MD-02 — Direct news:** Manager sends tagged news directly to `ali.rezaei`; Student sees it and another student does not. - [ ] **ST-MD-03 — All/student announcement:** Manager publishes an all-users item and a students-only item. Student receives both; audience labels and dismissal work. - [ ] **ST-MD-04 — Grade handoff:** Manager approves a submitted grade for Student. Student sees the final grade and report-card totals update correctly. - [ ] **ST-MD-05 — Objection handoff:** Student creates a grade objection; Manager resolves it with a note; Student sees the correct result. - [ ] **ST-MD-06 — Attendance handoff:** Student requests an excuse; Manager reviews it; Student sees the same final state. - [ ] **ST-MD-07 — Voting:** Manager creates a class-restricted vote; Student can vote only when eligible and only once. - [ ] **ST-MD-08 — Student data boundary:** Student cannot open Manager routes such as `/school/users`, `/school/settings`, `/school/grades`, or `/school/audit-logs`. - [ ] **ST-MD-09 — Account safety:** Manager can see/manage the intended Student account, but Student never sees other students' private records, national code, parent contact information, or credentials. ## 8. Pair 4 — Teacher versus Moaven Use Teacher `teacher1` and Moaven `naeb1`. - [ ] **T-MV-01 — Messages:** Send new tagged messages and replies in both directions. Verify one thread, correct unread counts, and notifications where supported. - [ ] **T-MV-02 — News Moaven→Teacher:** Moaven sends teacher-role or direct news. Teacher sees it on the dashboard. - [ ] **T-MV-03 — News Teacher scope:** Teacher can target only their own students/classes. Attempts to target Moaven, all users, another teacher's class, or another school are rejected by the server. - [ ] **T-MV-04 — Grade approve:** Teacher creates a submitted grade. Moaven approves it. Teacher sees `approved` and cannot silently edit an approved grade. - [ ] **T-MV-05 — Grade reject/reconsider:** Teacher creates another grade; Moaven rejects it; Teacher sees `rejected` and submits reconsideration where offered. - [ ] **T-MV-06 — Attendance oversight:** Teacher saves a class attendance sheet. Moaven sees matching totals and the correct absent students in school reports. - [ ] **T-MV-07 — Homework oversight:** Teacher creates homework and receives a student submission. Moaven's Homework Report reflects the assignment/submission counts. - [ ] **T-MV-08 — Online class oversight:** Teacher starts an internal class. Moaven opens the same room as a host, sees participants/messages, and does not create a fake student attendance record. - [ ] **T-MV-09 — School scope:** Moaven cannot approve or view records belonging to `teacher4` and school 2 by changing route IDs. ## 9. Pair 5 — Teacher versus Modir Madrese Use Teacher `teacher1` and Manager `modir1`. - [ ] **T-MD-01 — Messages:** Test new messages and replies in both directions, including read state and sender identity. - [ ] **T-MD-02 — Manager news:** Manager sends tagged teacher-role news. Teacher sees it; Student does not see it. - [ ] **T-MD-03 — Teacher news restriction:** Teacher can send only to assigned students/classes, while Manager can target broader school audiences. - [ ] **T-MD-04 — Grade lifecycle:** Teacher submits a tagged grade; Manager rejects it; Teacher edits/resubmits or requests review; Manager approves it. Both panels show the same final state and grade log. - [ ] **T-MD-05 — Attendance lifecycle:** Teacher records attendance; Manager sees the record, reports, and audit/activity information with correct totals. - [ ] **T-MD-06 — Homework/exam oversight:** Teacher creates a tagged homework and exam. Manager's reports show the records without changing their ownership to Manager. - [ ] **T-MD-07 — Assignment visibility:** Manager changes or creates a temporary class/subject/schedule assignment for Teacher. Teacher sees only the intended assignment. Remove the temporary assignment afterward. - [ ] **T-MD-08 — Permission change:** Manager changes one non-critical permission for Teacher. After a fresh login, both the menu and direct action must follow the permission decision. Restore the original permission afterward. - [ ] **T-MD-09 — Ownership security:** Teacher cannot open school settings, user management, access management, support tickets, or other Manager-only routes unless the product specification explicitly grants that permission. ## 10. Pair 6 — Moaven versus Modir Madrese Use Moaven `naeb1` and Manager `modir1`. - [ ] **MV-MD-01 — Messages:** Test tagged new messages and replies in both directions, unread/read state, and notification links. - [ ] **MV-MD-02 — Targeted news:** Manager sends direct news to Moaven; Moaven sends principal-role/direct news to Manager where allowed. Each item reaches only its selected audience. - [ ] **MV-MD-03 — Delegated permission deny:** Manager removes one non-critical Moaven permission. After Moaven logs in again, the protected menu/action and its direct URL must be unavailable. - [ ] **MV-MD-04 — Delegated permission allow:** Manager grants that permission. Moaven can use only that capability, with no unrelated privilege increase. Restore the baseline afterward. - [ ] **MV-MD-05 — Self-escalation protection:** Moaven must not be able to grant permissions to self, change Manager permissions, promote self to owner, or bypass a deny by typing a URL. - [ ] **MV-MD-06 — Manager-only controls:** Verify which operations are intentionally owner-only: school settings, module purchases, user-role changes, access delegation, credential reset, destructive history actions, and school-year closure. Any unexpected Moaven access is a security failure. - [ ] **MV-MD-07 — Shared operational data:** A safe action by Moaven, such as approving a test grade or reviewing an excuse, appears correctly in Manager reports/audit logs with Moaven as actor. - [ ] **MV-MD-08 — Concurrent edit:** Both open the same harmless test record. Tester A saves, then Tester B saves stale data. Record whether the system prevents overwrite or clearly applies last-write-wins; it must not corrupt the record. ## 11. Pair 7 — Modir Madrese versus Super Admin Use Manager `modir1` and Super Admin `admin`. ### Support and system notifications - [ ] **MD-SA-01 — Support request:** Manager creates a tagged ticket in **Peyesh → Poshtibani** (`/school/support-tickets`). Super Admin sees the correct school, creator, priority, subject, and body in `/super-admin/support-tickets`. - [ ] **MD-SA-02 — Support response:** Super Admin adds an admin note and changes status to answered/closed. Manager sees the same note/status after refresh. - [ ] **MD-SA-03 — Owner alert:** Super Admin sends a tagged alert to Dabirestane Daneshyar's owner. `modir1` receives the notification/dashboard item; Moaven, Teacher, and Student do not receive an owner-only alert. ### SMS wallet - [ ] **MD-SA-04:** Record the Manager's SMS balance, submit one tagged charge request, and confirm exactly one pending request appears for Super Admin. - [ ] **MD-SA-05:** Super Admin approves or rejects it. Manager sees the final status, and an approval changes the balance exactly once. - [ ] **MD-SA-06:** Refreshing either page does not approve twice or duplicate the wallet transaction. ### Module and school controls - [ ] **MD-SA-07 — Module off:** Record the current state of one non-critical module. Super Admin disables it for school 1. After hard refresh, Manager no longer sees the module entry and its direct route returns a safe denial. - [ ] **MD-SA-08 — Module restore:** Super Admin enables the module again. Manager regains access after refresh. Restore the exact original state. - [ ] **MD-SA-09 — School warning/status:** Verify Manager sees Super Admin's alert/status changes. If testing school deactivation, do it only at the very end, keep the Super Admin session open, and reactivate immediately. - [ ] **MD-SA-10 — Licence:** Record the old licence date, perform one controlled renewal only if disposable test data is used, verify Manager sees the new state, and record the change for cleanup. - [ ] **MD-SA-11 — Scope:** Manager cannot open any `/super-admin/*` page. Super Admin actions directed at school 1 do not alter school 2. ## 12. Pair 8 — Student versus Super Admin There is intentionally no direct Student–Super Admin inbox/contact workflow. Test the boundary and system-level effects instead. - [ ] **ST-SA-01 — No direct contact:** Super Admin is absent from Student contacts. Student is not given a Super Admin conversation route. - [ ] **ST-SA-02 — Route boundary:** Student cannot open `/super-admin`, schools, users, database, reports, SMS settings, support tickets, or audit logs. - [ ] **ST-SA-03 — Module impact:** Super Admin disables one Student-visible non-critical module for school 1. The Student menu and direct route both become unavailable after refresh; restore it immediately. - [ ] **ST-SA-04 — School status impact:** If school deactivation is tested, Student access is denied safely without exposing stack traces or another school's data. Super Admin can restore the school. - [ ] **ST-SA-05 — Data scope:** Super Admin can locate the correct Student in global administration, but a school-1 module/status change does not affect `p.nouri` in school 2. - [ ] **ST-SA-06 — Privacy:** Student never receives global admin notes, database tools, school financial data, permission screens, or alerts intended only for an owner. ## 13. Pair 9 — Teacher versus Super Admin There is intentionally no direct Teacher–Super Admin inbox/contact workflow. - [ ] **T-SA-01 — No direct contact:** Neither panel offers a direct Teacher–Super Admin message recipient. - [ ] **T-SA-02 — Route boundary:** Teacher cannot open any `/super-admin/*` route or global database/report page. - [ ] **T-SA-03 — Module impact:** Super Admin disables a non-critical Teacher-visible module for school 1. Teacher loses both the menu entry and direct route; restore the baseline. - [ ] **T-SA-04 — User permission impact:** Super Admin changes one non-critical grant for `teacher1`. After a fresh login, Teacher's actual server-side capability matches the saved setting. Restore it. - [ ] **T-SA-05 — Cross-school safety:** A school-1 module/permission change does not affect `teacher4` or expose school-2 classes/students to `teacher1`. - [ ] **T-SA-06 — Audit:** Super Admin's permission/module action is recorded with the correct actor and target; Teacher cannot read global audit details. ## 14. Pair 10 — Moaven versus Super Admin Use Moaven `naeb1` and Super Admin `admin`. - [ ] **MV-SA-01 — Support request:** Moaven submits a tagged school support ticket. Super Admin sees the correct school and creator. - [ ] **MV-SA-02 — Support response:** Super Admin answers/closes it. Moaven sees the admin note and new status. - [ ] **MV-SA-03 — No direct inbox:** Super Admin is not a recipient in Moaven's school messenger, and Moaven is not given a global-admin inbox route. - [ ] **MV-SA-04 — Module impact:** Super Admin toggles one non-critical school module. Moaven's menu and direct route both follow the new state; restore it. - [ ] **MV-SA-05 — Permission impact:** Super Admin changes one non-critical permission for `naeb1`. After a fresh login, the saved grant is enforced server-side. Restore it. - [ ] **MV-SA-06 — Owner-alert audience:** A Super Admin owner-only alert reaches `modir1`, not `naeb1`. - [ ] **MV-SA-07 — Scope:** Moaven cannot open Super Admin routes or view other schools, while Super Admin can still distinguish school 1 from school 2 correctly. ## 15. Cross-school isolation attack checks Run these after the normal same-school flows. They are critical because valid functionality is still unsafe if IDs can cross school boundaries. - [ ] **SEC-01:** `ali.rezaei` cannot message `teacher4`, `modir2`, or `p.nouri`. - [ ] **SEC-02:** `teacher1` cannot view or change school-2 students, attendance, grades, homework, exams, schedules, messages, or online classes by changing an ID in the URL/request. - [ ] **SEC-03:** `naeb1` and `modir1` cannot view or change school-2 users or records by changing an ID. - [ ] **SEC-04:** A school-1 announcement/news/message never appears on a school-2 dashboard. - [ ] **SEC-05:** A school-1 online-class URL/token cannot be used by a school-2 Student. - [ ] **SEC-06:** Download routes for homework answers, exam answers, online-class files, report cards, exports, and ID cards enforce both role and school scope. - [ ] **SEC-07:** Search and notification links never return another school's record. - [ ] **SEC-08:** Super Admin can act globally, but every targeted action changes only the explicitly selected school/user. ## 16. Optional same-role pairs These are outside the 10 different-role combinations. Run them only after creating safe additional accounts in the same test school. - [ ] **Teacher–Teacher:** direct messages work; neither Teacher can edit the other's grades/exams/homework/classes unless explicitly authorized. - [ ] **Student–Student:** students cannot directly message or access one another's private records unless a student-to-student feature is intentionally added. - [ ] **Moaven–Moaven:** messages work; permissions and audit actor remain distinct. - [ ] **Manager–Manager (`owner`–`principal`):** shared school data stays consistent; owner-only boundaries follow the written permission policy. - [ ] **Super Admin–Super Admin:** audit logs identify the correct actor and concurrent system changes remain consistent. ## 17. Cleanup checklist - [ ] Delete only the records created with the `[PAIR-...]` prefix where a safe delete action exists. - [ ] Restore all module states. - [ ] Restore `naeb1` and `teacher1` permissions. - [ ] Reactivate the school if status testing was performed. - [ ] Restore any temporary schedule/class assignment. - [ ] Confirm demo account passwords were not changed. - [ ] Record intentional leftovers such as audit logs, wallet transactions, submitted tickets, and licence changes. - [ ] Run one final login for Student, Teacher, Moaven, Manager, and Super Admin. ## 18. Bug report template Copy this block for every failure: ```md ### BUG-[number] — [short title] - Test ID: `ST-T-03` - Result: FAIL - Severity: Critical / High / Medium / Low - Tester A account/browser: - Tester B account/browser: - School: - Date/time and timezone: - URL: - Test prefix/record ID: - Preconditions: - Steps: 1. 2. 3. - Expected: - Actual: - Does refresh change the result?: - Screenshot/video: - Browser console error: - Network request status/response: - Reproducible?: Always / Sometimes / Once - Cleanup performed: ``` ## 19. Final sign-off | Area | Passed | Failed | Blocked | Tester initials | |---|---:|---:|---:|---| | Generic session/access checks | | | | | | Student–Teacher | | | | | | Student–Moaven | | | | | | Student–Manager | | | | | | Teacher–Moaven | | | | | | Teacher–Manager | | | | | | Moaven–Manager | | | | | | Manager–Super Admin | | | | | | Student–Super Admin | | | | | | Teacher–Super Admin | | | | | | Moaven–Super Admin | | | | | | Cross-school isolation | | | | | Release decision: `READY / NOT READY` Remaining critical/high bugs: 1. 2. 3.