Use the file uploads API for file listing tables, adds gallery view for file uploads

[snipe]

This finally gets us to the point where we're consuming the newly improved file uploads API in our UI - and it also introduces a gallery view option:

Viewing files

Screen.Recording.2025-07-31.at.1.23.20.PM.mov

Non-image media

Screen.Recording.2025-07-31.at.1.30.42.PM.mov

If file does not exist on disk

Screen.Recording.2025-07-31.at.1.24.22.PM.mov

I've also been able to remove/consolidate a few of the BS table formatters to make them more flexible.

Additionally, I reworked the delete modals so that they use the same code all across the boards. Previously, they behaved slightly differently when they were in a listing table versus on the object details page.

To-Do

• Figure out WHY ON EARTH that change from pageSize to pageLimit in the bootstrap-tables partial was needed. WTF.
• Still seeing a few quirks, where the wrong image is showing up when the thumbnail is clicked on the gallery
• A few of the other presenters used one of the methods I replaced so I have to smoke test the other areas where there's a download button in the tables
• Fix the delete modals
• Some weird pagination behavior needs fixing

This should get closer to not having any sections of the list views where we're not using our own API, which I'm pretty excited about.

A few tweaks that might be nice for the future:

• See if there's a way to remember the view (card vs list) between page loads. I don't see anything specifically documented, but we might be ale to drop a cookie or use local storage for that.

[snipe]

Still having a problem getting the delete modal to work within the template. It looks like we have two different behaviors:

#dataConfirmModal doesn't seem to be rewriting the form action to the href attached to the anchor tag, whereas #deleteForm does. As a result, using #dataConfirmModal tries to delete the (in this case) user instead of the file, since with no form action, it will just post against the page you're currently on, which would be the user view page.

Both of these are triggered via the .delete-asset class (though we should probably rename that, since we use it for other things as well) click action, but neither are working as I'd expect/hope.

Outside of the BS tables, we use that same confirmation on regular pages like this:

snipe-it/resources/assets/js/snipeit.js

Lines 138 to 154 in 7c95f03

	// confirm delete modal
	$el.on('click', '.delete-asset', function (evnt) {
	var $context = $(this);
	var $dataConfirmModal = $('#dataConfirmModal');
	var href = $context.attr('href');
	var message = $context.attr('data-content');
	var title = $context.attr('data-title');
	$('#myModalLabel').text(title);
	$dataConfirmModal.find('.modal-body').text(message);
	$('#deleteForm').attr('action', href);
	$dataConfirmModal.modal({
	show: true
	});
	return false;
	});

<a href="#" class="btn-block delete-asset btn btn-sm btn-danger btn-social hidden-print" data-toggle="modal" data-title="{{ trans('general.delete') }}" data-content="{{ trans('general.sure_to_delete_var', ['item' => $user->present()->fullName]) }}" data-target="#dataConfirmModal">
      <x-icon type="delete" />
      {{ trans('button.delete')}}
</a>

which makes sense, since we don't need to rewrite the form action if you're on the page of the thing you're trying to delete.

[snipe]

The last remaining piece here - which is for another PR - will be to switch to the API for GUI uploads and remove those files controllers altogether.