Role and permission reference

Waqar combines authentication, a selected school, a membership role, feature availability, and resource ownership. A role describes the broad job; it does not bypass the other checks.

Role or audience	Can normally do	Cannot do through that role alone
Visitor	View public pages; register a new school; sign in; verify or recover an account; accept an invitation	View a school or child without an accepted membership
School administrator	Manage school settings, semesters, staff, halqas, students, sessions, optional learning plans, keys, and authorized reports	Manage another school or internal service controls
Sheikh	Work with assigned halqas and their learners; read owned or assigned-halqa sessions; record attendance and recitations; use assigned-resource reports and allowed planning actions	View an unassigned same-school learner or halqa; change protected school, membership, subscription, feature, or key settings
Parent	View children linked by accepted invitations and the records the school makes parent-visible	View unrelated students, edit teaching records, or open school administration
API integrator	Use a school-issued key for operations allowed by its scopes and rollout eligibility	Use interactive pages as a user or exceed the key’s school, scope, feature, and quota boundaries

A sheikh may see only assigned halqas and the students in those halqas. Session history is limited to sessions the sheikh owns or sessions attached to an assigned halqa. An unassigned same-school record is intentionally presented like a missing record. A parent may see only linked children. A school administrator’s authority ends at the school boundary. The active school shown in navigation is therefore an important part of every permission decision.

Some routes permit both school administrators and sheikhs but expose actions conditioned by the record state. For example, a learning-plan action can also depend on whether planning is enabled, the effective student policy, and the assignment’s current status.

A pending school administrator can use only the Dashboard and Settings until approval. Other navigation, notification requests, and shortcuts remain absent.

The school role is evaluated separately from subscription limits and feature controls. The workspace hides ordinary PDF, CSV/Excel, certificate, and Learning Plan controls when their effective feature is unavailable; manually entered URLs remain protected by backend checks. API access adds further rollout, suspension, key, scope, network, and quota controls.

When an action is absent or denied:

1. Confirm the active account and school.
2. Confirm the membership role.
3. Confirm that the target record belongs to that school and is assigned or linked where required.
4. Ask a school administrator to check plan and feature availability.
5. For controlled API access, check the key, scopes, and platform rollout.

Never borrow an account, change an identifier in a URL, or request excessive permissions as a workaround.