Skip to main content

​
Journey-specific permissions

Roles and server checks limit accessible records and actions. The OHADA school installation uses its authentication and session/CSRF checks; platform services verify identity and permissions for their own requests. School staff do not automatically receive another school’s permissions. Private attachments require access checks. Logos and explicitly public content remain public; publishing a resource requires licence review and, for an exam, respect for its confidentiality window. Do not publish a private attachment as a public profile.

​
Institutes and families

An institute is limited to its Marketplace/Business organisation. It is not an Austrian School tenant and has no access to schools’ Django records. Tutors consent to affiliation. Operators cannot take parent/tutor decisions or read private messages merely because they own the business relationship. See Business.

​
Account and retention

Every role can open My account → Delete my account, confirm DELETE and then verify identity using password or Google. Follow steps and consequences. Success removes sign-in access, removes/deactivates the profile and signs out; necessary school and financial records can remain. It is not a promise to physically erase every historical record.

​
Support and integrations

An OHADA school founder can grant limited temporary partner support, then revoke it. This grants neither SSH/console access nor general access to grades/finance. API keys have scopes and country limits and must remain secret. A secure tunnel does not replace those authorisations.

​
Operate an OHADA school

Protect local/database secrets, limit physical/network access and use HTTPS. Keep the operating system and Docker updated; check backups and restores. Review authorised flows before connecting Drive, video or payments: see architecture. CountryConfig does not certify legal compliance. Report vulnerabilities privately to the team without publishing confidential data.