Contents

Getting oriented

• What this plugin does
• Who this is for
• Core concepts

Learner journeys

• Learner: find a seminar in the catalogue
• Learner: book a seminar or join the waitlist
• Learner: cancel a booking
• Learner: change a booked seminar date
• Learner: keep seminars in your calendar (iCal)
• Learner: sessions in your personal Moodle calendar
• Learner: track your bookings in My Seminars
• Learner: record your accommodation need
• Learner: register interest in an undated topic
• Learner: submit a travel-cost claim

Manager journeys

• Manager: book seminars for your team
• Manager: approve booking requests
• Manager: channel team demand into scheduled seminars

Trainer journeys

• Trainer: accept an assignment from the pool
• Trainer: run a session and record attendance
• Trainer: check participants in with the QR scanner
• Trainer: maintain your trainer profile
• Trainer: complete delegated tasks
• Trainer: review aggregated feedback

Platform administration journeys

• Platform administration: work from the dashboard
• Platform administration: review the KPI charts
• Platform administration: create and maintain seminar templates
• Platform administration: plan Runs and Sessions
• Platform administration: assign course managers
• Platform administration: use the course calendar (agenda)
• Platform administration: create a recurring Run series
• Platform administration: manage participants and the waitlist
• Platform administration: book on behalf and create and book a person
• Platform administration: manage buildings, rooms and equipment
• Platform administration: manage trainers
• Platform administration: export participant and signature lists
• Platform administration: generate documents from templates
• Platform administration: import Runs and bulk-edit
• Platform administration: mass-book with the Bulk booking Matrix
• Platform administration: set up approval workflows
• Platform administration: require a pre-booking form
• Platform administration: send serial messages to participants
• Platform administration: manage mandatory training
• Platform administration: manage accommodation needs
• Platform administration: capture and convert demand-requests
• Platform administration: curate catalogue search tiles
• Platform administration: delegate tasks to trainers
• Platform administration: manage the Seminar Manager work plan
• Platform administration: cancel a Run
• Platform administration: set seminar prices and payment methods
• Platform administration: reconcile payments
• Platform administration: settle travel-cost claims
• Platform administration: run the DATEV export
• Platform administration: tune reminders and the Seminar Manager digest
• Platform administration: monitor Certify proof status

Site administrator journeys

• Site administrator: complete the initial setup
• Site administrator: manage global notification templates
• Site administrator: curate delegatable task types

Reference

• Settings that matter
• Limitations
• Troubleshooting
• Appendix: page and URL inventory
• Related documents

What this plugin does

Manager pages keep explanatory guidance behind the Moodle Core ? help icon next to the relevant heading. This keeps the workflow compact while preserving the same guidance for keyboard and assistive-technology users.

Seminar Management (local_lernhive_seminarmanagement) is LernHive's complete event-training workflow: learners find and book seminars in a unified catalogue, trainers run sessions and record attendance, and administrators plan topics, dates, rooms, waitlists, approvals, payments and travel costs — with notifications, exports and audit trails throughout. It covers the whole lifecycle from "we should offer this" (demand-requests) to "everyone attended and the bookkeeper has the CSV" (attendance proof, DATEV export).

Pure learners normally enter seminars through My seminars in the primary navigation (Learn) or the catalog block. The launcher entry Planning is administrative: it appears for trainers, Seminar Managers, approvers, and site managers. Inside the Plugin Shell, learners see Catalog and My seminars. System-level seminar managers additionally see Dashboard, Runs, Seminar templates, and, when permitted, Approvals. Category-only approvers receive the direct Approvals destination. The Settings gear is reserved for master data and templates and is filtered by the same system-level capability rules as its destination.

Learner and guest self-service pages keep the shared Plugin Shell title and available actions, but do not show the Seminar Manager workspace navigation. This keeps pages such as Meine Reisekostenanträge, demand interest, pre-booking, guest booking and guest claim focused on the task at hand while the learner navigation model remains intentionally small.

The next manager interface will replace large trainer, room and Moodle-course selects with search-and-more pickers. Their paged, permission-scoped server foundation is available from 0.4.86; this release does not yet cut the current forms over to the new interaction.

Who this is for

Resource readiness before publishing

Seminar Managers with resource access see a readiness panel on Settings. It counts locations without rooms, rooms missing capacity or equipment, and Runs whose required equipment is not available. Each signal has one Review action leading to the relevant management surface. The panel is scoped to the Seminar Manager's permitted categories; global resources remain available to all permitted categories.

Key capabilities

Access is decided by capabilities (db/access.php); the five roles above are the documentation lens. The capability set falls into four classes:

• Self-service capabilities — granted to every logged-in user archetype (student, user, teacher, manager): catalogue viewing, self-booking, cancelling own bookings, demand interest, travel-cost submission.
• Coordinate capabilities — acting on other users' data; granted to manager and (scoped, per) editingteacher: booking for others, approval steps, attendance, mark-paid, expense approval.
• Manage capabilities — Seminar Manager-side management of the seminar structure; granted to manager (and to the Seminar Manager role).
• Admin capabilities — no archetype defaults (site admin only): global resources, template configuration, structure lock, task types.

Capabilities apply at course-category context unless marked "site admin only". Site admins may adjust archetype defaults at Admin → Users → Permissions → Define roles.

Who may act for other people

The capability opens the page; the scope decides for whom you may act (decision P10, 0.4.147):

• Attendance and waitlist follow the Seminar. Trainers assigned to the Run or to the Session and the Seminar Managers of the Run's category (:coordinate, or the system-wide :manage) record attendance and handle the waitlist for every participant, including external people and people outside their reporting line. The attendance capability alone is not enough: without an assignment or coordination the attendance sheet is refused. Participants still check themselves in. Trainers open the waitlist of their Run from My assignments (Waitlist next to View, for Runs with a waitlist; 0.4.152); the waitlist of other Runs stays closed to them. Next to it, Runs with Sessions offer Attendance (decision R13, 0.4.159): a Session assignment opens that Session's attendance sheet, a Run assignment the list of the Run's Sessions. The workplan link of tasks with the action record_attendance opens the same list.
• Booking for others keeps the reporting line: team leads book the people who report to them. Whoever holds :coordinate in the Run's category books anyone.

Assigning the Seminar Manager role

1. Go to Site administration → Users → Permissions → Assign system roles — or navigate to the target course category and use Category → Permissions → Assign roles.
2. Pick Seminar Manager (Seminarmanager/in).
3. Add the users who should be the operational owners for that category.
4. They immediately see the administrative Seminarverwaltung entry and the Settings gear / dashboard tools allowed by their capabilities.

Core concepts

Catalog

A single, unified place to find all seminar offerings that apply to the user — regardless of format.

My Seminars

The learner's personal overview of upcoming and past bookings, with status and actions.

Seminar template (technical record: Topic)

The reusable template that administrators build once and create Runs from („Seminarvorlage“). Participants see it as the Seminar: the catalogue shows it once, even when several alternative Runs are available.

Course template

A Moodle course used as the template that is copied for a new seminar course (course linkage strategy Create from course template, „Kursvorlage“).

Run (technical record: Booking)

One concrete delivery of a Seminar. Several Runs can be alternative date choices; a participant selects exactly one of them.

Session (technical record: Slot)

One required time window within a Run. A two-day Run therefore has two Sessions that belong together and are booked as one unit. For online or hybrid Seminars, administrators can add Session-specific meeting metadata such as the virtual room link, meeting provider, meeting ID and dial-in information; blank Session values inherit the Run-level metadata.

Guest booking

A booking for a person without a LernHive account. Retired by decision P12: nobody is booked without an account any more ("Create and book a person" creates the account). Guest bookings made before stay readable and can be converted into an account.

Approval (Stufe 2)

A required sign-off (by supervisor, mentor, or Seminar Manager) before a booking becomes effective.

Mandatory Training (Stufe 2)

A seminar flagged as required for a defined audience, with a deadline and escalating reminders.

Run status lifecycle

planned
  │
  ▼
bookable ──── (participants book) ──► booked
  │ │
  └── (Seminar Manager manually) ─────────────► executed
                                            │
                                            ▼
                                          closed

Any state → cancelled (terminal)

Journeys by role

Learner: find a seminar in the catalogue

What it does: shows all seminars that are bookable for the user, across every format, searchable and filterable.

1. Open the seminar catalog from a dashboard/catalog block or the Plugin Shell Catalog tab (for example from My seminars in the primary navigation, Learn) (/local/lernhive_seminarmanagement/catalog.php).
2. Use search or filters (format, trainer, period, category, tag) — or click one of the visual tiles above the search box to land in a pre-filtered view. In the monthly view, every alternative Run appears once on the day of its first Session. A multi-Session Run is not repeated on every Session day, and the date is not redundantly printed inside the dated calendar cell.
3. Open a card or list entry.
4. Review the detail page: full info, overlap warnings, optional "Trainer kontaktieren".
5. Click "Jetzt buchen" ("Book now").

Seminars marked "Visible without login" additionally appear in an anonymous teaser catalogue within their configured from/until window; the "Log in to book" button hands anonymous visitors to the configured portal or self-registration entry point. The teaser pages (Run detail, Seminar overview, date choice) are public only while the learning catalogue is public (Make the learning catalogue public in LernHive) and Force users to log in is off; otherwise they send signed-out visitors to the login. The seminar template image and images in the Seminar description follow the same rule, so signed-out visitors see them on the public pages. Moodle's guest access counts as signed out (decision P37, 0.4.163): guests see the teaser pages and the Seminar images only under the same conditions, otherwise they are sent to the login.

Expected result: I understand what is on offer and can decide whether to book.

Learner: book a seminar or join the waitlist

What it does: places me in a seminar, either confirmed or queued, and keeps me informed.

1. On a Run detail page, click "Jetzt buchen".
2. Review the binding confirmation. It lists the Seminar and selected Run, every Session, cost or explicit cost-free status, approval path, current capacity, assigned trainers, registration deadline when configured, and the applicable cancellation terms. Cancel returns to the same Run and creates no participation.
3. For a paid Run, choose Honorarium account, SEPA direct debit, or Invoice. Previously saved payment details are prefilled and remain editable. Honorarium accounts require the authorisation checkbox; SEPA requires a valid IBAN, BIC, and mandate confirmation. The generated SEPA mandate reference is shown in the confirmation message.
4. Select Book now to make exactly one booking. If asked, complete a pre-booking form, then confirm the displayed terms again.
5. If asked, pick addons / accommodation (Stufe 2).
6. I receive a confirmation email with .ical attachment (and a calendar event, depending on platform settings) — or a waitlist notice.
7. Later: see the booking in "Meine Seminare" and "Meine Kurse".

Expected result: I have a record in "Meine Seminare" with the correct status.

Limitations / notes

• If I am already in an overlapping Run, I get a soft warning but can proceed.
• If a pre-booking form applies (Stufe 2), I must complete it before the booking is finalized: clicking "Jetzt buchen" routes me through the form first; the booking only finalizes after submit.
• If the Run requires approval (Stufe 2), the booking enters "Pending approval" until the approver chain signs off.
• For priced Runs (Stufe 3) the price appears on the catalogue card and detail page, e.g. 149,90 EUR, plus a "zahlungspflichtig" hint whenever payment is actually required; with "Zahlung erforderlich" the participation holds in pending_payment until payment is recorded or made.
• The confirmation email contains a personal check-in QR code; "Meine Seminare" offers "Show check-in QR" so the trainer can scan it at the door.

Learner: cancel a booking

What it does: lets me cancel a booking with a required reason.

1. Open "Meine Seminare".
2. Click "Stornieren" on the relevant booking.
3. Enter a reason (mandatory).
4. Confirm.

Expected result: my booking is cancelled; Seminar Manager and trainer are notified; if auto-promote is on, the next waitlist entry is promoted.

Self-cancellation requires both the Run's learner-cancellation rule and the cancel_own capability in its seminar category. If either is missing, "My seminars" and the Run detail explain why online cancellation is not available and direct the learner to the seminar team. Opening a saved direct cancellation URL shows the same guidance instead of a technical error.

Learner: change a booked seminar date

What it does: moves an existing confirmed place or waitlist position to another Run of the same Seminar without a cancel-then-book gap.

1. Open My seminars and select Change date on the relevant entry.
2. Compare the alternative Runs. Every card lists all Sessions that belong to that Run, plus location and current availability.
3. Select the new Run.

The current place remains active while the target is checked. Source cancellation and target booking are committed together; if the target is no longer available, nothing is changed. A full Run can result in a new waitlist position when its waitlist is open.

Direct self-service is deliberately limited to the clean path. A Run that requires approval, payment, a pre-booking form, or would incur a cancellation fee must be changed through the seminar team so that approvals, answers and financial history are preserved.

Expected result: My seminars shows only the newly selected Run; personal calendar entries and Moodle-course access follow the new active participation.

Learner: keep seminars in your calendar (iCal)

What it does: adds booked seminars to my calendar and reminds me before they start. No active use needed — it just happens.

1. Book a seminar.
2. The .ical attachment is in my confirmation email — one VEVENT per Slot.
3. A platform-calendar event may also appear (dLMS default, BasisSH opt-in).
4. I can subscribe to a dynamic feed under my account preferences.

Dynamic subscription feed

1. Go to your account → Seminare abonnieren (or the Seminar Manager shares the URL).
2. URL format: /local/lernhive_seminarmanagement/ical_subscribe.php?token=<user-token>
3. The token is per-user and not session-authenticated, so Outlook, Apple Calendar, and Google Calendar can poll it.

Status changes (cancellation, rescheduling) bump the .ical SEQUENCE so external calendars update automatically on the next poll.

If Platform calendar integration is enabled in the plugin settings, a LernHive calendar event (using the Moodle core calendar) is created in user scope on every confirmed booking. Calendar events are updated on reschedule and removed on cancellation.

Expected result: my calendar reflects the latest state of my bookings.

Learner: sessions in your personal Moodle calendar

What it does: confirmed seminar sessions appear in your personal Moodle calendar automatically — no iCal setup required.

1. Once my booking is confirmed, every session of the seminar shows up in my Moodle calendar (Dashboard calendar block and /calendar).
2. Trainers and course managers additionally see the sessions of the seminars they are assigned to.
3. Cancellations and rescheduling clean the entries up automatically.

The calendar shows my sessions only. The overview of everything bookable lives in the learning catalogue's monthly view (/local/lernhive/catalog.php?view=month).

Learner: choose a seminar date option

What it does: the learning catalogue shows one stable Seminar instead of repeating one card for every alternative Run.

1. Open the Seminar card in /local/lernhive/catalog.php.
2. Compare the available date options. Each option lists every included Session plus its location, trainer, price and current capacity.
3. Open exactly one option, review its complete detail and book it.
4. Use "Back to date choices" to compare another option without leaving the Seminar context.

An active confirmed, approval-pending or waitlisted Run prevents a second alternative of the same Seminar. After cancellation, another option may be booked. Legacy Runs that have no Seminar relation remain separate catalog items.

Learner: track your bookings in My Seminars

What it does: a personal overview of my bookings with status and actions.

1. Open "Meine Seminare" from the Plugin Shell section navigation or a dashboard block (/local/lernhive_seminarmanagement/my.php).
2. Switch between "Anstehend", "Warteliste" and "Vergangen".
3. Use the action buttons: "Kalender", "Termin wechseln", "Stornieren", "Zum Kurs" — the date-change action only appears when a direct alternative is safe and available; the course button only appears while your Moodle-course enrolment is active; a configured link without current access is not shown.

Mandatory trainings show a "Pflichtschulung bis [date]" badge (Stufe 2). When Certify is installed, participants see whether their own certification period has already been issued (Stufe 2). Signed documents and Certify-issued proof links appear under "Meine Dokumente".

Expected result: I have a single source of truth for my seminar commitments.

Learner: record your accommodation need

What it does: tracks accommodation needs for multi-day Runs.

1. After booking, you are asked whether accommodation is needed.
2. Answer "not yet known", "no accommodation", "room needed", or "room with partner"; optionally add a night range plus a planning note (hotel_need.php).
3. The Run detail keeps the answer visible and editable until a Seminar Manager-set deadline.

Expected result: the administrator can plan hotel capacity from real answers instead of guesses.

Learner: register interest in an undated topic

What it does: lets you register interest in a topic that has no scheduled date yet, optionally with a wished period and a comment.

1. On the Catalog, switch to the "Auf Anfrage" tab.
2. Open the request → click "Interesse bekunden" (demand_interest.php).
3. Add an optional period and comment, submit.
4. You are notified by email when the request converts to a real Run — your interest is automatically migrated to a participation.

Expected result: demand is registered; you do not have to monitor the catalog manually for the topic to appear.

Learner: submit a travel-cost claim

What it does (Stufe 3): lets a participant of an executed Run submit a travel-cost claim (per-diem, mileage, public transport, lodging) and resubmit when a revision was requested.

1. Open the Run detail at view.php?id=<n> — once at least one Slot is past (or the Run is executed), the action box "Reisekosten" appears, within the configured submission window.
2. Click "Antrag stellen" → expense_submit.php opens — the form has hideIf logic (e.g., distance_km is hidden unless travel mode is car), per-Slot day claims, lodging, public-transport tickets, optional receipt attachments.
3. Submit; the claim status is pending.
4. Track all your claims under "Meine Reisekostenanträge" (expense_my.php).
5. If the Seminar Manager requests a revision, the claim re-opens (needs_revision) for editing and the same expense_submit.php is reused for resubmission.

Expected result: a submitted claim that the administrator can decide on; a personal queue that shows every claim's current state.

Manager: book seminars for your team

What it does: lets an authorized user book seminars for other people. The book_for_others capability is granted to the editingteacher archetype for team leads inside their reporting scope — and to Platform administration everywhere. The Seminar Managers of the Run's category (:coordinate) book without a reporting line.

1. Open a Run detail page → "Buchung im Auftrag" (book_for_others.php).
2. Use the participant picker to select one or more LernHive users.
3. Submit. Each bookee receives a separate confirmation email.

The booker_id is stored separately from participant_id so the audit trail always shows who booked whom.

Expected result: each bookee gets a confirmation; the booker has a clean overview of who they booked where.

Manager: approve booking requests

What it does (Stufe 2): when a seminar template or Run requires sign-off, bookings route through a serial approver chain before they become effective. With chain resolvers, the "Supervisor" resolver puts the reporting line — you — into the chain automatically.

1. After a report clicks "Jetzt buchen", their booking enters pending_approval.
2. Each approver in the chain receives a daily digest of pending items.
3. Work through the "Genehmigungen" queue (/local/lernhive_seminarmanagement/approvals.php) — only approval steps assigned to you are listed.
4. Approve or Reject with an optional decision note.
5. On final approval: status confirmed, confirmation email with .ical sent. On any rejection: status rejected, participant notified with reason.

Approval status is stored separately from booking status so the audit trail can distinguish "never approved" from "approved then cancelled later."

Expected result: only approved participants appear as confirmed.

Manager: channel team demand into scheduled seminars

What it does: demand-requests capture "interest in a topic that has no scheduled date yet" — a lightweight way to signal training needs for your team before anything is scheduled.

1. On the Catalog, open the "Auf Anfrage" tab to see open demand-requests.
2. Register interest yourself ("Interesse bekunden") and point your team members to the request — every logged-in user can register interest.
3. Once the interest threshold is reached, the responsible administrator is alerted via the daily digest and converts the request into a real Run.
4. Interested users are migrated and notified automatically; book any remaining team members via "Buchung im Auftrag".

Expected result: team training needs surface early and convert into bookable dates without chasing anyone by email.

Trainer: accept an assignment from the pool

What it does: shows me my assignments, the open pool, and my profile.

1. Open the administrative "Seminarverwaltung" entry and go to the trainer perspective (/local/lernhive_seminarmanagement/trainer.php).
2. Open "Offene Anfragen" — the pool of Runs needing a trainer.
3. Filter by own Fachthema.
4. Click "Anfrage annehmen".
5. In Stufe 1 (MVP) the assignment goes directly to confirmed-trainer status; in Stufe 2 with approval the Seminar Manager confirms first and the trainer receives a confirmation.
6. The booking appears in "Meine Einsätze".

The system blocks accepting or saving a trainer assignment if the trainer already has a confirmed Slot overlapping the same time window.

Expected result: I can plan and execute my teaching without calling the Seminar Manager.

Trainer: run a session and record attendance

What it does: records who attended, per Slot.

1. Open "Meine Einsätze", pick the Run for today.
2. Open the participant list, pick the Slot (attendance.php?slotid=<n>).
3. Select present / absent / excused / partially attended / no record (or use "all present"). Leave the optional minutes field empty except when you want to record the duration of partial attendance.
4. Add notes per participant if needed. Invalid minute values are highlighted in the affected row; the submitted status and note remain available for correction.
5. Optionally upload the signed attendance sheet.
6. Save and close the Slot.

Attendance corrections write an append-only audit trail (local_lhsem_attendance_log) shown as a collapsed correction-history panel on the attendance sheet.

Expected result: Run rolls up status; participants' attendance records are updated; later, Certify can issue certificates from this proof (Stufe 2).

Trainer: check participants in with the QR scanner

What it does: every confirmation email contains a personal check-in QR code (qr.php); participants can also open it from "Meine Seminare" via "Show check-in QR". The trainer scans it at the door to record attendance.

1. Open the QR scanner ("Open QR scanner", /local/lernhive_seminarmanagement/attendance_scanner.php).
2. Pick the target slot — the scanner offers slots within the scan window (past 12h to next 7 days).
3. Scan the participant's QR code, or paste the check-in token / full check-in URL manually.
4. The page confirms "Checked in: <name> …"; duplicates report "Already checked in". The "Recent check-ins" list shows what was recorded.

Expected result: attendance is recorded at the door without paper lists.

Trainer: maintain your trainer profile

1. Open the trainer perspective → "Mein Profil".
2. Maintain:
   • Topics of expertise (tag-style, free text)
   • Hourly rates per topic (informational, used for planning; no payment logic in Stufe 1)
   • Competences (free text, shown on Run detail to participants)
   • Internal notes for Seminar Managers (not visible to participants)

Seminar Managers or admins may pre-populate profiles: open /local/lernhive_seminarmanagement/trainer.php (as a manager) → pick the trainer → Profil bearbeiten.

Expected result: the pool matches trainers to requests by Fachthema, and participants see meaningful trainer info.

Trainer: complete delegated tasks

What it does: administrators can delegate operational tasks (e.g. "Beschreibung ergänzen", "Material hochladen") to the trainers of a Run.

1. Open the "Aufgaben" tab of the trainer perspective.
2. Work through the assigned tasks — each has a task type, optional due date and short instructions.
3. Mark a task completed — the delegating administrator receives a notification (popup + e-mail by default) and the task moves to the "Abgeschlossen" status.

Expected result: operational prep work is tracked instead of living in email threads.

Trainer: review aggregated feedback

1. Open the My feedback tab in the trainer perspective.
2. Review the overall numeric average and submission count across your actively assigned seminars.
3. Use the table to compare publishable seminar averages and open the related seminar.

Only seminars that meet the configured Reporting minimum group size are shown. Released assignments are excluded, free-text responses and individual submissions are never displayed, and suppressed seminars are reported only as a count.

Expected result: trainers receive useful evaluation signals without weakening anonymous-response protection.

Platform administration: work from the dashboard

What it does: the role-aware manager landing page (/local/lernhive_seminarmanagement/manager_dashboard.php) surfaces what needs attention now, current planning signals and the next useful action. The historical index.php entry redirects here for users working in the Administration workspace.

The page title is provided by the Plugin Shell. Contextual help appears inline with the relevant section heading, so no standalone question-mark controls are shown between the shell and the dashboard content.

1. Open the administrative "Seminarverwaltung" entry; the dashboard is the default Seminar Manager landing.
2. Use the fixed top navigation Dashboard / Seminar templates / Planning / Runs / Operations. Only the current seminar template context appears in the left navigation; there is no duplicate page navigation above the content.
3. Work the action queue first: pending approvals and payments, missing resources, mandatory-compliance gaps and other bounded Run signals link to their real workspaces. A resource warning names the missing sessions, trainer or rooms and opens the Seminar Wizard's Sessions step.
4. Use New seminar template to enter the six-step wizard. Master data and reusable configuration remain under the Settings gear.

Expected result: administrators land on the work that matters today, without scanning multiple lists.

Platform administration: review the KPI charts

What it does: the "KPI dashboard" page (/local/lernhive_seminarmanagement/dashboard_charts.php, nav entry "KPIs") renders visual KPIs across rooms, trainers, no-show rate, participants and proof handoff for the seminars you coordinate.

1. Open the dashboard → "KPIs".
2. Review the charts: utilization per room, trainer assignments per month, no-show rate by seminar template, top participants (confirmed vs. waitlisted), proof handoff volume per month.

If reporting data is not available on the site, the page says so and asks the site administrator to enable seminar reporting.

Platform administration: create and maintain seminar templates

What it does: a seminar template is the stable content and policy shared by its alternative Runs; the catalog shows it as one Seminar. The technical record remains Topic; managers do not need that implementation term in normal work. Later changes to the seminar template do not silently overwrite already-created Runs.

1. Open Seminar templates (seminars.php) and select an existing seminar template, or use New seminar template.
2. The wizard keeps one persistent seminar template context through six steps: Seminar template, Runs, Sessions, Moodle course, Booking, Review.
3. Define the reusable content and defaults in the first step:

1. Continue through the wizard. Runs are the alternatives participants may choose; every date/time belongs to a Session inside one Run. If you selected an evaluation template, the activity is created only when a new linked course is materialised; existing-course links are not modified.

Compatibility: bookmarked topics.php, topic.php and unfiltered bookings.php routes remain available for one release and lead to the canonical seminar template/Run workspace. Destructive actions use a separate confirmation and POST request.

Platform administration: assign course managers

What it does: course manager is a course-context role analogous to the trainer, attached directly to the booking (independent of the org chart).

1. Open the booking detail page → Course managers section → Manage course managers (booking_managers.php).
2. Pick a person via autocomplete; the scope is the whole booking or a single session.
3. The assignee gets a notification and the sessions appear in their personal Moodle calendar. Remove cleans both up again.

Platform administration: use the course calendar (agenda)

What it does: a coordinating agenda of every seminar session across all bookings — with the trainers and course managers per session.

1. Gear icon (settings) → Calendar card (calendar.php).
2. Sessions are grouped by month and day; filter by trainer or course manager; use Only my courses to limit the agenda to Runs where you are the responsible Seminar Manager. This choice is saved for your next visit; it is initially enabled for users who already manage a Run.
3. Clicking a session opens the booking detail page.

Platform administration: plan Runs and Sessions

What it does: a Run is one concrete alternative that participants can book (technical record: Booking). A Run:

• belongs to one seminar template and starts with its defaults
• carries one or more Sessions (technical record: Slot)
• has a status (planned → bookable → booked → executed → closed, plus cancelled — see the lifecycle table under Core concepts)
• belongs to exactly one primary course category

Creating a seminar template and its Runs

1. Start New seminar template, or open a seminar template and continue in its Run context.
2. In wizard step Runs, add every alternative that should appear below the one Seminar card in the catalog.
3. Override inherited values only where a concrete Run differs:
   • title, description, format, capacity
   • trainer(s)
   • course linkage (change strategy or pick a different existing course)
   • reminder offsets
4. In Sessions, add every date/time that is part of that Run. Leaving the wizard for a Location, Room or Equipment record returns to the same saved seminar template / Run / Session context. If the end is not after the start, the Session editor stays open, retains every input and marks the end field. Correct only the end time and save again. Every Session requires a trainer before the Run can be published. Trainer search includes only active profiles assigned to this seminar template and explains when no eligible result is available. Users who may maintain their own profile can open it directly and return to the same Session.
5. Review and publish. When ready to accept bookings, set the Run to Bookable — the Seminar appears in the participant-facing catalog. If a trainer is missing, Review names the affected Session and Assign trainer opens that exact editor; saving returns to Review so the corrected Run can be published immediately. After the last Draft Run is published, Review shows Publication complete and View published run instead of draft wording. If a seminar template still contains Draft Runs, Review identifies the published and remaining Draft counts separately. Published Sessions are maintained from Manage Sessions and are no longer editable in the creation wizard.

Seminar template settings

The defaults of a seminar template that the creation wizard does not ask for — custom fields, course access defaults, default booking type, duration, notification offsets, trainer pool policy, feedback template, cancellation fee and tiers, promotion defaults, certificate attendance rule, approval chain and the structure lock — are maintained on Seminar template settings (topic.php?id=<n>, decision P11, 0.4.150). Open it with the gear icon in the header of the seminar template page. Title, description, image, format and category stay in the wizard (Edit). Cancel returns to the seminar template page. The page needs the Seminar Manager role in the seminar template's category and, for a locked seminar template, the structure-lock capability.

Duplicating a seminar template

The copy icon (Duplicate seminar template) in the header of the seminar template page duplicates it (decision P14, 0.4.151). A confirmation in the usual page frame names the seminar template; Cancel returns to it. The copy is called "<title> (copy)", lies in the same category, is unlocked and takes over the defaults, the seminar template image and the description with its embedded files, the custom field values (locked ones and their files included) and the seminar template's mail profile, but no Runs or Sessions (0.4.153). The mail profile is taken over only if you may manage it and it is still ready to send; otherwise a notice says so and the copy uses the category's profile. After the copy the wizard opens on it. The action needs the Seminar Manager role in the seminar template's category.

Adding and editing Sessions

A Session is one contiguous time window of a Run. Multi-day seminars have multiple Sessions; three alternative dates are three Runs, not three Sessions of one Run.

Go to the Run workspace → Sessions → Add Session (slots.php?bookingid=<n>).

Room conflicts are checked on save. Seminar Managers holding override_conflict in the Run's primary category can deliberately accept a double-booking via a checkbox in the date editor; overridden conflicts remain auditable. Trainer conflicts remain hard failures.

Deleting a Session with recorded attendance (decision P13, 0.4.148). Recorded attendance is evidence. For a published Run such a Session cannot be deleted: the page explains why and offers Reschedule slot, the Session editor. For a Draft Run the confirmation first shows the impact — how many attendance entries for how many people, and who they are — and only the confirmed number of entries is accepted; if attendance changed in between, the deletion is refused and the impact is shown again. The creation wizard names the entries in its delete confirmation. The entries stay in the history but no longer count for attendance, certificates or the feedback release. The rule is enforced by the server, not only by the pages.

Course linkage strategies

The seminar template defines whether alternative Runs share one Moodle course (usually separated by groups) or receive one Moodle course per Run. The source and provisioning strategy is configured separately and revalidated when the course is materialised.

For each Run, the course section offers optional Course access starts and Course access ends overrides. When left empty, the corresponding seminar template default is inherited. The effective period is applied only while creating a new Moodle course; reusing an existing course does not change its access dates.

On confirmed booking: the participant is enrolled in the linked course (role student) via enrol_manual. On cancellation: the enrolment is suspended, not deleted, to preserve grades and progress history. The Zugriff auf Kurs button in "Meine Seminare" only appears if a linkage is active.

Seminar Managers may additionally enable Require attendance before course access for a date. The learner remains enrolled with access suspended until all date attendance is recorded as present. The configured course-access end still closes the enrolment window; certificates remain available through Certify.

Platform administration: create a recurring Run series

For predictable patterns (weekly, bi-weekly, monthly, yearly):

1. Go to Seminar templates → pick a seminar template → Neue wiederkehrende Buchung — or from the Buchungen list, row action Serie erstellen (recurrence.php?topicid=<n>).
2. Set:
   • pattern (weekly / bi-weekly / monthly / yearly)
   • start date + time
   • series end: either a fixed end date or a count of occurrences (max 52)
3. Click Vorschau to see the generated dates.
4. Click Erstellen — the engine creates independent Run records, one per occurrence. Each can be edited individually without affecting siblings.
5. Adjust any Run in the generated series if needed, then publish the series to the catalog.

Expected result: the program is planned efficiently; edits to one Run do not cascade to siblings.

Platform administration: manage participants and the waitlist

Viewing participants: open a Run → Teilnehmende panel. Columns: name, email, booking date, status (confirmed / waitlisted), Slot attendance (per Slot column), action buttons.

Waitlist management: the waitlist is FIFO by default.

When a confirmed participant cancels, auto-promote (if on) immediately moves the next waitlist entry to confirmed and sends a fresh confirmation email. Raising the capacity fills every freed seat in waitlist order. While people are waiting, new bookings join the waitlist instead of taking a free seat — also with manual promotion — and the catalogue shows no free seats. Promotion emails go out automatically. A cross-Booking waitlist view is available at waitlist.php.

In a Run that requires approval, promotion (automatic or Promote) does not confirm the person: the booking moves to Pending approval and the approval chain receives the request, as for a new booking. The seat is confirmed by the last approval. While a request waits for a decision, automatic promotion keeps the seat for it. A person whose approval chain names no approver stays on the waitlist; automatic promotion moves the next person up. Guests are confirmed directly, as a guest booking is (0.4.164).

Cancelling a participant's booking

1. On the Teilnehmende panel, click Stornieren on the row.
2. Enter a cancellation reason (mandatory).
3. Confirm. The participant receives a cancellation notification.

The audit log records who cancelled, when, and why. This record survives Run deletion.

Expected result: waitlist state reflects intent; capacity shifts and prioritizations are handled without side channels; participant lists can be exported for hotel or catering planning.

Platform administration: book on behalf and create and book a person

Booking on behalf of another user (requires local/lernhive_seminarmanagement:book_for_others):

1. Open a Run detail page → Buchung im Auftrag.
2. Use the participant picker to select one or more LernHive users.
3. Submit. Each bookee receives a separate confirmation email.

Create and book a person (decision P12) — nobody is booked without an account with an email address, also not by staff. This replaces the guest booking; old links to guest_booking.php lead here. Requires book_for_others in the Run's category.

1. Open a Run → Person anlegen und buchen (/local/lernhive_seminarmanagement/book_person.php?bookingid=<n>).
2. Enter email address, first and last name and, optionally, the organisation (stored in the account field "Institution"). For a new account you may choose a department and position when the org chart is installed and you may staff departments.
3. Submit:
   • The address belongs to one account you may book (active, a role in the Run's category tree, inside your line scope or you coordinate the category): that account is booked like "book on behalf", with approval, deadlines, audience, capacity, audit, companion course and all seminar mails. Name and organisation of the account stay unchanged.
   • The address is unknown and you may create users (moodle/user:create): a new account is created and booked. Without SSO it gets the login type "manual" and Moodle's mail with the login details; the password must be changed at the first login. With SSO (auth_oidc enabled) it gets the SSO login type with the email address as username and no password mail.
   • Every other case shows the same message: an account you may not book, several accounts with this address, or no account while you may not create one. The message does not tell whether the address has an account.
4. Without a department only the Seminar Managers of the category book a new account; line managers book people of their area.

The booking confirmation comes from the person who booked, replies go to them. Public self-booking without an account does not exist and stays so: visitors log in or register.

Guests booked before P12 keep their claim link (/local/lernhive_seminarmanagement/claim.php?token=<token> from their confirmation email): after logging in they take over their booking history.

Convert a former guest into an account (requires :coordinate in the Run's category and :guest_book):

1. Open the Run → Frühere Gastbuchungen (/local/lernhive_seminarmanagement/guests.php?bookingid=<n>; the entry only appears while the Run has guests to convert).
2. Pick In Konto umwandeln next to the guest. Name and organisation are prefilled from the guest booking; the email address is fixed.
3. Confirm with Umwandeln. The same rules as above apply: the address of an account you may book links that account, an unknown address creates an account if you may create users, every other case shows the neutral message. If the account is already booked into a Run of the guest, cancel one of the two bookings first.

All bookings of the guest move to the account, each move is recorded in the audit. For open Runs the person is enrolled in the companion course and gets the calendar entries.

Retention of unused accounts: an account created by "Person anlegen und buchen" or "In Konto umwandeln" that never logs in is suspended 12 months after its last session and deleted 3 months later, unless a valid certification or an open recertification window protects it. Switch: Site administration → Plugins → Local plugins → Seminarmanagement → Retention of accounts from bookings (default on). Lifting the suspension keeps the account for good.

Former guests who are not converted are anonymised 12 months after their last session: email, name, organisation, attendance notes and cancellation reasons are removed, the bookings stay for statistics (scheduled task "anonymise former guests").

Expected result: every booked person has an account and gets a confirmation; the booker has a clean overview of who they booked where.

Platform administration: manage buildings, rooms and equipment

What it does: maintains buildings, rooms, equipment; assigns rooms to Runs without double-booking.

Resource structure:

Site
 └── Building (Gebäude)
       └── Room (Raum) — capacity, equipment checklist, floor plan
             └── Equipment type links (many-to-many via checklist)
Equipment types (Ausstattung) — flat list: projector, whiteboard, …

Open the Settings gear and choose Locations, Rooms, or Equipment. When the directory is empty, the page proposes the next valid step instead of leaving an empty table:

1. Create a Location — name, address, optional notes. Choosing the guided path continues directly to its first room.
2. Add a Room — every new room belongs to a Location; set capacity and scope. Legacy unassigned rooms stay editable and can be assigned later. A category-scoped Location may contain only rooms from that category; a global Location may contain global or category-scoped rooms.
3. Add reusable Equipment types such as projector or whiteboard and attach them to rooms. Back actions retain the current Location filter.

Room picker logic on Run/Date forms — the picker automatically filters to rooms that:

• have capacity ≥ Run capacity_max
• are global or owned by the Run's primary category
• provide every equipment type required by the Run plus any additional requirement selected for this Date

The Date form reports how many rooms were excluded by capacity and equipment. It can still be saved without a room when no configured room matches. A room selection is checked again on save so stale browser state cannot bypass the requirements.

Time conflicts are validated server-side when the Date is saved. They block the save unless the user deliberately checks the capability-gated conflict override (see override_conflict).

Global resource CRUD requires manage_resources_global at system level. Holders of manage_resources_local reach the same Plugin-Shell Settings hub but can create and edit only category-owned resources in their assigned categories. Global resources are available as read-only choices.

Expected result: clean room assignments with no accidental double-booking.

Platform administration: manage trainers

Assigning a trainer to a Run: on the Run edit form → Trainer field → select from the pool. The trainer immediately sees the Run in their Meine Einsätze tab.

Alternatively, open the Run to the trainer pool (leave the Trainer field blank and tick Im Trainer-Pool anbieten). Trainers with matching Fachthema tags can then self-select from Offene Anfragen.

Trainer assignment acceptance flow: in Stufe 1 (MVP), when a trainer accepts from the pool, the assignment goes directly to confirmed-trainer status; the Seminar Manager sees this in the Run detail. In Stufe 2, Seminar Managers can require explicit release of trainer assignments before they become confirmed.

Conflict detection: the system blocks saving a trainer assignment if the trainer already has a confirmed Slot overlapping the same time window. A Manager-level capability can override if needed (for legitimate exceptions).

Platform administration: export participant and signature lists

What it does: produces printable and machine-readable participant and signature lists — before a session for signature lists, after a session for audit.

Participant list: from a Run detail → Teilnehmerliste exportieren → pick format:

Signature list (Unterschriftenliste): same location → Unterschriftenliste → PDF with a signature column per Slot. Optional logo slot for letterhead use.

Expected result: document ready for print or archive.

The participant export also includes the equipment required by the Run. This is the union of the equipment configured on the Run and its Sessions. The same information is available as the {{booking_equipment}} document variable and in the manager Run list.

Platform administration: generate documents from templates

What it does: generates recurring Run documents from templates and Run variables: invitations, participant lists, attendance lists, signature sheets and customer-specific Office documents. Use it when the standard participant/signature exports are not enough because the customer needs a branded document, extra fields, editable DOCX output, or a mail-merge style batch.

1. Open a Run.
2. Open the document output action (generate_document.php).
3. Choose a template and output format.
4. Preview with one participant or the first matching row.
5. Generate for confirmed, waitlisted or all active participants.
6. Download the generated PDF, DOCX or XLSX package.

Expected result: the generated file contains only allowlisted Run and participant variables, is logged for audit, and can be printed, edited further in Office, or archived.

Platform administration: import Runs and bulk-edit

What it does: allows mass import of Runs from a file and mass edits across selections — e.g. migrating a year's catalog in or adjusting rooms across many Runs.

Bulk booking import

1. Open /local/lernhive_seminarmanagement/booking_import.php.
2. Download the column template (CSV/XLSX).
3. Fill in: title, topic (by name or id), start, end, room, trainer, capacity, primary_category.
4. Upload → Dry-run to preview errors per row.
5. If clean, click Importieren.

Bulk booking edit

1. Go to the Buchungen list.
2. Filter/search to the target set.
3. Tick the relevant rows → Massenbearbeitung.
4. Pick the field to change (e.g., room, trainer, reminder offset).
5. Apply.

Expected result: the planned change is applied atomically; errors report per row.

Platform administration: mass-book with the Bulk booking Matrix

What it does: a three-step assistant for booking many users into many bookings at once, with a preview matrix and a final audit log including CSV export. This is distinct from the CSV-driven Run import above — that one creates new Runs from a spreadsheet; here you pick existing LernHive users and existing Runs and book them in a User × Run grid. Use it for onboarding a cohort across multiple seminars, mass-booking a department into mandatory training, or rolling out a yearly compliance program.

1. Step 1 — /local/lernhive_seminarmanagement/bulk_booking.php — multi-select users and Runs.
2. Step 2 — bulk_booking_preview.php — preview matrix, deselect individual cells, view conflicts and capacity warnings.
3. Step 3 — bulk_booking_result.php — final action result with per-cell outcome (confirmed / waitlisted / blocked) and a CSV export button for the audit trail.

Issuing dozens of bookings at once is a high-blast-radius operation, so it is gated by its own capability (bulk_book, manager-only by default; site admins can grant editingteacher in scoped contexts).

Expected result: mass enrolment with a clear audit per cell; failures are isolated and visible.

Platform administration: set up approval workflows

What it does (Stufe 2): routes bookings through a serial approver chain before they become effective.

Setup per seminar template or Run:

1. Edit a seminar template or Run → tick Genehmigung erforderlich.
2. Add an approver chain in the Approval-Chain editor on topic.php / booking.php.
3. Save.

Chain resolvers: the Approval-Chain editor has a resolver-type dropdown per chain step. Instead of always picking explicit users, you can pick resolver sources:

Snapshot guarantee: when a participant submits a booking, the chain is resolved fresh and a snapshot of the approver users is stored on the approval-step record. Subsequent HR-data changes do not re-route an already-pending approval — audit-safe. New submissions resolve fresh against current data.

Participant experience: after clicking "Jetzt buchen", the booking enters pending_approval. Each approver in the chain receives a daily digest of pending items and works through the Genehmigungen queue (see the Manager journey above). On final approval: status confirmed, confirmation email with .ical sent. On any rejection: status rejected, participant notified with reason. When the participation is cancelled (by the participant, the seminar team or the cancellation of the whole Run), its open approval steps close as withdrawn and leave the queue; a later decision is refused. Booking the same Run again starts a new approval round (decision R7, 0.4.157).

Tip: approval status is stored separately from booking status so the audit trail can distinguish "never approved" from "approved then cancelled later."

Platform administration: require a pre-booking form

What it does (Stufe 2): presents a reusable confirmation form to participants before their booking is finalized (e.g. "Hiermit bestätige ich, dass ich befugt bin XYZ zu buchen") — for authorization statements, data-protection acknowledgements, declarations of competence.

1. Open the plugin home → "Vor-Buchungsvorlagen" (/local/lernhive_seminarmanagement/prebooking_forms.php) → Neue Vorlage.
2. Create a template: name + intro text + fields (static text block, required checkbox, free-text).
3. On a Run, pick the template in the "Vor-Buchungsformular" select; leave as "None" to skip the gate.
4. Participants who click "Jetzt buchen" are routed through the form first; the booking only finalizes after submit.
5. Under the Run detail page (Einreichungen panel), the administrator sees all submissions and can download each as PDF (prebooking_download.php) for the legal archive.

Expected result: one immutable submission per (booking, user); bodies kept for legal review; PDF always reproducible.

Platform administration: send serial messages to participants

What it does (Stufe 2): sends one subject/body to every participant of a booking in a single click, with an audit timeline — for schedule changes, room moves, mandatory pre-reads, anything that has to reach all confirmed (or waitlisted, or both) participants of a specific booking.

1. On the Runs list, row action "Seriennachricht senden" (booking_serial_mail.php).
2. Pick the recipient scope: confirmed / waitlisted / all active.
3. Compose subject and HTML body, send.
4. The same page shows a timeline of who sent what, when, to how many — counts only in the UI, bodies kept for legal review.

Expected result: each dispatch is logged in local_lhsem_serial_mail_log with sender, subject, scope, recipient count, timestamp; delivery reuses the booking_confirmation message provider so per-user output preferences (email / popup) are respected.

Who sends the mail (decision P27, 0.4.161): messages the system triggers — reminders, automatic confirmations, waitlist promotions, digests — come from the no-reply address (or the Academy profile's identity). Messages a person triggers come from that person, and replies go to them: the serial mail and one-off messages of the seminar team, a cancellation of someone else's booking and the cancellation of a whole Run. Participants who cancel themselves get the notice from the no-reply address.

More messages from the acting person (decision R25, 0.4.168): these messages now come from the person who caused them as well, and replies go to them:

• trainer and course manager assignment: the person who assigns (in the creation wizard, the person saving the Session)
• booking for others, also bulk booking and converting a demand request: the booker, for the confirmation and for the waitlist notice
• manual waitlist promotion: the person who promotes
• approval result: the approver who made the final decision

Still from the no-reply address: your own booking, the automatic promotion after a cancellation, reminders and other scheduled messages, and the guest booking.

Platform administration: manage mandatory training

What it does (Stufe 2): marks a Run as required for a defined audience with an end-by date — for compliance trainings.

1. Edit a Run → tick "Pflichtschulung".
2. Set Zielgruppe (cohort, group, or explicit user list) and Abgabedatum (deadline).
3. Save.

The audience is notified on assignment. Automatic reminders fire at T-30, T-7, and T-1 before the deadline. Administrators see compliance KPIs ("X of Y completed") in the Run detail; learners see a "Pflichtschulung bis [date]" badge in "Meine Seminare".

Platform administration: manage accommodation needs

What it does (Stufe 2): tracks accommodation needs for multi-day Runs. Participants record their need after booking (see the Learner journey); administrators plan hotel capacity from the answers.

1. Open the Run-level Hotel needs view from the Run detail: Hotelbedarf → /local/lernhive_seminarmanagement/hotel_needs.php?id=<n>.
2. Review:
   • summary count per need type
   • all LernHive-user participations including unanswered rows
   • direct edit links per row
3. Export CSV/PDF for external hotel coordination.

Platform administration: capture and convert demand-requests

What it does: captures and manages "interest in a topic that has no scheduled date yet". Participants register interest; the administrator watches the count; once the threshold is hit, the request can be converted into a real Run that automatically migrates the active interested users into participations.

1. Open "Bedarfsanfragen" — list view at /local/lernhive_seminarmanagement/demand_requests.php.
2. Click "Neue Anfrage" or edit one — the edit form is at demand_request.php (title, description, primary category, optional seminar template link, threshold count). On save the request immediately appears in the participant Catalog under the "Auf Anfrage" tab.
3. When the threshold is reached, the daily Seminar Manager digest highlights the request — open it and click "In Buchung umwandeln" → demand_convert.php walks through the conversion in a single transaction:
   • creates a new Run (cloning seminar template defaults if linked)
   • migrates active interested users to participations
   • notifies the migrated users

Expected result: demand is captured before scheduling, conversion is one click and audit-clean, interested users are notified at threshold and at conversion.

Platform administration: curate catalogue search tiles

What it does: configurable visual tiles (image + label + filter or URL link) that appear above the Catalog search box, so learners land in pre-filtered views without typing — highlight seasonal programs, mandatory training audiences, or popular topics on the Catalog landing page.

1. Open the CRUD list at /local/lernhive_seminarmanagement/catalog_tiles.php.
2. Click "Neue Kachel" → edit form at catalog_tile.php — set label, sort order, image (filemanager), and target (filter pre-set or external URL).
3. Save — the tile immediately appears above the Catalog search filters.

Expected result: learners discover the right corner of the Catalog faster; administrators steer demand toward strategic offerings.

Platform administration: delegate tasks to trainers

What it does: delegates operational Run tasks to trainers, with status tracking and completion notifications.

1. Open a Run, click "Delegierte Aufgaben" (booking_tasks.php).
2. Click "Aufgabe delegieren".
3. Pick a task type from the catalog (e.g. "Beschreibung ergänzen", "Material hochladen"); site admins curate the catalog under Site administration → Plugins → Delegierbare Aufgabentypen.
4. Optionally pick a concrete trainer of this booking (default: any active trainer), set a due date, and write short instructions.
5. The trainer sees the task in the "Aufgaben" tab of the trainer perspective.
6. Once the trainer marks it completed, you receive a notification (popup + e-mail by default) and the task moves to the "Abgeschlossen" status.

Platform administration: manage the Seminar Manager work plan

Shipped operational surface: every Run has exactly one Seminar Manager. If an eligible creator does not select another person, the creator is assigned automatically. This records accountability; it does not grant additional Moodle permissions. The versioned workflow foundation and scope-precedence snapshot are implemented behind the service boundary. Lifecycle-aware task instances, My tasks, the Run checklist and dashboard counters are live. Interactive template authoring and Workplan delegation controls are not yet exposed in this UI.

1. Create or edit an Run and select its Seminar Manager. A person outside the Run's category scope cannot be selected.
2. The configured work-plan binding is resolved from system, category, seminar template, or this Run. The most specific configured binding wins and is snapshotted on the Run.
3. Open My tasks for overdue, today, this week, later, waiting, and recently completed work across Offerings. Older completion history remains available on the Run's Workplan.
4. Open an Run's Work plan for preparation, publication, delivery, follow-up, and cancellation phases. If no workflow has been applied, the page explains that an administrator or Seminar Manager of the category must assign one and does not show misleading 0% progress.
5. Use Open action where the task has a canonical destination. State-backed work such as Assign trainer has no independent completion checkbox and changes only when the underlying seminar data changes.
6. Linked trainer execution appears through the existing trainer-task page. Programmatic delegation remains visible under Waiting for others; interactive delegation and recall controls remain planned.

State-backed work completes automatically and may reopen. If a confirmed trainer is released, Assign trainer becomes open again and history explains the transition.

Standard flow

• creation instantiates the selected versioned plan
• trainer assignment, valid dates/rooms, and publication complete matching work
• delivery activates attendance and follow-up work
• close requires required work to be resolved or an authorised, documented override

Trainer withdrawal

• Assign trainer reopens
• open work assigned to that trainer returns to the Seminar Manager or requires explicit reassignment
• completed work and its actual completing person remain in history

Date change

• untouched relative due dates recalculate; manual overrides stay unchanged
• conditional work covers trainer/participant communication and affected room, catering, hotel, or external services
• the original invitation remains completed; date-change communication is new work

Cancellation

Cancelling a Run goes through an impact preview (see Platform administration: cancel a Run). Completed work stays in history. Open work becomes Not applicable, started work Aborted, and trainer delegations Withdrawn. Conditional work of the cancellation phase becomes due.

A linked replacement Run with a fresh plan is still planned; until then, create the new Run yourself. Participants are never moved silently. A manager change transfers open, non-delegated manager work; existing delegations remain assigned and the new manager inherits oversight.

Platform administration: cancel a Run

What it does (0.4.156): cancels a Run for everybody. Before you confirm, a preview shows per Run how many participations are affected (by status), how many waitlist places, how many paid and open payments, and how many people receive the cancellation message.

1. Open the Run (booking.php) and click Cancel Run, or tick several Runs in the Run list and choose Set status: Cancelled.
2. Check the preview on cancel_run.php.
3. Choose a cancellation reason or describe it (required), then click Cancel … Run(s).

Expected result:

• confirmed participations, pending approvals and waitlist places become Cancelled; no cancellation fee applies and the participants' cancellation deadlines do not count; the waitlist is emptied
• nothing is refunded automatically: paid and open payments are marked Review refund in the payment overview (see reconcile payments)
• the Sessions leave the calendars, reminders stop
• everybody affected receives the cancellation message with a calendar cancellation (iCalendar METHOD:CANCEL, same entry as the invitation); guest participants without an account receive it by email. People can switch the message Seminar Run cancelled off in their notification preferences; administrators switch it off site-wide in the mail templates
• cancelling again changes nothing and sends nothing; a cancelled Run cannot be reopened

Open approval steps of the cancelled participations close as withdrawn and leave the approvers' queue (decision R7, 0.4.157).

Required capability: coordinating the Run's category (:coordinate).

Platform administration: set seminar prices and payment methods

What it does (Stufe 3): attaches a structured price to a Run and decides whether and how participants pay. The learner sees the price on the catalogue card and the seminar detail page — with a "zahlungspflichtig" hint whenever payment is actually required. Use it for paid seminars: open enrolment courses with participation fees, or externally billed trainings where the seminar shows the price but an invoice or external system collects it.

1. Open the Run form (booking.php) → tick "Preis anzeigen" (priced).
2. Enter the amount as a decimal (comma or dot, e.g. 149,90) — it is stored as cents server-side, negative or malformed values are rejected.
3. Pick the currency from the select (EUR / CHF / GBP / USD; default EUR).
4. Tick "Zahlung erforderlich" if the booking must not confirm before payment — participations then hold in pending_payment.
5. Choose the Zahlungsmethode that appears once payment is required: Manuelle Rechnung (administrator marks paid in the Payment-State Console), Online-Zahlung (…) per enabled Moodle payment gateway, or Externes System (Webhook) for third-party billing.
6. Save — the price line appears for learners; without "Zahlung erforderlich" the price is purely informational.

Expected result: learners see 149,90 EUR (plus · zahlungspflichtig when payment is required) on cards and the detail facts list; the chosen payment method routes the participation through the matching payment source .

Required capability: editing the Run form (:coordinate on the category); marking payments needs :mark_paid.

Platform administration: reconcile payments

What it does (Stufe 3): the Payment-State Console is a per-Booking participation list with payment status and per-row actions. Use it after invoices have been sent, to record which payments arrived, waive fees for special cases, or process refunds for cancellations.

1. Open a Run with payment_required=1 → the action box "Zahlungen verwalten" appears on booking.php; click it.
2. You land on /local/lernhive_seminarmanagement/payment_state.php?bookingid=<n> — every participation row shows the current payment status.
3. Row actions route through payment_action.php:
   • Mark paid — record an incoming payment with reference + date
   • Waive — waive the fee with a mandatory reason
   • Refund — refund a previously paid amount with a mandatory reason
4. The Run-level digest counters in the dashboard "Aktionsbedarf" section update once you save.

After a Run cancellation, its paid and open payments carry the badge Review refund. The work queue Outstanding payments lists such Runs with the number of reviews. Refund a paid amount or Waive an open claim to close the review. If nothing is refunded, click No refund: the payment keeps its status, the audit log records who closed the review and when, and the badge disappears (decision R8, 0.4.158).

Expected result: payment reality is tracked alongside booking state; the audit log captures who acted, when, why; the dashboard counter for pending payments goes down.

Required capability: local/lernhive_seminarmanagement:mark_paid (manager, editingteacher, Seminar Manager).

Platform administration: settle travel-cost claims

What it does (Stufe 3): a queue of submitted travel-cost (Reisekosten) claims for the bookings you own, with a three-action decision form per claim. Use it after a Run is executed and participants submit their claims; settle them before the DATEV export.

1. On bookings.php, the row action "Reisekosten verwalten" (or directly: /local/lernhive_seminarmanagement/expense_approvals.php?bookingid=<n>) opens the queue scoped to that Run; without ?bookingid= the queue spans all owned Runs.
2. Click a claim → expense_decide.php shows the claim form with the three actions:
   • Approve — finalizes the claim and feeds it into DATEV-eligible state
   • Reject — ends the workflow with a mandatory reason
   • Request revision — flips the claim into needs_revision so the participant can edit and resubmit

Expected result: claims clear the queue with a clear audit trail; revisions cycle without re-submission churn.

Platform administration: run the DATEV export

What it does (Stufe 3): generates a DATEV-compatible CSV of approved travel-cost claims for a chosen period, with a preview, generate-button, and a recent-batches table for re-download. Run it end of month / quarter, to hand the file to the bookkeeper.

1. Open /local/lernhive_seminarmanagement/expense_export.php.
2. Pick a period and preview the matched claims.
3. Click "CSV erzeugen" — the batch is logged and the file downloads.
4. The "Letzte Batches" table at the bottom lets you re-download a previously generated file for a clean audit trail.

Setup: a site admin first configures the four DATEV settings on the plugin admin page — see "Settings that matter".

Expected result: a clean CSV that imports into DATEV without manual reformatting; every batch has a reproducible re-download.

Platform administration: tune reminders and the Seminar Manager digest

All notifications travel through LernHive's notification surface (Moodle Message API under the hood). Users control their channel preferences (email, popup, mobile if installed) in their personal Message preferences.

Trigger summary (MVP)

Post-seminar feedback: create an enabled workflow with trigger after_last_slot, provider feedback_request, and recipient scope feedback_qualified. The daily workflow sends the linked Moodle Feedback URL only to confirmed participants who meet the Run's attendance threshold. Participants who already submitted are skipped, and a repeated task run does not send the same request twice.

Per-seminar-template reminder configuration: on the seminar template (or Run override), set up to two reminder offsets. Example: 7 days before and 1 day before. The scheduled task send_reminders fires daily and sends due reminders (deduplicated per participant per Run).

Digest for Seminar Managers: instead of receiving one email per "waiting for approval" event, Seminar Managers get a single daily digest: "Es liegen N Seminarbuchungen zur Prüfung vor." This is a first-class product decision, not a config option.

Administrators may override notification templates per seminar template or per Run (Stufe 2). The global template — managed by the site administrator — is the fallback.

Platform administration: monitor Certify proof status

What it does (Stufe 2): if local_lernhive_certify is installed and an external certification is mapped to the Run (by idnumber = seminar:{bookingid}), the plugin automatically emits a seminar_attendance_proof_available event when:

1. The Run is marked executed.
2. The participant's per-Slot attendance rolls up to present.

Certify then:

• matches the certification by idnumber
• handles template selection, validity period creation, PDF rendering, dispatch, CC recipients, and archive

Seminar Management shows a read-only proof status/link on the Run detail for administrators and on "Meine Seminare" for participants. It does not generate or store certificate documents itself. Certificate templates, PDFs, dispatch and archives are managed in Certify, not in Seminar Management.

Site administrator: complete the initial setup

Complete these steps once, in order, before opening the plugin to users.

1. Global plugin settings — navigate to Admin → Plugins → Local plugins → Seminar Management Settings (/admin/settings.php?section=local_lernhive_seminarmanagement) and work through the table under "Settings that matter" below.
2. Global notification templates — see the next journey.
3. Resource hierarchy — build the building/room/equipment directory (or delegate to Platform administration; see the resource journey above). Global resources visible to all Seminar Managers require manage_resources_global.
4. Trainer profiles (optional pre-population) — see "Platform administration: manage trainers".
5. Role assignment — assign the Seminar Manager role for per-category delegation (see "Who this is for").
6. DATEV settings (Stufe 3, one-time) — configure the four DATEV settings on the plugin admin page:
   • SKR03 Konto (default chart of accounts)
   • SKR04 Konto (alternative chart of accounts)
   • Berater-Nr (DATEV consultant number)
   • Mandanten-Nr (DATEV client number)

Portal surface (optional, Stufe 3+, when the customer uses local_customerportal): the seminar plugin appears in the customer portal catalog (platform) with an overlay showing Installed / Not installed, Installed version, Compatibility with the current LernHive version, an Upgrade required banner if the Run model or capability list changed and the customer's installation is behind, and a Request extension CTA (e.g., "Activate Stufe 2 features").

Site administrator: manage global notification templates

Navigate to /local/lernhive_seminarmanagement/notification_templates.php (requires configure_templates — site admin only).

For each trigger, review and adapt the default template:

Templates support these placeholders:

Platform administration may override templates per seminar template or per Run (Stufe 2). The global template is the fallback.

Inherit the Academy mail profile

TPL-012 replaces the Seminar-specific global-only branding assumption with an explicit shared profile from the Run's primary course category. The Academy profile supplies HTML/plain layout, sender identity and Reply-To; Seminar and Run overrides continue to supply Seminar-specific message content and timing. Extended visibility categories do not affect the mail identity. Profile inheritance is available; optional Seminar/Run-specific profile overrides are still planned.

Site administrator: curate delegatable task types

The catalog of task types that Platform administration can delegate to trainers is curated site-wide under Site administration → Plugins → Delegierbare Aufgabentypen (task_types.php, requires manage_task_types). Add, rename or retire task types here; administrators pick from this list when delegating.

Settings that matter

Navigate to Admin → Plugins → Local plugins → Seminar Management Settings (/admin/settings.php?section=local_lernhive_seminarmanagement).

Limitations

What the plugin does not do, and what users do not see:

• Internal plugin logs and audit tables are not exposed to end users (only Seminar Manager-scoped views expose them).
• Administrators do not see other Seminar Managers' Runs outside their category scope.
• Site-global notification templates are not editable below site admin.
• Academy/category-specific layout, From and Reply-To inheritance uses the Run's primary category; optional Seminar/Run profile overrides remain open.
• Users do not see other users' guest-participant records (unless they own the guest record).
• Trainer profile internal notes meant only for Seminar Managers are hidden from participants.
• Trainer hourly rates are informational (planning only); there is no payment logic for trainers in Stufe 1.
• Overlap detection for learner self-booking is a soft warning, not a block.
• Automatic guest-history linkage on SSO login is not available in Stufe 1 — guests must use the email-verified claim link.
• Stufe-2 features (approvals, pre-booking forms, mandatory training, hotel needs, serial mail, Certify integration) and Stufe-3 features (prices, payments, travel costs, DATEV) are only available on installations that have activated the respective Stufe.
• Certificate generation, dispatch and archive live in Certify — Seminar Management only emits the attendance proof and shows read-only status.

Troubleshooting

An administrator does not see the administrative tools

Check that the user has the capability local/lernhive_seminarmanagement:coordinate in the relevant course category. Assign the Seminar Manager role at category context or ask a manager to add them. The old "Verwaltung" tab no longer exists; administrative tools now live on the dashboard and behind the Settings gear.

A Run does not appear in the participant catalog

Check all of the following:

1. Status is bookable (not planned or executed).
2. The participant has local/lernhive_seminarmanagement:view in the Run's primary category (or one of its extended categories).
3. The Run's bookable from / until dates (if set) include today.
4. If the Run requires group membership, the participant is in that group.

A room appears as conflicting but the slot is in a different building

Conflict detection is slot-time-based, not building-based. Two Slots using the same room at the same time conflict regardless of building. Check whether the same room record was accidentally assigned to both Slots.

The confirmation email does not include a .ical file

The .ical is attached by the booking_confirmed message template. Verify that the global template (or per-Booking override) includes {ical_attached} in the body. If the placeholder is missing, the file will not be included.

A participant's calendar event is not updating after a reschedule

The platform calendar event updates on reschedule only if Platform calendar integration is enabled in the plugin settings. The .ical subscription feed always updates regardless of this setting.

The bulk import reports errors on every row

The most common cause is a category name mismatch. The import field primary_category must exactly match the idnumber of the target course category (not the display name). Download the template again and check the column header for the expected format.

A guest's historical bookings are not showing after they registered

The claim flow is email-verified. The guest must click the link in their original confirmation email (or request a new claim token from the Seminar Manager) and verify that the email address matches. Automatic linkage on SSO login is not available in Stufe 1.

Appendix: page and URL inventory

All controllers live in the plugin root (local/lernhive_seminarmanagement/). There are no trainer/ or coordinator/ subdirectories — every page is reachable at the top level.

Related documents

Attendance

Seminar Managers can record Partially attended for an individual slot. An optional number of attended minutes is stored with the slot record and cannot exceed the slot duration. The booking rollup is updated automatically and is available to reporting and certificate workflows.