OneRoster (1.2 e grupos avançados)

O OneRoster é um padrão internacional de troca de listas escolares (publicado pela 1EdTech): descreve, num formato comum, as organizações, os anos letivos, os cursos, as turmas, as matrículas e os utilizadores de uma escola. Serve para ligar um SIS, um ENT ou um LMS a outra ferramenta sem reintrodução de dados nem formato proprietário.

Esta página destina-se à direção dos sistemas de informação (a SI) da instituição. Descreve o que o Omniscol expõe e consome em OneRoster, a autenticação esperada, e o âmbito real de cada sentido de troca.

Versões suportadas

O Omniscol suporta o OneRoster 1.2 Rostering — a base (Org, AcademicSession, Course, Class, Enrollment, User, Demographics) — bem como a camada OR-Groups (Advanced Groups Service), o padrão de grupos aditivo que acrescenta três entidades (Group, GroupMembership, GroupAssociation) por cima da 1.2.

A camada OR-Groups é um padrão em curso de publicação. É estritamente aditiva sobre a 1.2: um Group apenas referencia as entidades Class / User / Org / AcademicSession da 1.2, em somente leitura. A versão 1.3 do OneRoster está anunciada para tornar Class uma especialização de Group — orientação com a qual a implementação do Omniscol já converge.

Omniscol produtor (Omniscol → ENT / LMS)

Como produtor, o Omniscol expõe a lista da instituição em somente leitura, via uma API REST conforme com OneRoster, para que um ENT ou um LMS a leia.

• A base Rostering 1.2 é servida em /ims/oneroster/rostering/v1p2/… (por exemplo /orgs, /schools, /academicSessions, /courses, /classes, /enrollments, /users, /teachers, /students, /demographics, cada um com as suas variantes aninhadas).
• A camada de grupos é servida em /ims/oneroster/groups/v1p0/… (/groups, /groupMemberships, /groupAssociations e as suas variantes aninhadas).
• O âmbito é o ano letivo atual por defeito; um parâmetro permite visar outro ano ou cobrir todos os anos.

Os dados refletem o planeamento consolidado do Omniscol (horários ativos / publicados). O produtor é somente leitura por opção: nenhuma escrita (PUT / DELETE) é exposta — um sistema remoto não comanda a criação ou a eliminação de entidades no Omniscol.

Autenticação do produtor

Os pontos de acesso do produtor são protegidos por OAuth2 no fluxo client_credentials (token de máquina a máquina, sem utilizador), emitido pelo servidor OAuth2 do Omniscol. Não estão reservados às contas Premium: o acesso é controlado pelos scopes OAuth2, não pela oferta. Cada scope é específico de um serviço, e o acesso aos dados demográficos está compartimentado dentro da 1.2:

Um token OR-Groups não dá acesso à base Rostering, e reciprocamente. Nenhum scope de escrita é anunciado. Os scopes privilegiados são atribuídos pela administração Omniscol no momento do registo do cliente OAuth2; um cliente não pode autoatribuí-los. A gestão dos clientes OAuth2 e dos tokens é descrita em OAuth2 / OIDC (provedor) e API Omniscol.

O âmbito dos alunos é conduzido pela camada de grupos

Escolha estruturante: a lista dos alunos de uma turma ou de um grupo é exposta via OR-Groups (GroupMembership), não pela base 1.2 sozinha. Um consumidor que apenas lê a Rostering 1.2 obtém o catálogo (Courses, Classes), as matrículas professor → curso e a lista dos utilizadores, mas não a pertença dos alunos. Para saber quem está em que turma ou em que grupo, o consumidor deve implementar a camada OR-Groups. Esta escolha reflete o modelo francês: um aluno está matriculado numa turma ou num grupo, e não disciplina por disciplina.

O produtor expõe-se em REST. O formato bundle CSV OneRoster (arquivo zip de um ficheiro por coleção), por sua vez, é suportado no lado da importação, para os fornecedores que entregam a sua lista por ficheiro em vez de por API — veja a seção do consumidor abaixo.

Omniscol consumidor (SIS → Omniscol)

Perfil francês (ensino escolar)

O perfil francês para o ensino escolar faz corresponder as noções francesas com o modelo OneRoster: uma divisão de turma (a turma no sentido efetivo) torna-se um Group do tipo organizacional principal; um grupo torna-se um Group de difusão pedagógica; um grupo de grupos um Group transversal; as partições e os alinhamentos tornam-se associações de grupos; uma afetação de um professor a um curso torna-se uma matrícula de professor. Os identificadores como o INE ou o identificador do agente são transportados nos userIds do utilizador.

Identificadores e confidencialidade

Cada entidade exposta transporta um identificador estável, o sourcedId.

• Os identificadores estruturais (instituição, ano, curso, turma, grupo) são estáveis e imutáveis de uma exportação para a outra: um consumidor pode confiar neles para correlacionar os dados ao longo do tempo.
• O identificador do utilizador é anonimizado: o Omniscol nunca coloca o seu próprio identificador nominativo no fio. O token colocado no fio é derivado por uma função de sentido único (HMAC) própria da conta; as matrículas e as pertenças reutilizam este token sem nunca expor o identificador de origem.

Estado

• Produtor — disponível e demonstrável sem parceiro remoto (a exportação basta-se a si mesma). Rostering 1.2 e a camada OR-Groups são servidos em somente leitura, com autenticação OAuth2.
• Consumidor — a configuração de importação faz parte da sincronização Premium. A colocação em serviço de uma sincronização ao vivo com um SIS depende do fornecedor e, se aplicável, dos calendários ministeriais: é definida sob pedido, conector a conector. Não se trata de uma sincronização chave na mão imediata.