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
Description of issue:
When an asset is checked out to a user who does not have an assigned location (i.e., the location is null), the asset’s location field still inherits the “default location” instead of being set to null (as derived from the user).
Why this is a problem:
As the IT department, we do not track the physical locations of our users. When an asset is assigned to a user, we only know that the user is responsible for it, but we have no knowledge of the device’s actual location. However, we know for certain that the device is not in the “default location” (which is usually our IT office). The current behavior creates confusion, as the location field incorrectly suggests that the asset remains in the default location.
Workaround with default-user-location not working neither:
As a workaround, we attempted to assign a default location called “user-specific” to all users. The idea was that this value would populate the asset’s location field when the asset is checked out to a user. To implement this, we used the ldap-sync command:
php artisan snipeit:ldap-sync --location=user-specific --summary
While this workaround correctly sets the location to “user-specific” for assets checked out to users, it also incorrectly assigns “user-specific” to assets checked out to a specific location. This behavior is problematic because assets explicitly checked out to a location should retain that location in the location field, not “user-specific.”
If this second issue (the incorrect overwrite of location-specific assets with “user-specific”) could be resolved, it might reduce the need to address the first issue for us. However, it would still be beneficial to understand the logic behind the current behavior, in case there is a deliberate reason for it.
The text was updated successfully, but these errors were encountered:
👋 Thanks for opening your first issue here! If you're reporting a 🐞 bug, please make sure you include steps to reproduce it. We get a lot of issues on this repo, so please be patient and we will get back to you as soon as we can.
Description of issue:
When an asset is checked out to a user who does not have an assigned location (i.e., the location is null), the asset’s location field still inherits the “default location” instead of being set to null (as derived from the user).
Why this is a problem:
As the IT department, we do not track the physical locations of our users. When an asset is assigned to a user, we only know that the user is responsible for it, but we have no knowledge of the device’s actual location. However, we know for certain that the device is not in the “default location” (which is usually our IT office). The current behavior creates confusion, as the location field incorrectly suggests that the asset remains in the default location.
Workaround with default-user-location not working neither:
As a workaround, we attempted to assign a default location called “user-specific” to all users. The idea was that this value would populate the asset’s location field when the asset is checked out to a user. To implement this, we used the ldap-sync command:
php artisan snipeit:ldap-sync --location=user-specific --summary
While this workaround correctly sets the location to “user-specific” for assets checked out to users, it also incorrectly assigns “user-specific” to assets checked out to a specific location. This behavior is problematic because assets explicitly checked out to a location should retain that location in the location field, not “user-specific.”
If this second issue (the incorrect overwrite of location-specific assets with “user-specific”) could be resolved, it might reduce the need to address the first issue for us. However, it would still be beneficial to understand the logic behind the current behavior, in case there is a deliberate reason for it.
The text was updated successfully, but these errors were encountered: