Added #9594 : Feature api image uploads and remove

[PetriAsi]

Description

Fixes #9594, #9483,#9413,#5007

Allow images to be added and removed via api for accessories, assets, asset models, categories,companies, components, consumables,departments, locations, manufacturers, suppliers and users. That great news for for automation and data sync.

So with this PR you can use 'image' or 'image_delete' attributes to api and result are expected.

I added image support by allowing multipart/form-data requests to api . As there's already ImageUploadRequest class that I used for updating images and also image deletes. So no need to maintain duplicate any code for api images handling.

POST request are working without anything special, but PUT and PATCH will require additional '_method' attribute containing request method. That's due to how php/laravel handles multipart requests.

Pros: You can use 'image' or 'image_delete' attributes to api and result are expected. Just send request as multipart/form-data and you are done. Sending images with multipart request needs little server resources. Sending image is straightforward cause no need to convert it to base64 before sending.

Cons: Setting images via json formatted request is not possible with this PR.

@snipe if you like keep api just for json request, then this can be done in new request class like ApiImageUploadRequest that would handle encoded image-fields and image_deletes.
There's also undocumented api for assets that accepts image_source attribute as base64 encoded images #6146 . As "image" field cannot be currently set via API, would it be acceptable to use direcly "image" field instead of "image_source"? This image_source feature can and meby should be combined to ApiImageUploadRequest.

Type of change

• [ x] New feature (non-breaking change which adds functionality)
• [ x] This change requires a documentation update

How Has This Been Tested?

Image uploads tested with curl command like:

curl --request POST      --url https://devbox:8443/api/v1/hardware      --header 'Accept: application/json'      --header 'Authorization: Bearer xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx'      --insecure -F 'model_id=1' -F 'status_id=1' -F 'image=@1623706902-300_x_250_2019.png'

Test Configuration:

• PHP version: 7.4.19
• MySQL version 10.4.19-MariaDB
• Webserver version nginx
• OS version Alpine/docker

Checklist:

• I have read the Contributing documentation available here: https://snipe-it.readme.io/docs/contributing-overview
• I have formatted this PR according to the project guidelines: https://snipe-it.readme.io/docs/contributing-overview#pull-request-guidelines
• My code follows the style guidelines of this project
• I have performed a self-review of my own code
• I have commented my code, particularly in hard-to-understand areas
• I have made corresponding changes to the documentation (api documentation cannot be edited)
• [x ] My changes generate no new warnings
• I have added tests that prove my fix is effective or that my feature works
• New and existing unit tests pass locally with my changes

[snipe]

Hi there - thanks for this! This looks great, but can you make these changes against the develop branch, per our contributing documentation?

Thanks!

[PetriAsi]

Ups. I actualy have done this against develop , but missed it when doing pull request.

[PetriAsi]

@snipe What you think, should this be rewritten with new ApiImageUploadRequest class that would allow json image uploads? More I think about this, more I like json based alternative to multipart/form-data.
To validate base64 I would like use something like base64-validation to do all hard work.

[snipe]

@PetriAsi - thanks! Re: whether this should be written with a ApiImageUploadRequest, my biggest challenge there is just the old DRY pain in the arse. We try really hard to not repeat validation, etc, since when it changes in one place, we invariably forget to change it in another.

What's the intent here, that images get uploaded and resized via the API? If so, I'd be more inclined to modify the ImageUploadRequest to look for an is_json or some such thing to prepare the image that way, versus creating another form request.

[PetriAsi]

(..Is there something wrong with Codact as it throws errors on security scan)

@snipe Yes, my intention is that api should do same verifications and manipulations to images uploaded via api that it does to images uploaded from web gui.

As I see api image upload can be divided two separate problems that can be resolved independently.

1. Image uploads . Current PR does that, so it's working solution for api image uploads. Not perfect as it need multipart/form-data request, but this is acceptable.
2. Json based requests for image uploads. This is more trickier. Current workaround with image_source have it limitations , no content verification etc.

As problem 1 can be treated as resolved with this PR. And For json formatted image uploads, I could make new separate issue/PR.

As you said for DRY it's better modify ImageUploadRequest to work with json formatted requests instead of duplicating current code to new class. I'll think ways to implement validation rules and file handling logic that will work with multipart/form-data and json formatted inputs.

[PetriAsi]

@snipe , @uberbrady This is now ready to pull, image uploads are working with json and multipart/form-data. File type restrictions are working as expected and all image manipulation is shared no matter where image came from.

I added json base64 decoding as trait, goal was decode files before validation and add them to $request->files, but I could not find way to add file to request. And I really tried. :) But modifying request fields was working ,so trait converts base64 encoded field to UploadedFile, and that did it!

[PetriAsi]

And now a special image_source field isalso handled with ConvertsBase64ToFiles.

[PetriAsi]

Added two more issues (#9413,#5007) that this PR fixes.

[PetriAsi]

@uberbrady ,is there something that I can do or should do with this PR ? And I could make v6 version of PR also if I just know what branch I should use. :)

[uberbrady]

@PetriAsi I've looked over the PR a few days ago and I thought it seemed very pretty and well-built to me - I think we just need to figure out if we want to take it against current develop, or against our v6 integration branch. We should hopefully have an answer for you today.

[PetriAsi]

@uberbrady Thanks for info. I'm not trying to rush, maybe I'm just over excited for my first feature PR. I hope that you can take it against current develop. I also tested it again v6-integration and it seems to fit there as well, just with little manual tweaking.

[snipe]

Love your excitement! :)

I’m willing to take this into develop - Can you make it work against the develop-v6-integration branch too? (This is all going to be awful merge conflict hell right before v6 releases, but…)

[PetriAsi]

@snipe Yes, I love my excitement. That's what moves me , many times I'm just a passenger. :)
I'll merge it to develop-v6-integration and make new PR for it.

[snipe]

Hi @PetriAsi - I've merged this into master and tagged it into v5.2.0, but I'm not sure how we should handle the API documentation on this.

image as the field, as a string? A "file"? I know we went back and forth, so just checking to see where this one netted out.

[PetriAsi]

@snipe
For the json requests, image field should be formatted string like:
data:@[mime];base64,[base64encodeddata]
For example like on page File to Base64 and selecting option "Data URI -- data:content/type;base64"

This simple format works fine for single image fields, but if we like to support uploading multiple files once (ie. for assets) we need format that carry also filenames. But that will be another story.

It's also possible to submit image upload request as multipart/form-data to api, without json formatting. Actually all api requests can be done as form requests.
SnipeitPS is currently using multipart/form-data for image uploads if powershell is v 7.0 or greater. That saves encoding overhead on sending side and also on server.