Beiträge von Bruce Forte

Zitat von volker.trotte

Mich würde interessieren, welches Ergebnis es hier gibt

Mich auch (unsere agorumcoreaudit.ibd hat ~600 GB).

Hallo nochmal,

ist ja super gelaufen. Ich hab mich eigentlich nur deshalb in diesen Thread eingeklinkt, weil ich die PDF-Library selbst auch noch nie verwendet habe und plötzlich wissen wollte, was sie kann. Jetzt haben wir beide was davon - Party.

Zitat

Nur der Vollständigkeit halber:

Da die Funktion readMetadata eine Objekt-ID verlangt, war noch eine kleine Anpassung notwendig.

Jein. Erstmal hast du natürlich Recht, das Beispiel funktioniert nur, wenn du ebenfalls die Datei im angegebenen Ort liegen hast (also Zeile 5, das ist ziemlich unwahrscheinlich). Aber: Du hast bei div. Funktionen in agorum die Wahl, ob ID, UUID, oder Pfad grade die beste Variante für dich ist. Pfade machen meiner Erfahrung eigentlich nur dann Sinn, wenn der Code möglichst leserlich sein soll, weil man so direkt sieht, um was es konkret geht (z. B. .../Test.pdf - wie cool, ein PDF zum Rumspielen). Prinizipiell möglich wären jedoch (mind.) all diese Varianten und Pfad ist die langsamste:

let myPDF = '/agorum/roi/Files/bla/Test.pdf'            // Pfad
let myPDF = '123456';                                   // Objekt ID
let myPDF = '85699c60-aea5-11eb-b0ed-00155d999a03';     // Objekt UUID

let pdfMeta = pdf.readMetadata(myPDF);

In Schleifen nehme ich hingegen immer IDs, denn hier ist auch am ehesten Geschwindigkeit gefragt:

let pdf = require('common/pdf');
let objects = require('common/objects');

// Loop over all the PDFs in the house (might be many thousands)
objects.query('nameextension_ci:pdf').iterate('id', row => {
  let pdfMeta = pdf.readMetadata(row.id);

  // Do crazy things with pdfMeta ...
});

Hallo dmsrostra,

Zitat

Mittels common/xml stringify bin ich zu einem String gekommen, der dann durchsucht werden könnte. Scheint mir aber etwas unprofessionell.

Ja, das klingt wirklich etwas umständlich.

Dein "XML-JavaScript-Format" hört übrigens auch auf den Namen JSON und ist wirklich cooler als XML. Einer der größten Vorteile an JSON ist, dass sofort alle (Unter-)Eigentschaften als JS-Objekt verfügbar sind und sehr einfach abgefragt werden können.

Probier das mal aus (Zeile 5 musste anpassen):

let pdf = require('common/pdf');
let _ = require('/agorum/roi/Scripting/Libraries/3rdparty/lodash');

// --- Config -------------------------------------------------------------
let myPDF = '/agorum/roi/Files/Testing/Test.pdf';
// ------------------------------------------------------------------------


// Load all metadata from a PDF (returns JSON)
let pdfMeta = pdf.readMetadata(myPDF);

// Find any (nested) property named "name", containing the string "CreateDate"
let results = findNested(pdfMeta, 'name', 'CreateDate');

// We only want the 1st result
let createDate = results[0];

// Bingo! :)
console.log(createDate);


// --- Helper
function findNested(obj, key, needle) {
    if (_.has(obj, key) && obj[key].includes(needle))
        return [obj.value];

    let res = [];
    _.forEach(obj, function(val) {
        if (typeof val == "object" && (val = findNested(val, key, needle)).length)
            res.push.apply(res, val);
    });
    return res;
}

Das Ergebnis ist ein String und sieht z.B. so aus:

>> 2023-09-20T14:25:14+01:00

Mit dem Ergebnis kannst du weiterarbeiten. Evtl. möchtest du in deine Zeitzone übersetzen und am liebsten auch ein für deutschsprachige Augen ansehnlicheres Datum? Easy:

let niceDate = new Date(createDate).toLocaleString('de-DE');
console.log(niceDate);

>> 20. September 2023 15:25:14 MESZ

Hi,

agorum ist im Fehlerfall gerne äußerst gesprächig und was es dir eigentlich sagen will, geht darum manchmal im Lärm unter. In deinem Fall ist das hier relevant

Zitat

Remote document service server is configured, but login is not possible

Ich vermute darum, dass die Zugangsdaten auf dem "remote document service server" nicht korrekt eingetragen sind.

Solltest du mit Windows arbeiten, findest du die relevante Konfigurationsdatei hier:

C:\Program Files (x86)\agorum\agorum core DocumentServer\jboss\server\default\deploy\documentservice.ear\lib\properties.jar\agorum\agceptit\dynawebservices\properties\DynaWebServicesClient.properties

Unter Linux bin ich nicht sicher, wo sie sich versteckt, aber du findest sie im Zweifel mit

find / -iname dynawebservicesclient.properties

Die kannst du mit deinem Lieblingstexteditor öffnen und dann Zeile 20 + 21 anpassen:

Anschließend muss der Dienst (oder alternativ die Maschine) neu gestartet werden.

Hallo,

danke für die Antwort, mit dem beschriebenen Vorgehen funktioniert's. Die Formatanpassung für das Metadatum bleibt nun erhalten, auch wenn nachträglich weitere Änderungen an der Konfig vorgenommen werden.

Hallo,

ich möchte die Standardformatierung für ein Metadatum vom Typ "long" für die Listendarstellung (acic) anpassen. Im Standard wird der Wert um einen hier unerwünschten Punkt ergänzt, den ich gerne loswerden möchte:

Lieber wäre mit stattdessen dieses Ausgabeformat: 2000, 2001, usw.

In der metadata.yml ist im entsprechenden Eintrag bereits eine Formatangabe gemäß Doku angegeben, die hier jedoch nicht zum gewünschten Effekt führt:

veranlagungsjahr:
  displayName: Veranlagungsjahr
  type: long
  format: "####"

Vom Metadata Designer wird die Angabe wie erwartet interpretiert:

Im FilingAssistant Configurator (hier befindet sich u.a. die Konfiguration für meine Liste) kann ich hingegen offenbar keine Formatangaben einsehen oder Ändern, zumindest ist mir hierzu noch nichts begegnet. Die Formatierungsregel in metadata.yml greift jedoch auch nicht. Ich könnte nun noch auf die total verrückte Idee kommen die durch den Configurator erzeugte Konfigurationsdatei nachträglich etwas zu modifizieren (was wir zwar eigentlich gar nicht mögen...):

MetaDb: MAIN_MODULE_MANAGEMENT/filingassistant/2.0/control/Addons/mein.projekt/Lists.json

// vorher:
{
        "hidden": false,
        "defaultValue": "",
        "displayName": "Veranlagungsjahr",
        "descriptionLong": "",
        "format": "",
        // ...
}

// nachher:
{
        "hidden": false,
        "defaultValue": "",
        "displayName": "Veranlagungsjahr",
        "descriptionLong": "",
        "format": "####", // edit
        // ...
}

...aber zum gewünschten Effekt führt:

Dieser kleine Hack wird jedoch bei jeder künftigen im Configurator vorgenommen Änderung frecherweise wieder mit "format": "" überschrieben, also rückgängig gemacht. Darum die Frage: Welches wäre das "richtige Vorgehen" in diesem Zusammenhang? In der Doku konnte ich dazu bislang leider noch nichts finden. Meine agorum Version ist 10.2.4

Hallo aw.agorum,

danke für die Tipps. Der Aufruf aus aguila hat mit _refresh leider nicht funktioniert, denn die Syntax ist abweichend.
Aber so funktioniert's: (das gilt zumindest für agorum < 11):

let service = require('filingassistant/service');

// ...

service.action('_refreshClient', [ folder ]);

Hallo,

ich (agorum core v10.2.x script kiddie) möchte gerne aus einem aguila widget einen refresh im aktuellen smart assistent fenster auslösen. Mein Code legt nach Klick auf einen Button u. A. eine neue Datei im akt. Ordner an. Damit sie sichtbar wird, möchte ich den Ordner anschließend aktualisieren. Wie könnte das funktionieren?

let create = folder => {
  aguila.enter(() => {
    let widget = aguila.create({ /* ...fancy widget with button... */ });

    widget.on('action', action => {
      if (action.name === 'myButton') {
        aguila
        .fork(() => objects.tryCreate('file', {
          name:'MyNewFile.txt',
          target: folder
        }))
        .then(() => {
          // Refresh folder now, pls.
        });
      }
    });
  });
};

create( objects.find('the/target/folder') );