snipe-it
snipe-it copied to clipboard
snipe
Consumables counting error
Debug mode
- [X] I have enabled debug mode
- [X] I have read checked the Common Issues page
Describe the bug
When you delete an user who has got consumables product the quantity counter increase more 1. and the name disappearing and show deleted user!
That is an very annoying bug for us, because the quantity number should to stay and the user name also!
Please fix it this!
Reproduction steps
...
Expected behavior
when i delete an user his consumables stay on him, and the quantity number show correct quantity, because the consumables product stay on him.
Screenshots
No response
Snipe-IT Version
6.0.8
Operating System
linux
Web Server
apache2
PHP Version
7.4.3
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
Hello there!! Where are you watching this behavior? In the consumables view even if the user is deleted the count remains as if the consumable is still checked out. It stays with the deleted user as you say. In the screenshot, I have 2 consumables assigned to 2 different users. Then deleted those users and the remaining is still 8/10.
(Also I don't think you're supposed to be allowed to delete a user that has anything checked out to them. That's what "Checkin and Delete" is for.)
Edit: Sorry for the double-post there. Internet is a little wonky right now.
That's true!! The only thing the controllers ('normal' and API) doesn't consider as constraint are consumables :S
I fix that in this PR https://github.com/snipe/snipe-it/pull/11663 Which maybe indirectly fixes OP's issue? as now it doesn't let the user with consumables assigned to get deleted.
That was the behaviour in the 6.0.7 and early 6.0.8
Tested!
Köszönettel:
Szalay Zoltán IT operation
From: Ivan Nieto Vivanco @.> Sent: Thursday, August 11, 2022 11:21 PM To: snipe/snipe-it @.> Cc: Szalay Zoltán @.>; Author @.> Subject: Re: [snipe/snipe-it] Consumables counting error (Issue #11548)
Hello there!! Where are you watching this behavior? In the consumables view even if the user is deleted the count remains as if the consumable is still checked out. It stays with the deleted user as you say. In the screenshot, I have 2 consumables assigned to 2 different users. Then deleted those users and the remaining is still 8/10.
[image]https://user-images.githubusercontent.com/653557/184244230-785e119e-e66b-43e2-aac2-570b2e066760.png
— Reply to this email directly, view it on GitHubhttps://github.com/snipe/snipe-it/issues/11548#issuecomment-1212505777, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AZFDA7YLZVKE57PWWUT2ZFLVYVVD5ANCNFSM54KX275Q. You are receiving this because you authored the thread.Message ID: @.***>
anyway wouth be better solution I think if we would see this form: Deleted user(name) or we would can choose this ….
Waht do you think?
Köszönettel:
Szalay Zoltán IT operation
From: Ivan Nieto Vivanco @.> Sent: Thursday, August 11, 2022 11:21 PM To: snipe/snipe-it @.> Cc: Szalay Zoltán @.>; Author @.> Subject: Re: [snipe/snipe-it] Consumables counting error (Issue #11548)
Hello there!! Where are you watching this behavior? In the consumables view even if the user is deleted the count remains as if the consumable is still checked out. It stays with the deleted user as you say. In the screenshot, I have 2 consumables assigned to 2 different users. Then deleted those users and the remaining is still 8/10.
[image]https://user-images.githubusercontent.com/653557/184244230-785e119e-e66b-43e2-aac2-570b2e066760.png
— Reply to this email directly, view it on GitHubhttps://github.com/snipe/snipe-it/issues/11548#issuecomment-1212505777, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AZFDA7YLZVKE57PWWUT2ZFLVYVVD5ANCNFSM54KX275Q. You are receiving this because you authored the thread.Message ID: @.@.>>
anyway here is an other unlogical thing! Sometimes maybe happen that we give out an consumables, but change our mind! So we have to check in! Now at this time this is impossible in 6.0.9…. Why?
Please before you develop somethin try to overthinking the snipe it consumables handling logic….
Köszönettel:
Szalay Zoltán IT operation
From: Ivan Nieto Vivanco @.> Sent: Friday, August 12, 2022 12:06 AM To: snipe/snipe-it @.> Cc: Szalay Zoltán @.>; Author @.> Subject: Re: [snipe/snipe-it] Consumables counting error (Issue #11548)
I fix that in this PR #11663https://github.com/snipe/snipe-it/pull/11663 Which maybe indirectly fixes OP's issue? as now it doesn't let the user with consumables assigned to get deleted.
— Reply to this email directly, view it on GitHubhttps://github.com/snipe/snipe-it/issues/11548#issuecomment-1212544417, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AZFDA7YWXOCN2DIWSX424QDVYV2M5ANCNFSM54KX275Q. You are receiving this because you authored the thread.Message ID: @.@.>>
I’m going to assume that part of this issue is a language barrier, but please don’t suggest that we don’t think about things before we push them out. It’s very rude. We have been developing this software for 9 years. While we don’t do everything perfectly every time, we don’t need the extra attitude.
sorry than
Az iOS Outlookhttps://aka.ms/o0ukef letöltése
Feladó: snipe @.> Elküldve: Friday, August 12, 2022 5:51:25 PM Címzett: snipe/snipe-it @.> Másolatot kap: Szalay Zoltán @.>; Author @.> Tárgy: Re: [snipe/snipe-it] Consumables counting error (Issue #11548)
I’m going to assume that part of this issue is a language barrier, but please don’t suggest that we don’t think about things before we push them out. It’s very rude. We have been developing this software for 9 years. While we don’t do everything perfectly every time, we don’t need the extra attitude.
— Reply to this email directly, view it on GitHubhttps://github.com/snipe/snipe-it/issues/11548#issuecomment-1213261557, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AZFDA7ZZWRT6TVFCNYAVWGTVYZXH3ANCNFSM54KX275Q. You are receiving this because you authored the thread.Message ID: @.***>
This issue is pretty old and we've pushed out quite a few releases including one that we mentioned should fix this issue, so I'm going to close this for now.