Drag-and-drop column reordering, interested in a PR?

[kubakubikulakubakubakbubak]

Hi,

We run Snipe-IT in-house and the most common complaint from our team was that table columns can only be shown or hidden, not reordered, people end up scrolling sideways past columns they don't care about to reach the ones they do.

I've written a small client-side plugin that adds drag-and-drop column reordering to the bootstrap-table instances (assets, licenses, users), with the order persisted per user. It's built on bootstrap-table's own reorderColumns extension, so upstreaming it wouldn't pull in anything beyond jQuery UI sortable, and it touches no controllers or migrations as it stands.

Would you be interested in this going into Snipe-IT proper? If so I'd be glad to open a PR, I'd just want your input on two things first:

1. Where the per-user column order should live (user setting vs. client-side storage).
2. Whether you'd want it enabled by default or behind a setting.

Happy to share the code or a short screen recording before I spend time cleaning it up for review. And if a GitHub discussion or issue is the better place for this, just say so and I'll move it there.

Thanks,
Jakub

[snipe]

That's a good question - I'd say localStorage for now, just because we'd have to build an entire UI and database structure around every single items table view in the system, and that seems... sub-optimal. I'd be happy to look at a PR, but bear in mind, as I've mentioned, the BS tables extension has never worked properly, and I'm not sure how well it will play with our CSS sticky columns (we do not use BS tables extension for that because it was also broken so we had to roll our own.)

[snipe]

localStorage is, of course, less ideal, since it wouldn't be preserved across different devices, but the UI nightmare that would come with keeping it in the database, plus fallback behaviors when we add a new column, rename/remove a column, etc). If in the database, I could see a small settings icon that loads a modal for reordering, but again, many people want different columns/ordering depending on the context of the page. For example, on a user's "assets" tab, you might not want/need allllll of the info you'd want on the assets listing page. So if we do database-style, that starts to get very mess very quickly.

[kubakubikulakubakubakbubak]

Thanks, localStorage works for me, and agreed that the database version isn't worth the UI and migration cost.

On per-context ordering: I'd key the stored order off the table's existing data-cookie-id-table value rather than a single global preference, so the asset listing and a user's assets tab get separate orders automatically, consistent with how column visibility already works. For added/renamed/removed columns, the stored value is just an ordered list of field names, reconciled on init, unknown fields dropped, new ones appended at their default position, and a fallback to defaults if the overlap is too poor to use.

Point taken on the extension. I'd skip it and reorder the columns array with refreshOptions instead, using native drag events on the header cells, no jQuery UI, and we don't inherit the extension's problems.

Sticky columns I want to verify rather than assume. Let me test against your sticky CSS first, scope it to the asset listing table, and post a short screen recording here (including the pinned-column case) before opening a PR. If it can't be made to behave cleanly with your implementation I'll say so rather than send something half-working.

[snipe]

That sounds great. The reason we had to toss the sticky column BS tables extension is that it was acting weird on tables with very few items, resulting in strange wrapping on the sticky columns that wasn't lining up with the actual row - which was obviously be dangerous at worst (if the sticky delete button was aligned with the wrong row) or annoying at best (where the sticky edit button was aligned to the wrong row and then the user would end up editing the wrong thing.) It was also conflicting with the open+close info-panel, where the tooltips for "delete", etc were hovering over the panel instead of the actual button, so those are some things to look out for. You'll notice in resources/partials/bootstrap-table.blade.php there are a bunch of places where we have to do a quick refresh of the table and recalculate some things to avoid all of that. It's pretty well documented though, so you shouldn't have much trouble figuring out what we're doing.

[snipe]

That said, if the drag+drop stuff ends up being too janky, we could still do the settings icon+modal approach, but save it via localStorage instead of a DB for simplicity. I know a lot of people have wanted this for a while, so I'm thrilled you're willing to take a stab.