Custom fields¶
On install (db/install.php) and on every upgrade (db/upgrade.php), the plugin calls
tool_sga_migrate() (db/migrate.php), which creates auxiliary tables and reapplies the
same set of course and user custom field categories/fields — the same idempotent
get_or_create() logic used by auth_suap for profile fields is reused here via
locallib.php.
Course fields¶
sga_bulk_course_custom_field() creates, via core_course (course area), the
following course custom field categories:
Category |
Fields (shortname) |
|---|---|
Campus |
|
Course |
|
Subject/Curricular component |
|
Class |
|
Diário (register) |
|
Open |
|
Integrador AVA |
|
Painel AVA |
|
User fields¶
sga_bulk_user_custom_field() creates a single user profile field category, SGA,
with the fields:
Field (shortname) |
Description |
|---|---|
|
@escolar e-mail (Google Classroom) |
|
@academico e-mail (Microsoft) |
|
Secondary e-mail (staff) |
|
Campus data |
|
Course data |
|
Latest class data |
|
Hub ( |
|
Admission period |
|
Variations of the user’s name |
|
User type |
|
Program name |
|
JSON of the last login ( |
Note
This set of user fields partially overlaps with the fields created by auth_suap
(another plugin in the same suite, with its own profile field category). Since both plugins
use get_or_create() by shortname (not by category), if both are installed on the
same Moodle instance, whichever runs its install/upgrade first “wins” the field definition
(category, type, visibility); the second one simply reuses the already-existing field with
the same shortname, without changing it. This is not necessarily a bug — it could be a
deliberate convention of fields shared between plugins in the suite — but it is not
explicitly documented in either plugin.
Data tables¶
tool_sga_migrate() also ensures the existence (via dbman->table_exists(), without
recreating them if they already exist) of five tables:
Table |
Use |
|---|---|
|
Raw log of every Upload synchronization (SGA → Moodle) request received ( |
|
Learning path structure (name, description, course, ordering). Created by the
migration, but no code in this plugin ( |
|
Snapshot of metrics for self-paced mini-courses (enrolled, accesses, passed, failed, certificates etc.), grouped by course/campus/class type. |
|
Snapshot of self-enrolment restrictions per course. |
Danger
db/install.xml declares two tables with different names from the ones
tool_sga_migrate() actually creates: tool_sga_relatorio_cursos_autoinstrucionais
(with the tool_ prefix, timecreated field) and tool_sga_restricoes_autoinscricao,
instead of sga_relatorio_cursos_autoinstrucionais (without the tool_ prefix,
timegenerated field instead of timecreated) and sga_restricoes_autoinscricao,
which are created by migrate.php. Since Moodle processes install.xml automatically
on install (before calling xmldb_tool_sga_install()), the likely result is that the
two tables with the ``tool_`` prefix are created and never used by any code in this
plugin, while the tables without the prefix (actually used, although no reading code for
them was found during this review) are created separately by migrate.php. This results
in four tables for two data needs. This could not be confirmed on a real installation; it is
recorded here as the source code stands today, without modifying it.