Test paperless-ngx Adapter

[Banis]

Hallo zusammen,

vielen Dank für den Adapter, ich bin tatsächlich der Meinung dass dieser seine Berechtigung hat. Wie ich paperless bisher in verbindung mit iobroker nutze habe ich bereits hier skizziert:

https://forum.iobroker.net/topic/70115/verzeichnis-überwachen-und-datei-in-datenpunkt-schreiben

Nun aber zu meiner Frage: mit deinem Adapter könnte ich meine bisherige Vorgehesnweise deutlich vereinfachen. Leider habe ich es bisher nicht geschafft die Dokumentensuche im Adapter so einzuschränken, dass die Suchbegriffe nur auf Dokumente mit bestimmten Tags angewendet werden. Ist dies möglich? Falls ja wie?

[Ben1983]

@banis Ich wüsste nicht wie.
Ist das mit der API (also wie Du es jetzt benutzt möglich)?

[Banis]

@ben1983

bisher frage ich das wie folgt über die API ab

http://paperless:8000/api/documents/?title__istartswith=&title__iendswith=&title__icontains=&title__iexact=&content__istartswith=&content__iendswith=&content__icontains=&content__iexact=&archive_serial_number=&archive_serial_number__gt=&archive_serial_number__gte=&archive_serial_number__lt=&archive_serial_number__lte=&archive_serial_number__isnull=&created__year=&created__month=&created__day=&created__date__gt=&created__gt=&created__date__lt=&created__lt=&added__year=&added__month=&added__day=&added__date__gt=&added__gt=&added__date__lt=&added__lt=&modified__year=&modified__month=&modified__day=&modified__date__gt=&modified__gt=&modified__date__lt=&modified__lt=&original_filename__istartswith=&original_filename__iendswith=&original_filename__icontains=&original_filename__iexact=&checksum__istartswith=&checksum__iendswith=&checksum__icontains=&checksum__iexact=&correspondent__isnull=&correspondent__id__in=&correspondent__id=&correspondent__name__istartswith=&correspondent__name__iendswith=&correspondent__name__icontains=&correspondent__name__iexact=&tags__id__in=&tags__id=3&tags__id=4&tags__id__all=16&tags__name__istartswith=&tags__name__iendswith=&tags__name__icontains=&tags__name__iexact=&document_type__isnull=&document_type__id__in=&document_type__id=&document_type__name__istartswith=&document_type__name__iendswith=&document_type__name__icontains=&document_type__name__iexact=&storage_path__isnull=&storage_path__id__in=&storage_path__id=&storage_path__name__istartswith=&storage_path__name__iendswith=&storage_path__name__icontains=&storage_path__name__iexact=&owner__isnull=&owner__id__in=&owner__id=&is_tagged=&tags__id__all=
3%2C4%2C16&
tags__id__none=&correspondent__id__none=&document_type__id__none=&storage_path__id__none=&is_in_inbox=&title_content=&owner__id__none=

wobei die mittlere Zeile eine einschränkung auf Dokumente mit den Tags 3,4 und 16 bedeutet.

[Ben1983]

@banis OK, ich kenne von der API nur:

/api/documents/?query=your%20search%20query

Aber für deine Suche müsste man ja die ids der tags kennen, richtig?

[Banis]

@ben1983 ja genau die IDs der Tags könnten dann z.B. in einem weiteren Feld wie bisher das Suchfeld angegeben werden. Im Optimalfall kombiniert mit einem weiteren Feld in dem man angeben kann, ob die IDs ein "und" oder eine "oder" Verknüpfung sein sollen.

[Ben1983]

@banis OK.

1. Wo finde ich eine Doku zum Aufbau der Abfrage?
   Hier: REST API von Paperless
   finde ich nichts, oder ich sehe es nicht.

2. Man muss doch dann die IDs der Tags kennen.
   Ist das wirklich sinnvoll und wäre es nicht schöner die Tags auszuschreiben?
   Das wird aber bestimmt nicht von der API unterstützt.

[Ben1983]

@banis ich habe eine Version 0.1.0 online geschoben.
Hier kann im ersten Step ein Array an tags (ids) hinzugefügt werden.
Zusätzlich kann ausgewählt werden, ob eine und / oder Verknüpfung realisiert wird.

Gerne kann getestet werden

[Codierknecht]

@ben1983
Ich hab' den Adapter gerade erst entdeckt.
Damit erspare ich mir das Auslesen der Datenbank per SQL, um mich über neue Dokumente benachrichtigen zu lassen.

Ich habe Dir 'nen PR mit 2 kleinen Textkorrekturen eingestellt. Sowas stört meinen inneren Monk

Edit
Was mir aufgefallen ist: Wenn man den Adapter auf 'ne falsche IP schickt, wird er trotzdem grün, produziert aber (logischerweise) fleißig Fehlermeldungen.

[Codierknecht]

Super! Mit der neuen Version 0.1.1 kann ich jetzt Trigger auf die Korrespondenten legen.
Damit lasse ich mich benachrichtigen, wenn aus den Mail-Accounts Dokumente importiert wurden.

Das Script möchte ich euch nicht vorenthalten:

const ignoreList = ['Scanner'];

// paperless-ngx.0.correspondents.detailed.001.document_count
on({id: /^paperless-ngx\.0\.correspondents\.detailed\..+\.document_count$/, change: "gt"}, function(obj) {
    console.log(obj);
    const id = obj.id.replace('document_count', 'name');
    const correspondent = getState(id).val;
    if (!ignoreList.includes(correspondent)) {
        const documentCount = obj.state.val;
        const lastCount = obj.oldState.val;
        const count = documentCount - lastCount;
        // hier nur als Log. Ich lasse mir das per Signal senden
        console.log(`Es wurden ${count} neue Dokumente für den Korrespondenten ${correspondent} verarbeitet.`);
    }
});

[Ben1983]

@codierknecht Was für ne Textkorrektur, sehe keinen PR.

[Codierknecht]

@ben1983
Sollte jetzt vorhanden sein.
Direktes Editieren im Original-Repo produziert wohl keinen PR.

[OliverIO]

@codierknecht sagte in Test paperless-ngx Adapter:

Direktes Editieren im Original-Repo produziert wohl keinen PR

eigentlich schon, aber man muss noch einen weiteren Schritt machen.
Das ist bei github aber nicht immer so ganz ersichtlich.
Editieren im original Repo macht die folgenden Schritte:

1. fork des originalRepos in dein Github account
2. einen branchnamen vergeben
3. einchecken der Änderungen

Wenn du dann mit deinen Änderungen fertig bist, müsste da was davon stehen das das Repo soundsoviel "ahead" des eigentlichen Repos ist.
Das steht etwas zwischendrin. ungefähr auf der Höhe wo auch die Anzahl commits des Repos ausgegeben werden.
Da klickt man dann drauf und "schon" kommt automatisch der PR-Dialog.
Wenn man dann den abspeichert, dann ist der PR angekommen.

[Codierknecht]

@oliverio
Mit Git bin ich noch nie so richtig warm geworden.
Mir persönlich hat SVN bislang immer gereicht.

[OliverIO]

@codierknecht

hier meinte ich github

git ist meiner Meinung nach gegenüber svn um einiges fortschrittlicher und hat bei der collaboriativen zusammenarbeit vorteile.

mehrfach erlebt:
der entwickler hat vor seinem urlaub vergessen seine sourcen wieder einzuchecken.
ist immer ein riesen ding gewesen und hat, weil auch andere regeln nicht beachtet wurde öfters zu inkompatiblen code ständen geführt.

[arteck]

@codierknecht sagte in Test paperless-ngx Adapter:

Mir persönlich hat SVN bislang immer gereicht.

na herzlich willkommen in den 90-ern

[Ben1983]

@codierknecht sollte jetzt auch möglich sein, dass man entweder die Dokumente mit allen Tags durchsucht, oder einzelnen ausblendet, oder nur in einzelnen sucht.