You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
So under the API for check in in you have to specify the status id, it looks like that the code is taking the last status id of the device that is deploy-able.
In an environment where you may be using status that indicate that an assets is deployed you have to set the status to asset first before assigning the status where if we call the API directly we can assign a status at the same time that the device is checked out.
Expected Behavior
The behavior should be over-writable via an option parameter that allow the user to specify a device.
Current Behavior
Takes whatever the current status is.
Possible Solution
Implement a -status_id optional parameter
The text was updated successfully, but these errors were encountered:
For me it seems that snipeit reference is not up to date. Not the first time :)
When looking at snipe-it code app\Http\Controllers\Api\AssetsController.php checkout function does not use status_id at all. And checkin function while using it, does now actually require it. Still file app\Http\Requests\AssetCheckoutRequest.php allows specifying status_id but does not require it.
Reset-SnipeitAssetOwner supports setting status_id if needed. And all cases where I have used it set-snipeitassetowner works fine. Do you have some case where this is making some kind of issue? There's no code in SnipeitPS that alters status_id at checkout it just left out in request.
Maybe this can be reported to snipe-it as reference issue, on their repo.
Context
So under the API for check in in you have to specify the status id, it looks like that the code is taking the last status id of the device that is deploy-able.
In an environment where you may be using status that indicate that an assets is deployed you have to set the status to asset first before assigning the status where if we call the API directly we can assign a status at the same time that the device is checked out.
Expected Behavior
The behavior should be over-writable via an option parameter that allow the user to specify a device.
Current Behavior
Takes whatever the current status is.
Possible Solution
Implement a -status_id optional parameter
The text was updated successfully, but these errors were encountered: