Add document file name to API

[bauerj]

I have found one change in the API that I perceive as a regression. The old API used to contain a file_name attribute for documents. This is gone now. I have used the file ending to choose which viewer to use (PNG files don't work in Adobe Reader for example).

This means that currently only PDF documents can be viewed in Paperless App, if Paperless-NG is the backend.

[jonaswinkler]

The endpoints for previews and downloads correctly report filenames and content type as part of the response (Content-Disposition and Content-Type). I thought having the filename in the document object would be redundant. The fetch view of OG paperless does this as well.

I can add these again, However: Paperless generates PDF documents with embedded text from images and stores both the original image and the PDF document in its media folder. The API prefers to serve the PDF over the original, if available. There's an option that forces paperless to serve originals, which I need to document. The response headers always reflect what's being served.

Some background: I really wanted paperless to be able to add selectable text to image-only documents (both pdf documents without text and pure images), and since I didn't really feel comfortable with overwriting the original documents, I've decided to keep both. This solution also allows users to retroactively add text layers to image-only documents, and keep track of which documents this has already been done for. Also: No issues when the pdf libraries decide to fail. Also: No issues when users want to move away from paperless, original documents still there.

If I were to add filenames again, each document would have both an original_file_name, and maybe an archived_file_name, if one is available. Should we do that?

I really need to get this documented.

[bauerj]

I guess I could implement that by parsing the Content-Disposition header but that would mean I either had to

1. Make a request to the download endpoint, even if the file is already downloaded, just to find out the type. Of course this would dramatically increase the time it takes to open a document.
2. Maintain a mapping of document -> file type locally. I tried not to store any metadata locally to prevent getting it out-of-sync with the server.

I guess solution number 2 is okay but I would prefer your proposal of including original_file_name and archived_file_name as that would be cleaner.

[jonaswinkler]

Well, that's done. I'm sorry for making this somewhat more complicated, however, these changes were required for the new OCR mechanisms.

[bauerj]

Thanks! No worries, this seems to be straight-forward 😊