Open brianhoganm opened 2 years ago
I would also add that once a request is fulfilled and returned, it is removed from the requestors list. With the above request, the asset would be placed back into deployable for another request.
Totally agree!
On Tue, Oct 25, 2022, 1:48 PM dlane11 @.***> wrote:
I would also add that once a request is fulfilled and returned, it is removed from the requestors list. With the above request, the asset would be placed back into deployable for another request.
— Reply to this email directly, view it on GitHub https://github.com/snipe/snipe-it/issues/11934#issuecomment-1290997338, or unsubscribe https://github.com/notifications/unsubscribe-auth/A2FP6U65YG3IFFQJPSV4N7TWFATRTANCNFSM6AAAAAAQ6X5RHE . You are receiving this because you authored the thread.Message ID: @.***>
Another issue is that after checking in the item once the item is physically returned, the client has to cancel the request in order to request the items again. This is confusing.
There are some news about this bug?
Do we have any news about it? Thank you!
Hi, Do you have any updates about this request? Thank you
I don't beleive there is any news on this yet. I know Snipe and other programmers are working hard on releasing new features and fixes. Maybe it might get fixed in version 7! Let's hope..
As I'm sure I mentioned in other threads, this isn't really a bug, The way this was originally designed was that multiple people could request the same item. The use case was test equipment for our QA team, where whoever came first (or for some reason had higher priority) would get it first, but the requests after it were still valid. Sara returns the test mobile device, so then the next person in the request queue can have it checked out to them.
This is, of course, not everybody's use-case, so we're trying to think through ways we can expand this functionality to better meet a wider set of needs.
As I'm sure I mentioned in other threads, this isn't really a bug, The way this was originally designed was that multiple people could request the same item. The use case was test equipment for our QA team, where whoever came first (or for some reason had higher priority) would get it first, but the requests after it were still valid. Sara returns the test mobile device, so then the next person in the request queue can have it checked out to them.
This is, of course, not everybody's use-case, so we're trying to think through ways we can expand this functionality to better meet a wider set of needs.
Thanks Snipe. Makes sense. We use this for teachers to request assets which has been a HUGE help! This has helped me so much because when teachers request an item, I can check out the itemto them and fill out the expected check out date which of course than send out email reminders to turn it back in.
As I'm sure I mentioned in other threads, this isn't really a bug, The way this was originally designed was that multiple people could request the same item. The use case was test equipment for our QA team, where whoever came first (or for some reason had higher priority) would get it first, but the requests after it were still valid. Sara returns the test mobile device, so then the next person in the request queue can have it checked out to them.
This is, of course, not everybody's use-case, so we're trying to think through ways we can expand this functionality to better meet a wider set of needs.
Just wondering if these changes will be made in the V7 updates?
Hi, I would also like this option to be implemented. Maybe a simple settings toggle ("mark requested items as non-requestable") would be good to keep both options available.
Debug mode
Describe the bug
@snipe - I love the Requestable Assets feature in Snite-IT. This is very useful. I know others have requested dates feature but I would like to know if I am not understandin how the request works:
When a user request a laptop, I can go ahead and check the item out. This works great. However, if another user goes in to make a request, why doesn't the Request button get grayed out or disabled? I have people who are requesting the same item even though it's already deployed. I understand there is a learning curve /and I need to communicate to my staff that if an item says deployed with an expected check-in date, they should NOT click on request. Is there anyway we can fix this so that the request button is disabled?
Reproduction steps
...
Expected behavior
I would think that once someone requests an item the "request" button should be disabled.
Screenshots
Snipe-IT Version
6.10
Operating System
Windows
Web Server
IIS
PHP Version
7.4
Operating System
No response
Browser
No response
Version
No response
Device
No response
Operating System
No response
Browser
No response
Version
No response
Error messages
No response
Additional context
No response