Bug: Editing an asset resets current location to default location

[ckinsler]

Expected Behavior (or desired behavior if a feature request)

We just ran into an odd issue where we checked in an asset and changed it's location at the same time, moving it into a "Lab" location. This allows us to reimage the PC to get it ready for the next deployment before going into storage. This check in piece DID move the current location as expected, however a subsequent EDIT of the asset (to update an custom "image date" field) subsequently moved the asset back to its DEFAULT location instead of leaving it where it was.

This ONLY seems to happen on assets that ARE NOT checked out to someone (if they are deployed, it seems to leave the locations alone)

So Several points here:

• Ideally when editing an asset, the currently assigned location should stay the same, and not be changed back to its default location (just like it does when an asset is in a deployed state)

• If this is done: For non checked-out assets, we probably also need to expose the (current) Location field in the edit asset screen as well, since there will be no way to move the asset BACK somewhere without a subsequent check-out\check-in action (as only the default location field is editable)

.

For clarity, here's the business case for the asset flow:

1. Asset is in an inventory location (likely it's default)
2. Asset gets checked out to user (and takes on a current location of the user's profile)
3. Asset is returned from user, and at time of check-in is moved to a "Lab" location
4. Asset is refurbished\re-imaged, and a custom data field is edited on asset indicating the refresh data (this is the step that is currently overwriting the current location data)
5. Asset location at some point needs to be updated back to Inventory location (or could be any location) for next deployment -- this wouldn't necessarily always be it's default location if it was moved to another Lab, inventory area, etc

---

Actual Behavior

See above

Please confirm you have done the following before posting your bug report:

• [X] I have enabled debug mode
• [X] I have read checked the Common Issues page

---

Provide answers to these questions:

• Is this a fresh install or an upgrade? Fresh

• Version of Snipe-IT you're running v4.1.9 - build 3128 (master)

• Version of PHP you're running PHP 7.0.22

• Version of MySQL/MariaDB you're running mysql Ver 15.1 Distrib 10.1.30-MariaDB

• What OS and web server you're running Snipe-IT on Ubuntu 16.04.3 x64, Apache2

• What method you used to install Snipe-IT (install.sh, manual installation, docker, etc) install.sh

• WITH DEBUG TURNED ON, if you're getting an error in your browser, include that error N/A

• What specific Snipe-IT page you're on, and what specific element you're interacting with to trigger the error See Above

• If a stacktrace is provided in the error, include that too. N/A

• Any errors that appear in your browser's error console. N/A

• Confirm whether the error is reproducible on the demo: https://snipeitapp.com/demo. Yes, all confirmed via demo URL's

• Include any additional information you can find in app/storage/logs and your webserver's logs. N/A

• Include what you've done so far in the installation, and if you got any error messages along the way. N/A

• Indicate whether or not you've manually edited any data directly in the database N/A

[snipe]

Thanks for the detailed bug report - we'll take a look.

[snipe]

I can see where/why this is happening, I'm just not exactly sure how to get around it.

The code itself is very simple:

if ($asset->assigned_to=='') {
            $asset->location_id = $request->input('rtd_location_id', null);
}

The purpose for that is so that if you change the asset's current default location during a normal edit, it updates the location_id to whatever the new default location is - which is generally a thing you'd want. It's an unusual use-case for someone to change the location to a non-default when it's not checked out, versus just updating the default RTD location.

So I'm trying to figure out how to solve for your use-case without donking things upon for other folks who don't override locations on checkin.

[ckinsler]

As a stop gap, maybe only run that update IF the default location is actually edited? We had edited only a custom field when we did our update, which (since it wasn't checked out) changed the location of the asset

We could also internally change our process to just check out the asset back to a location (vs. just changing the location as part of the check-in), but that'd probably be confusing to folks since there is an option to change the location as part of the check-in

I remember seeing a prior feature request to allow you to check in and re-check out at the same time -- maybe that would be the better long term answer? So you'd actually be reassigning the asset properly vs just changing its current location ID?

[snipe]

maybe only run that update IF the default location is actually edited

How would we know that though?

[ckinsler]

Is there not a way to compare the before\after values on an update to see if they change?

Another thought -- What if you exposed the asset's current location (in addition to default) as an editable field on the asset screen? That way you could change it's physical location without necessarily checking it out (which may be a more frequently used use case, to still keep the asset available for check-out).

Right now if you DO change the location during a check-in event, there's currently no way to update it back to some place else anyway (sans a checkout or this edit event). So that would also fix that issue as well

Thoughts?

[snipe]

Is there not a way to compare the before\after values on an update to see if they change?

There is, but it will look the same when submitted whether it was pre-populated (because of edit) or whether it was changed during the edit.

What if you exposed the asset's current location (in addition to default) as an editable field on the asset screen?

We could do that, but then we'd have to remove the location override in checkin/audit, since we'd just run into the same problem all over again.

[ckinsler]

We could do that, but then we'd have to remove the location override in checkin/audit, since we'd just run into the same problem all over again.

Not sure I understand here -- you can already change the current location away from default on a check-in action. If you made this change, that current location field would ultimately be visible and editable under the edit screen. (I think) the only thing you'd need to remove is the location overwrite on the asset edit save (the code where you're overwriting location if the assigned_to is blank). This code wouldn't be needed anymore, as the user could change the current location AND default location from the same asset edit screen at the same time.

It's been a long day, so I apologize if maybe I'm missing something?

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions!

[JonathonReinhart]

Here's another actual, acknowledged issue, closed by stale bot. Please re-open.

[eitler-terra]

We have the same Problem. Please re-open.

[athompsoncmc]

Same issue. We "assign" devices to classrooms by just bulk auditing the current location because the bulk checkout doesn't work with barcode scanners. If the device is edited then it's removed from the location, then we don't see it as assigned to the location.

[stale[bot]]

Okay, it looks like this issue or feature request might still be important. We'll re-open it for now. Thank you for letting us know!

[stale[bot]]

Okay, it looks like this issue or feature request might still be important. We'll re-open it for now. Thank you for letting us know!

[NMX-Drew]

I'm having this issue with Version v5.3.0 - build 6470 (master), has any work been done on it? I'd like to add a +1 to this issue if not

[cunego]

Hi, Any news on a solution for this behaviour ?

When we checkout a Monitor f.ex. to a an office of ours, the 'Checked out To', actual 'Location' and 'Default Location' are all set to the name of the office. Checked out To = Office A Location = Office A Default Location = Office A

When the monitor is now moved from the office to our warehouse, the monitor is checked in. This sets the actual 'Location' field, which is fine. We want to keep the 'Default Location', so we know from which Office the asset came. Checked out To = <Empty> (checkedin) Location = Warehouse Default Location = Office A

When an IT user now simply edits the asset - it doesn't matter which field - , after saving the asset, the actual 'Location' field is set allways to the 'Default Location' field, which is - in our case - NOT fine.

As a workaround, we can only avoid this if we change the asset by using the Bulk Edit method. If we do not touch the 'Default Location' field, the 'Default Location' is still set to our office, and the actual 'Location' is still set to our warehouse.

The only very annoying thing is that I cannot prevent my IT users from editing the assets in a normal way, by means of the 'Edit Asset' button in the 'View Asset xxxx' view... and this happens a lot.

Like ckinsler is asking : Is there a way to prevent changes to the 'Default Location' and 'Location' field when changing OTHER fields in the asset and saving them ???

PS : Also, the actual 'Location' field is not allways visible in the details of an asset.

[timurkun]

Agree, still have this issue. Users confused and periodically lose actual locations of their assets:(

[snipe]

I believe this has been fixed recently - can anyone confirm if they're still seeing this?

[snipe]

Hi there - We haven't heard back in a bit, so I'm going to close this ticket for now, but will re-open it if you're still having issues.