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.
* WIP - beginning of improved requested assets
- Use Ajax tables for faster loading
- Use new notifications for requesting an asset
TODO:
- Use ajax tables for requestable asset models
- Use new notifications for canceling an asset request
- Expire requests once the asset has been checked out to the requesting user
* Only show asset name in email if it has one
* Refactor requested method to only include non-canceled requests
* Refactored requestable assets to log request and cancelation
* Added softdeletes on checkout requests
* Differentiate between canceling and deleting requests
* Added asset request cancelation notification
* Added timestamps and corrected unique key on requests table
* Improved requests view
* Re-use blade for cancel/request email
* Refactored BS table formatter for requested assets
* Location name min reduced to 2
* Added PAT test as maintenance option
This needs to be refactored into database-driven options with a UI
* Better slack message
* Added getImageUrl method for assets
* Include qty in request notifications
TODO:
- Try to pull requested info from original request for cancelation, otherwise it will default to 1
* Removed old asset request/cancel emails
* Added user profile asset request routes
* Added profile controller requested assets method
* Added blade link to requested assets for profile view
* Sort user history desc
* Added requested assets blade
* Added canceled at to checkoutRequest method
* Include qty in request
* Fixed comment, removed allowed_columns
* Removed Queable methods, since we don’t use a queue
* Fixed return type in method doc
* Fixed version number
* Changed id to user_id for clarity
* Add presenters for models. Move bootstrap table JSON generation to these presenters, which cleans up controllers a lot. Move view specific modifications from the models to the presenters as well.
* Fix some issues found by travis and codacy
* Fix a few more issues found while testing.
* Attempt another acceptance test fix
* Try something else
* Maybe..
* Create a new action_log table to replace asset_log. Use Polymorphism to generalize class and targets. Port everything I can find to use it. Add a migration to port the asset_logs table to action_logs.
* Initial work on requestable asset models
* Backend work for polymorphic requests table to store checkout requests.
* Add missing files
* Add a record to the db when requesting items. Build up a testing route for interfacing with this.
* Users can now toggle requests of items on the request page. Reformat page to use the same tab layout we use elsewhere
* Polymorphic request function. Implement requesting of asset models. Need to port mail/slack to notifications still.
* Implement requesting of asset models. Build up emails and notifications to support it. Allow specifying a quantity of model to request.
* Add view to show currently requested assets. Needs some work and cleanup, but it isn't accessible from anywhere yet.
