Feature/admin zip upload on reset

[hahn-kev]

closes #327

[github-actions]

UI unit Tests

1 tests  ±0   1 ✔️ ±0   0s ⏱️ ±0s
1 suites ±0   0 💤 ±0 
1 files   ±0   0 ❌ ±0 

Results for commit 5e9402d. ± Comparison against base commit 27ca67b.

♻️ This comment has been updated with latest results.

[github-actions]

C# Unit Tests

33 tests  +3   33 ✔️ +3   10s ⏱️ -2s
  6 suites ±0     0 💤 ±0 
  1 files   ±0     0 ❌ ±0 

Results for commit 5e9402d. ± Comparison against base commit 27ca67b.

♻️ This comment has been updated with latest results.

[myieye]

I tried to upload the zip that I downloaded and it didn't work:

Sounds like you picked the right one (reading here and here) and we even zip it explicitly with that type. Seems like tus does something weird here. Anyway, that's why I expanded/introduced the allowed zip types.

[hahn-kev]

Alright I've pushed my error code work and set translations in place as well.

As for the zip mime type. According to a comment on this answer windows will report the mime type of a .zip file as application/x-zip-compressed. The mime type we're getting in the backend comes directly from the browser file API, we pass the mime type as metadata to tus, so it's probably not changing anything there. Can you console log out the file type when it's selected and report back what you see and if you get something else? I just tried and I can't ever get x-zip-compressed doesn't matter the zip file or browser.

My main concern with that is that different OS or something will report the type differently and an admin might be stuck.

[myieye]

@hahn-kev I can't ever get application/zip. I tried Firefox and Chrome and downloading the zip from the API in k8s and locally.

[hahn-kev]

I get the same thing from powershell, I wonder why it's different in the browser on my machine. Well I guess we can support both and hope there's no extras. @rmunn could you see what a browser on linux reports the mime type for a zip file is?