Beiträge von Majob

Hallo @annkatrin.goepfert,

danke für die Rückmeldung. Ist tatsächlich nicht die erhoffte Rückmeldung, aber dann mach ich erstmal weiter so. Es ist halt umständlich bei der Entwicklung, da man für jede Miniänderung immer gleich den Workflow deployen muss, bevor ich die Auswirkungen sehe. Vielleicht könntet ihr als Story mit aufnehmen, irgendwann den Dialog die Ausführkonfiguration anzufassen, sodass man neben den Token-Variablen auch direkt Parameter übergeben könnte.

Hallo annkatrin.goepfert,

ich benutze bereits die initialize und finalize Knoten. Die sind tatsächlich sogar das Problem. Angenommen ich entwickle gerade einen eigenen neuen Workflow-Knoten, der in unterschiedliche Workflows eingebunden werden soll und dieser Workflow-Knoten benötigt einen einfachen Parameter:

// Configuration widget for this workflow
let builder = require('/agorum/roi/customers/acworkfloweditor/js/utils/configuration-builder')();
// define the configuration for the node
let config = () => [
  {
    title: 'Wichtiger Parameter',
    name: 'parameterName',
    editors: [ 'editor', 'expression' ],
    editor: {
      type: 'agorum.composite.form.element.text',
    }
  },
];

module.exports = {
  widget: () => builder.build(config()),
  config: config
};

Mittels initialize-Knoten lasse ich die Parameter dann auf die Variable "myConfig" schreiben. Das führt dann zu folgendem Zustand des Tokens, wenn der Workflow-Knoten benutzt wird:

{
  "sys_acw_internal": {
    "myConfig": {
      "parameters": {
        "parameterName": "Ein wichtiger Wert"
      }
    }
  }
}

Soweit so gut. Jedoch möchte ich zum Testen den Workflow gern über die Ausführen-Schaltfläche ausführen. Wenn ich dort die oben gezeigten Token-Variablen übergebe, dann werden diese durch den initialize-Knoten durch nicht vorhandene Parameter überschrieben. Mir bleibt aktuell nur der Workaround, den Workflow für jede Änderung zu deployen und dann aus einem anderen Workflow heraus zu testen. Das mache ich nun schon relativ lange so, ist aber während der Entwicklung ziemlich umständlich.

Hallo,

ich habe häufiger mal folgende Szenario: Ich habe einen eigenen parametrisierten Workflow-Knoten. Dieses möchte ich gern über die "Ausführen"-Schaltfläche im Workflow-Editor direkt testen. In der Ausführkonfiguration kann ich aber nur die token-Variablen übergeben und nicht die benötigten Parameter. Wenn ich versuche, die Parameter als Workaround in der Ausführkonfiguration direkt an das Token zu schreiben, werden sie anschließend im agorum.basic.initialize wieder mit den nicht vorhandenen Parametern überschrieben. Gibt es für dieses Szenario ein BestPractice ohne den Workflow bei jeder Änderung deployen zu müssen und dann über einen anderen Workflow zu testen?

VG

Manuel

Hallo,
hab inzwischen in der /agorum/roi/customers/agorum.uninstall.manager/js/uninstaller.js-Datei die Lösung gefunden. Dort existiert eine remove-Worker-Funktion, die für den Verwendungszweck funktioniert.

let removeWorker = (name, type) => {
  let w = Packages.agorum.roi.workers.Workers.get(name);
  if (w) w.remove();
  
  let s = Packages.agorum.commons.statistic.Statistic.getStatistic('WorkersStatistic.' + type + '.' + name);
  if (s) s.removeFromParent();
};

annkatrin.goepfert, Oliver Kaufmann Jedoch ist zu beachten, dass in dem Code der uninstaller.js wohl noch ein Fehler steckt. Im Namen des Statisitc-Node des Workers ist der type eigentlich gar nicht enthalten. Nur wenn ich den Code wie folgt abwandele, funktioniert auch das Löschen der Worker Statistik

let removeWorker = (name) => {
  let w = Packages.agorum.roi.workers.Workers.get(name);
  if (w) w.remove();
  
  let s = Packages.agorum.commons.statistic.Statistic.getStatistic('WorkersStatistic.WorkersSubStatistic.' + name);
  if (s) s.removeFromParent();
};

Hallo,

weiß jemand einen Weg, um einen Worker programmatisch z.B. per pre-Script zu löschen? Ich konnte erfolgreich den dazugehörigen MetaDB-Eintrag des Workers löschen. Jedoch ist der Worker anschließend nach wie vor im SupportTool zu sehen. Erst nach einem Neustart verschwindet der Worker wirklich.

Kann ich das (Neu)laden der Worker aus der MetaDB irgendwo anstoßen, ohne Agorum neu starten zu müssen?

Hallo,
wir haben inzwischen eine Lösung gefunden, die gänzlich ohne CSS auskommt. Grundsätzlich war der Wunsch, dass in einer Status-Spalte der Wert "aktiv" zusätzlich mit einem grünen und der Wert "inaktiv" mit einem roten Icon angezeigt wird. Das sollte so aussehen wie im Screenshot aus Smart Orga. Bei der Lösung aus Smart Orga wird dabei mit einem css-Selektor ein entsprechendes SVG-Icon zur n-ten Spalte hinzugefügt. Problem dabei ist, dass das Icon immer in der n-ten Spalte angezeigt wird, selbst wenn der Nutzer manuell die Spaltenreihenfolge ändert.

Daher haben wir stattdessen zunächst die Icons in die Werte des Metadatums selbst als Unicode-Zeichen integriert 🟢=> https://www.compart.com/de/unicode/U+1F7E2. Jedoch ist die SOLR-Suche nach Metadaten, die mit einem Unicode-Icon beginnen, nicht so schön. In einem zweiten Schritt haben wir daher die Icons in separate Übersetzungsdateien ausgelagert und speichern lediglich die Übersetzungskeys als Werte am Metadatum. Mit Hilfe des etwas spärlich dokumentierten Features, Metadaten anzulegen, deren Werte vor der Anzeige übersetzt werden, ist es uns dann gelungen, die Übersetzung in die Listen-Konfiguration aufzunehmen (siehe https://agorumdocproxy.agorum.…5056aa0ecc/acds-anchor-48).

Also falls nochmal jemand das Problem hat



VG

Manuel

Oh, gut dass wir drüber reden...

Das heißt, das expirationData hat eigentlich nichts mit der Ablaufdauer der Revisionssicherheit zu tun? Wie können wir dann programmatisch die Dauer angeben, wie lange ein Dokument revisionssicher gehalten werden soll? Oder sind das immer fix 10 Jahre?

Viele Grüße

Manuel

Hallo,

ich wollte mal fragen, wie es möglich ist, eine alternative OCR-Engine an Agorum anzubinden. Und ob das vielleicht auch mal jemand gemacht hat? Wir würden gern mal ein bisschen mit anderen (im Zweifel auch kostenpflichtige) Engines testen und die Ergebnisse vergleichen.