Feature - Improve assets bulk checkin/checkout

[FlorentDotMe]

Description

Needs review/improvements: So far, you can expect some things to be broken.

Main changes

• Replicate the assets selection method (dynamic select2 field) of Bulk Checkout to the Quick Scan Checkin view:

  • API: filter dynamic assets list to show only Deployed assets

• Add Checkin and Checkout as Bulk actions for selected items in assets index, asset / user views:

  • API: add ability to handle assets tag or id as parameters to prefill the asset tags list in the checkin/checkout view
  • Scripts: share commun javascript functions by moving them to snipe-it.js

• Add additional fields to be set on Bulk checkin: Status, Checkin Date

• Ability to scan assets tags is preserved.

Current development status

• No conflict with latest develop branch
• Code seems functional with features decribed below
• No PHP unit tests - May be needed to prevent regressions
• Lack of comments

Screenshots

New Bulk Checkout action

Bulk Checkin result

Bulk Checkout result

Bulk Checkin/Checkout in assets, users and kit views

Linked feature requests: #14466

Type of change

• Breaking change (fix or feature that would cause existing functionality to not work as expected)
• This change requires a documentation update

How Has This Been Tested?

Usual use of the bulk checkin/checkout process.

Checklist:

• I have read the Contributing documentation available here: https://snipe-it.readme.io/docs/contributing-overview
• I have formatted this PR according to the project guidelines: https://snipe-it.readme.io/docs/contributing-overview#pull-request-guidelines
• My code follows the style guidelines of this project
• I have performed a self-review of my own code
• I have commented my code, particularly in hard-to-understand areas
• I have made corresponding changes to the documentation
• My changes generate no new warnings
• I have added tests that prove my fix is effective or that my feature works
• New and existing unit tests pass locally with my changes

[snipe]

One thing that has prevented us from handling this in the past is the JS selectivity based on the status of the object, For example, if you select all but have a mix of checked in and checkout assets, we should probably deselect the ones that are not eligible for the action selected. The UX on that gets a little squirrely IMHO. What if you accidentally selected the wrong option, now everything you previously selected gets un-selected. We can handle this on the backend, of course - the same way we do with other bulk things, where we let you select it, but once you get to the confirmation interstitial, we tell you why we can't do the thing you're trying to do.

We already send the "checkoutability" etc through the API which is handled through the formatters, and determines whether you see an enabled/disabled checkin/checkout button, so this isn't exactly a hard problem to solve, but accidental clicks could definitely be a friction point.

[what-the-diff]

PR Summary

• Added Status Check for Assets
  A new check is added to the AssetsController that verifies if an Asset is 'Deployed'. This will help in accurately retrieving the list of deployed assets.

• Modified Checkout, Checkin Methods in AssetsController.php
  The code has been updated to improve how we handle data during the checkout and check-in procedures. It improves the efficiency and reliability of these operations.

• Expanded Functionality in BulkAssetsController
  New case scenarios for check-out and check-in have been added to BulkAssetsController to handle group actions on assets better.

• Changes to Asset State Tracking Procedures
  Enhancements are made to the way we keep track of whether an asset is checked-out or not, providing more accurate information on the status of assets.

• Improvements to Asset Selection Procedures
  The 'assetSearch' function has been added to improve the ability to search assets effectively and accurately.

• Upgrade of User Interface Elements
  Modifications have been made to various components of the user interface, such as forms, notes, and sections which enhances user experience when navigating through pages.

• Inclusion of Translations for Checkin and Checkout Buttons
  This would simplify the understanding and usage of the checkin and checkout operations for non-English speakers.

• Bulk Asset Management Functionality
  A new function has been added to manage assets in bulk, especially for actions like checkins and checkouts.

• Introduction of New Routes in API
  New routes for checkouts and checkins via tags or IDs are added, enabling more specific and flexible asset management.

• Updating Views for Asset Management

  • A new view, asset-bulk-actions, was introduced to handle multiple asset operations.
  • hardware/view.blade.php was updated to include new view and removed redundant elements.
  • Several other views have been updated for better handling of asset management operations.

• Improved Search Functionality
  The button handling the clearing of search input in bootstrap-table.blade.php view has been updated for better user experience.

[snipe]

We already handle this case here I think.

status has a switch case for Deployed on line 239

[FlorentDotMe]

Not sure to get the point, as index() and selectlist() functions are not calling each other. Or perhaps that's your point? Calling index() from selectlist()?

[FlorentDotMe]

One thing that has prevented us from handling this in the past is the JS selectivity based on the status of the object, For example, if you select all but have a mix of checked in and checkout assets, we should probably deselect the ones that are not eligible for the action selected. The UX on that gets a little squirrely IMHO. What if you accidentally selected the wrong option, now everything you previously selected gets un-selected. We can handle this on the backend, of course - the same way we do with other bulk things, where we let you select it, but once you get to the confirmation interstitial, we tell you why we can't do the thing you're trying to do.

We already send the "checkoutability" etc through the API which is handled through the formatters, and determines whether you see an enabled/disabled checkin/checkout button, so this isn't exactly a hard problem to solve, but accidental clicks could definitely be a friction point.

Hi @snipe, thanks for your quick feedback. There is a lot of code change highlighted, despite some parts are just reindented. I hope it won't be too painful to read :)

You are right about such mix can occur when selecting non checkable (in or out) assets. Dynamically unselecting them will definitely need to notify the user.

Perhaps such notifications can immediately appear in the Status table for non eligible items, explaining why they don't appear in the assets tag input? I will have a deeper look at the "checkoutability" calls and other bulk actions to find out simple ways to clarify this.

[FlorentDotMe]

I resumed development of this PR several days ago after a long stalling period. I also noticed that in the meantime some work on it has been done separately in #15680.

So far, there are some substantial differences and additions:

• Assets tags are passed in the HTTP request, instead of being passed directly to the View
• Initial checkability verification on selected assets
• Add a checkin date in the Bulk Checkin
• Move the list of assets to the bottom, due to its dynamic size related to the number of selected assets
• Checkin: add the status of process checkin (similarly to Bulk Checkout).
• ... (possibly some other points)

Below are some screenshots of the implemented modifications:

1. Update menu entries title to make them consistent
   

2. Checkin/Checkout Bulk Action
   

3. Process initial checkability of assets on loading Checkin/Checkout view
   

4. Selecting a User shows assigned assets
   

5. Confirm Bulk Checkout of selected assets to a User and update the list of assigned assets