Glossário¶
Geração automática
Este arquivo é gerado automaticamente a partir do catálogo canônico .vigim/ddd/terms/terms.yaml.
Legenda de Status¶
| Status | Descrição |
|---|---|
| RASCUNHO | Termo em rascunho ou revisão inicial. |
| REVISÃO | Termo aguardando validação. |
| EM DESUSO | Termo em desuso, substituído por outro. |
| REMOVIDO | Termo removido da metodologia. |
Tabela de Siglas¶
| Sigla | Termo |
|---|---|
| DTO | DTO |
A¶
Abandoned¶
Maximum retries reached.
Accepted¶
Nomination accepted by the nominee.
Accepted¶
Invite accepted, membership created.
Access Blocked¶
Access blocked due to payment default.
Access Capability¶
Moodle capability that controls report visibility.
Access Counter¶
Total number of accesses to the file.
Access Grant¶
Operational access right granted, blocked, suspended or revoked. Always linked to an order_transaction.
- Ver também: Grant Status, Order Transaction
Access Granted¶
Access granted.
Access Level¶
Access level for the file.
Access Policy¶
Form access policy. Defines who can submit.
Access Reactivated¶
Access reactivated after regularization.
Access Revoked¶
Access revoked (permanent cancellation).
Access Scope¶
Video access scope: authorized courses and categories.
Access Status¶
Match users by access flags: never accessed, has accessed, never modified since creation.
Access Target¶
Access target: course or course group (by ID).
Access Variation¶
Complementary access variation: password, token, or invitation.
Account Auto Created¶
Moodle account automatically created for buyer.
Action Execution¶
Created when a workflow action is dispatched. Tracks the full lifecycle: pending -> running -> succeeded/failed/skipped. Stores input payload and output result as JSON for audit trail. Business rules: - Executions are append-only (immutable after creation, status updates via new record or field update). - triggerid is null for manual dispatches (no trigger involved). - payload_json captures what was passed to the action. - result_json captures what the action returned (success data or error details). - Failed executions include error details in result_json. - Skipped executions occur when a guard condition is not met. - Retention: cleaned by clean_audit_logs_command per audit_retention_days setting. FK: actionid -> workflow_action.id, triggerid -> action_trigger.id (nullable).
- Ver também: Workflow Action, Action Trigger, Execution Payload
Action Execution Completed¶
Signal emitted by the workflow engine after an action execution transitions to a terminal state. Consumers use this event for audit dashboards, retry scheduling (on failure), and chaining dependent actions. Payload: action_id, execution_id, trigger_id (nullable), status, duration_ms, timestamp. Consumers: - Audit trail records execution outcome for compliance. - Retry scheduler can re-dispatch failed actions (configurable per action_type). - Action chaining: downstream actions can listen for specific upstream completions. Not emitted for pending or running states — only terminal states.
- Ver também: Workflow Action, Action Execution, Execution Status
Action Trigger¶
Links an event source to a workflow action. When the trigger condition fires, the engine dispatches the parent action with the trigger's payload. Business rules: - trigger_type determines what activates the trigger (form_submission, event_signal, schedule, etc.). - config_json holds trigger-specific configuration (e.g., event_class for event_signal, cron for schedule). - priority controls evaluation order when multiple triggers fire simultaneously (lower = first). - Multiple triggers per action are OR-joined: any trigger activates the action. - Deleting a trigger does not affect past executions. FK: actionid -> workflow_action.id.
- Ver também: Trigger Config, Workflow Action
Action Type¶
Defines what kind of operation the action performs. Core provides 6 built-in types; extensions register additional types via the extend_workflow_actions hook. Built-in types: - create_item: creates a MIDDAG item (used by customform post-submission). - send_message: sends a Moodle notification or external message. - emit_document: triggers docbuilder document emission. - call_webhook: makes an outbound HTTP call to an external URL. - assign_role: assigns a Moodle role to a user in a context. - enrol_user: enrols a user in a course. Each type determines which payload fields are valid and how execute() behaves.
Active¶
Report published and visible.
Active¶
Rule active, triggers enabled for firing.
Active¶
File is active and accessible via permanent URL.
Active¶
Video is active and available for referencing.
Active¶
Template activated and available for emission.
Active¶
Access active and valid.
Active¶
Active endpoint receiving deliveries.
Active¶
Active snippet, injected into pages within scope.
Active¶
Active study plan in execution.
Active¶
Job role available for assignment to members.
Active¶
Active mapping, synchronization enabled.
Active¶
Active membership, user associated with the node.
Activity¶
Recent activity feed tab showing extension actions with type, severity and metadata.
Activity Feed¶
Entry in the recent activity feed published by extensions. Belongs to the framework domain, consumed centrally by the dashboard.
Activity Feed Trackable¶
Contract that entities implement to declare they contribute events to the activity feed. Defines get_activity_type() and get_activity_data() for the activity_feed aggregate to consume.
- Ver também: Activity Feed
Adapter¶
Isolates Moodle dependencies from the rest of the framework. Every Moodle call goes through the framework/moodle/ boundary. May or may not implement a contract, depending on the need for substitution.
- Referências:
- ADR-201, ADR-202
Adapter Type¶
Moodle certificate module associated with the template for document generation.
Add Criteria¶
Creates a new segment_criteria child for the given segment. Validates config_json against the criteria_type schema via the corresponding criteria_provider_interface. Assigns sort_order (appended at end by default). Invalidates the parent segment's cached evaluation result.
Add Group Item¶
Creates a group_item linking a MIDDAG item to the instance group. Sets sort_order based on existing items. If the group principal_selection strategy is latest, the new item automatically becomes principal. Dispatches Principal Item Changed if the principal changes.
- Ver também: Group Item, Principal Item Changed
Adherence Score¶
Student adherence percentage to the plan: on-time goals divided by total goals.
Admin Dashboard¶
Multi-tab interface rendered by admin_controller. Each tab exposes a different administrative concern: home (React DashboardHome component with news and health), status (system checks and environment), tools (maintenance actions), activity (recent activity feed), logs (framework log viewer), jobs (async job monitor) and audit (audit trail viewer). JSON endpoints provide health score and license info for the home widget. Routes: - /admin/home — Home tab (DashboardHome React component) - /admin/status — System status (Mustache template) - /admin/tools — Admin tools (Mustache template) - /admin/activity — Activity feed (Mustache template) - /admin/logs — Log viewer - /admin/jobs — Job monitor - /admin/audit — Audit log viewer - /admin/dashboard/health — JSON health score endpoint - /admin/dashboard/license — JSON license info endpoint
- Ver também: Dashboard Tab, Health Score, System Status, Activity Feed, Audit and Traceability
Admin Dashboard Tab¶
Navigation tab within the admin dashboard. Each tab maps to a controller action and renders a distinct administrative view.
Admin Setting¶
A single setting definition within a Settings Page. Uses the typed DSL to declare type, label, description, default value and validation. The settings_resolver maps each definition to the appropriate Moodle admin_setting_* class (e.g., text -> admin_setting_configtext, select -> admin_setting_configselect). Config keys follow the convention mdg_{extension}_{name} to avoid collisions across extensions. Business rules: - Each setting belongs to exactly one Settings Page. - The setting type determines which DSL class to use (text, checkbox, select, etc.). - Options can be static (array) or lazy-loaded (resolved at render time via config_schema_interface). - The default value is used when no config value is stored. - Settings are accessed at runtime via settings_support::get(BackedEnum).
- Ver também: Setting Type, Config Schema, framework/moodle/settings/setting.php
Admin Tool¶
Administrative maintenance action available in the tools tab. Each tool performs a diagnostic or cleanup operation and returns a Tool Result.
- Ver também: Tool Result, Maintenance Tool
After¶
Timestamp is after the given date.
Aggregate Signal¶
Contract for domain signals scoped to an aggregate and item type. Enables hierarchical dispatch where subscribers listen by aggregate, type or action. Extends Symfony EventDispatcher.
-
Ver também: Signal, Dispatcher
-
Referências:
- ADR-701
All¶
Every criteria must match (AND composition). Default.
Allocation Cancelled¶
Allocation manually cancelled.
Allocation Created¶
Allocation created from B2B purchase.
Allocation Expired¶
Allocation expired per offering policy.
Allocation Nominated¶
Person nominated to consume allocation.
Allocation Nomination¶
Nomination of a person to consume a B2B allocation. Tracks nomination status through consumption or rejection.
Allocation Status¶
B2B allocation status in the slot lifecycle.
- Ver também: B2B Allocation
Allocation Used¶
Allocation consumed (access granted).
Analytics (analytics)¶
Data and analytics: BigQuery export, Looker Studio integration and BI dashboards.
Any¶
At least one criteria must match (OR composition).
Approved¶
Payment approved.
Archived¶
Rule archived, cannot be reactivated.
Archived¶
File is archived; URL returns 404 but file remains in the system.
Archived¶
Video is archived; references return an unavailability fallback.
Archived¶
Template archived, no new emissions allowed.
Archived¶
Snippet archived, not available for activation.
Archived¶
Archived plan, no active tracking.
Assign Role¶
Assign a Moodle role to user in context.
Attempt Result¶
HTTP status code, response body (truncated) and timestamp of an attempt.
Audit¶
Audit trail viewer tab showing who did what, when and where on audited entities.
Audit¶
Aggregate root of the traceability subsystem. Each audit record captures: actor (user ID), action (create, update, delete, custom), subject type and ID, timestamp and optional metadata. Child entities store field-level diffs (Audit Diff) and full state snapshots (Audit Snapshot). Records are created automatically by signal subscribers when auditable entities change. Retention is configurable via audit_retention_days setting (default: 90). Cleanup runs via clean_audit_logs_command. Persistence: middag_audit_log (root), middag_audit_diff (diffs), middag_audit_snapshot (snapshots). Domain: framework/domain/audit/. Contracts: audit_service_interface, audit_log_repository_interface, audit_diff_repository_interface.
-
Ver também: Signal, Audit Diff, Audit Snapshot, Clean Audit Logs
-
Referências:
- ADR-505, ADR-503
Audit Actor¶
Actor responsible for the decision or transition in the enrolment lifecycle. Preserves traceability.
Audit and Traceability¶
Core subsystem that provides automated traceability for entity lifecycle events. Signal subscribers capture create/update/delete operations and persist audit records with actor, action, field-level diffs and full state snapshots. The admin dashboard exposes an audit tab for browsing and filtering audit history. Retention is policy-driven and enforced by the clean_audit_logs_command scheduled task. Components: audit_log_service (recording), audit_query_service (reading), audit_api_controller (REST).
- Ver também: Audit, Signal, Admin Dashboard
Audit Diff¶
Immutable value object that records the change of a specific field between two states. Persists in middag_audit_diff. Contains field_name, old_value and new_value.
- Referências:
- ADR-505, ADR-503
Audit Filter¶
Readonly value object encapsulating optional filter parameters: extension, eventname, subjecttype, date_from, date_to, search. Used by audit_query_service::list() and audit_api_controller. Factory: from_array(array). to_array() filters null values. Note: audit_log and audit_diff entities live in framework/domain/audit/ — this VO is specific to the admin query interface.
Audit Query Service¶
Domain service for querying audit logs with filtering, pagination and detail lookup in the admin audit tab.
- Ver também: Audit Filter
Audit Snapshot¶
Immutable value object that captures the complete state of a subject at the time of the audit event. Persists in middag_audit_snapshot. Payload serialized in configurable format.
- Referências:
- ADR-505, ADR-503
Auth Config¶
Authentication type and credentials: Bearer token or HMAC-SHA256 shared secret.
Authenticated¶
File accessible only to authenticated users.
Authenticated¶
Form accessible only to authenticated users.
Authentication and Security¶
Core subsystem responsible for user authentication and session management within MIDDAG. Provides auth_service (login, token validation, session handling) and auth_controller (authentication routes). Wraps Moodle authentication APIs behind framework contracts. Supports configurable auth type selection via admin settings. Extensions can consume authentication_interface and capability_interface without direct Moodle coupling. Components: auth_service, auth_controller, authentication_interface, capability_interface.
- Ver também: Adapter, Authorizer
Authorizer¶
Implements authorizer_interface encapsulating permission and Moodle context checks. Allows services and extensions to inject authorization via DI without depending on static calls.
-
Ver também: Adapter
-
Referências:
- ADR-301
Autocomplete¶
Searchable input with AJAX-backed option lookup.
Automessage (automessage)¶
Intelligent communication: automated pipelines, triggers, templates and multichannel sending queues.
Available¶
Allocation available for nomination.
Awaiting Response¶
Ticket awaiting response from the student or requester.
B¶
B2B Allocation¶
Auditable reservation of a unit purchased in B2B mode. Each slot is individually auditable with expiration policy per offering.
- Ver também: Allocation Nomination, Allocation Status, Nomination Status, Order Transaction
Batch Completed¶
Batch processing completed, fully or partially.
Batch Started¶
Batch emission processing started.
Batch Status¶
Aggregated status of batch emission processing.
Batch Target¶
Individual batch target: user and emission result.
Before¶
Timestamp is before the given date.
Between¶
Timestamp falls within a date range (inclusive).
Block¶
Visual block component (Moodle block) managed and registered by the framework.
- Referências:
- ADR-308
Blocked¶
Delivery blocked by throttle or condition.
Blocked¶
Access blocked due to payment default.
Blocking Level¶
Blocking level of the compliance policy. Combinable values: total, course, certificate.
Bridge Correlation¶
Correlation identifiers between the enrolment domain and the enrol_middag technical bridge.
Bridge Execution¶
Technical call to enrol_middag with correlation, authorship and return. Records each execution of the enrolment bridge.
Build Segment Subquery¶
Produces a segment_subquery value object containing a SQL fragment, bind parameters, and estimated row count. The subquery can be embedded in automessage targeting, bulk enrolment cleanup, or any consumer that needs to filter users by audience. This is the core performance optimization: segments return subqueries, not user lists. Delegates SQL fragment generation to criteria_provider_interface::build_sql() per criteria. Composes fragments via AND (match_type=all) or OR (match_type=any).
Bulk¶
Cleaning of multiple users via selection or segment.
C¶
Cache Config¶
Widget cache configuration: TTL and pre-computation via cron.
Cache Entry¶
Cached data, timestamp, and status of a cache entry.
Cached Item Repository¶
Decorator over item_repository that adds MUC (Moodle Universal Cache) caching without modifying the base repository. Implements the same item_repository_interface.
-
Ver também: Repository
-
Referências:
- ADR-303
Calculate Health Score¶
Evaluate all 7 criteria and aggregate into a single health score.
Call Webhook¶
Make an outbound HTTP call to an external URL.
Cancel Job¶
Cancel a pending or running job.
Cancelled¶
Allocation manually cancelled.
Cancelled¶
Transaction cancelled or refunded.
Cancelled¶
Cycle closed by explicit cancellation.
Cancelled¶
Invite cancelled before acceptance.
Capability¶
File accessible only to users with a specific capability.
Category¶
Filter by Moodle course category ID.
Certificate¶
Adapter for the mod_certificate module.
Certificate Block¶
Prevents certificate issuance until compliance is met.
Certificate Metadata¶
Preserved certificate metadata: name, issuance date, issuing module and validation code.
Certificate Snapshot¶
Certificate copy preserved before cleaning: PDF and structured metadata.
Channel Set¶
Selected delivery channels: email, notification, message, webhook, whatsapp, sms.
Check DB¶
Verify all required MIDDAG database tables exist.
Check License¶
Verify license status against MIDDAG account server.
Check License¶
Scheduled command that verifies license validity against the MIDDAG account server and updates local license status.
- Ver também: License Manager
Check News Availability¶
Check if the news endpoint setting is configured.
Check Result¶
Individual verification result: field, found value, applied regex and pass/fail outcome.
Checkbox¶
Boolean toggle.
Clean Activity Feed¶
Scheduled command that removes activity feed entries older than configured retention days (setting: activity_retention_days, default: 90).
- Ver também: Activity Feed
Clean Audit Logs¶
Scheduled command that purges audit records older than configured retention days (setting: audit_retention_days, default: 90).
- Ver também: Audit
Clean Logs¶
Delete log files older than configured retention period.
Clean Logs¶
Scheduled command that removes framework log entries older than configured retention days (setting: log_retention_days, default: 30).
Clean Test Data¶
Remove all seeded test data across audit, activity, jobs and log files.
Clean Test Data¶
Remove all seeded test data from audit, activity, jobs and log files.
Cleaning Action Log¶
Detailed trail of actions executed during a cleaning operation. Audit record.
Cleaning Operation¶
Academic cleaning operation: controlled reset of user progress in courses. Records type, preset, targets, status and audit trail.
- Ver também: Cleaning Target, Cleaning Action Log, Cleaning Options, Cleaning Preset, Operation Type, Operation Status
Cleaning Options¶
Combination of the 12 cleaning options selected for a specific operation.
Cleaning Preset¶
Predefined combination of cleaning options. Classifies the selected operation mode.
Cleaning Snapshot¶
Pre-cleaning record of academic state and, optionally, the certificate. Audit snapshot, not a restoration mechanism.
- Ver também: Certificate Snapshot, Certificate Metadata
Cleaning Target¶
Cleaning target: user and course or batch of users selected for progress reset.
Closed¶
Ticket permanently closed.
Cohort ID¶
Cohort ID in the current context.
Cohort Mapping¶
Mapping between organizational unit and Moodle cohort with default job role and membership period.
Cohort Mapping Created¶
Event emitted when a unit-cohort mapping is created with defaults.
Cohort Mapping Disabled¶
Event emitted when a unit-cohort mapping is disabled.
Cohort Membership¶
Match users belonging to one or more Moodle cohorts.
Cohort Sync¶
Membership created automatically by synchronization with Moodle cohort.
Collect System Status¶
Collect environment information across 9 sections for the admin status tab.
Colour Picker¶
Colour selection control with hex value.
Command¶
Serializable work unit independent of the executor, encapsulating the intent of an asynchronous or reusable operation. Used when there is real benefit in reuse, deferral or retry.
-
Ver também: Job
-
Referências:
- ADR-705
Command Bus¶
Central dispatch mechanism for the command pattern (ADR-705). Receives a command_interface object, resolves the corresponding handler class by naming convention, and invokes it. Two dispatch modes: dispatch() for synchronous execution, dispatch_async() for serialization and execution via Moodle adhoc task. The command_bus_interface is an @api contract consumed by extensions to decouple intent from execution. Contract: command_bus_interface in framework/contract/.
Completed¶
Job completed successfully.
Completed¶
Batch completed successfully.
Completed¶
Course completed and validity window started.
Completed¶
Operation completed successfully.
Completed¶
Goal completed within the deadline.
Completed¶
All plan goals completed.
Completed¶
All required steps completed.
Completion Reset¶
Removes only the completion status — learner retakes mandatory activities.
Completion Resolution¶
Produced by instancegroup_interface::resolve_completion(). Captures the evaluation result including which item satisfied the completion requirement and when the evaluation occurred. Business rules: - Completion is evaluated on-demand, not cached (depends on Moodle completion state). - If ANY active item in the group is completed by the user, is_completed=true. - completed_item_id identifies which specific item was completed (first match). - If no items are completed, is_completed=false and completed_item_id=null. - Learningpath uses this to determine stage progression. PHP: readonly value object. Immutable after construction.
Completion Timestamp¶
Timestamp of when the step was completed by the student.
Compliance (CC-08)¶
Core capability that verifies whether the user profile meets mandatory requirements. Extensions implement compliance_interface to block actions when requirements are not met (e.g., enrolment blocks enrollment if documentation is incomplete, docbuilder blocks emission if mandatory data is missing). Graceful degradation: when no provider is registered, the user is considered compliant. Contract: compliance_interface in framework/contract/.
- Ver também: Enrolment (enrolment), Document Builder (docbuilder)
Compliance Check Log¶
Immutable compliance verification record. Preserves field, value, regex and result.
Compliance Deferral¶
Temporary deferral granted to a user for compliance with the profile required by the policy.
Compliance Policy¶
Set of profile validation rules applicable to a global or per-course context. Defines blocking level, deferral and organizational scope.
- Ver também: Compliance Rule, Blocking Level, Field Reference, Validation Pattern, Policy Scope, Deferral Period
Compliance Rule¶
Compliance rule: profile field, validation regex and mandatory flag.
Compliance Status¶
User compliance status. Derived from evaluating rules against the profile.
Compliant¶
User meets all policy rules.
Condition¶
A condition defines where a feature applies on the Moodle site. Each condition is owned by an extension instance (e.g., a snippet, a marketing rule) and contains one or more condition groups composed via AND logic. Attributes: - fullname (string): human-readable condition name. - description (string, nullable): narrative description. - enabled (bool): whether this condition is active. - owner_type (string): the item_type of the owning entity (e.g., 'snippet', 'seo_rule'). - owner_id (int): the ID of the owning entity. Business rules: - A condition with no groups matches all contexts (graceful degradation). - Groups within a condition are AND-composed: all groups must match. - Within each group, rules are OR-composed: at least one rule must match. - Disabling a condition makes it match all contexts (same as no condition). - Deleting the owner cascades deletion of the condition and its groups. Persistence: EAV via middag_items (type: condition) + middag_itemmeta. Contract: conditions_interface in framework/contract/.
- Ver também: Condition Group, Condition Scope, Condition Match Mode
Condition Evaluation¶
Evaluates a set of condition rules against a Moodle context (category, course, module, page). Rules are AND-composed: the context must satisfy ALL rules to match. Each rule checks scope + match_mode + target IDs/types. Used by integrations/snippets and content/marketing to determine where to apply their features.
Condition Group¶
Groups organize rules within a condition. Each group has a scope (category, course, module, page, system) and a match mode (include or exclude). Groups are AND-composed within their parent condition; rules within a group are OR-composed. Attributes: - condition_id (int): FK to parent Condition. - scope (condition_scope): what level this group targets. - match_mode (condition_match_mode): include or exclude logic. - values (array): target IDs (category_ids, course_ids) or type names (module types, page identifiers). - sort_order (int): ordering within the condition. Business rules: - A group with scope=category and match_mode=include targets ONLY listed categories. - A group with scope=module and match_mode=exclude targets everything EXCEPT listed module types. - An empty values array in a group means "all" for that scope (no restriction). - Groups with scope=system always match — used as an explicit "apply everywhere" marker. Persistence: EAV via middag_items (type: condition_group, parent: condition) + middag_itemmeta.
- Ver também: Condition Scope, Condition Match Mode
Condition Match Mode¶
Controls the logic of the rule. Include means ONLY listed targets match. Exclude means everything EXCEPT listed targets matches.
Condition Operator¶
Provides 13 operators for conditional field behavior: eq, neq, in, not_in, gt, gte, lt, lte, truthy, falsy, exists, empty, matches. Used in form DSL directives (visible_when, required_when, disabled_when, hidden_when) to control field visibility and validation based on other field values. Operators incompatible with mform (matches, numeric comparisons on string fields) generate a runtime warning and degrade to server-side validation.
- Referências:
- ADR-806
Condition Provider Model¶
Extensibility model for the conditions engine. Extensions implement condition_provider_interface to add custom condition types (e.g., time-based, device-based, AB test). Providers are registered during boot() and the service delegates evaluation to the appropriate provider based on the condition type. The interface defines: - get_type(): string — unique type identifier (e.g., 'time_range', 'device', 'ab_test'). - matches(condition_rule, context): bool — evaluate the condition for a specific context. - get_applicable_context_ids(condition_rule): int[] — resolve matching context IDs. Contract: condition_provider_interface in framework/contract/.
Condition Rule¶
A condition rule defines where something applies in the Moodle site. Used by integrations/snippets (inject code in specific pages) and content/marketing (apply SEO rules by category). Rules compose scope (what to target) + match_mode (include or exclude) + IDs/types. Business rules: - A rule with scope=category and match_mode=include targets only the listed categories. - A rule with scope=module and match_mode=exclude applies everywhere EXCEPT listed module types. - When no rules are configured, all contexts match (graceful degradation). - Multiple rules are AND-composed: context must satisfy ALL rules to match. - The PHP VO condition_rule already exists in framework/contract/ — this term aligns with it. - conditions_interface::matches() evaluates a rule against a Moodle context. PHP: readonly value object (condition_rule.php in framework/contract/).
- Ver também: Condition Scope, Condition Match Mode
Condition Scope¶
Determines the level at which the condition operates. Combined with match_mode and target IDs to form a complete rule. Higher scopes (system) are broader; lower scopes (module) are more specific.
Conditions Graceful Default¶
Design principle for conditions engine: absence of rules means universal applicability. An extension with no condition rules applies everywhere. This prevents silent failures when conditions are not configured and simplifies the default extension setup. The conditions_interface::matches() returns true when the rule set is empty.
Conditions Service¶
Central service for the conditions engine capability. Orchestrates evaluation of conditions against Moodle contexts, manages registered condition providers, and resolves applicable context IDs for a given set of rules. Responsibilities: - Evaluate whether a Moodle context matches a condition rule set. - Return all context IDs matching a rule set (for bulk operations). - Accept and manage condition_provider registrations from extensions. - Delegate evaluation to the appropriate provider when custom condition types are used. Implements conditions_interface. Extensions register condition_provider_interface implementations during boot().
- Ver também: Condition Rule, Condition Scope, Condition Match Mode, Condition
Config Schema¶
Each extension declares its settings as a PHP enum implementing config_schema_interface. Each case defines the setting key, PHP type, default value and available options. Supports lazy options (resolved only during admin UI rendering) for dynamic enumerations that depend on database state.
-
Ver também: Support
-
Referências:
- ADR-311, ADR-312
Configure Connector¶
Operational process that receives credential field values and an endpoint URL, validates them against the connector_type schema, persists encrypted credentials via connector_credential children, and transitions status to configured. Precondition: all required credential_fields must be provided. Postcondition: connector status is configured; previous health check is invalidated.
- Ver também: Credential Field, Connector Credential
Configured¶
Credentials stored but not yet tested.
Connected¶
Last health check passed — service reachable.
Connection Reference¶
Reference to the BigQuery connection registered in CC-02 (connectors).
Connector¶
A connector represents an integration point with an external service (Twilio, WooCommerce, BigQuery, Sentry, etc.). Core manages the connector lifecycle (create, configure, test, disable); extensions register connector types during boot() and consume connectors for their specific domain. Attributes: - fullname (string): human-readable connector name. - description (string, nullable): narrative description. - connector_type (string): type slug from connector_type enum. - endpoint (string, nullable): base URL or connection string. - extension (string): slug of the owning extension. - last_check_at (int, nullable): timestamp of last health check. - last_check_status (string, nullable): result of last health check. Business rules: - Each connector belongs to exactly one extension (via extension field). - Credentials are stored encrypted via connector_credential children. - health_check() tests connectivity and updates connector_status. - Scheduled health checks run via core's check_connectors_command (configurable frequency). - Status transitions: unconfigured -> configured (credentials stored) -> connected (health OK) -> degraded (intermittent) -> disconnected (health failed). Any state -> unconfigured (credentials removed). - Extensions MUST implement connector_interface to register types in the connector_registry. Persistence: EAV via middag_items (type: connector) + middag_itemmeta. Contract: connector_interface + connector_registry_interface in framework/contract/.
- Ver também: Connector Credential, Connector Type, Connector Status, Connector Health Changed, Audit and Traceability, Credential Field, Health Check Result
Connector Binding¶
Operational ecommerce binding for a connection registered in CC-02 (connectors), with capability matrix per provider.
- Ver também: Connector Capability Matrix, Connector Ref
Connector Binding Configured¶
Commercial binding configured and activated.
Connector Capability Matrix¶
Capabilities supported by the external provider: individual, recurring, B2B and events.
Connector Credential¶
Stores a single credential field value for a connector. Each connector type defines which credential fields are required via get_credential_fields(). Values are encrypted using Moodle's encryption API before storage. Attributes: - connector_id (int): FK to parent Connector. - field_key (string): credential field identifier (matches connector_interface::get_credential_fields()). - encrypted_value (string): encrypted credential value. Business rules: - field_key must match one of the keys returned by connector_interface::get_credential_fields(). - encrypted_value is stored via encrypt_data() / decrypt_data() from Moodle core. - Credentials are NEVER exposed in API responses or logs. - Deleting all credentials for a connector resets its status to 'unconfigured'. - Updating a credential invalidates the last health check (status -> configured). FK: connector_id -> connector.id. Persistence: EAV via middag_items (type: connector_credential, parent: connector) + middag_itemmeta.
Connector Credential Validation¶
Guard rule evaluated before Configure Connector. Compares provided credential field keys against connector_interface::get_credential_fields() for the connector type. Fails if any required field is missing or empty. This prevents a connector from transitioning to configured without complete credentials.
Connector Extension Binding¶
Each connector belongs to exactly one extension that registered its connector_type during boot(). The extension is responsible for implementing connector_interface for that type, including health_check(), get_credential_fields() and execute(). The binding is established via the extension field on the connector and cannot be changed after creation. This ensures that the owning extension always controls the connector behavior.
Connector Health Changed¶
Signal emitted by the connector service after a health_check() call results in a status transition (e.g., connected -> degraded, degraded -> disconnected). Consumers use this event for monitoring dashboards, alerting, and automatic retry scheduling. Payload: connector_id, previous_status, new_status, health_check_result, timestamp. Consumers: - Dashboard widget (ConnectorHealthBadge.tsx) refreshes on this event. - Scheduled retry logic can re-enable degraded connectors after successful re-check. - Audit trail records the transition for compliance. Not emitted when health_check() confirms the current status (no transition).
- Ver também: Connector, Connector Status, Health Check Result
Connector Ref¶
Reference to the connection registered in CC-02 (connectors).
Connector Registry¶
Registry that manages available connector types. Extensions register connector implementations during boot() via the connector_registry_interface @api contract.
- Ver também: Connector
Connector Settings¶
Configurable parameters for connector health check scheduling and retry behavior. Settings: connectors_health_check_interval (int, default 3600 = 1h), connectors_max_retries (int, default 3).
Connector Status¶
Reflects the current operational state based on credential configuration and health checks. Transitions: unconfigured -> configured (creds stored) -> connected (health OK) -> degraded (intermittent failures) -> disconnected (health failed). Any -> unconfigured (creds removed). Dashboard aggregates status across all connectors for system health score.
Connector Status Transition¶
Validates that a connector status change follows the allowed transition graph: unconfigured → configured (credentials stored), configured → connected (health OK), connected → degraded (intermittent), degraded → disconnected (consecutive failures), any → unconfigured (credentials removed). Rejects invalid transitions.
Connector Type¶
Determines how the connector communicates with the external service. Core provides 5 built-in types; extensions can register additional types. Built-in types: - http_api: REST/GraphQL via HTTP client (most common). - oauth2: OAuth 2.0 flow with token refresh. - sdk: native PHP SDK provided by the service vendor (e.g., Google Cloud PHP). - webhook: inbound webhook receiver (connector listens for events). - database: direct DB connection for read-only analytics queries. The connector_type determines which credential_fields are required and how health_check works.
Connectors Service¶
Central service for the connectors capability. Orchestrates the full connector lifecycle: creation, credential storage, health check execution, status transitions and registry management. Responsibilities: - CRUD operations on connectors. - Store/retrieve encrypted credentials per connector. - Execute health checks and update connector status based on results. - Manage the connector registry (delegate to connector_registry_interface). - Dispatch Connector Health Changed signals on status transitions. Implements connector_registry_interface for registry operations. Extensions register connector_interface implementations during boot().
- Ver também: Connector, Connector Credential, Connector Status, Health Check Result, Credential Field
Container¶
Dependency injection container based on Symfony ContainerBuilder; official mechanism for creating, resolving and managing the lifecycle of structural framework services.
- Referências:
- ADR-601, ADR-207
Contains¶
Substring match (LIKE %value%).
Content (content)¶
Content management: translation, video library, file repository and SEO/marketing.
Context Override¶
Optional customization of marketing metadata for a specific context (course or category).
Contract¶
Interface that defines an architectural role with real need for DI, substitution or composition. Marked with @api when publicly stable; internal by default when without this annotation.
-
Ver também: Extension (base)
-
Referências:
- ADR-901, ADR-404
Controller¶
Receives Request via http_kernel and validates input via form_request before execution. Delegates business logic to domain services. Specialized traits provide auth checks, Moodle page setup, form rendering and URL generation.
- Referências:
- ADR-801, ADR-803
Core Capability¶
Moodle capabilities defined by the core extension for admin access control.
Count Jobs by Status¶
Return job counts grouped by status for dashboard badges.
Course¶
Filter by specific course ID.
Course¶
Document linked to a course.
Course¶
Data originated from the course.
Course Block¶
Blocks access to the linked course until compliance is met.
Course Certificate¶
Adapter for the mod_coursecertificate module.
Course Completion¶
Match users who completed a specific course.
Course Enrollment¶
Match users enrolled in any course. Boolean check on enrolment existence.
Course Enrolment Policy¶
Business configuration applied per course, offering or logical item to determine validity, expiration and re-entry.
- Ver também: Validity Window
Course ID¶
Course ID in the current context.
Course Role¶
Match users with a specific role in course context. Supports category scope with optional subcategory inclusion.
Create Item¶
Create a MIDDAG item.
Create Segment¶
Creates a new segment entity with the given configuration. Initial status is always draft — the admin must explicitly activate the segment after configuring criteria. Returns the new segment ID. Validates: fullname is required, cache_ttl >= 0, contextid is valid.
Created¶
Job created, awaiting execution.
Created¶
Batch created, awaiting processing.
Credential Field¶
Returned by connector_interface::get_credential_fields(). Describes a single input field for the connector configuration form. The field_type determines the UI component: text (plain input), password (masked), url (with validation), select (dropdown). Business rules: - Each connector_type defines its own set of credential_fields. - required=true fields must be filled before the connector can transition to 'configured'. - The placeholder provides a hint for the input (e.g., "sk-live-xxxx" for an API key). PHP: readonly value object. Immutable after construction.
- Ver também: Connector Credential
Criteria Config¶
Polymorphic config object — the valid fields depend on the parent criteria's criteria_type. Stored as JSON in segment_criteria.config_json. The criteria provider validates the config against the criteria_type schema before persisting. Attributes: - field_name (string, nullable): target field identifier (e.g., 'email', 'firstaccess'). - operator (segment_operator, nullable): comparison operator. - field_value (string, nullable): comparison value. - target_id (int, nullable): reference ID (cohort ID, course ID, role ID). - target_ids (array, nullable): list of reference IDs (multi-select). - category_id (int, nullable): category scope for course_role criteria. - include_subcategories (bool): include subcategories for course_role (default false). - sql_query (string, nullable): raw SQL for custom_sql criteria. - before_value (int, nullable): timestamp for date range upper bound. - after_value (int, nullable): timestamp for date range lower bound. Field mappings by criteria_type: - profile_field: field_name + operator + field_value. - custom_profile_field: field_name + operator + field_value. - date_field: field_name + before_value and/or after_value. - access_status: field_name (neveraccessed, accessed, nevermodified). - cohort_membership: target_ids (cohort IDs). - course_enrollment: (no config, checks any enrollment). - course_role: target_id (role ID) + category_id + include_subcategories. - system_role: target_id (role ID). - course_completion: target_id (course ID). - event_occurrence: field_name (event class name) + operator (is_true/is_false). - custom_sql: sql_query (validated for SELECT-only). PHP: final readonly class with factory method from_json(string).
Criteria Provider Interface¶
Extension point contract in framework/contract/. Extensions implement this interface to add custom criteria types to the segmentation engine. Each provider handles one criteria_type and is responsible for: - Declaring available fields with operators and metadata. - Generating SQL WHERE clauses from criteria_config. - Producing human-readable descriptions for display. - Validating criteria config_json against the type schema. Registration: extensions call the criteria registry in boot() to register their providers. Discovery: segment_service aggregates all providers for field listing and criteria evaluation. PHP: interface criteria_provider_interface in framework/contract/. Methods: get_type(), get_fields(), build_sql(), describe(), validate_config(). Annotation: @api — stable extension contract.
- Ver também: Criteria Type, Segment Field, Criteria Config
Criteria Provider Model¶
Core provides 11 built-in criteria types (profile_field through custom_sql). Extensions can add custom types by implementing criteria_provider_interface and registering in boot() via the segment criteria registry.
Contract: criteria_provider_interface in framework/contract/.
Each provider must implement: - get_type(): string — unique criteria type identifier. - get_fields(): list
- Ver também: Criteria Type, Segment Field
Criteria Type¶
Defines which kinds of rules can compose a segment. Core provides 11 built-in types. Extensions can register additional types via criteria_provider_interface during boot(). Each type determines: - What config_json fields are valid for segment_criteria. - Which operators from segment_operator are available. - How to generate the SQL WHERE clause. - How to produce a human-readable description. Built-in types cover user profile, access, enrollment, cohort, events, and admin-only SQL. The enum is extensible: extensions register new providers, and get_criteria_types() returns all available types (built-in + extension-provided).
Criterion Status¶
Pass/fail status for a single health criterion check.
CSAT Rating¶
Satisfaction rating: scale from 1 to 5 stars.
CSAT Response¶
Satisfaction rating submitted by the student after ticket resolution.
CSAT Submitted¶
Event emitted when a satisfaction rating is submitted by the student.
CSS¶
CSS code.
CSV¶
Membership created via CSV file import.
Custom¶
Custom data, manually defined.
custom¶
Custom extension developed by MIDDAG for a specific client. Distributed in a separate plugin.
Custom Cert¶
Adapter for the mod_customcert module.
Custom Form¶
Form configured by operations with structural mode, fields, access policy, and post-submission actions. Visual or external mode, immutable after creation.
- Ver também: Form Step, Form Field, Post Submit Action, Form Mode, Form Slug, Access Policy, Access Variation, Form Scope, Form Limits, Form Status, Form Logo
Custom Form (customform)¶
Intelligent forms: multi-step forms with dynamic fields, post-submission actions and trackable submissions.
Custom Forms (customform)¶
Extension for data collection and automation via dynamic forms.
Custom Profile Field¶
Match users by Moodle custom profile fields. Dynamically discovers available fields at runtime.
Custom SQL¶
Match users via raw SQL subquery. Restricted to site administrators (Custom SQL Restriction rule).
Custom SQL Restriction¶
Security guard for the custom_sql criteria_type. Raw SQL subqueries can access any data in the database, so they must be restricted to site administrators only. The segment_service::add_criteria() checks the current user's capability before accepting custom_sql criteria. The custom_sql provider validates that the SQL is a SELECT statement (no INSERT, UPDATE, DELETE, DROP, etc.).
D¶
Danger¶
Score < 50. Critical issues.
Dashboard (dashboard)¶
Operational dashboard: multi-extension widgets, contextual filters and consolidated view.
Dashboard Panel¶
Panel configured with widgets and role-based visibility. Controls layout, organizational filter, and widget instance collection.
- Ver também: Widget Instance, Panel Visibility, Organization Filter
Dashboard Widget¶
Extensions implement dashboard_widget_interface to provide widgets that appear in the admin dashboard home tab. Each widget declares its title, position (priority) and rendering logic. The dashboard collects all registered widgets and renders them in the DashboardHome React component. Widgets can return Mustache templates or React component references. Contract: dashboard_widget_interface in framework/contract/.
-
Ver também: Widget, Admin Dashboard
-
Referências:
- ADR-803
Data Resolver¶
Callback for widget data resolution.
Data Seeder Service¶
Domain service for generating test data across extensions. Used in development and testing environments only.
Database¶
Direct database connection (read-only, for analytics).
Date Field¶
Match users by timestamp columns with range operators (before, after, between). Covers: firstaccess, lastaccess, timecreated, timemodified.
Deactivated¶
Form manually deactivated; submissions are preserved.
Deadline¶
Final deadline of the study plan.
Default¶
Product default view.
Defaulted¶
Late payment or default detected.
Deferral Period¶
Deferral period in days configured in the compliance policy.
Deferred¶
Emission deferred due to incomplete profile, awaiting compliance.
Deferred¶
User with active deferral period.
Deferred Emission Processed¶
Deferred emission processed after user became compliant.
Degraded¶
Intermittent failures — service partially available.
Delete Segment¶
Removes the segment entity and all child segment_criteria from persistence. Active segments must be archived first before deletion (prevents accidental removal of in-use segments). Consumers are not notified — they handle missing segments gracefully.
Delivery¶
Record of a payload delivery to an endpoint in response to an event. Tracks attempts with exponential backoff.
- Ver também: Delivery Attempt, Webhook Payload, Delivery Status, Retry Schedule, Webhook Endpoint
Delivery Abandoned¶
Max retries reached.
Delivery Attempt¶
Individual delivery attempt with HTTP status code, response body and timestamp.
Delivery Created¶
Delivery created for processing.
Delivery Failed¶
Attempt failed (retry scheduled).
Delivery Sent¶
Payload delivered successfully.
Delivery Status¶
Delivery status in the webhook lifecycle.
- Ver também: Delivery
Department¶
Support unit with its own queue, assigned agents and SLA configured in hours.
- Ver também: SLA Config
Describe Criteria¶
Delegates to the appropriate criteria_provider_interface::describe() method based on the criteria_type. Returns a segment_criteria_description VO with a localized label (e.g., "Email contains '@example.com'", "Cohort: Managers"). Used in segment display, automessage targeting summaries, and audit logs.
- Ver também: Segment Criteria Description
Description¶
Read-only informational block (no stored value).
Diagnostics and Health¶
Core subsystem that provides system monitoring and health assessment. Includes the health_score_service (aggregated health rating), system_status_service (environment info and configuration checks), and Moodle check definitions for the admin health page. The admin dashboard status tab displays collected diagnostics. Connector health checks (CC-02) feed into the overall health score. Components: health_score_service, system_status_service, check definitions.
- Ver também: Health Score, System Status, Admin Dashboard
Directory¶
Server directory path input with existence check.
Disable Connector¶
Administrative process that sets connector enabled=false. Optionally clears all connector_credential children, resetting status to unconfigured. A disabled connector is invisible to consumer extensions but preserved for audit.
Disabled¶
Report disabled.
Disabled¶
Permanently disabled endpoint.
Disabled¶
Snippet disabled.
Disabled¶
Disabled mapping, synchronization stopped.
Disconnected¶
Last health check failed — service unreachable.
Dispatch Workflow Action¶
Core workflow engine process. Iterates over the action triggers (OR-joined), evaluates each against the current event/context, and dispatches the action for execution when any trigger matches. Validates payload against payload_schema_json before dispatching.
- Ver também: Action Trigger
Dispatcher¶
Service based on Symfony EventDispatcherInterface that publishes signals and other typed occurrences. Publicly accessed via middag::dispatch().
-
Ver também: Signal
-
Referências:
- ADR-701
Display Mode¶
File display mode presented to the user.
Document¶
Document field with country and type configuration (CPF, SSN, NIF, etc.).
Document Builder (docbuilder)¶
Document generator: configurable templates, issuance contexts, tracking and certificate integration.
Document Config¶
Document configuration: ISO country and document type (CPF, SSN, NIF, etc.).
Document Emission¶
Record of a concrete document emission for a specific user, with validation code and reference to the generated PDF.
Document Emitted¶
Document emitted successfully, PDF generated and validation code assigned.
Document Invalidated¶
Document marked as invalidated via workflow action.
Document Requested¶
Event emitted when a document issuance is requested via docbuilder from the ticket.
Document Template¶
Reusable template that defines layout, dynamic fields, and application context of a document type.
- Ver também: Template Field
Download¶
File served as a direct download.
Draft¶
Report in draft, not published.
Draft¶
Form under construction, not available for submission.
Draft¶
Template in draft, not yet available for emission.
DTO¶
Data Transfer Object for transporting data between layers without business logic.
- Referências:
- ADR-204, ADR-401
Duration¶
Time duration input with unit selector.
E¶
E-commerce Hub (ecommerce)¶
Extension for sales and automated enrolments integrated with Moodle.
Ecommerce (ecommerce)¶
Commerce: e-commerce platform integration, order synchronization, products and sites.
Elect Group Principal¶
Evaluates the group principal_selection strategy (latest, manual, first_available) to determine which group_item becomes principal. Updates is_principal flags. Called after item addition, removal, reordering, or explicit operator action. Produces no result if strategy is manual and no explicit selection was made.
- Ver também: Principal Selection Strategy
Email¶
Email field with format validation.
Embedded Report¶
Looker Studio dashboard configured for embedding in Moodle. Controls base URL, access capability and parameter mappings.
- Ver também: Parameter Mapping, Report URL, Report Status, Access Capability
Emission Batch¶
Grouping of emissions generated in batch, with target list, aggregated status, and progress.
- Ver também: Batch Target
Emission Context¶
Application context of the document template.
Emission Deferred¶
Emission deferred due to incomplete profile, awaiting user_became_compliant.
Emission Metadata¶
Emission tracking data: who emitted, when, reason, and origin (manual, workflow, helpdesk).
Emission Status¶
Lifecycle status of a document emission.
Emit Document¶
Emit a document via docbuilder extension.
Emitted¶
Document emitted successfully, PDF generated.
Encrypted Password¶
Password stored with Moodle encryption API.
Endpoint Created¶
New endpoint registered.
Endpoint Disabled¶
Endpoint disabled.
Endpoint Paused¶
Endpoint paused.
Endpoint Status¶
Operational status of the webhook endpoint.
- Ver também: Webhook Endpoint
Ends With¶
Suffix match (LIKE %value).
Enrol User¶
Enrol user in a course via enrolment extension.
Enrolment (enrolment)¶
Academic management: registrations, enrolments, lifecycle, progress cleanup and profile compliance.
Enrolment Event Entry¶
Historical entry for a transition, maintenance or synchronization in the enrolment lifecycle.
Enrolment History (enrolment)¶
Extension that manages the complete student lifecycle, from registration to completion.
Enrolment Origin¶
Origin of the enrolment lifecycle. Identifies the channel or mechanism that triggered the enrolment.
Enrolment Period¶
Start, completion, expiration and closure dates of the enrolment lifecycle.
Enrolment Record¶
Persists the full enrolment cycle: identity, course/offering binding, current status, transition history, validity period and correlation with the technical Moodle enrolment bridge. Serves as the aggregate root for all enrolment-related events and state changes.
- Ver também: Enrolment Event Entry, Bridge Execution, Enrolment Status, Enrolment Origin, Enrolment Period, Audit Actor, Bridge Correlation, Reentry Reason
Enrolment Status¶
Status of the enrolment lifecycle. Defines the current position of the cycle in the lifecycle flow.
Entity (base)¶
Abstract immutable domain entity class, base for persistable framework types.
- Referências:
- ADR-401, ADR-402
Entry Result¶
Detailed delivery result: channel used, timestamp and failure reason.
Entry Status¶
Individual delivery status for a recipient in the queue.
Environment Name¶
Observability integration environment.
- Ver também: Observability Config
Equals¶
Exact value match.
Error Event Projection¶
Projection of the event sent to the observability provider (not persisted).
Escalation Note¶
Escalation note recorded when the ticket is moved between departments.
Evaluate Condition¶
Checks a Moodle context (category, course, module, page) against a condition rule set. Rules are AND-composed: the context must satisfy ALL rules. Returns boolean. Delegates to registered providers for custom condition types. When no rules are configured, returns true (graceful degradation).
Evaluate Segment¶
Core segmentation process. Iterates over segment_criteria children, delegates SQL generation to the appropriate criteria_provider_interface per criteria_type, composes WHERE clauses via match_type (all=AND, any=OR). Returns an evaluation_result with member count, cache status, and timestamp. Respects cache_ttl: if a cached result exists and is not expired, returns it without re-evaluation. Enforces Segment Draft Gate: draft segments raise an exception.
- Ver também: Evaluation Result
Evaluation Result¶
Produced by segment_service::evaluate(). Immutable value object capturing the result of a segment evaluation. Attributes: - member_count (int): number of users matching all criteria. - is_cached (bool): whether the result came from cache. - evaluated_at (int): UNIX timestamp of the evaluation. - cache_expires_at (int, nullable): UNIX timestamp when cache expires (null when cache_ttl=0). Business rules: - member_count is the number of users matching all criteria. - is_cached indicates whether the result came from cache. - cache_expires_at is null when not cached (cache_ttl=0). - Consumers should check is_cached and cache_expires_at to decide if re-evaluation is needed. PHP: final readonly class with from_array()/to_array(). JsonSerializable.
Event¶
Fired by domain event received via CC-01.
Event Occurrence¶
Match users who triggered (or did not trigger) a specific Moodle event. Queries logstore_standard_log.
Event Signal¶
Triggered by a domain signal dispatch.
Event Subscription¶
Binding between a catalog event and a destination endpoint.
Event Type¶
Catalog event type (e.g.: course_completed, cleaning_executed).
Exclude¶
Matching contexts are excluded.
Executable¶
Server executable path input.
Execute Maintenance Tool¶
Dispatch a maintenance tool action and return the result.
Execute Workflow Action¶
Receives a dispatched action with validated payload. Creates an action_execution record (status: pending → running). Invokes the action type handler. On success, sets status to succeeded and stores result_json. On failure, sets status to failed and stores error details. On guard condition not met, sets status to skipped. Dispatches Action Execution Completed signal on terminal state.
- Ver também: Action Execution, Action Execution Completed
Execution Payload¶
Captures the full I/O of an execution. input_json is the data provided by the trigger; output_json is the result returned by the action; error_message captures failure details. Business rules: - input_json is set at creation (immutable). - output_json is set after execution completes (null while pending/running). - error_message is set only on failure (null on success/skipped). PHP: readonly value object. Immutable after construction.
Execution Status¶
Tracks the execution lifecycle. Transitions: pending -> running -> succeeded/failed/skipped. Terminal states (succeeded, failed, skipped) are immutable.
Execution Weight¶
Numeric weight for execution ordering (lower = first).
Expiration Policy¶
B2B allocation expiration policy (days or no expiration).
Expired¶
Form expired due to submission limit or date.
Expired¶
Allocation expired per offering policy.
Expired¶
Nomination expired without response.
Expired¶
Validity expired or enrolment expired without completion.
Expired¶
Invite expired without acceptance within the deadline.
Export Configuration¶
Global export configuration: which tables/views to export, frequency and connection reference in CC-02 (connectors).
- Ver também: Export View, Export Frequency, Connection Reference
Export Configured¶
Export configuration created or updated.
Export Frequency¶
Export frequency: daily or custom.
Export Job¶
Execution of a full export to BigQuery. Tracks status, per-table results and field sanitization.
- Ver também: Job Table Result, Job Status, Sanitization Blacklist
Export View¶
SQL view (default or plugin-customized) selected for export to BigQuery.
Exported¶
Table/view exported successfully.
Extension (base)¶
Abstract class from the controlled extension layer that extensions extend to implement register() and boot(), registering controllers, services, hooks and filters in the kernel.
- Referências:
- ADR-602, ADR-902
Extension Info¶
Produced by system_status_service::collect_extensions() and consumed by the extensions management Inertia page and the system status report. Maps directly to the data returned by extension_service::get_all() with added distribution and license fields. Implements JsonSerializable. Factory: from_array(array).
- Ver também: Extension (base)
Extension Loader¶
Kernel component that discovers native extensions by directory and external extensions via the extend_local_middag_extensions hook, validates dependencies and orders loading.
-
Ver também: Extension (base)
-
Referências:
- ADR-602, ADR-603
Extension Management¶
Administrative view listing installed MIDDAG extensions with status, version, group and configuration links. Rendered via Inertia React component.
- Ver também: Extension (base), Extension Info, License Manager
External Service¶
Extensions declare service definitions via get_service_definitions() in their extension class. The build_statics:services pipeline generates the Moodle db/services.php file from these declarations, mapping each method to its corresponding external function.
-
Ver também: Controller
-
Referências:
- ADR-306
F¶
Facade¶
Stable static access point for external consumers. Represents a public entry to the framework and delegates to services resolved by the container. Generated via CLI — not manually edited.
-
Ver também: Contract
-
Referências:
- ADR-901, ADR-604
Fail¶
Criterion failed. Zero points.
Failed¶
Job failed completely.
Failed¶
Table/view export failure.
Failed¶
Message delivery failure.
Failed¶
Execution failed with error.
Failed¶
Submission processing failed.
Failed¶
Operation terminated with failure.
Failed¶
Attempt failed.
Fetch News Feed¶
Fetch product news from external endpoint and return cached News Feed.
Field¶
Fields support inline validation rules, conditional visibility (visible_when, hidden_when) and dependency-based requirements. Compiled to a neutral field_definition value object that is consumed by the renderer adapter, decoupling schema declaration from rendering target.
-
Ver também: Field Type, Condition Operator
-
Referências:
- ADR-806
Field Dependency¶
Dependency between fields: depends_on, dependency_type, and dependency_value.
Field Reference¶
Reference to the Moodle field validated by the rule: standard or custom profile field.
Field Source¶
Data origin referenced by the dynamic field of the template.
Field Type¶
Enumerates all valid field types: TEXT, TEXTAREA, PASSWORD, EMAIL, URL, INT, FLOAT, SELECT, MULTISELECT, RADIO, CHECKBOX, SWITCH, DATE, DATETIME, DURATION, FILE, ENTITY_PICKER, HIDDEN, STATIC, HEADER. Each case determines rendering behavior, client-side validation and server-side type coercion.
- Referências:
- ADR-806
Field Validation¶
Per-field validation rules: max length, min/max, format.
Field Visibility¶
Visibility of a sensitive field (sent or not) in the sanitization policy.
File Area¶
Each file area defines a named storage zone (e.g. logos, attachments) with its own access control and serving logic. The handler implements file_area_handler_interface (Group A) and receives delegation from local_middag_pluginfile() for secure file delivery.
-
Ver também: Statics Generator
-
Referências:
- ADR-307
File Path¶
Server file path input with validation.
File Scope¶
File visibility scope.
File Slug¶
Friendly, globally unique textual slug for file identification.
File Status¶
Lifecycle status of the institutional file.
File Upload¶
File upload field.
File Version¶
File version when versioning is enabled.
Filter¶
Synchronous value transformation applied in a pipeline, separate from the dispatcher. Filters do not represent occurrences and are not derived from signals.
- Referências:
- ADR-703
Form¶
The schema is compiled to neutral field_definition value objects, then hydrated with user input by the form_resolver. An interchangeable renderer adapter (mform for server-side HTML or Inertia for React) produces the output. Complex validation cases escalate to form_request via const REQUEST for full server-side validation before controller execution.
-
Ver também: Field, Form Renderer, Form Request
-
Referências:
- ADR-802, ADR-805, ADR-806
Form Action Type¶
Post-submission action type. Defines the behavior executed after submission.
Form Created¶
Event emitted when a form is created with defined mode and policy.
Form Deactivated¶
Event emitted when a form is deactivated.
Form Expired¶
Event emitted when a form expires due to submission limit or date.
Form Field¶
Form field with type, validation, and dependencies. Linked to a step or directly to the form.
Form Field Type¶
Form field type. Defines rendering and validation.
Form Limits¶
Submission limit and/or expiration date for the form.
Form Logo¶
Logo or image of the form displayed on the public interface.
Form Mode¶
Structural mode of the form: visual or external. Immutable after creation.
Form Published¶
Event emitted when a form is made available for submission.
Form Renderer¶
Receives field_definition value objects from the Form and renders them via the target adapter. Implements form_renderer_interface (@internal). MVP ships two adapters: mform_renderer (server-side HTML via MoodleQuickForm) and inertia_renderer (JSON props for React). Isolated behind an anti-corruption boundary — no moodleform symbol appears outside the adapter.
-
Ver também: Render Target, Form
-
Referências:
- ADR-805
Form Request¶
Canonical validation mechanism that normalizes input regardless of entry point. Auto-injected via form_request_resolver before controller execution, so the controller always receives validated data.
-
Ver também: Controller
-
Referências:
- ADR-802
Form Scope¶
Form scope. Defines visibility range.
Form Slug¶
Friendly, globally unique slug for public identification of the form.
Form Status¶
Form status in the lifecycle.
Form Step¶
Step of the multi-step form. Available only in visual mode.
Form Step Order¶
Position in the multi-step form step sequence.
Form Submission¶
Triggered when a customform form is submitted.
Form Submission¶
Received and persisted submission with asynchronous processing lifecycle. Immutable after creation, audit record.
- Ver também: Processing Log, Submission Status
Full Clean¶
Total reset — removes progress, grades, completion and all academic data.
G¶
Generate Status Report¶
Convert collected status data into a plain-text report.
Get Applicable Contexts¶
Resolves all context IDs matching the given rules. Used for bulk operations (e.g., "find all courses where this snippet should appear"). Each scope (category, course, module, page) is resolved independently, then intersected.
Get Audit Detail¶
Retrieve full detail of a single audit log entry including diffs.
Get Audit Filter Options¶
Return available filter options for the audit log query interface.
Get Available Fields¶
Aggregates segment_field VOs from all registered criteria_provider_interface implementations. Each provider contributes its fields with metadata (name, label, category, operators, advanced). Fields are grouped by category for UI display. Extension-provided fields appear alongside built-in fields. Used by the segment criteria form to populate the field selector.
- Ver também: Segment Field
Get Job Detail¶
Retrieve full job detail with execution attempts.
Global¶
File visible across the entire site.
Global¶
Form visible across the entire Moodle installation.
Global¶
Policy applicable to the entire Moodle installation.
Global Scope¶
Automatic cross-cutting filter applied to all query_builder queries via global_scope_interface. Registered in the global_scope_manager during boot(). Can be excluded per query with without_scopes().
-
Ver também: Query Builder
-
Referências:
- ADR-506
Goal Date¶
Target date for completing a study plan goal.
Goal Status¶
Status of an individual study plan goal.
Grant Status¶
Status of the access right granted to the user.
- Ver também: Access Grant
Group Active¶
Group is active, accepting enrollment and progression.
Group Archived¶
Group is archived, no enrollment but history preserved for reporting.
Group Disabled¶
Group is disabled, invisible to all operations.
Group ID¶
Group ID in the current context.
Group Item¶
A group item is the association between an instance group and a MIDDAG item (which wraps a Moodle course or resource). Each group item tracks whether it is the principal (active version) and its sort order within the group. Business rules: - At most ONE group_item per group can have is_principal=true. - When is_principal changes, the instancegroup_service must update the previous principal. - sort_order determines display order in admin UI (lower = first). - Deleting a principal group_item triggers re-election via the group's principal_selection strategy. - The referenced Item (via itemid FK) must exist in middag_items. FK: groupid -> instance_group.id, itemid -> middag_items.id.
- Ver também: Instance Group, Item
Group Status¶
Controls visibility and operational availability of the group. Transitions: active -> archived (preserves history), active -> disabled (hides completely), archived -> active (reactivation), disabled -> active (reactivation). Archived groups are read-only for reporting. Disabled groups are invisible to all operations.
H¶
Header¶
Visual header element, no data input.
Heading¶
Visual section separator with title.
Health Check Result¶
Produced by connector_interface::health_check(). Immutable value object capturing the result of a connectivity test. The connector_status is updated based on the result. Business rules: - success=true -> status becomes 'connected'. - success=false with previous 'connected' -> status becomes 'degraded' (first failure). - success=false with previous 'degraded' -> status becomes 'disconnected' (consecutive failures). - latency_ms helps identify slow services for monitoring. PHP: readonly value object. Immutable after construction.
- Ver também: Connector Status
Health Color¶
Enum with factory method from_score(int): success (>=80), warning (>=50), danger (<50). Used by health_score to determine the badge color in the DashboardHome React component.
Health Criteria Result¶
Result of a health score criterion: name, points, maximum, and status.
Health Criterion¶
Produced by health_score_service for each evaluated aspect: cron timeliness (20pts), jobs without failure (20pts), PHP requirements (15pts), disk space (10pts), license active (15pts), extensions OK (10pts), HTTPS enabled (10pts). Status is ok or fail via Criterion Status enum. Readonly value object with to_array().
- Ver também: Criterion Status
Health Score¶
Calculated by health_score_service and exposed via /admin/dashboard/health JSON endpoint. The score (0-100) is the sum of individual Health Criterion points. A color indicator is derived via Health Color: success (>=80), warning (>=50), danger (<50). Displayed in the DashboardHome React component as a visual health badge. Implements JsonSerializable.
- Ver também: Health Criterion, Health Color, Criterion Status
Health Score Result¶
Total score 0-100, color, and list of health score criteria.
Health Score Service¶
Domain service that computes the system health score by evaluating 7 criteria and aggregating their points.
- Ver também: Health Criterion, Health Color, Criterion Status, Extension Info
Helpdesk (helpdesk)¶
Support center: tickets, service queues, SLA and feedback.
Hierarchy Level¶
Ordered position of a canonical type in the strict organizational hierarchy.
Home¶
Landing tab with DashboardHome React component, health score and news feed.
Hook¶
Action hook derived from a dispatched occurrence, exposed as a canonical string name. Uses middag/ prefix and snake_case segments. Not the primary publication mechanism of the framework.
-
Ver também: Hook Manager
-
Referências:
- ADR-701, ADR-703
Hook Manager¶
Component that manages actions and filters in WordPress style. Exposes add_action(), add_filter(), do_action() and apply_filters(). Used by extensions, external plugins and hookfiles.
HTML¶
HTML code.
HTML Editor¶
Rich text editor for HTML content.
HTTP API¶
REST/GraphQL API integration via HTTP client.
HTTP Client¶
Contract for external HTTP communication. Wraps cURL/Guzzle behind http_client_interface for testability and isolation. Used by connectors, webhooks and external API integrations.
HTTP Kernel¶
HTTP request cycle coordinator. Receives Request from an entry point (index.php, webhook.php, ajax.php), resolves route via router, applies parameter resolution chain and delegates to controller.
-
Ver também: Route, Controller
-
Referências:
- ADR-801, ADR-603
I¶
Import Repository¶
Specialized repository for backup restoration: inserts data directly into the database preserving historical timestamps, intentionally bypassing the item_repository business logic.
-
Ver também: Item
-
Referências:
- ADR-503, ADR-310
In List¶
Value is one of the specified values (multi-select).
In Progress¶
Technical enrolment confirmed, cycle started and user with active access.
In Progress¶
Agent has taken the ticket and it is in progress.
In Progress¶
User has completed at least one step, path in progress.
Inactive¶
Job role deactivated, not available for new assignments.
Inactive¶
Deactivated membership (auto or manual), history preserved.
Include¶
Only listed targets match — whitelist logic.
Indexation Directive¶
Robots directive: index/noindex and follow/nofollow.
Indexation Policy¶
Exposure rules and robots directives for the marketing profile.
Individual¶
Cleaning of a single user in a course.
Inertia¶
Dual response strategy: requests with X-Inertia header receive JSON props; initial page loads receive full HTML bootstrap. Three components manage the lifecycle: inertia_adapter (response builder), inertia_factory (component resolution), inertia_manager (shared data and versioning).
-
Ver também: Controller
-
Referências:
- ADR-804
Inline¶
File displayed inline in the browser.
Instance Group¶
An instance group represents a logical collection of courses or resources that are functionally equivalent or versioned. The group maintains a principal item (the currently active version) and tracks completion across all items in the group. Business rules: - Every group MUST have exactly one principal item at any time (or none if all items are disabled). - When a new course version is added, the principal selection strategy determines which item becomes principal. - Completion is resolved at group level: if ANY active item is completed by a user, the group is considered completed. - Learningpath stages reference groups (not courses directly), enabling transparent course version upgrades. - Ecommerce products map to groups, so purchasing a product enrolls in the current principal item. - Enrolment re-enrollment logic uses the principal item to determine where to re-enrol expired users. Persistence: EAV via middag_items (type: instancegroup) + middag_itemmeta. Contract: instancegroup_interface in framework/contract/.
- Ver também: Group Item, Group Status, Principal Selection Strategy, Completion Resolution, Principal Item Changed
Instance Group Versioning¶
Instance groups decouple consumer systems (learningpath stages, ecommerce products, enrolment targets) from specific courses. When a course is updated or replaced, a new item is added to the group and becomes principal. Existing references to the group continue to work — consumers interact with the group, not individual courses.
Instancegroup Reference¶
Reference to the instancegroup (CC-06) associated with the step.
Instancegroup Service¶
Central service for the instancegroup capability. Orchestrates the full group lifecycle: creation, item add/remove, principal election via configurable strategy, and completion resolution across group items. Responsibilities: - CRUD operations on instance groups. - Add/remove group items with automatic principal re-election. - Elect principal item based on configured strategy (latest, manual, first_available). - Resolve group completion for a user (any active item completed = group completed). - Dispatch Principal Item Changed signals on principal transitions. Implements instancegroup_interface.
- Ver também: Instance Group, Group Item, Group Status, Principal Selection Strategy, Completion Resolution
Integrations (integrations)¶
Integration hub: webhooks, observability (Sentry), code snippets and external connectors.
Internal Note¶
Internal note visible only to agents. Not accessible by the student.
Interval¶
Periodic firing at configurable interval.
Invalidate Segment Cache¶
Called when segment_criteria are added, modified, or removed. Clears the cached evaluation result so the next call to Evaluate Segment performs fresh evaluation. Also called when external data changes (e.g., cohort membership) that could affect segment membership.
Invalidated¶
Document marked as invalidated, PDF preserved.
Invite¶
Membership created after invite acceptance.
Invite Accepted¶
Event emitted when an invite is accepted, creating or linking the user.
Invite Expired¶
Event emitted when an invite expires without acceptance.
Invite Sent¶
Event emitted when a membership invite is sent to a specific node.
Invite Status¶
Status of the membership invite to the organization.
IP List¶
IP address/range list for access control.
Is Empty¶
Field is null or empty string.
Is False¶
Boolean/flag field is false or disabled.
Is Not Empty¶
Field has a non-empty value.
Is True¶
Boolean/flag field is true or enabled.
Item¶
Aggregate root of the EAV-based persistence model. Each item has a TYPE discriminator (declared via #[item_type] attribute), a status, ownership (userid, extension), timestamps and metadata stored as key-value pairs in middag_itemmeta. Extensions declare item types during boot() and consume items via item_repository_interface. The item family provides: item_service (CRUD + signals), item_query_service (typed search), item_validator_service (pre-persistence validation), diff_builder_service (audit diffs), item_mapper (DB ↔ entity) and audited_item_repository (auto-audit decorator). Persistence: middag_items (root), middag_itemmeta (metadata EAV). Domain: framework/domain/item/. Contracts: item_service_interface, item_repository_interface, item_query_service_interface.
-
Ver também: Item Revision, Item Type
-
Referências:
- ADR-501, ADR-502, ADR-503
Item Revision¶
Immutable historical record created when an item is updated or deleted. Captures the full item state (all fields and metadata) at the moment of the change. Used for audit history, rollback analysis and compliance. Each revision links to its parent item and records the actor and action that triggered it. Persistence: middag_item_revision table. Domain: framework/domain/item_revision/. Contracts: item_revision_service_interface, item_revision_repository_interface.
-
Ver também: Item
-
Referências:
- ADR-501, ADR-503
Item Transition¶
Triggered when an item changes status (from_status -> to_status).
Item Type¶
Each extension registers its item types during boot. Core uses short slugs (e.g. product); external plugins use namespaced format (vendor_slug:type_slug) to avoid collisions. Duplicate type identifiers cause a fatal error at boot.
-
Ver também: Item
-
Referências:
- ADR-502
J¶
JavaScript¶
JavaScript code.
Job¶
Aggregate root for async execution governance. When a command is dispatched via dispatch_async(), the command bus creates a Job record, serializes the command, and enqueues a Moodle adhoc task. The job tracks: status (pending, running, completed, failed), deduplication key, correlation ID, related subject (entity type + ID), max attempts and retry policy. Each execution creates a Job Attempt child. The admin dashboard jobs tab displays active and recent jobs with filtering. Persistence: middag_job (root), middag_job_attempt (attempts). Domain: framework/domain/job/. Contracts: job_service_interface, job_repository_interface.
-
Ver também: Job Attempt, Command Bus
-
Referências:
- ADR-504, ADR-705, ADR-503
Job Attempt¶
Immutable child record representing one execution attempt of a Job. Records attempt number (1-based), transport method (adhoc_task, sync), status (running, completed, failed), error message (if failed), result payload (if completed), start and end timestamps. Multiple attempts occur when retry policy allows re-execution after failure. Persistence: middag_job_attempt table. FK: jobid → middag_job.id.
- Referências:
- ADR-504, ADR-705
Job Cancelled¶
Pending job cancelled via dashboard.
Job Completed¶
Job completed (fully or partially).
Job Failed¶
Job failed completely.
Job Query Service¶
Domain service for querying async jobs with status filtering, retry and cancel operations in the admin jobs tab.
Job Retried¶
Failed job re-enqueued via dashboard.
Job Role¶
Job role from the global catalog with optional mapping to a Moodle role.
Job Role Status¶
Job role status in the global catalog.
Job Started¶
Export job started.
Job Status¶
Export job status within the export lifecycle.
- Ver também: Export Job
Job Table Result¶
Export result of an individual table/view within an export job.
Jobs¶
Async job monitor tab showing command execution status, attempts and correlation.
JS Capture Flag¶
JavaScript capture flag (default: disabled).
JS Error Captured¶
JavaScript error captured and sent to the provider.
K¶
Kernel¶
Framework bootstrap coordinator: initializes the container, discovers resources, executes the extension lifecycle and compiles the service graph. Bootstrap via core\hook\after_config.
-
Ver também: Container, Extension (base)
-
Referências:
- ADR-601, ADR-602, ADR-603
L¶
Language Code¶
Translation language code (e.g.: pt_br, en, es).
Learning Path¶
Enrolment triggered by learning path progression.
Learning Path¶
Training path with sequential steps referencing instancegroups via CC-06.
- Ver também: Path Step
Learningpath (learningpath)¶
Learning journeys: sequential paths with stages, progress and study plans.
License Manager¶
License Snapshot Reader runs at bootstrap with fail-closed semantics (no snapshot = no PRO). License Manager tracks state transitions (active/expired/invalid). License Service performs external verification against account.middag.com.br.
-
Ver também: Extension (base)
-
Referências:
- ADR-605
Link¶
Clickable link to an external or internal URL.
List Audit Entries¶
Query audit log entries with filtering and pagination.
List Jobs¶
Query async jobs with status filtering and pagination.
Local¶
Local development environment.
Logs¶
Framework log viewer tab with filtering and retention management.
M¶
Maintenance Tool¶
Each case maps to an action handler in tools_service::execute(). The enum replaces hardcoded action strings with type-safe identifiers. Cases: purge_cache, clean_logs, check_db, reset_extension_config, reindex, check_license.
Manage¶
Full administrative access. Cloned from moodle/site:config. Archetype: manager.
Managed File¶
Institutional file with permanent URL and access control.
- Ver também: File Version
Management Dashboards (dashboard)¶
Extension for native metrics and administrative dashboards within Moodle.
Manual¶
On-demand firing by the operator.
Manual¶
Triggered manually by an operator via admin UI.
Manual¶
Enrolment performed manually by admin or manager.
Manual¶
Re-entry manually requested by admin or manager.
Manual¶
Membership created manually by admin or manager.
Mapper¶
Component that converts physical database records (stdClass) into domain entities and vice-versa, isolating the physical schema from upper layers.
- Referências:
- ADR-503
Mapping Defaults¶
Cohort mapping defaults: default job role and default membership period for members via cohort.
Mapping Source¶
Value source for report parameter mapping.
- Ver também: Parameter Mapping
Mapping Status¶
Status of the mapping between unit and cohort.
Mapping Target¶
Parameter name in Looker Studio.
Marketing Profile¶
Central governance profile for external discovery and presentation: social preview, SEO, indexation, and structured data.
Member Deactivated¶
Event emitted when a membership is deactivated, preserving history.
Member Linked¶
Event emitted when a user is linked to a node with job role and membership period.
Member Received From Cohort¶
Event emitted when a member is created from an addition to the Moodle cohort.
Member Synced To Cohort¶
Event emitted when a member is mirrored to the mapped Moodle cohort.
Member Unlinked¶
Event emitted when a membership between user and node is terminated.
Members Imported¶
Event emitted when a batch import of members is completed.
Membership Origin¶
Origin of the membership between user and organizational node.
Membership Period¶
Membership period: start date and optional end date. Auto-deactivation upon expiration.
Membership Status¶
Status of the membership between user and organizational node.
Message Automation (automessage)¶
Extension for automated communication rules and message dispatching.
Message Blocked¶
Delivery blocked by throttle or condition.
Message Failed¶
Delivery failure for recipient.
Message Rule¶
Communication rule: combination of trigger, template, segment and delivery channels.
- Ver também: Message Trigger
Message Sent¶
Message sent successfully to recipient.
Message Service¶
Cross-cutting service for dispatching Moodle messages (notifications, emails). Wraps message_send() behind message_service_interface. Consumed by automessage, helpdesk and workflow actions.
-
Ver também: Automessage (automessage)
-
Referências:
- ADR-203
Message Template¶
Message template with substitution variables, subject and body.
Message Trigger¶
Rule firing condition: type and specific configuration.
Message Trigger Config¶
Trigger parameters: event, period or reference date.
Message Trigger Type¶
Type of trigger that fires the communication rule.
Metric Cache¶
Pre-computed data cache for a registered widget.
Metrics Cache Expired¶
Cache expired — direct resolution required.
Metrics Precomputed¶
Metrics cache updated via cron.
MIDDAG Hooks API¶
Integration mode in which a Moodle plugin uses add_action() and add_filter() from the hook_manager to react to events or transform MIDDAG data, without registering a complete extension.
- Ver também: Hook Manager
MIDDAG Hooks File¶
Integration mode in which a standalone PHP file (middag_hooks.php) registers actions and filters without depending on a Moodle plugin. Automatically detected in dirroot, dataroot or active theme.
- Ver também: Hook Manager
Moderate¶
Content moderation access. Archetypes: editingteacher, manager.
Module¶
Filter by activity module type (e.g., assign, quiz, forum).
Moodle Event Bridge¶
Inbound: translates Moodle events into internal signals via dispatch_event(), allowing framework subscribers to react without coupling to Moodle event classes. Outbound: emits Moodle events via definitions generated by build_statics, enabling external plugins to observe framework activity.
-
Ver também: Signal, Dispatcher, Statics Generator
-
Referências:
- ADR-304
Multicheckbox¶
Multiple boolean toggles from a list of options.
Multiselect¶
Multiple selection from a list of options.
N¶
Native¶
Native document generation by the framework, without external module.
native¶
Extension that lives inside local_middag/classes/extensions/. Distributed with the framework.
New¶
Newly opened ticket, awaiting support.
News Feed¶
Readonly value object wrapping news_item[] with from_cache flag. Factory methods: from_raw(array, bool) parses raw JSON items, empty() returns an empty feed. Implements JsonSerializable with items, count and from_cache fields.
News Item¶
Fetched by news_service from the URL configured in the news_endpoint setting. Readonly value object implementing JsonSerializable. Fields: title, summary, url, date, category. Factory: from_array(array) handles both 'summary'/'description' and 'url'/'link' key variants from the external API.
News Service¶
Domain service that fetches product news from the configured endpoint and caches the result. Returns a News Feed value object.
Node Attributes¶
Extended attributes of the organizational node: description, logo, external code. Configurable per level.
Nominated¶
Person nominated to consume the allocation.
Nomination Status¶
Status of the person nomination to consume a B2B allocation.
- Ver também: Allocation Nomination
Non-Compliant¶
User does not meet one or more policy rules.
Not Contains¶
Substring does not match.
Not Equals¶
Value does not match.
Not In List¶
Value is not in the specified list.
Not Started¶
User has not started the path yet.
Notification¶
Sends a notification after submission.
O¶
OAuth2¶
OAuth 2.0 authorization flow with token refresh.
Observability Config¶
Main configuration for the observability provider integration. Controls connection, environment, sample rate and sanitization.
- Ver também: Provider Connection Ref, Environment Name, Sample Rate, JS Capture Flag
Observability Disabled¶
Observability integration disabled.
Observability Enabled¶
Observability integration enabled.
Offering Capability Flags¶
Capability flags enabled on the offering, limited by the connector binding matrix.
Offering Created¶
Commercial offering created.
OK¶
Criterion passed. Full points awarded.
Operation Status¶
Status of the cleaning operation in the execution lifecycle.
Operation Type¶
Cleaning operation type. Classifies the execution mode.
Optional¶
Optional step, does not block sequence or completion.
Order Transaction¶
Center of the commercial cycle — order or transaction received from the external world. Persists commercial status, received events and triggered effects.
- Ver também: Transaction Status
Organization¶
File restricted to a specific organizational unit (unit_id).
Organization¶
Enrolment triggered by organizational affiliation.
Organization¶
Node in the organizational tree (root or intermediate). Records identity, position in hierarchy, canonical type, labels and status.
- Ver também: Cohort Mapping, Job Role, Organizational Unit Type, Unit Type Label, Hierarchy Level, Node Attributes, Role Mapping, Job Role Status, Mapping Defaults, Mapping Status
Organization (organization)¶
Organization, department and unit management. Unit hierarchy with members and invitations.
Organization Created¶
Event emitted when a root or intermediate node is created in the organizational tree.
Organization Deactivated¶
Event emitted when an organizational node is deactivated, preserving history.
Organization Filter¶
Organizational unit filter applied to the panel.
Organization Invite¶
Invite to join a specific organizational node with configurable deadline.
Organization Member¶
Temporal membership between a Moodle user and an organizational node, with job role, membership period and status.
- Ver também: Organization Invite, Membership Period, Membership Status, Membership Origin
Organization Moved¶
Event emitted when a node is moved within the organizational tree (without sub-units).
Organizational Unit Type¶
Canonical organizational unit type (label). Fixed identity, configurable labels per tenant.
Overdue¶
Goal overdue, target date exceeded.
Overridden¶
Admin manually unblocked, bypassing evaluation.
Overview¶
Global overview tab with consolidated metrics and cross-tab summary.
P¶
Page¶
Filter by site page identifier (dashboard, profile, etc.).
Page Metadata Projection¶
Final projection of marketing modules for a rendered page.
Panel Configured¶
Panel created or updated.
Panel Visibility¶
Capability/role that can view the panel.
Parameter Mapping¶
Mapping from Moodle context to a report parameter in Looker Studio.
Partial Clean¶
Selective reset — removes progress and attempts, preserves final grades and completion.
Partially Failed¶
Job completed with failures in individual tables.
Partially Failed¶
Batch completed with partial failures, valid emissions preserved.
Password¶
Masked password input.
Path Reference¶
Reference to the source path of the study plan.
Path Step¶
Path step with defined order, requirement and reference to an instancegroup.
Path Step Order¶
Position of the step in the path sequence.
Paused¶
Rule paused, triggers do not fire.
Paused¶
Paused endpoint — does not generate new deliveries.
Pending¶
Execution queued, not yet started.
Pending¶
Submission received, awaiting queuing.
Pending¶
Emission pending processing.
Pending¶
Nomination pending acceptance.
Pending¶
Evaluation not yet performed.
Pending¶
Cycle created, awaiting technical bridge confirmation.
Pending¶
Operation created, awaiting execution.
Pending¶
Delivery created, awaiting processing.
Pending¶
Goal awaiting completion by the student.
Pending¶
Invite sent, awaiting acceptance.
Per Organization¶
Form visible only to a specific organizational unit.
Per Organization¶
Policy applicable to a specific organizational unit.
Performance Trace Captured¶
Performance trace captured.
Permanent URL¶
Immutable file URL: /local/middag/file/{slug_or_id}.
PHP Error Captured¶
PHP error captured and sent to the provider.
Plan Goal¶
Individual study plan goal: associated step and target date for completion.
Plan History¶
Previous plan preserved as history after study plan reset.
Plan Status¶
Lifecycle status of the study plan.
Plugin¶
Custom view registered by plugin via callback.
Policy Scope¶
Compliance policy scope. Defines the validation coverage.
Port List¶
Network port list for service configuration.
Post Submit Action¶
Simple post-submission action without branching: notification, redirect, webhook, or persistence.
Principal Item Changed¶
Signal emitted by the instancegroup service when the principal group_item changes due to item addition, removal, re-ordering, or explicit operator action. Consumers react to update dependent references (learningpath stages, ecommerce products, enrolment targets). Payload: group_id, previous_principal_id (nullable), new_principal_id (nullable), reason (added, removed, reordered, manual), timestamp. Consumers: - Learningpath recalculates stage targets when principal changes. - Ecommerce updates product-to-course mapping. - Enrolment re-enrollment logic adjusts target course. Not emitted when principal remains the same after strategy re-evaluation.
- Ver também: Instance Group, Group Item
Principal Selection Rule¶
Constraint evaluated during Elect Group Principal. Three strategies: latest (most recently added item), manual (operator explicitly sets), first_available (first enabled item by sort_order). The rule ensures at most one item has is_principal=true at any time. If no items are available, principal is null.
Principal Selection Strategy¶
Determines which group_item becomes principal when items are added, removed, or re-ordered. Three strategies: latest (most recently added item), manual (operator explicitly sets principal), first_available (first enabled item by sort_order). Business rules: - Strategy is set at group creation and can be changed by admin. - When strategy is 'latest', adding a new item automatically makes it principal. - When strategy is 'manual', only explicit operator action changes the principal. - When strategy is 'first_available', the first enabled item by sort_order is principal. - If no items are available (all disabled), principal is null. PHP: readonly value object. Immutable after construction.
Privacy Repository¶
Specialized repository for bulk LGPD/GDPR operations (export, delete, anonymize). Executes optimized queries without loading models into memory. Receives contextlist from Moodle.
pro¶
Premium MIDDAG extension distributed in a separate plugin (e.g.: local_middagpro). Up-sell model.
Processed¶
Submission successfully processed.
Processing¶
Batch in processing.
Processing Log¶
Record of each action executed during submission processing with timestamp and result.
Product Offering¶
Configurable commercial offering in MIDDAG, mapped to an external product. Flags per capability, access target and mapping rules.
- Ver também: Offering Capability Flags, Access Target, Expiration Policy
Production¶
Production environment.
Profile Field¶
User profile field.
Profile Field¶
Match users by standard Moodle user profile columns (text, select, boolean). Covers 14 fields: username, email, country, auth, confirmed, suspended, etc.
Progress Percentage¶
Path completion percentage, considering only required steps.
Progress Status¶
User progress status in the path.
Progression¶
Re-entry triggered by learning path or curriculum progression.
Provider Connection Ref¶
Reference to the external connection registered in CC-02 (connectors).
Public¶
File accessible without authentication.
Public¶
Form accessible without authentication.
Published¶
Form available for submission according to the access policy.
Purge Cache¶
Purge all MIDDAG cache definitions (default, item, loader, openapi_spec, opengraph, customform_render).
Q¶
Query Builder¶
Provides 13 filter operators for expressive queries over items and their metadata. Supports relation filters, global scopes (automatic cross-cutting constraints) and cursor-based pagination. Accessed via search_factory and search_executor facades.
-
Ver também: Repository, Global Scope
-
Referências:
- ADR-506, ADR-507
Queue Completed¶
Send queue processing completed.
Queue Created¶
Send queue created for rule execution.
Queued¶
Delivery awaiting processing in the queue.
Queued¶
Submission queued for asynchronous processing.
Quick Access Link¶
Typed value object replacing the untyped array [id, title, url] returned by abstract_extension::get_quick_access_links(). Rendered as navigation links in the admin extension settings tabs. Each extension can declare zero or more links.
R¶
Reactivated¶
Cycle resumed after suspension period.
Recycling¶
Re-entry due to recycling after validity expiration.
Redirect¶
Redirects the user after submission.
Reentry Reason¶
Reason for re-entry in the enrolment lifecycle. Classifies the reason for a new cycle.
Reference Context¶
Shortcode context: course_id and module where the shortcode was inserted.
Refunded¶
Transaction refunded.
Regex¶
Value extracted via regular expression.
Regex¶
Value matches a regular expression pattern.
Register Condition Provider¶
Extensions call this during boot() to register custom condition types (e.g., time-based conditions, device conditions, AB tests). The provider implements condition_provider_interface and handles evaluation for its type.
Regularization¶
Re-entry for regularization of pending issues or compliance.
Reindex¶
Rebuild search and metadata indexes.
Rejected¶
Nomination rejected by the nominee.
Relative Date¶
Firing relative to a user reference date (e.g., birthday, enrollment).
Release Marked¶
New release registered in the observability provider.
Remove Criteria¶
Deletes the specified segment_criteria from the segment. Re-sequences sort_order for remaining criteria. Invalidates the parent segment's cached evaluation result. If the last criteria is removed, the segment becomes an "all users" segment.
Remove Group Item¶
Deletes a group_item from the instance group. If the removed item was the principal, triggers Elect Group Principal to select a new principal based on the group strategy. If no items remain, principal becomes null.
- Ver também: Principal Item Changed
Render Target¶
Passed to render_form($form, target: render_target::INERTIA) to override the controller default rendering mode. Extensible — new renderer adapters add a case to the enum without changing the form DSL or existing adapter implementations.
- Referências:
- ADR-805, ADR-803
Renderable¶
Each renderable is paired with a Mustache template in templates/{slug}/ and rendered server-side in Moodle pages mode. Extensions use the pattern for widgets (dashboard cards) and table_builder (data tables with sorting, filtering and pagination).
-
Ver também: Controller, Widget
-
Referências:
- ADR-803
Report Activated¶
Report published.
Report Created¶
New report configured.
Report Disabled¶
Report disabled.
Report Status¶
Embeddable report status within the lifecycle.
- Ver também: Embedded Report
Report URL¶
Base URL of the Looker Studio embed.
Repository¶
Official persistence boundary. Isolates physical table names and centralizes queries by family: item (current state), item_revision (history), audit (traceability) and job (governance).
- Referências:
- ADR-503
Required¶
Required step for path completion.
Reset Extension Config¶
Reset extension configuration to defaults.
Resolve Group Completion¶
Queries Moodle completion state for all active items in the group for a given user. Returns a Completion Resolution value object. If ANY active item is completed, is_completed=true with the first completed item identified. Evaluation is on-demand, not cached. Used by learningpath for stage progression.
- Ver também: Completion Resolution
Resolved¶
Ticket marked as resolved by the agent.
Restricted¶
Form accessible only with a complementary variation (password, token, or invitation).
Result¶
Typed operation outcome value object carrying success/failure state, optional data payload and error details. Returned by services and command handlers to avoid exception-driven control flow.
Retry¶
Scheduled for retry.
Retry Job¶
Re-enqueue a failed job for another execution attempt.
Retry Schedule¶
Exponential backoff intervals: 30s, 2min, 10min, 1h, 6h.
Revoked¶
Access permanently revoked.
Role Mapping¶
Optional mapping between job role and Moodle role. Null if no mapping.
Route¶
Routes are declared as attributes on controller methods and auto-discovered at boot time. URL generation uses plugin_aware_url_generator, which injects the correct base path per plugin to produce absolute Moodle-compatible URLs.
-
Ver também: Controller, HTTP Kernel
-
Referências:
- ADR-801
Rule Activated¶
Communication rule activated.
Rule Archived¶
Communication rule archived.
Rule Created¶
New communication rule created.
Rule Paused¶
Communication rule paused.
Rule Status¶
Communication rule lifecycle status.
Rule Triggered¶
Rule trigger fired, send queue will be created.
Run Once¶
One-time firing at scheduled date/time.
Running¶
Job in progress.
Running¶
Execution in progress.
Running¶
Operation in progress.
S¶
Sample Rate¶
Percentage of monitored traffic (0.0 to 1.0).
Sanitization Blacklist¶
List of field patterns to exclude from export: password, secret, token.
Sanitization Policy¶
Anonymization and context enrichment policy for events sent to the provider. Passwords, tokens and cookies are always removed.
- Ver também: Field Visibility, Observability Config
Sanitization Policy Updated¶
Anonymization policy changed.
Schedule¶
Triggered on a cron schedule (cron expression).
Schedule¶
Separate from the Command itself — the schedule only declares when and how often, not how to execute. Does not govern individual execution attempts or retry logic, which is handled by the Job aggregate.
-
Ver também: Command
-
Referências:
- ADR-705
Scheduled¶
Enrolment triggered by automatic scheduling.
Scheduled¶
Cleaning triggered automatically by scheduling.
SDK¶
Native PHP SDK provided by the service vendor.
Seed Test Data¶
Generate test data for dashboard tabs using data_seeder_service.
Seed Test Data¶
Generate test data for extensions in development environments.
Segment¶
A segment defines a dynamic audience via composable criteria rules. Unlike static user lists, segments produce SQL subqueries that can be embedded in larger queries (e.g., automessage targeting, bulk enrolment cleanup). This design avoids materializing potentially thousands of user IDs. Attributes: - fullname (string): human-readable segment name. - description (string, nullable): narrative description. - match_type (segment_match_type): how criteria combine — all (AND) or any (OR). - cache_ttl (int): cache duration in seconds (0 = no cache, default 3600). - status (segment_status): lifecycle state (draft, active, archived). - contextid (int): Moodle context scope (system, category, or course). Business rules: - Segments are composed of one or more segment_criteria, joined by match_type. - get_subquery() returns a segment_subquery VO (SQL + params + estimated count), NOT a user list. - evaluate() triggers fresh evaluation and returns evaluation_result with member count + cache status. - Segments in 'draft' status cannot be evaluated by consumers (Segment Draft Gate). - cache_ttl controls how long evaluation results are cached. - A segment with no criteria matches all users ("all users" case). - Modifying criteria invalidates the cached evaluation result. - Extensions can register custom criteria_type via criteria_provider_interface in boot(). Persistence: EAV via middag_items (type: segment) + middag_itemmeta. Contract: segments_interface in framework/contract/.
- Ver também: Segment Criteria, Segment Status, Criteria Type, Segment Match Type, Segment Operator, Evaluation Result
Segment Active¶
Segment active, evaluable by consumer extensions.
Segment Archived¶
Segment archived, preserved for audit but not evaluable.
Segment Audience Model¶
Unlike static user lists, segments are dynamic audience definitions. They produce SQL subqueries that can be embedded in larger queries for performance in bulk operations. This design avoids materializing potentially thousands of user IDs in memory. Consumer extensions (automessage, enrolment/cleaner) use get_subquery() to compose efficient database operations. Key properties: - Dynamic: segment membership changes as user data changes. - Composable: subqueries embed in any SQL query via IN (subquery). - Cacheable: evaluation results cached with configurable TTL. - Lazy: segments only evaluated when explicitly requested.
Segment Cache Strategy¶
Segment evaluation results are cached using the segment's cache_ttl setting: - cache_ttl > 0: result cached for N seconds, served from cache until expiry. - cache_ttl = 0: no caching, every evaluation runs fresh SQL. - Default: 3600 seconds (1 hour). Invalidation triggers: - Adding, modifying, or removing criteria from the segment. - Changing the segment's match_type. - Manual invalidation via segment_service::invalidate_cache(). - External data changes are NOT tracked automatically (e.g., cohort membership changes). Consumers that need real-time accuracy should use cache_ttl=0 or call invalidate_cache(). Cache stores: member_count + evaluated_at timestamp. The segment_subquery (SQL) is NOT cached — it's always generated fresh. Only the evaluation result (member_count + cache metadata) is cached.
Segment Criteria¶
A segment criteria is a single rule that filters users. Multiple criteria compose the segment subquery via AND (match_type=all) or OR (match_type=any). Each criteria has a type (criteria_type enum) and a config_json payload specific to that type. Attributes: - segmentid (int): FK to parent segment. - criteria_type (criteria_type): determines what config_json fields are valid. - config_json (string): JSON payload — structure varies by criteria_type. - sort_order (int): evaluation order (cheaper rules first for performance). Business rules: - criteria_type determines what config_json fields are valid and which operators are available. - sort_order determines evaluation order (relevant for performance — cheaper rules first). - Deleting or modifying a criteria invalidates the parent segment's cached evaluation. - The criteria_provider_interface implementation for the criteria_type validates config_json. - Multiple criteria of the same type are valid (e.g., two profile_field rules). FK: segmentid -> segment.id. Persistence: EAV via middag_items (child) or dedicated segment_criteria table.
- Ver também: Segment, Criteria Config, Criteria Type
Segment Criteria Composition¶
The segment match_type field (segment_match_type enum) determines the boolean operator joining criteria subqueries. all (default) requires every criteria to match — produces an intersection of audiences. any requires at least one criteria to match — produces a union. This rule governs how Build Segment Subquery composes the WHERE clauses. Special case: a segment with no criteria matches all users regardless of match_type. Within a single field, multiple values from the same criteria are OR'd together (e.g., country = 'BR' OR country = 'PT' within one criteria).
Segment Criteria Description¶
Produced by segment_service::describe_criteria(). Immutable value object that formats a criteria rule into a human-readable sentence. Attributes: - criteria_type (criteria_type): type of the criteria. - label (string): human-readable summary (e.g., "Email contains '@example.com'"). - field_name (string): source field name. - operator_label (string): human-readable operator (e.g., "contains", "is before"). Business rules: - Each criteria_provider_interface implementation produces the label via describe(). - The label should be localized using the Moodle string system. - Used in segment display, audit logs, and automessage targeting summaries. PHP: final readonly class.
Segment Draft¶
Segment under construction, not yet evaluable by consumers.
Segment Draft Gate¶
Guard rule enforced by segment_service::evaluate() and segment_service::get_subquery(). When a consumer requests evaluation of a draft segment, the service throws middag_domain_exception. This prevents incomplete or untested segments from being used in production flows (automessage targeting, bulk operations). Transition: draft -> active requires at least one criteria configured.
Segment Extensibility Model¶
Extensions interact with core.segments in two modes: 1. Consumer mode — use segments_interface to target audiences: - automessage: get_subquery() to target message recipients. - enrolment/cleaner: get_subquery() to bulk-cleanup enrollments by audience. - Any extension: evaluate() to count audience members for dashboards/reports. 2. Provider mode — add custom criteria types via criteria_provider_interface: - Implement criteria_provider_interface with get_type(), get_fields(), build_sql(), describe(). - Register in boot() via the criteria registry. - Custom criteria appear alongside built-in criteria in the segment builder UI. Consumer mode uses framework/contract/segments_interface.php (stable @api). Provider mode uses framework/contract/criteria_provider_interface.php (stable @api). Both contracts are designed for graceful degradation: if core.segments is not available (e.g., disabled), consumers handle the absence without errors.
Segment Field¶
Value object returned by criteria_provider_interface::get_fields() and aggregated by segment_service::get_available_fields(). Describes one filterable dimension with its metadata for UI rendering and config validation. Attributes: - name (string): field identifier (e.g., 'email', 'cohort', 'firstaccess'). - label (string): human-readable label (localized). - category (string): UI grouping (e.g., 'account', 'profile', 'access', 'enrollment', 'other', 'event'). - criteria_type (criteria_type): which criteria provider handles this field. - operators (array): list of segment_operator values available for this field. - is_advanced (bool): whether the field is shown in advanced mode only (default true). Business rules: - Fields are aggregated from all registered criteria_provider_interface implementations. - The category determines UI grouping in the criteria form. - The operators list constrains which operators are valid for this field. - is_advanced=false means the field is always visible; true means it requires "Show more". - Extension-provided fields appear alongside built-in fields. PHP: final readonly class.
Segment Match Type¶
Determines the boolean composition of criteria subqueries within a segment. Stored as a field on the segment entity. Governs Build Segment Subquery behavior. - all (default): every criteria must match — intersection of audiences. - any: at least one criteria must match — union of audiences. The match_type is a segment-level setting, not per-criteria. All criteria within a segment share the same composition mode.
Segment Operator¶
Cross-cutting enum of all comparison operators available for segment criteria. Not all operators apply to all criteria types — each criteria_provider_interface implementation declares which operators its fields support via get_fields(). Operator categories: - Text: equals, not_equals, contains, not_contains, starts_with, ends_with, regex. - Presence: is_empty, is_not_empty. - Date: before, after, between. - Boolean: is_true, is_false. - Set: in_list, not_in_list.
Segment Service¶
Central service for the segments capability. Implements segments_interface (@api) and orchestrates criteria provider implementations. Manages segment lifecycle, criteria CRUD, evaluation, cache, and field discovery. Responsibilities: - CRUD: create, update, delete segments and their criteria. - Evaluation: iterate criteria, delegate SQL generation to providers, compose subquery. - Cache: manage evaluation cache with TTL, invalidate on criteria changes. - Field discovery: aggregate available fields from all registered criteria providers. - Description: produce human-readable criteria descriptions via providers. Depends on: - criteria_provider_interface implementations (registered in boot() by extensions). - segment_subquery VO (framework/contract/). - segment_evaluation_result VO. PHP: final class segment_service implements segments_interface. Contract: segment_service_interface (local @api, generated by pipeline).
- Ver também: Segment, Segment Criteria, Criteria Config, Evaluation Result, Segment Field, Segment Criteria Description
Segment Settings¶
Settings for core.segments registered as typed settings via core_config enum and core_settings DSL. Managed by the core extension settings page. Available settings: - segments_default_cache_ttl (int): default cache TTL for new segments (default 3600). - segments_max_criteria (int): maximum criteria per segment (default 50, guard). - segments_allow_custom_sql (bool): whether custom_sql criteria type is enabled (default true). These settings are system-level (site admin only). Per-segment settings (match_type, cache_ttl) are stored on the segment entity itself.
Segment Status¶
Controls whether a segment can be evaluated and consumed by other extensions. Transitions: draft -> active (enable evaluation), active -> archived (preserve for audit), archived -> active (reactivation). Draft segments are not visible to consumer extensions (Segment Draft Gate rule).
Segment Subquery¶
Returned by segments_interface::get_subquery(). Contains a SQL fragment selecting user IDs, bind parameters, and an estimated row count. Consumer extensions embed this subquery in larger queries (automessage targeting, bulk enrolment cleanup, report filtering). Already implemented in framework/contract/segment_subquery.php. Not generated by pipeline — lives in framework/contract as @api. Attributes (existing): - sql (string): SQL subquery (e.g., "SELECT userid FROM {user} WHERE ..."). - params (array): bound parameters for the subquery. - count (int): estimated member count (may be cached).
- Ver também: Segment
Select¶
Dropdown select with static or lazy-loaded options.
Select¶
Selection field with predefined options.
Send Message¶
Send a notification or message via Moodle messaging.
Send Queue¶
Send queue for a specific rule execution, with per-recipient entries and throttle.
- Ver também: Send Queue Entry
Send Queue Entry¶
Individual per-recipient entry in the send queue, with delivery result.
Sent¶
Message sent successfully to the recipient.
Sent¶
Payload delivered successfully.
SEO Metadata Config¶
Configuration of title, description, and canonical URL for search engines.
SEO Metadata Data¶
Title, description, keywords, and canonical URL for SEO.
Service¶
Framework orchestration component. When local to an aggregate, lives in the domain; when cross-cutting, lives in framework/service.
- Referências:
- ADR-401
Setting Type¶
Classification of admin setting UI control. Each type maps to a concrete DSL class and a Moodle admin_setting_* target.
- Ver também: framework/moodle/settings/setting_type.php
Settings Page¶
A settings page represents a logical grouping of admin settings rendered as a tab in the extension configuration UI. Each extension can declare multiple pages. The settings_resolver converts the page definition into a Moodle admin_settingpage and registers it under the extension category in the admin tree. Pages are identified by slug (e.g., 'configuration', 'license', 'auth') and contain an ordered list of Admin Setting children. Core provides 3 built-in pages: configuration (general settings), license (key and info), auth (authentication method). Extensions add their own pages via get_settings().
- Ver também: Admin Setting, framework/moodle/settings/page.php
Settings Resolver¶
Converts typed DSL setting definitions into Moodle admin_setting_* objects. Handles config key canonicalization with mdg_{extension}_{name} convention.
- Ver também: Settings Page, Admin Setting, Config Schema, framework/moodle/settings/settings_resolver.php
Shortcode¶
Registered via shortcode_manager::register() during boot() and processed as a Moodle text filter. Each shortcode resolves to a handler that receives parsed attributes and returns rendered HTML. Malformed shortcodes are silently ignored (fail-safe); handler exceptions propagate to the caller.
- Referências:
- ADR-704
Signal¶
Typed occurrence published by the dispatcher via middag::dispatch(). Primary internal publication mechanism — distinct from Moodle events, public action hooks and audit records.
Simple Certificate¶
Adapter for the mod_simplecertificate module.
Simple Persistence¶
Persists submission data without additional action.
Skipped¶
Table/view skipped (not processed).
Skipped¶
Execution skipped (guard condition not met).
SLA Breached¶
Event emitted when the ticket SLA deadline is exceeded.
SLA Config¶
Department SLA configuration: deadline in hours for response and resolution.
SLA Status¶
Derived SLA status of the ticket.
Snippet¶
Injectable code fragment (JS/CSS/HTML) with scope controlled by CC-09 (conditions), execution weight and versioning.
- Ver também: Snippet Version, Snippet Type, Snippet Scope, Snippet Status, Execution Weight
Snippet Activated¶
Snippet activated.
Snippet Created¶
New snippet created.
Snippet Disabled¶
Snippet disabled.
Snippet Rolled Back¶
Previous version restored.
Snippet Scope¶
Injection scope controlled by CC-09 (conditions).
Snippet Status¶
Operational status of the snippet.
- Ver também: Snippet
Snippet Type¶
Code type of the snippet.
- Ver também: Snippet
Snippet Version¶
Content version of a snippet. Each edit creates a new version preserving previous ones.
Snippet Version Created¶
New content version created.
Social Preview Config¶
Open Graph and Twitter Cards configuration for social sharing.
Social Preview Data¶
Title, description, and image for social sharing.
Staging¶
Staging/pre-production environment.
Standalone¶
Standalone document, not linked to a course.
Starts With¶
Prefix match (LIKE value%).
Statics Generator¶
Extensions declare definitions for tasks, events, caches, access capabilities, services, messages, hooks and file areas. The statics generator reads these declarations and produces the corresponding Moodle integration files (db/tasks.php, db/events.php, etc.), replacing multiple individual generation scripts with a single CLI.
- Referências:
- ADR-305
Status¶
System status tab displaying environment info, Moodle version, PHP version and extension health checks.
Step Completion¶
Record of an individual step completion by the student.
Step Requirement¶
Flag that defines whether the step is required or optional in the path.
Stored File¶
File upload stored in Moodle file area.
Structured Data Config¶
JSON-LD schema configuration (Course, Organization) for structured data.
Structured Data Schema¶
Basic JSON-LD schema for Course and Organization.
Study Plan¶
Study schedule generated for a student in a path, with deadline, distributed goals and adherence.
- Ver também: Plan Goal, Plan History
Submission Failed¶
Event emitted when submission processing fails.
Submission Processed¶
Event emitted when a submission is successfully processed.
Submission Queued¶
Event emitted when a submission is queued for processing.
Submission Received¶
Event emitted when a submission is received and persisted.
Submission Status¶
Submission status in the processing lifecycle.
Succeeded¶
Execution completed successfully.
Success¶
Score >= 80. System healthy.
Support¶
Support classes live in framework/moodle/support/ and serve as the boundary between framework code and Moodle globals. They contain no business logic — only interface translation and type conversion. Each class maps to a Moodle subsystem (enrol, course, user, etc.).
-
Ver também: Adapter
-
Referências:
- ADR-203, ADR-201
Support Center (helpdesk)¶
Extension for integrated student support and assistance within Moodle.
Suspended¶
Access temporarily suspended.
Suspended¶
Access temporarily paused, cycle preserved.
System¶
System-wide scope — matches all contexts.
System¶
Data originated from the system.
System Role¶
Match users with a specific system-wide role assignment.
System Status¶
Collects environment information across 9 sections: environment, MIDDAG, extensions, settings, plugins, themes, cron, requirements.
- Ver também: Extension Info
System Status Service¶
Domain service that collects environment and system information across 9 sections for the admin status tab.
- Ver também: Extension Info
T¶
Table Export Failed¶
Individual table/view export failure.
Table Exported¶
Table/view exported successfully.
Table Result Status¶
Export result status of an individual table/view.
- Ver também: Job Table Result
Template Activated¶
Template activated and available for emission.
Template Archived¶
Template archived, no new emissions allowed.
Template Created¶
New document template created.
Template Field¶
Dynamic field of the template that references data from the profile, course, or system.
Template Status¶
Lifecycle status of the document template.
Template Variable¶
Substitution variable in the template: {user.firstname}, {course.fullname}, {date.now} etc.
Terminated¶
Permanently terminated membership.
Test Connector Connection¶
Invokes connector_interface::health_check() for the connector type. Produces a Health Check Result value object. Updates connector status based on success/failure: success=true → connected; first failure after connected → degraded; consecutive failures → disconnected. Dispatches Connector Health Changed signal on status transition.
- Ver também: Health Check Result, Connector Health Changed
Text¶
Single-line text input.
Text¶
Free text field.
Textarea¶
Multi-line text input.
Third-Party Extensions¶
Integration mode in which an external Moodle plugin registers a complete extension (with register/boot lifecycle) in MIDDAG via the extend_local_middag_extensions hook.
- Ver também: Extension (base), Extension Loader
third_party¶
Third-party extension registered via extend_local_middag_extensions. Responsibility of the external developer.
Throttle Config¶
Configurable delivery limit per period for rate control.
Ticket¶
Support ticket with context, messages, internal notes and lifecycle. Always belongs to a department.
- Ver também: Ticket Message, Internal Note, CSAT Response, Ticket Status, Ticket Context, SLA Status, Escalation Note, CSAT Rating
Ticket Assigned¶
Event emitted when an agent takes ownership of the ticket.
Ticket Closed¶
Event emitted when a ticket is permanently closed.
Ticket Context¶
Automatic ticket context: course_id, activity_id and user_id.
Ticket Created¶
Event emitted when a new support ticket is opened.
Ticket Escalated¶
Event emitted when a ticket is moved to another department.
Ticket Message¶
Public message exchanged between student and agent within the ticket context.
Ticket Reopened¶
Event emitted when a ticket is reopened by the student, resetting status to new.
Ticket Resolved¶
Event emitted when a ticket is marked as resolved.
Ticket Status¶
Ticket status in the support workflow.
Time¶
Time-of-day selector (HH:MM).
Tool Result¶
Returned by tools_service::execute() after running a maintenance action. Readonly value object implementing JsonSerializable. Named constructors: ok(message), fail(message). Replaces the untyped array {success, message}.
Tools¶
Maintenance tools tab with administrative actions (cache purge, diagnostics, etc.).
Tools Service¶
Domain service that executes administrative maintenance actions. Dispatches each Maintenance Tool case to its handler and returns a Tool Result.
- Ver também: Maintenance Tool, Tool Result
Total Block¶
Blocks all Moodle access until compliance is met.
Transaction Approved¶
Payment approved.
Transaction Cancelled¶
Transaction cancelled or refunded.
Transaction Defaulted¶
Late payment or default detected.
Transaction Manager¶
Centralizes database transaction management, encapsulating the compatibility workaround between the Moodle 4.x transaction model and modern PHP Throwable.
-
Ver também: Repository
-
Referências:
- ADR-302
Transaction Received¶
Transaction received from the external world.
Transaction Status¶
Commercial status of the transaction in the order lifecycle.
- Ver também: Order Transaction
Translatable Field¶
Translated field of the item: fullname, summary, name, or intro.
Translatable Item¶
Reference to the translatable item: type (course, section, activity) and ID.
Translated Content¶
Translated content of the field in the specified language.
Translation Entry¶
Translation of a specific field in a given language for the translatable item.
Translation Set¶
Set of translations for a translatable item (course, section, or activity).
- Ver também: Translation Entry
Trigger Config¶
Stored as JSON in action_trigger.config_json. Valid fields depend on trigger_type. Field mappings by trigger_type: - form_submission: form_id (int, customform form ID). - event_signal: event_class (string, FQCN of the signal class). - schedule: cron_expression (string, standard cron format). - manual: (no config needed). - item_transition: item_type (string), from_status (string), to_status (string). PHP: readonly value object with factory method from_json(string, trigger_type).
Trigger Type¶
Defines what event source can activate a workflow action. Core provides 5 built-in types. Built-in types: - form_submission: fires when a customform form is submitted (config: form_id). - event_signal: fires when a domain signal is dispatched (config: event_class FQCN). - schedule: fires on a cron schedule (config: cron_expression). - manual: fires when an operator explicitly triggers via admin UI. - item_transition: fires when an item changes status (config: item_type, from_status, to_status). Each type determines the valid trigger_config structure.
U¶
Unconfigured¶
No credentials stored yet.
Unit Type Label¶
Singular/plural label pair per tenant for a canonical unit type.
Update Segment¶
Updates segment properties. Changing match_type invalidates the cached evaluation. Status transitions are validated: only draft->active, active->archived, archived->active are allowed. Changing status to archived does not delete the segment.
URL Param¶
Parameter from the current URL.
Used¶
Allocation consumed — access granted.
User Compliance¶
User compliance state relative to a compliance_policy. Records status, deferral and verification history.
- Ver também: Compliance Deferral, Compliance Check Log, Compliance Status, Check Result
User ID¶
ID of the logged-in Moodle user.
User Profile¶
Data originated from the user profile.
User Progress¶
User progress in a path, with overall status, per-step completion and percentage.
- Ver também: Step Completion
V¶
Validation Code¶
Unique code for verifying the authenticity of the emitted document.
Validation Pattern¶
Validation regex applied to the profile field by the compliance rule.
Validator¶
Contract for entity and DTO validation. Implements validator_interface with validate() returning a result with collected errors. Used by services before persistence.
-
Ver também: Result
-
Referências:
- ADR-401
Validity Window¶
Post-completion validity interval defined by the course enrolment policy.
Version Content¶
Code content in this snippet version.
Version Metadata¶
File version metadata: timestamp, replaced by, size, and mime type.
Video Entry¶
Video in the centralized repository with course referencing via shortcode.
- Ver também: Video Reference, Video Tag
Video Reference¶
Reference of a video in a course via shortcode [videolibrary id=X].
Video Status¶
Lifecycle status of the video in the repository.
Video Tag¶
Organization tag for classifying videos in the repository.
View¶
Read-only admin dashboard access. Archetypes: teacher, editingteacher, manager.
View Source¶
SQL view origin: product default or registered by plugin via callback.
- Ver também: Export View
W¶
Warning¶
Score >= 50. Some issues detected.
Webhook¶
Inbound webhook receiver from external service.
Webhook¶
Sends data to an external URL via webhook.
Webhook Endpoint¶
External endpoint configured to receive events via HTTP POST. Controls destination URL, authentication (Bearer/HMAC) and subscriptions.
- Ver também: Event Subscription, Auth Config, Endpoint Status
Webhook Payload¶
Serialized JSON of the event with fixed structure.
Widget¶
Reusable interface component rendered inside plugin screens or blocks.
- Referências:
- ADR-803
Widget Instance¶
Widget instance on the panel with specific configuration. References a valid widget_registration.
Widget Metadata¶
Name, icon, description, and source extension of the widget.
Widget Registered¶
New extension registered widget via CC-04.
Widget Registration¶
Widget registration provided by an extension via callback (CC-04). Controls name, data type, resolution, pre-computation, and cache.
- Ver também: Metric Cache, Widget Metadata, Data Resolver, Cache Config
Widget Unregistered¶
Extension deactivated, widget removed.
Workflow Action¶
A workflow action is a named, typed operation that extensions provide and the workflow engine orchestrates. Actions are triggered by events (form submissions, signals, schedules, manual operator actions, item status transitions) and executed with a payload. Business rules: - Each action belongs to one extension (via extension field) and has one action_type. - Actions are registered in the workflow_registry during boot(). - An action can have multiple triggers — ANY matching trigger activates the action. - Executions are logged for audit (action_execution children with status + payload + result). - payload_schema_json defines the expected input structure (JSON Schema format). - The engine validates the trigger payload against the schema before executing. - Enabled=false disables the action without removing its triggers. - Consumers: customform (post-submission actions), helpdesk (ticket routing), docbuilder (document emission after approval). Persistence: EAV via middag_items (type: workflow_action) + middag_itemmeta. Contract: workflow_action_interface + workflow_registry_interface in framework/contract/.
- Ver também: Action Trigger, Action Execution, Action Type, Execution Payload, Action Execution Completed, Connector, Audit and Traceability
Workflow Action Registration¶
Each extension that provides workflow capabilities registers its action types in the workflow_registry during boot(). Registration includes the action type identifier, handler class, supported trigger types, and payload schema. The workflow engine discovers available action types through the registry.
Workflow Guard Condition¶
Optional guard evaluated after payload validation but before action execution. Extensions can register guard conditions per action type. When a guard fails, the execution is recorded with status skipped and the reason in result_json. Guards are distinct from payload validation: they check business state, not input format.
Workflow Payload Validation¶
Guard rule evaluated before Execute Workflow Action. Compares the incoming payload structure against the JSON Schema defined in the action's payload_schema_json field. Rejects execution if the payload is malformed or missing required fields.
Workflow Registry¶
Registry that manages available workflow action and trigger types. Extensions register implementations during boot() via the workflow_registry_interface @api contract.
- Ver também: Workflow Action
Workflow Service¶
Central service for the workflow capability. Orchestrates action dispatch, trigger evaluation, execution lifecycle management, and registry operations. Responsibilities: - Dispatch workflow actions when triggers fire. - Execute actions with validated payload and record audit trail. - Manage the action/trigger type registry (delegate to workflow_registry_interface). - Dispatch Action Execution Completed signals on terminal states. Implements workflow_registry_interface for registry operations. Extensions register action types during boot().
- Ver também: Workflow Action, Action Trigger, Action Execution, Action Type, Trigger Type