Add storage containers/boxes

[gyhughes]

What is the problem you are trying to solve with this feature?

As a user I would like the ability to store items in cardboard boxes, plastic storage containers, server racks, etc. I have 4 plastic bins in my garage all with miscellaneous items. I would like to know/track which items are in which box in the garage.

What is the solution you are proposing?

Implement Storage Containers, allowing items to become placed within a container. The containers would be within a Storage Location. Attributes: name, description.

What alternatives have you considered?

Labels, but could get messy, and probably not the point of labels.

Additional context

No response

Contributions

• [X] I have searched through existing issues and feature requests to see if my idea has already been proposed.
• [ ] If this feature is accepted, I would be willing to help implement and maintain this feature.
• [ ] If this feature is accepted, I'm willing to sponsor the development of this feature.

[hay-kot]

I'd like to implement this, but I'm not sure the best approach. I could see two ways

1. Nested Locations, which just allows a location to belong to another location and that would allow you to specify granular locations like Office -> Closet -> Blue Box
2. Nested Items which would accomplish the same thing, but with items instead.

Or maybe both are needed? I'd like to solve this problem, but I think I need some more discussion around the approach to take to make sure I get the design right.

[gyhughes]

Maybe both. I could see box within a box within a box (or location like bedroom->closet->shelf->box). I can also think of item within item: NAS=[HD1,HD2,HD3,HD4,DRAM1,SSD]

[Froghut]

I guess in the context of searching it might be nice for containers to be able to be both, perhaps with checkboxes. A cabinet might be only a (nested) location, but a box (or from the example above the NAS) might be both a location and an item. That way I could search for a specific box when searching for items.

[StoneCotton]

I could see both being super flexible. As already mentioned, some items could end up being stacked, or items that are kits are a good example. A use case I have is with photography or video equipment. Let's say I have a camera bag, in that I have a camera body, couple lenses, batteries, filters, and some storage media. Each of these I'd like to be able to input information about since they are all individual items, just put together or customized to my current wants and needs. It would be great to be able to nest these items into a "camera bag" location or storage kit, and then assign that camera bag to a place like storage closet. There's something to be said about grouping then multiple of these locations together to something like Storage Closet->Camera Shelf->Equipment Box->Camera Bag->Items but the issue I could see there is having a large chain complicate things. Maybe limiting it to a certain number of nests if that's an implementation?

Sidenote, even though this is only in beta, this is almost a perfect solution for what I've been looking for. Snipe-IT is the only alternative I've known previous to this, but this is the one feature which they have not done anything with for years which has prevented me from using it for this exact reason. From even just using Homebox for the last hour, it has the simplicity that I'm looking for so if a feature like this is implemented, it would be a no brainier.

[Motordom]

I can see the merit in both and would use both. It would also be important to allow nested items within nested locations. For example:

Nested locations

[SL] Cupboard -- [SL] Box 1 ---- [I] Camera ---- [I] PSP

Nested items

[SL] Office -- [I] Microsoft Surface Pro 5 ---- [I] Surface Pro type cover ---- [I] Surface Pro pen ---- [I] Surface Pro dock

Both

[SL] Cupboard -- [SL] Box 1 ---- [I] Camera ------ [I] 32GB SD card ---- [I] PSP ------ [I] 16GB Memory stick

[Mevas]

From a technical point of view, this feature seems pretty straight forward to implement, at least on the backend side of things. You'd just have a new column, in both the locations and items table, each holding a foreign key pointing to their own table, thus allowing "nesting", where any location / item can be the child of any other location / item, with infinite depth. This approach would also be backwards-compatible, requiring no changes to be made to the search functionality or already existing relationships between locations and items, or similar pre-existing features.

On the frontend side of things is where the bulk of the work would be needed, I feel like, to be able to find a user-friendly way of conveying these relationships and an easy way of editing them. Probably a combination of a drag & drop collapsible tree structure and autocomplete fields (on both the location and item page, allowing the search & selection of a parent) would be the most intuitive way of handling it. Though, in my experience, the drag & drop structure is somewhat of a nightmare to implement, so autocomplete fields would be most likely enough, especially in beta.

I would try implementing at least part of this myself, but I have no experience with either Go or Vue, so all I can do is make suggestions, having implemented a similar nesting system with drag & drop in an unrelated work project.

[hay-kot]

Okay, so here's what I'm thinking so far for the implementation

1. Recursive Relationships Child/Parent for both Locations and Items with unlimited deep nesting with a maximum recommended depth of say 3-4 items for performance reasons, but likely won't be an issue
2. When fetching a single item we return the parent node with a summary (not all fields loaded) and the children (as summary objects)

New Questions I Have

1. When you delete a parent, should the delete cascade down the tree? If I delete an item do all it's children then get deleted as well?
2. What's the optimal way to view these in browser? Not edit, but actually view your items in some way that provides useful information? Would an org chart work?

Will probably have more questions once I get into implementing.

[Mevas]

1. No, the parent of its children should be set to null, because maybe you just took the items out of the box and threw the box away. Maybe there is use for deleting the entire content of a box recursively, but deleting only the parent should still be the default behavior, to avoid unintentional data loss.
2. Probably the most natural and simplest way to convey a hierarchical structure is with a tree, like a folder system (such as the one displayed above by @Motordom), ideally collapsible, containing the name, tags and perhaps description on each row. It can also make for a pretty compact view of a certain collection. An org chart would also work I assume, but I feel like it would get tricky to correctly render deeper structures. Another interesting visualization could be how disk space analyzers - such as Spacesniffer - display the file system, but it's most likely a non-trivial thing to implement.

[hay-kot]

Initial support has been merged into the nightly branch, should be available here in the next half hour or so. All the main pieces are there, but could use some fine tuning.

Closing this one for now, if someone wants to outline a feature request on a better visual representation of the nesting relationships, that would be appreciated!