架构、模块与角色

本页概述Omniscol的应用架构，以及学校一侧可见的角色。具体的合同承诺（可用性、备份、保留期限、监控）以经过确认的法律或商务文件为准。

托管与可靠性

Omniscol托管在欧盟境内，具体位于AWS巴黎和Scaleway巴黎。产品采用备份、监控机制，并在各学校账户之间做逻辑隔离；适用于某个账户的具体细节取决于合同和所涉及的环境。

用户层面的详细说明参见FAQ——安全与托管。

软件架构

• Web应用：应用只需加载一次，之后各界面通过REST/JSON交互动态渲染（单页应用）。
• CouchDB作为主数据库。
• Redis作为应用端同步和日志所用的数据库。
• TypeScript用于界面（webapp）。
• Node.js / Express后端，负责协调内部引擎（api、webapp、portal、panel、ical、mcp、oauth2等）。
• **C++**用于生成算法，运行在按需启动的专用虚拟机上。

安全

• 对外通信使用HTTPS。
• Cloudflare作为唯一入口（防DDoS保护）。
• 密码先在客户端用scrypt预哈希，再在服务器端重新哈希并加盐。密码不会以明文存储或传输。
• JWT认证，签名密钥与较短的有效期配合使用；密钥轮换或吊销可使已签名的令牌失效。
• 已签名、会过期的分享链接，绑定生成它的账户，并会因该账户修改密码或被停用而失效。
• 带有根密钥和派生令牌、接口范围和有效期的API令牌。
• OIDC / 单点登录，视合同和账户设置而定。
• JSON导出和内部备份，保证数据可迁出。

用户角色

Omniscol在学校一侧区分多种角色：

这些名称与角色技术标识之间的对应关系，详见用户与角色。

同一位用户可以同时拥有多个角色。例如，参与排课的教师可以同时是教师和管理员。

“分享链接”角色并不对应普通的用户账户。它指的是签名链接：课表的网页链接是只读的，而某些定向链接可以允许有限的操作，例如在到期日之前填写某位教师的可用时间。

此外，还有一些内部角色仅限Omniscol团队使用：平台管理、翻译、销售和分销合作伙伴。其中部分账户出于维护的需要，可以登录学校的账户。此时他们以该学校超级管理员的身份操作，权限高于管理员：向数据库导入原始数据、启用或停用付费选项、以某位用户的名义登录。这些访问会触发可见的登录提醒，且其令牌很快过期。权力越大，责任越大。

模块

标准账户中可见的模块：

• 主页（home）——入口页面和当日概览。
• 课表（schedules）——查看和临时调整。
• 仪表盘（dashboard）——教室使用率和服务时间的统计。
• 缺勤管理（absences）——缺勤申报和代课。
• 课表管理（timetables）——课表的构建、生成和发布。
• 管理（admin）——用户、设置、导入/导出和集成。

视合同而定，还可能出现其他模块，尤其是用于学生管理和值守任务规划的**人员调度**。

多学校

每所学校在服务器端逻辑隔离，并访问自己的域名。一所学校的数据在应用中对其他学校不可见。不过，经申请可以在不同账户之间启用通信通道，共享教室和教师的占用冲突。这对共用楼宇的学校，或共享资源的学校集团非常有用。