Paperless-NG compatibility

[qcasey]

I'm using paperless-ng, do you have any plans to make this app compatible? :)

When connecting, I get a popup that says:

Error while connecting to server
type '_InternalLinkedHashMap<String,dynamic>' is not a subtype of type 'Document' in type cast

Using 0.0.6.1006 from FDroid.

[bauerj]

I'm using paperless-ng, do you have any plans to make this app compatible? :)

I haven't heard of paperless-ng before but now that I have I absolutely do!

The websocket API sounds very neat. This way new documents could instantly be added to the view.

@jonaswinkler Do you think the REST API is stable enough that I could start adding compatibility to the app? Is there an easy way to distinguish between Paperless and Paperless-NG through the API?

[jonaswinkler]

Hi there!

No word on the websocket API yet. I've got that working on a feature branch, and it shows neat progress bars while consuming and returns the document ID when complete, for opening the document. But its pretty much experimental at this point.

As for the REST Api.

• The endpoints for tags, logs, types and correspondents won't change.
• The endpoint for document currently returns documents with "correspondent_id", which is used for editing this property. It also returns "correspondent" inlined, which is read only, and useful for displaying the document and its accompanied metadata in the UI. Same goes for types and tags. I'm not entirely happy with this, so this might change. That's also why I didn't bother to put in the relevant documentation, yet.
• The endpoints for downloading / previews and thumbnails won't change.
• The endpoint for posting documents won't change. If, at all, I'll add form fields for specifying custom titles, correspondents, tags, etc that paperless should use when creating the document. *
• The endpoints for searching and search suggestions MIGHT change.
• I'll probably add token authentication and an endpoint to request a token with username/password. That's easy since the Django REST framework has that built in and it just needs to be enabled. That would at least ensure that the credentials stored in the app are specific to paperless only and not some password that the user might have reused elsewhere.

Given this information, do you have an idea why your app would return this error?

As for distinguishing between OG paperless and this:

• I haven't thought of that yet. Paperless-ng has an /api/search/ endpoint and you could check its status code (200 vs 404) This will always be there, and a GET on that with no query is very fast.

Cheers.

* I think it would be rather cool to specify that in the app just before uploading a document. If not specified, paperless would just fall back to defaults (matching algorithms and using the filename as the title). I know that the older /push/ endpoint had that to a degree, but it relied on this weird file name parsing logic. I changed that quite a bit. If we want this, open an issue over at paperless-ng and we can discuss how to do it.

[jonaswinkler]

FYI, regarding correspondent_id, etc. I'll change these to correspondent, etc, and remove serving nested objects once I figured out how to handle that in the front end. This will be final. I did this initially, since it's much easier to get the document lists going.

However, they're still served as primary keys, and not as URLs.

[bauerj]

No word on the websocket API yet. I've got that working on a feature branch, and it shows neat progress bars while consuming and returns the document ID when complete, for opening the document. But its pretty much experimental at this point.

Neat indeed! My plan for the old API is to query it every few seconds and check if there's anything new. Of course that's not a good plan as consuming might take unpredictably long and fail altogether.

I'll probably add token authentication and an endpoint to request a token with username/password.

That sounds wise.

• I haven't thought of that yet. Paperless-ng has an /api/search/ endpoint and you could check its status code (200 vs 404) This will always be there, and a GET on that with no query is very fast.

This works reasonably well as long as it's a binary decision between paperless and paperless-ng. However, I think it's likely that the API will change in the future. It would make live easier for client developers (e.g. me) if there was a version endpoint that returns a message like

{"version": "0.9.4", "product": "paperless-ng", "api_version": 2}

This would enable this app to maintain backwards-compatibility with older servers without an elaborate probing process to determine available features.

* I think it would be rather cool to specify that in the app just before uploading a document. If not specified, paperless would just fall back to defaults (matching algorithms and using the filename as the title). I know that the older /push/ endpoint had that to a degree, but it relied on this weird file name parsing logic. I changed that quite a bit. If we want this, open an issue over at paperless-ng and we can discuss how to do it.

Yes, I will do so.

Your API changes seem sensible and I'm excited to start working on compatibility in Paperless App!

[jonaswinkler]

Of course that's not a good plan as consuming might take unpredictably long and fail altogether.

Another cool thing about these web sockets is that we get a precise error message when that happens, instead of nothing.

[jonaswinkler]

API's done!

Except for the versioning thing, which I'm not entirely sure about yet. Django offers support for versioning. Clients can specify the version they want to use, and the API serves the corresponding version of the requested endpoint. I'll look into that.

Mention me if you feel that something is missing.

[mvdkleijn]

Sounds like this could be a nice collaboration for both apps :-) Excited to see where this is headed. I just installed paperless-ng last night instead of the original and I'm liking it.

The combination of paperless-ng and this paperless mobile app sounds like a winning combination for me.

[bauerj]

The app is now mostly working with Paperless-NG. Currently it's not possible to view non-PDF files though: jonaswinkler/paperless-ng#108

[bauerj]

The limitation mentioned above is now fixed with recent builds of Paperless-NG.

[bauerj]

Version 0.0.7 has now been released. It maintains full compatibility to Paperless NG!