snipe / snipe-it

A free open source IT asset/license management system
https://snipeitapp.com
GNU Affero General Public License v3.0
10.92k stars 3.16k forks source link

Requestable Assets #11934

Open brianhoganm opened 2 years ago

brianhoganm commented 2 years ago

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

  1. None
  2. ...

Expected behavior

I would think that once someone requests an item the "request" button should be disabled.

Screenshots

SNIP

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

dlane11 commented 1 year 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.

brianhoganm commented 1 year ago

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: @.***>

brianhoganm commented 1 year ago

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.

dfilippi commented 1 year ago

There are some news about this bug?

AlbertoSilva82 commented 1 year ago

Do we have any news about it? Thank you!

negie1989 commented 1 year ago

Hi, Do you have any updates about this request? Thank you

brianhoganm commented 1 year ago

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..

snipe commented 1 year ago

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.

brianhoganm commented 1 year ago

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.

BernardMcWeeney commented 3 months ago

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?

Bresel1 commented 3 months ago

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.