Snipe-it: Child assets don't inherit default location from parent

[tomholovis]

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

Describe the bug
If you change the default location/location of an asset, sub-assets (assets that are checked out to the asset) should inherit the new location.

To Reproduce
Steps to reproduce the behavior:

1. Create asset "parent"
2. Create asset "child1" and "child2"
3. Check out child1 and child2 to parent
4. Change the default location of parent (i.e it has been shipped to a different location)
5. child1 and child2 maintain their current location and do not inherit the location of parent

Expected behavior
Child1 and child2 should inherit the location of the parent.

Server (please complete the following information):

• Snipe-IT Version 4.7.7
• Hosted by Snipe-IT

[snipe]

It seems like that's behaving as expected. The default location is just where the item would be normally if it weren't checked out to someone/something. Changing that automatically could potentially cause some issues with different use-cases where that behavior isn't expected.

I'm not sure what the best way to handle this would be.

[tomholovis]

So if the location of the parent changes the location of the child should change. This is how it works if you check an item out to a person. If you change the persons location then the location of the item also changes (not the default location, the current location). (at least it did last time I tried)

[snipe]

People don't have a "default" location though, they just have a location.

[tomholovis]

Yes, so when you change the location of the parent the child should inherit this location. Sorry I probably confused things by even mentioning the word default.

Person location -> checked out asset location
Asset location -> child asset location

[snipe]

My concern here is that there may be use-cases that we're not considering, and this could end up being a breaking change that messes other folks up, so trying to think through the best way to handle this.

[tomholovis]

Absolutely. I haven't spotted any edge cases myself, it just feels like an anomaly. Two similar actions result in two different outcomes.

I'll leave it with you. Feel free to drop me a mail if you want to seem my specific use-case.

[snipe]

Well the tough part is that because you don't actually set an asset's real location, only the default location, updating the "Default location" of a parent asset and having that update the actual location of child assets seems like it could be confusing behavior.

"Default location" doesn't affect child items assigned to a parent anywhere else, so this would be a one-off behavior.

[snipe]

Assets assigned to people assume the person's actual location. The Default location of that asset doesn't actually change though, just the location that's displayed for where it really is. (That's de-normed in the database as location_id just for performance reasons.) Updating the Default location for child assets here would be a change in behavior.

I could potentially change the actual location of the child assets, but leave the Default location alone, which seems the better way to go, since the very nature of Default location is "when it's not checked out, this is where it lives."

[snipe]

I'm not sure if I'm being clear here - sorry. The tricky part is that the parent asset doesn't have a "real" location, just a default location. Also this gets more confusing and complicated if the parent asset is checked out to a person - how many steps down that line do we go?

[tomholovis]

You just took the words out of my mouth.

When you update the default location of an item that is not checked out it also updates its current location.

Therefore it is the inheritance of actual locations that I am interested in.

A device that is checked out to location Y has its actual location updated to location Y. Then it follows that any assets checked out to this parent asset should also have their actual location updated.

The only reason changing a default location comes into it is if the parent is not checked out anywhere. Changing the default location updates the actual location.

[tomholovis]

I'm not sure if I'm being clear here - sorry. The tricky part is that the parent asset doesn't _have_ a "real" location, just a default location. Also this gets more confusing and complicated if the parent asset is checked out to a person - how many steps down that line do we go?

Every asset has both an actual location and a default location does it not?

[snipe]

Every asset has both an actual location and a default location does it not?

Yes, but an asset that isn't assigned doesn't have a way to surface that real location, since it's assumed to be inherited. (Assets checked out to assets/locations was not originally part of this system, and I still deeply regret adding it sometimes.)

[tomholovis]

(Assets checked out to assets/locations was not originally part of this system, and I still deeply regret adding it sometimes.)

It's the main reason we use the software. We have very few people and a large number of locations. I appreciate that we're not really using the software for its intended application of tracking IT assets but it's the simplest, easiest to use solution I've managed to find for asset tracking. The only work-around I have to do at the moment is related to shipping. I have to change the default location to the devices intended destination and then checkout to "In transit".

Perhaps we should have a chat about how we're using the software?

[snipe]

I have a PR open for this here:
https://github.com/snipe/snipe-it/pull/7458

As I mention in the PR, I'm not sure how far down the recursion black hole we want to go here...

[tomholovis]

Thank you!

I'm not sure how far down the recursion black hole we want to go here...

Where's the excitement without sub-queries of sub-queries?...

[snipe]

@tomholovis - give that a whirl and let me know how it works out for you.

[tomholovis]

Closed by #7458

[tomholovis]

@tomholovis - give that a whirl and let me know how it works out for you.

I don't have a self hosted instance to test with :-/

[snipe]

Roger that - let me run this past QA tomorrow when they're up and we'll see if we can merge it for you soon.

[snipe]

Er, today, technically.

[tomholovis]

Who knows! I'm currently GMT+8...

[snipe]

It's 3:25AM here (California), but QA is based off of EST