Accessories can now be flagged as requestable and requested by users from
the requestable items page, the same way assets and asset models already
can. No migration is needed since the accessories table already carries a
requestable column.
I kept the semantics deliberately simple: a request just records intent
(and the requested quantity) and notifies the admins. It does not touch or
reserve stock. The admin still performs the normal checkout, which is what
actually decrements quantity. That way requests behave the same for unique
assets and for quantity-based accessories, instead of inventing a separate
"reserved" state.
The admin "Requested" queue already lists every checkout request
polymorphically (it showed asset models too), so accessory requests appear
there as well; I extended that view to render the accessory name, image and
a checkout action so an admin can actually see and fulfil the request.
While wiring this up I also fixed a pre-existing bug in the request flow:
the Requestable trait saved a 'qty' key, but the column is 'quantity' and
wasn't fillable, so requested quantities were being silently dropped (this
affected asset models too). Quantity is now persisted and read back
correctly.
Components and licenses can follow the same pattern; they each just need a
small migration to add the requestable column.
Renamed CheckoutRequest action classes to include "Action" in their names for consistency and clarity. Enhanced error handling in controllers to standardize error responses with translations. Updated usage of the renamed action classes throughout the code to ensure proper integration.
