Native requirements / continuing-education tracking module

[kainhofer]

Feature request: Native requirements / continuing-education tracking module

Summary

I would like to propose a new native Admidio core module called Requirements.

The module is intended to track recurring requirements that members of an organization must fulfil, for example:

• CPD / continuing professional development
• IDD requirements
• CADS / CERA requirements
• security training
• recurring certifications or examinations
• other organization-specific training or qualification requirements

A first implementation of the module already exists locally and currently covers:

• training/activity providers
• activities entered by users
• administrative review of activities
• actual attendance time
• activity status and review information
• visibility/edit permissions
• changelog integration
• module preferences
• database installation/update support
• native Admidio presenters, services, entities and Smarty templates

The next phase would add requirement types, role-dependent credit requirements, credits assigned to activities, fulfilment calculation/visualisation and activity import.

The intention is to implement this as a normal Admidio core module and to follow existing Admidio architecture and UI patterns rather than introduce a separate framework or subsystem.

Main use case

An organization can define a requirement such as:

Full members must obtain 15 CPD credits per calendar year.
Associated members must obtain 10 CPD credits per calendar year.

The requirement is linked to normal Admidio roles.

A member records an activity such as a course, seminar or examination and assigns the credits from that activity to the appropriate requirement period.

The activities view then shows whether the member has fulfilled the applicable requirements for the current and previous periods.

Administrators can review activities and accepted credit values.

Requirement types

A requirement type would contain, among other things:

• name
• short name
• description
• active/inactive state
• period definition:
  • year
  • quarter
  • month
  • week
  • recurring every 1–10 years based on the most recent relevant fulfilment
• handling when several affected roles apply to the same member:
  • highest requirement
  • lowest requirement
  • sum of the requirements

Examples:

• CPD — calendar year
• IDD — calendar year
• security training — every three years from the last fulfilment

Requirements by role

The required number of credits may differ between roles.

Example:

Role	CPD requirement
Full member	15
Associated member	10

A role-specific rule would also define whether a requirement applies:

• in full whenever the user held the role during any part of the period, or
• pro rata according to the duration of the membership.

Existing historical Admidio role memberships should be used when calculating earlier periods.

Rules can have validity dates so that changed requirements are not applied incorrectly to older periods.

For example:

• 2024–2025: Full members require 12 CPD credits
• from 2026: Full members require 15 CPD credits

Activity credits

Activities can contribute different numbers of credits to different requirement systems.

Example:

One seminar may count as 6 CPD credits and 3 IDD credits.

Credit records would contain:

• activity
• requirement type
• requirement period/reference
• credits claimed by the user
• credits accepted by an administrator/reviewer

If an accepted value exists, it is used for fulfilment calculations. Otherwise the claimed value is used.

An accepted value of 0 therefore explicitly means that no credits were accepted and must override the claimed value.

Users can enter credits for any requirement type, even if that requirement currently does not apply to one of their roles.

Explicit assignment to a requirement period

The period to which an activity contributes cannot always be derived from the activity date.

For example:

• a university course may run from September until January;
• the associated examination may take place in February;
• the organization may decide that the complete course credits count toward only one particular year.

Therefore each activity-credit record must explicitly identify the period to which the credit applies.

One activity-credit entry always contributes to exactly one requirement period.

Fulfilment view

Above the activity list, the module should show a compact fulfilment overview for the logged-in user.

For each applicable requirement type it could show:

• required credits
• attained credits
• percentage fulfilled
• progress bar
• current period
• selected number of previous periods

For recurring requirements such as security training it should show:

• last relevant fulfilment
• next due date
• whether the requirement is currently fulfilled or overdue

Credits entered for requirement types that do not apply to the user's roles should be shown separately as additional attained credits.

The number of previous periods should be selectable as a normal view/filter parameter rather than a permanent user preference.

Import

Activities should also be importable from CSV and, if appropriate using the existing Admidio import infrastructure, XLSX.

Recommended format:

• one row per activity
• fixed columns for activity data
• dynamic columns for requirement credits

Example:

provider_short_name,title,begin_date,end_date,credit_CPD,period_CPD,credit_IDD,period_IDD
ACME,University Course,2025-09-01,2026-01-31,10,2026,2,2026-Q1

Administrators could import activities for arbitrary users.

Normal users could import activities only for themselves.

Users in administrator imports could be resolved through:

• Admidio user ID, or
• a selected profile field such as e-mail address, username or membership number.

Providers could be resolved through:

• provider ID, or
• provider short name.

Providers would need to exist before import.

Permissions

For the initial implementation no new role permission is proposed.

The module should use the normal Admidio mechanisms:

• module visibility through Component
• normal logged-in users manage their own activities
• normal administrators manage requirement configuration and review other users' activities
• no separate requirements-administrator role right for now

This can be extended later if a dedicated reviewer permission becomes necessary.

Changelog

Requirement definitions, role-specific rules, activities, providers and activity credits are audit-relevant and should support the existing Admidio changelog infrastructure where appropriate.

All new database tables use the normal Admidio audit columns.

Database approach

The proposed extension intentionally keeps the database model small.

In addition to the existing provider and activity tables, the next phase would require only three main tables:

• req_requirement_types
• req_requirement_role_rules
• req_activity_credits

req_requirement_role_rules combines both the role assignment and the role-specific credit requirement. This avoids introducing separate generic assignment and rule tables.

Open design questions

Before continuing implementation, feedback would be particularly useful on:

1. Whether this belongs in Admidio core rather than as a plugin.
2. Whether role-specific requirements should use a normalized cross-reference table or follow any existing Admidio convention of storing role IDs directly in configuration fields.
3. Whether the proposed three-table extension is sufficiently lean.
4. How requirement-type and activity-credit history should best be presented through the existing changelog.
5. Whether CSV plus XLSX should both be supported initially or CSV should be the first implementation.
6. Whether a dedicated reviewer permission should remain out of scope for the first version.
7. Whether the fulfilment overview belongs directly above the activity list or should additionally receive its own overview page.

The aim is to settle the data model and integration approach before implementing the next part of the module.