Register active custom asset definitions as orderable itemtypes (GLPI 11)

[bygadd]

Summary

GLPI 11 introduced native custom assets defined via Setup → Asset definitions. The plugin's hardcoded $ORDER_TYPES array in plugin_init_order() does not include them, so custom asset classes never appear in the Item type dropdown when creating a new Product reference, making it impossible to order anything based on a custom asset definition.

This PR introduces a new Orderable capacity that admins enable per asset definition (Setup → Asset definitions → {asset} → Capacities). Asset classes whose definition has the capacity enabled — and for which the current user has read permission — are appended to $ORDER_TYPES.

Implementation notes

• New PluginOrderOrderableCapacity class (extends \Glpi\Asset\Capacity\AbstractCapacity) with label, icon, description, and a usage count based on existing PluginOrderReference rows.
• Capacity is registered against AssetDefinitionManager at plugin_init_order() time, after which active definitions are iterated and filtered.
• Per-user permission is enforced via $class::canView(), which delegates to the asset's AssignableItem READ check plus the definition's is_active flag.
• The class_exists() guard on \Glpi\Asset\AssetDefinitionManager makes the block a no-op on GLPI ≤ 10.x, preserving backward compatibility.
• The existing AssignableItem handling from Fix generateitem massive action #560 already works correctly with custom asset classes once they are registered as orderable itemtypes — no changes to link.class.php are required.

Testing

Tested on GLPI 11.0.6, PHP 8.3, Order plugin 2.12.6 with a custom asset definition ("Електро Материали НН"):

Step	Result
Orderable capacity appears in Capacities tab with proper label/icon/description	✅
Capacity disabled → custom asset absent from Product reference Item type dropdown	✅
Capacity enabled → custom asset appears, references can be created	✅
Type and Model dropdowns populate via + 'Type' / + 'Model' class name convention	✅
Order validation flow	✅
Item delivery flow	✅
Generate item massive action (form renders fully, submit works)	✅
Reception flow, generated assets appear in corresponding Assets section	✅
Native itemtypes (Computer, Monitor, Printer, Peripheral) verified unaffected	✅

Checklist

• I have performed a self-review of my code.
• I have added tests (when available) that prove my fix is effective or that my feature works.
• I have updated the CHANGELOG with a short functional description of the fix or new feature.
• This change requires a documentation update.

[bygadd]

Updated visual evidence — capacity-based design

Demonstrating the new capacity workflow on stock GLPI 11.0.6 with custom asset "Електро Материали НН".

1. The new Orderable capacity in Setup → Asset definitions → {asset} → Capacities (here shown enabled):

2. Item type dropdown shows the custom asset once the capacity is enabled:

3. Product reference can be created with the custom asset (Test reference, type Крива С, model 16A):

4. Order item flow — adding the new reference to an order:

5. Generate item massive action renders fully and submits:

6. Generated assets in Item delivered tab (Waiting for delivery):

7. After delivery — items reach Taken delivery state with serial numbers, visible in Associated items:

[stonebuzz]

This is a good start =)

However, the Order plugin should introduce an "Order" capability for the custom Asset, allowing this feature to be enabled or disabled on a per-asset basis.

Additionally, this functionality should verify the read permissions of the currently authenticated user for the specified custom Asset before proceeding.

[bygadd]

Thanks for the review @stonebuzz, both points were spot on.

The branch has been updated (force-pushed to keep a single clean commit, 6f94427). Summary of the changes:

1. New Orderable capacity — inc/orderablecapacity.class.php introduces PluginOrderOrderableCapacity extending \Glpi\Asset\Capacity\AbstractCapacity. Admins now toggle it per asset definition under Setup → Asset definitions → {asset} → Capacities. Provides label, icon (ti ti-shopping-cart), description, and a usage count based on existing PluginOrderReference rows.

2. setup.php filtering — registers the capacity with AssetDefinitionManager, then iterates active definitions and appends a class to $ORDER_TYPES only when:

• the Orderable capacity is enabled on that definition, and
• $class::canView() passes for the current user (which delegates to the asset's AssignableItem READ check + the definition's is_active flag).

End-to-end re-tested on GLPI 11.0.6 / PHP 8.3:

Scenario	Result
Capacity appears in the Capacities tab with proper label/icon/description	✅
Capacity disabled → custom asset is absent from Item type dropdown	✅
Capacity enabled → custom asset appears, references can be created	✅
Generate item massive action renders and submits	✅
Items reach Taken delivery state, generated assets visible in Assets section	✅
Native itemtypes (Computer, Monitor, Printer, etc.) unaffected	✅

Also updated the PR description (top of this thread) and the CHANGELOG entry to reflect the new opt-in design.

Let me know if you'd like any adjustments — happy to iterate.

[stonebuzz]

You must declare your capacity in order for it to appear in the list.

This should be done in the setup.php file using:

AssetDefinitionManager::getInstance()->registerCapacity(...)

In addition, when a capacity is disabled, the associated data must be properly cleaned from the database.

In particular, this concerns the glpi_plugins_orderorder_item table, which—if I recall correctly—stores the relationship between an asset and an order.

[bygadd]

Thanks for the follow-up @stonebuzz, the new commit 5fd0975 addresses the data cleanup point.

On registerCapacity() — small clarification: the current branch (6f94427 and now 5fd0975) already declares the capacity through \Glpi\Asset\AssetDefinitionManager::getInstance()->registerCapacity(...) in setup.php, so it appears in the Capacities tab on GLPI 11 asset definitions and the Orderable toggle is admin-controlled. The inline review thread above is anchored to the original ea13dd1 push (the auto-register block) which is no longer in the branch — that may be why it reads as if the registration is missing.

On the cleanup — implemented onCapacityDisabled() on PluginOrderOrderableCapacity. When an admin disables Orderable on a definition, the callback removes:

• order line items in glpi_plugin_order_orders_items whose itemtype matches the disabled custom asset class;
• product references in glpi_plugin_order_references whose itemtype matches the disabled custom asset class.

The cascade order matters: PluginOrderReference::pre_deleteItem() rejects deletion while a reference is still in use by orders_items, so child records are deleted before parents. Free-form references (PluginOrderReferenceFree) are intentionally left untouched as they carry no itemtype reference.

End-to-end tested on GLPI 11.0.6 / PHP 8.3 on two installations:

Scenario	Result
Disable capacity → references and orders_items for the targeted class are removed	✅
Native itemtypes (Computer, Monitor, Printer, …) are untouched	✅
Other custom assets that still have the capacity enabled are untouched	✅
Re-enabling restores the asset class in the Item type dropdown; new references and order items can be created	✅
The capacity description shows the live "Used by N order references" count, surfaced in the GLPI confirmation dialog before disabling	✅

Specifically on the second installation, disabling the capacity on a small custom asset definition while keeping a much larger one (~12k order line items, ~600 references) enabled left the larger one fully intact — confirming the targeted, per-class scope of the cleanup.

Happy to iterate further if you'd like adjustments.

[stonebuzz]

You must declare your capacity in order for it to appear in the list.

This should be done in the setup.php file using:

AssetDefinitionManager::getInstance()->registerCapacity(...)

In addition, when a capacity is disabled, the associated data must be properly cleaned from the database.

In particular, this concerns the glpi_plugins_orderorder_item table, which—if I recall correctly—stores the relationship between an asset and an order.