snipe-it
snipe-it copied to clipboard
snipe
FEATURE REQUEST: File Upload via REST API
I'd like to request a possibilty to upload files to Assets (and maybe other entities) via REST API.
I found #5007 requesting the same issues and was wondering that this still is not possible. Seems to be a feature of high value and potential.
Alternatively, I could image a feature attaching files via an php artisan snipeit:import but REST API seems more suitable.
Thank you!
@snipe I could have some time to write PR for this, after v6 is out. If I do, how following api path plan look to you?
/hardware/[asset_id]/files (GET -> List uploaded files for asset) /hardware/[asset_id]/files (POST -> upload new file(s) with optional notes) /hardware/[asset_id]/files/[file_id] (GET download file) /hardware/[asset_id]/files/[file_id] (DELETE download file)
I planned to use AssetFilesController as starting point, extend it to support base64 encoded files same way as image upload api does.
@snipe I could have some time to write PR for this, after v6 is out. If I do, how following api path plan look to you?
/hardware/[asset_id]/files (GET -> List uploaded files for asset) /hardware/[asset_id]/files (POST -> upload new file(s) with optional notes) /hardware/[asset_id]/files/[file_id] (GET download file) /hardware/[asset_id]/files/[file_id] (DELETE download file)
I planned to use AssetFilesController as starting point, extend it to support base64 encoded files same way as image upload api does.
I would love this functionality, and those endpoints are perfect.
Perhaps as a stop-gap solution (that would work well in my use-case at least) when an asset's "image" is replaced (using /hardware/id:PUT) the older image could be relegated to the uploaded files instead of removed?
This was already done, no? #9767
I might be misunderstanding that other thread but it seems to be talking about the single image associated with an asset. I've got that set up ok, but any new upload replaces the old one, and in my case I'm tracking possible degradation/damage over time, so need to have older points of reference if, say, a key was pried off by the previous user (or 3 users back and went unreported)
Yes, currently only image uploads are done. Same code will work for file/attachment uploads, after some tweaks.
The big thing for me is to keep a history/record of uploads, not just the most recent image. I'm fine if it's the same API/endpoint, I just want the images not to replace one another.
@NocturnalNick does snipe it keep history of images currently when using browser to upload/change images?
@PetriAsi No. If you upload the image in the "Edit Asset" page it won't keep the old ones. You can upload a file/attachment to the asset and it'll stay there, but there's no API endpoint for that (yet, that's what I'm asking for here)
Hej Guys! @snipe just to make clear I (and probably @NocturnalNick and @PetriAsi ) am asking of uploading attachments to an asset, as shown here:
not just an image to be displayed as the asset's device image
I think this has not been done with #9767 Correct me if I am wrong guys
That's what I want too, I was just saying that we CAN upload an image currently as the device image, and at least for my purposes it would suffice if those device images were kept as a history. I'd rather have file upload functionality as you are after instead, but if new endpoints aren't as easy as adjusting behaviours of old ones...
i am also interested in the feature described by @bjv the solution @PetriAsi described would be exactly what we need.
Was this ever implemented? If so, does it also handle user photos?
Hello @ShaunNeighbourSwale . As far as I know it was not. However @snipe 's comment on #12350 does seem to state the opposite (for users not assets). It might be a case where the documentation is not caught up with the API? I'll run a few tests.
+1
This feature would be great since we are generating handover protocols for assets when they are checked out to an employee. Uploading them via API would be really helpful.
+1 handover protocols for assets and keeping files in SnipeIT, would help a lot. Today it means manually uploading.
Hi there, was this feature ever implemented? Interested in using at our organization. Many thanks!
I got bored and decided to give it a go, and have managed to implement the functionality for this, with the endpoints @PetriAsi described above.
I'm currently having issues running the test suite, and creating a PR (github has somehow decided that 55 of snipe's own commits should be included with the 10 of mine... which seems very wrong). If anyone is able to lend advice it would be appreciated, alternatively I'll keep tackling it as/when I get time
Thank you for taking a stab at this. You probably want to rebase to get rid of those commits of mine. Re: tests, I’ll tag in @marcusmoore, who is our testmeister.
Where this will get tricky is that we will have to store that file temporarily on the server, and make sure it’s run through the same sanitization, mime validation, etc that is used in the non-API controllers.
At least try rebasing so you can open the PR and then we can work with you on the tests :)
@Scarzy when you open the PR the tests will run automatically on GitHub. If you didn't add any new tests then you can skip getting the test suite running locally.
@marcusmoore I haven't created a test for the feature yet, as I was hoping to run the existing tests first, but I am conscious that as a new feature for the API it probably needs a new test
This feature was added and a real big thanks for that and the work which was done. However there is no Documentation in the api Reference and I can not seem to get the file upload to work. I am assuming that it works fine just since there is no Documentation except via code (in the Pull request the comments it is refered to inconsitently) I'm assuming that I'm implementing it incorrectly.
EDIT: I would also like to add that the responce message "File(s) successfully uploaded" from /hardware/{id}/files GET does not portray what is being requsted
However there is no Documentation in the api Reference
Yeah, that's on me. Sorry. It's on my to-do list to give snipe some content to put in the documentation, when I get chance.
I am assuming that it works fine just since there is no Documentation except via code (in the Pull request the comments it is refered to inconsitently) I'm assuming that I'm implementing it incorrectly.
I've just checked the test commands from the PR against the v7.0.9 tag, and they behave as I would expect. All I had to change from the exact commands in the PR was; the asset ID, the API key, the port number, and - when appropriate - the file ID.
I hope you've had some luck in the last couple of days, but if you're still struggling; if you can provide the command you're using I may be able to lend a hand?
I'm not sure I see what you mean by it being inconsistent. Please could you highlight it, so I can try to clear it up when I get a documentation update sorted.
EDIT: I would also like to add that the responce message "File(s) successfully uploaded" from /hardware/{id}/files GET does not portray what is being requsted
Fair
Hi and thanks for implementing Asset file endpoints. I added a PR to extend them to Asset Models. As a TODO reminder, I leave a list of all models currently accepting file upload:
- [x] Assets
- [x] Asset Models
- [ ] Licenses
- [ ] Accessories
- [ ] Consumables
- [ ] Components
- [ ] Users
