The PlayerHUD Availability Condition is a required-companion extension for the PlayerHUD Block. It lets teachers restrict access to activities, resources, or course sections based on a student’s progress in PlayerHUD.

It plugs directly into Moodle’s native Restrict access system, unlocking content only when a student reaches a specific Level, owns a required Item, belongs to a Character class, or has gamification active.

👈 Use the sidebar to jump to any section on this page.

✨ Features

• 🎯 Restrict by Minimum Level: unlock content only once a student’s PlayerHUD level reaches a configured threshold.
• 🎒 Restrict by Owned Item: unlock content based on how many units of a PlayerHUD item a student currently holds, with a comparison operator (>=, >, <, =).
• 🧙 Restrict by Character Class: unlock content only for students who have a specific RPG class assigned in PlayerHUD.
• 🎮 Restrict by Gamification Status: unlock content only for students who have gamification active (not paused/opted out) in the course’s PlayerHUD block.
• 🧠 Native Restrict Access Integration: appears as a regular option inside Moodle’s own “Restrict access” panel — no separate configuration screen, no extra capability to manage.
• 🧩 Context-Aware Availability: the restriction option is only offered when a PlayerHUD block instance actually exists in the course; it stays hidden otherwise.
• ⚡ Real-Time Evaluation: the condition is recomputed on every page load directly from the student’s current PlayerHUD data — no caching, no stale “unlocked” state.
• 📝 Dynamic Description Text: the “Not available unless…” message shown to students is built from the live requirement (level, item name and quantity, class name, or gamification status), not a static string.
• 🧩 Bulk Course-Wide Editing (optional): manage every PlayerHUD restriction in the course from a single dashboard via the separate Report Unlocker plugin.

🕹️ PlayerGames Ecosystem

This plugin is part of the PlayerGames gamification ecosystem. Together, these plugins transform Moodle into an immersive experience:

• PlayerHUD Block (Required): the gamification engine — XP, levels, inventory, quests, trade, and RPG progression. This condition has no data to evaluate without it.

  👉 https://github.com/jeanlucio/moodle-block_playerhud

• PlayerHUD Filter: inserts collectible item drops, trade offers, and the compact HUD widget directly inside course content using shortcodes.

  👉 https://github.com/jeanlucio/moodle-filter_playerhud

• PlayerGroup: lets students autonomously form their own groups directly from the activity page — no teacher intervention needed.

  👉 https://github.com/jeanlucio/moodle-mod_playergroup

🧩 Optional Integration: Report Unlocker

PlayerHUD restrictions are normally configured and edited one activity at a time, through each activity’s own Restrict access panel (see Usage). The separate Report Unlocker report plugin (report_unlocker, by the same author, but not part of the PlayerGames family) adds a course-wide dashboard that lists every access restriction in the course — including PlayerHUD Level, Item, Character, and Gamification conditions — with inline editing, bulk removal, and an AI assistant for natural-language changes. Report Unlocker reads and writes the same {course_modules}.availability JSON this plugin produces, always scoped to the course’s own PlayerHUD block instance, so nothing changes in how the restriction is stored. Without Report Unlocker installed, restrictions still work exactly as documented in Usage — only the bulk, course-wide dashboard is unavailable.

👉 https://github.com/jeanlucio/moodle-report_unlocker

📦 Requirements

🛠️ Installation

1. Ensure the PlayerHUD Block is installed first: 👉 https://github.com/jeanlucio/moodle-block_playerhud This availability condition depends on the block and will not function without it.
2. Download the .zip file or clone this repository.
3. Extract the folder into your Moodle availability/condition/ directory.
4. Rename the folder to playerhud (if necessary). Final path: your-moodle/availability/condition/playerhud/
5. Visit Site administration > Notifications to complete installation.

📖 Usage

1. Add the PlayerHUD Block to the course (see Installation) — the restriction option only appears in courses where a PlayerHUD block instance exists.
2. Turn Edit mode on in the course.
3. Edit an activity, resource, or section.
4. Open the Restrict access section and click Add restriction…
5. Select PlayerHUD.
6. Choose the restriction type and its parameters (see the reference table below).

Students only gain access once the defined condition is met; the description shown to them is generated dynamically from the same condition.

Restriction Type Reference

Notes

• The restriction is always re-evaluated server-side on every page load — there is no client-side caching of the “unlocked” state to go stale.
• If the PlayerHUD block is removed from the course after a restriction was configured, the condition safely evaluates to unavailable rather than erroring.
• Editing restrictions one activity at a time is the default flow. For a course-wide dashboard with inline editing and bulk removal, see the optional Report Unlocker integration.

🧪 Automated Tests

The plugin ships with unit/integration (PHPUnit) and browser acceptance (Behat) tests, executed on every CI push against the full Moodle 4.5 → 5.2 matrix (PostgreSQL & MariaDB).

PHPUnit — Unit & Integration Tests

vendor/bin/phpunit --testsuite availability_playerhud

Overall line coverage (PHPUnit + Xdebug): 94%.

Behat — Acceptance Tests

php admin/tool/behat/cli/init.php
vendor/bin/behat --tags=@availability_playerhud --profile=chrome

Full test-by-test breakdown and coverage table →

🔐 Security & Compliance

• Instance isolation: item/class name lookups in get_description() and the inventory count in is_available() are always scoped to the course’s own PlayerHUD block instance (blockinstanceid) — a forged availabilityconditionsjson payload pointing at another course’s item or class cannot leak its name, nor can it be satisfied by inventory granted through a different course’s block.
• XSS-hardened rendering: the levelval and itemqty values from the availability tree are cast to int before being persisted (save()) and before being rendered (get_description()) — a forged payload cannot inject HTML/JS into the “Not available unless…” message shown to every student, teacher, and admin viewing the course.
• Safe deserialization: the block’s stored configdata is read with unserialize_object(), restricting the payload to stdClass — a tampered configuration can never trigger arbitrary object instantiation or a POP-gadget chain the way a bare unserialize() could.
• Server-side re-evaluation: is_available() is always recomputed from the student’s live PlayerHUD data on every check; nothing about the “unlocked” state is trusted from the client.
• No external API calls: the condition only ever reads Moodle’s own database.
• Privacy-aware: implements Moodle’s null_provider — this plugin stores no personal data of its own; it only evaluates access rules against data owned by the PlayerHUD Block.

Privacy Provider

The PlayerHUD Availability Condition implements Moodle’s null_provider — it only reads data owned and stored by the PlayerHUD Block (level, inventory, RPG class, gamification status) to compute an access decision; it never persists any personal data of its own. See the block’s own documentation for its full GDPR export/delete coverage.

📄 License

This project is licensed under the GNU General Public License v3 (GPLv3).

Copyright: 2026 Jean Lúcio