Campos customizados¶
Na instalação (db/install.php) e em toda atualização (db/upgrade.php), o plugin chama
tool_sga_migrate() (db/migrate.php), que cria tabelas auxiliares e reaplica o mesmo
conjunto de categorias/campos customizados de curso e de usuário — a mesma lógica idempotente
de get_or_create() usada por auth_suap para campos de perfil é reaproveitada aqui via
locallib.php.
Campos de curso¶
sga_bulk_course_custom_field() cria, via core_course (área course), as seguintes
categorias de campo customizado de curso:
Categoria |
Campos (shortname) |
|---|---|
Campus |
|
Curso |
|
Disciplina/Componente curricular |
|
Turma |
|
Diário |
|
Aberto |
|
Integrador AVA |
|
Painel AVA |
|
Campos de usuário¶
sga_bulk_user_custom_field() cria uma única categoria de campo de perfil de usuário,
SGA, com os campos:
Campo (shortname) |
Descrição |
|---|---|
|
E-mail @escolar (Google Classroom) |
|
E-mail @academico (Microsoft) |
|
Secundário (servidores) |
|
Dados do campus |
|
Dados do curso |
|
Dados da última turma |
|
Dados do polo |
|
Período de ingresso |
|
Variações do nome do usuário |
|
Tipo de usuário |
|
Nome do programa |
|
JSON do último login ( |
Note
Este conjunto de campos de usuário tem sobreposição parcial com os campos criados por
auth_suap (outro plugin da mesma suíte, com sua própria categoria de campos de perfil).
Como ambos os plugins usam get_or_create() por shortname (não por categoria), se
ambos estiverem instalados no mesmo Moodle, o primeiro a rodar a instalação/upgrade “vence”
a definição do campo (categoria, tipo, visibilidade); o segundo apenas reaproveita o campo
já existente com o mesmo shortname, sem alterá-lo. Isso não é necessariamente um bug —
pode ser uma convenção deliberada de campos compartilhados entre plugins da suíte — mas não
está documentado explicitamente em nenhum dos dois plugins.
Tabelas de dados¶
tool_sga_migrate() também garante a existência (via dbman->table_exists(), sem
recriação se já existirem) de cinco tabelas:
Tabela |
Uso |
|---|---|
|
Log bruto de cada requisição de Sincronização de envio (SGA → Moodle) recebida ( |
|
Estrutura de trilhas de aprendizagem (nome, descrição, curso, ordenação). Criadas pela
migração, mas nenhum código deste plugin ( |
|
Snapshot de métricas de minicursos autoinstrucionais (matriculados, acessos, aprovados, reprovados, certificados etc.), agrupado por curso/campus/tipo de diário. |
|
Snapshot de restrições de autoinscrição por curso. |
Danger
db/install.xml declara duas tabelas com nomes diferentes dos que
tool_sga_migrate() efetivamente cria: tool_sga_relatorio_cursos_autoinstrucionais
(com prefixo tool_, campo timecreated) e tool_sga_restricoes_autoinscricao, em
vez de sga_relatorio_cursos_autoinstrucionais (sem o prefixo tool_, campo
timegenerated em vez de timecreated) e sga_restricoes_autoinscricao, criadas por
migrate.php. Como o Moodle processa install.xml automaticamente na instalação
(antes de chamar xmldb_tool_sga_install()), o resultado provável é que as duas
tabelas com prefixo ``tool_`` são criadas e nunca usadas por nenhum código deste plugin,
enquanto as tabelas sem o prefixo (efetivamente usadas, embora nenhum código de leitura
delas tenha sido encontrado nesta revisão) são criadas separadamente por migrate.php.
Isso resulta em quatro tabelas para duas necessidades de dados. Não foi possível confirmar
isso em uma instalação real; registra-se aqui como fica no código-fonte hoje, sem alterá-lo.