Version 7.1.0
Hinweis
Nachdem Microsoft den Support für den Internet Explorer am 15. Juni 2022 eingestellt hat, ist die Version 7.1 ist die letzte Version von docs365 documents, die den Internet Explorer 11 noch eingeschränkt unterstützt. Bei Verwendung des Internet Explorers wird in der Anwendung ein Warn-Hinweis eingeblendet, dass der Support für den Internet Explorer bald ausläuft. Das betrifft auch externe Programme, die die Oberfläche oder den Archivieren-Dialog über einen eingebetteten Browser (WebView) laden, wie beispielsweise ältere Versionen des Outlook-Add-Ins von docs365 documents. Diese Programme sollten aktualisiert werden, damit auch eine zukünfigte Funktionsfähigkeit gesichert ist.
Mandanten
Mandanten sind eine neue, optionale Funktion, die Sichtbarkeit von Vorgängen in einem Archiv auf bestimmte Benutzer einzuschränken. Dabei wird jeder Vorgang in einem Archiv genau einem Mandanten zugeordnet und ist dann nur noch für denjenigen Benutzer sichtbar, die in dem Archiv ebenfalls dem gleichen Mandanten zugeordnet sind.
In der englischsprachigen Oberfläche sowie in der API und STAR-Code werden die Mandanten als Clients bezeichnet.
In der Administrationsoberfläche ist ein neuer Bereich Mandanten hinzugekommen, in dem die Mandanten eingerichtet werden können. Neben dem Namen kann auch ein Kürzel eingerichtet werden, das (anders als beispielsweise die Kurznamen im Archiv) keine Beschränkung auf ein bestimmtes Format hat. In diesem Fall sind Punkte oder Umlaute ebenfalls erlaubt. Das Kürzel ist das bevorzugte Feld, um in Datentabellen auf Mandanten zu filtern.
Die Mandanten-Funktion ist in Archiven standardmäßig deaktiviert und muss daher pro Archiv zunächst aktiviert werden. Bei bestehenden Archiven, in denen bereits Vorgänge existieren, müssen dabei alle existierenden Vorgängen einem Mandanten zugeordnet werden. Denn sobald die Mandanten aktiviert sind, ist der Mandant ein Pflichtfeld in den Vorgängen.
In der Tabelle „Zuordnung“ kann dann eingestellt werden, in welchen Archiven welche Benutzer diesem Mandanten zugeordnet sind. Nur die hier zugeordneten Benutzer haben dann Zugriff auf die jeweiligen Vorgänge. Die Oberfläche für die Zuordnung kann über einen Klick auf das Icon in der Zeile des gewünschten Archivs erreicht werden, dort sind dann zwei Tabellen zu finden: In der linken Tabelle werden alle Benutzer angezeigt, die dem Mandaten nocht nicht zugeordnet sind. Für die Zuordnung müssen sie in die rechte Tabelle verschoben werden. Das kann wahlweise durch den Benutzer und die Pfeiltasten zwischen den Tabellen durchgeführt werden, oder durch einen Doppelklick auf einzelne Benutzer.
Bei Anwendern, die keinem der Mandanten zugeordnet sind, wird das Archiv vollständig ausgeblendet.
Wenn die Mandanten im Archiv aktiviert sind, gibt es in den zugehörigen Archiv-Formular(en) automatisch ein neues Feld „Mandant“, in dem diese nun auswählbar sind. Ein Anwender kann hier nur diejenigen Mandanten auswählen, denen er selbst zugeordnet ist. Bei der Zurordnung zu nur einem Mandanten wird das Feld damit automatisch vorausgefüllt.
Wenn in einem Archiv die Mandanten aktiviert sind, werden in dem Dialog „In Postfach legen“ sowie in der Workflow-Aktion „Vorgang versenden“ nur noch diejenigen Benutzer zur Auswahl angeboten, die Zugriff auf die Mandanten aller ausgewählten Vorgänge haben.
Wenn ein Benutzer in einem Archiv genau einem Mandanten zugeordnet ist, wird dieser beim Archivieren
automatisch gesetzt, solange in der API kein Mandant (client_id) übergeben wurde. Das ist
sinnvoll, wenn man einen API-Client verwendet, der nicht auf die Mandanten vorbereitet ist, in diesem
Fall weist man dem Dienstbenutzer genau einen Mandanten zu, der dann automatisch für alle neuen
Vorgänge verwendet wird.
Mandanten in Vorschlagsfiltern
In den Vorschlagsfiltern kann der ausgewählte Mandant über eine neue Variable client
gefiltert werden.
Dabei enthalten client und client.identifier das Kürzel des Mandanten. Wenn man
beispielsweise eine Datentabelle hat, die eine Spalte mit dem Kurznamen mandant enthält
und dessen Inhalt das jeweilige Kürzel des Mandanten enthält, kann man eine der beiden
folgenden Varianten wählen, um in der Datentabelle auf den Mandanten zu filtern:
table.mandant = client
_mandant = client.identifier
client.name enthält den Namen des Mandanten.
Bei Vorschlägen aus Archiven muss im Vorschlagsfilter das fest eingebaute Feld client_id
mit dem Wert client.id verwendet werden.
client_id = client.id
Mandanten in Formular-Events
Die Verwendung der Mandanten in Formular-Events werden in der STAR-Dokumentation beschrieben.
Fristen
Beim Archivieren von neuen Vorgängen kann die Aufbewahrungsfrist (vor dessen Erreichen ein Vorgang nicht gelöscht werden darf) jetzt auch für jeden Vorgang individuell eingestellt werden. Darüber hinaus ist ein neues Feld „Löschdatum“ hinzugekommen.
Beide Felder sind im Tab „Info“ des Archivieren- bzw. Vorgangsdialogs zu finden.
Die individuelle Aufbewahrungsfrist des Vorgangs darf die im Archiv eingestellt Aufbewahrungsfrist nicht unterschreiten. D.h. wenn man im Archiv beispielsweise eine Aufbewahrungsfrist von einem Jahr eingestellt hat, wird das Feld „Aufbewahrungsfrist“ automatisch auf das Datum ein Jahr in der Zukunft gesetzt, die Auswahl eines früheren Datums führt beim Speichern zu einer Fehlermeldung.
Das Löschdatum muss mindestens das Datum der Aufbewahrungsfrist sein und gibt an, wann ein Vorgang gelöscht werden sollte. Das Löschen geschieht nicht automatisch, es ist aber möglich, sich durch einen Filter auf die Spalte „Löschdatum“ im Archiv eine Löschliste anzeigen zu lassen.
In den Rollen gibt es einen neuen Befehl „Fristen bearbeiten“. Wenn ein Benutzer dieses Recht hat, können die Aufbewahrungsfrist und das Löschdatum auch nachträglich noch bearbeitet werden.
Über die beiden Variablen $expiration_date und $deletion_date können beide Felder auch in
Formular-Events abgefragt und verändert werden.
Eskalationsregeln und erweiterte Terminplanung
In der Administrationsoberfläche können Eskalationsregeln angelegt werden. Die Regeln werden dann in der Terminplanung verwendet. Sie legen fest, wer einen Termin in sein Postfach erhält, wie oft an nicht bearbeitete Termine erinnert wird und wer benachrichtigt wird, wenn nach Ablauf einer definierten Zeit der Termin noch nicht erledigt ist.
Die erste Stufe der Regel legt den regulären Bearbeiter fest. Der Bearbeiter kann direkt in der Regel festgelegt werden oder offen gelassen werden, so dass er erst in der Terminplanung eingestellt wird.
Der eingestellte Bearbeiter erhält den Termin bei Fälligkeit in sein Postfach. Sofern er in seinen Benutzereinstellungen E-Mail-Benachrichtigungen aktiviert hat, wird er zusätzlich per E-Mail darüber informiert.
Zusätzlich können Erinnerungen eingestellt werden. Erinnerungen erfolgen per E-Mail, wenn der Termin noch nicht erledigt ist. Bei einer Einstellung von 2 Erinnerungen im Abstand von 2 Tagen wird beispielsweise am 3. und am 5. Tag eine Erinnerungs-Email verschickt, sofern der Termin bis dahin noch nicht erledigt ist. Über die Einstellung „Wochenende“ können Wochenenden ausgeschlossen werden, 2 Tage Abstand bedeutet dann 2 Werktage, ein Termin, der am Freitag fällig ist, wird bei einem Abstand von 2 Werktagen also erst am Dienstag wieder erinnert.
Optional können in der Regel eine zweite und dritte Stufe eingestellt werden. Diese legen die Eskalation fest. Ein Termin eskaliert, wenn er im eingestellten Abstand nach der letzten Erinnerung weiter nicht erledigt ist. Sind z.B. 2 Erinnerungen im Abstand von 2 Tagen eingestellt, wird am 3. Tag und am 5. Tag erinnert. Am 7. Tag eskaliert der Termin.
Eskalation bedeutet hier, dass der Termin zusätzlich ins Postfach des in der Eskalationsstufe eingestellten Benutzers gelegt wird. Er liegt dann in beiden Postfächern und kann von beiden Benutzern erledigt werden. Erledigt einer von beiden den Termin, so bleibt er im Postfach des jeweils anderen liegen, wird aber als erledigt markiert. Auf den beiden Eskalationsstufe können ebenfalls wieder Erinnerungen eingestellt werden. Das Verhalten ist hier analog zum oben beschriebenen für den regulären Bearbeiter.
Erreicht ein Termin die oberste festgelegte Stufe und die maximale Zahl von Erinnerungen, stellt das System die Erinnerungen ein.
Ein paar Hinweise zu Sonderfällen:
wird eine Regel nachträglich verändert, hat das Auswirkungen auf geplante Termine, nicht aber auf vergangene Termine, auch wenn diese noch unerledigt sind und sich in der Erinnerungs-Phase oder in der Eskalation befinden. Wurde beispielsweise gestern ein Termin fällig, für den gestern User A als Empfänger auf der ersten Eskalationsstufe eingetragen war, so eskaliert der Termin auch dann noch an User A, wenn zwischenzeitlich User B stattdessen in der Regel eingetragen wurde. Nur für heute neu angelegte Termine oder Terminausführungen ab dem nächsten Tag (bei wiederkehrenden Terminen) wird die Änderung berücksichtigt.
gleiches gilt auch für wiederkehrende Termine, wenn der Bearbeiter in der Regel offen gelassen wurde und erst in der Terminplanung eingestellt wird. Wird der Bearbeiter in der Terminplanung geändert, wirkt die Änderung nur für zukünftige Ausführungen des Termins.
ist in einer Regel ein Benutzer eingestellt, der zwischenzeitlich deaktiviert wurde, so wird der Termin zwar in sein Postfach gelegt, weitere Erinnerungen werden aber übersprungen und der Termin eskaliert sofort auf die nächste Stufe, sofern vorhanden
wurde ein Benutzer verwendet, für den keine E-Mail-Adresse hinterlegt wurde, können keine Erinnerungen verschickt werden. Es wird eine Warnung im System-Ereignisprotokoll ausgegeben, weiter passiert nicht. Die Erinnerungsschleife läuft regulär weiter, bei der nächsten Erinnerung wird es erneut versucht.
Zusammen mit der Einführung der Eskalationsregeln wurde auch die Terminplanung auf dem Reiter „Termine“ im Vorgang erweitert. Es ist nun möglich, pro Vorgang mehr als einen Termin anzulegen und den Absender, unter dem der Termin im Postfach des Empfängers landet, frei einzustellen - hier wurde bisher immer der aktuell angemeldete User verwendet, der nun nur noch als Vorbelegung dient. Außerdem wurde ein Rollenrecht „Terminplanung“ eingeführt, das notwendig ist, um auf dem Termine-Reiter Änderungen machen zu können.
Benutzer können nur noch nach Ablösung deaktiviert werden
Benutzer können nicht mehr ohne Weiteres deaktiviert werden. Die Checkbox zum Aktivieren/Deaktivieren wurde aus der Benutzer-Konfiguration entfernt. Eine Deaktiviertung ist nur noch möglich, wenn der User vorher von einem anderen User abgelöst wurde. Beim Ablösen werden seine Termine, Postfach-Einträge etc. auf den anderen Benutzer übertragen. Das Deaktivieren ist hier wie bisher über eine Checkbox im Dialog Ablösen möglich. Für ein erneutes Aktivieren steht ein Knopf in der Toolbar des Benutzer-Datengitters zur Verfügung.
Ordnerstruktur in Archivliste
Die Archivliste in der linken Seitenleiste des Client-Viewers lässt sich nun in Ordner gruppieren. Dazu steht in der Archivkonfiguration ein neues Feld „Ordner“ zur Verfügung. Alle Archive mit dem gleichen Eintrag werden dann in einem Ordner zusammen gefasst. Dabei werden zunächst die Ordner in alphabetischer Reihenfolge und anschließend Archive ohne Ordner angezeigt. Archive werden innerhalb der Ordner jeweils nach dem eingestellten Sortierindex sortiert. Gleiches gilt für die Archive ohne Ordner.
Verbesserungen im Formular-Editor
Verteilung von Formularfeldern auf mehrere Tabs.
Verbesserte Berücksichtigung und Kennzeichnung unsichtbarer Felder.
Code-Editor: Syntax-Highlighting der Star-Programmiersprache, Autovervollständigung für Feld-Variablen.
Abfrage bei Erstellung neuer Formulare, bei der Abfrage können sowohl der Formularname als auch die Anzahl der Spalten definiert werden. Desweiteren kann eingestellt werden, ob direkt alle Felder oder zunächst nur ein leeres Formular erstellt werden soll.
In der Formularvorschau werden alle Feld-Trigger (Buttons, z.B. zur Auswahl bestimmter Werte) so dargestellt wie im produktiven Formular.
Entfernung des Spaltenmodus für die Einstellung der Labelbreite. Stattdessen kann gleichsam über Strg/Ctrl+Mousedrag die Labelbreite für alle Felder in einer Formularspalte gleichzeitig geändert werden. Ein Hinweis dazu erscheint einmalig.
Neue Spalten werden bei Drag&Drop von Feldern nicht mehr automatisch hinzugefügt. Stattdessen existiert zur besseren Übersicht eine Titelzeile über dem Formular. Die Titelzeile zeigt die Spalte an, in der sich ein Feld befindet (z.B. Spalte 1, Spalte 2 usw.). Über einen Button rechts neben der Titelzeile können neue Spalten manuell hinzugefügt und über die Spaltentitel wieder entfernt werden, sofern die Spalten leer sind. Zudem kann das Formular auch über die Titelzeile vergrößert werden.
Formulare können ex- und importiert werden.
Verbesserungen im Workflow-Designer
Gleichzeitiges Löschen und Verschieben mehrerer Status durch die Möglichkeit zur Mehrfachauswahl. Eine Mehrfachauswahl ist auch über gängige Tastenkürzel möglich, z.B. Strg/Ctrl+A für die Auswahl aller Status, oder Strg/Ctrl+Mouseclick für die Auswahl und Abwahl weiterer Status.
Möglichkeit zur Verschiebung mehrfach verzweigter Transitionen.
Automatisches Scrolling beim Drag & Drop von Status außerhalb des sichtbaren Bereichs.
Spaltenfilter auf Untertabellen
Bei den Spaltenfiltern ist die Möglichkeit hinzugekommen, nach Werten in Untertabellen zu filtern. In der Spaltenauswahl werden die Untertabellen neben Datenfeldern, Standardspalten etc. als eigene Gruppe angezeigt, in der dann die einzelnen Spalten der Untertabelle zur Auswahl stehen.
Es werden bei der Suche im Datengitter dann diejenigen Vorgänge angezeigt, bei denen es mindestens eine Zeile in der Untertabelle gibt, die die gesuchten Wert enthält.
Archive als Vorschlagsquelle
In den Vorschlägen eines Datenfelders ist es jetzt möglich, auch die Werte aus einer Spalte eines existierenden Archivs zu wenden.
Dafür muss man unter Vorschläge den Wert Archiv auswählen und dann in der Vorschlagsquelle das Archiv und dessen Spalte auswählen. Auch Vorschlagsfilter können wie bei der Vorschlagsquelle Datentabelle verwendet werden.
Wenn eine Archiv-Spalte als Vorschlagsquelle eingestellt ist, werden beim Aufruf der Vorschläge keine Rollenrechte beachtet, sodass Anwender möglicherweise auch Werte einsehen könnten, auf die sie direkt im Archiv keinen Zugriff haben.
Tabelle für Übersetzungen
In der Administrationsoberfläche können nun Übersetzungen für selbst konfigurierte Elemente der Benutzeroberfläche gepflegt werden, beispielsweise für die Namen der Archive oder die darin konfigurierten Datenfelder (Spalten).
Die Eingabe eines Ursprung-Textes, sowie die Übersetzung selbst bilden die Grundlage. Zusätzlich wird eingestellt, für welche Sprache die Übersetzungen gilt und auf welche Kategorie sich das Ergebnis auswirkt.
Folgende Kategorien sind konfigurierbar:
Archiv-Name
Spalten-Name
Workflow-Status
Workflow-Übergang
Global (die Überstzung gilt dann für jedes aufgezählte Element)
Postfach-Einträge im Hotfolder
Für die Konfiguration eines Hotfolders wurde der optionale Parameter Postbox hinzugefügt.
Hiermit wird die Angabe von Login-Namen in einer kommagetrennten Liste ermöglicht. Konfigurierten Benutzer
erhalten beim Import den Vorgang zusätzlich ins Postfach.
[Demo-Archiv]
...
Postbox=admin, testuser
Ein neues Attribut result.postbox ist nun aufrufbar. Hier können Benutzer als Strings hinzugefügt
werden. Falls das Attribut nicht definiert wird, verwendet die Direktive Postbox=... stattdessen.
import importservice
class ImportService(importservice.Base):
def process(self, file, result):
result.postbox = ["admin", "testuser"]
Untertabellen in PDF-Exporten
Die Metadaten der Untertabellen eines Vorgangens werden nun ebenfalls im PDF-Format exportiert. Die im Admin konfigurierten Spalten-Formate werden mitübernommen.
Standard-Exportformate in Export-Services
In Export-Services können nun auch die serverseitigen Export-Funktionen (wie z.B. „PDF mit Dokumenten“) aufgerufen werden, die bereits von Anwendern manuell in der Oberfläche ausgeführt werden können.
Mehr dazu in der Export-Services-Dokumentation.
Ersetzen von Dokumenten durch Import-Services
Import-Services konnten in existierenden Vorgängen bereits neue Dokument hinzugefügt werden, die dann an letzter Stelle der Dokumenten-Liste zu finden waren. Jetzt ist es auch möglich, die Position der neuen Dokumente im Vorgang zu bestimmen sowieso existierende Dokument in Vorgang komplett zu ersetzen.
Die Details zu diesem Feature sind in der Import-Services-Dokumentation zu finden.
Neue Aktionsroutine „Bemerkung hinzufügen“
In Workflow-Übergängen gibt es nun die Aktion Bemerkung hinzufügen. Beim Konfigurieren in der Administrations-Oberfläche wählt man, ob die Pflichteingabe eines Textes beim Übergang zum nächsten Status notwendig ist. Ist die Eingabe keine Pflicht, so wird der Dialog zwar aufgerufen, aber er lässt sich ohne die Eingabe eines Textes trotzdem bestätigen. In diesem Fall wird keine Bemerkung erstellt. Im umgekehrten Fall ist der Benutzer dazu aufgefordert das Textfeld nicht leer zu lassen.
Info-Nachrichten für Benutzer in Formular-Events
In Formular-Events gibt es eine neue Funktion user_message(text), mit der man einen Info-Text
an den Benutzer übergeben kann, der diesem nach der Ausführung des Events als Info-Dialog angezeigt
wird.
XRechnungen
Die SmartIndexing-Regeln für Eingangrechnungen können bei Verwendung der Business-Lösung INVOICE nun auch XRechnungen einlesen, wenn man eine XML-Datei in einem gültigen XRechnung-Format hochlädt.
Verschiedenes
Im Titel des Aufgaben-Tabs wird jetzt die Anzahl der ungelesenen Einträge im Postfach angezeigt.
Wenn man Englisch als Sprache eingestellt hat, wird jetzt auch die Historie auf Englisch angezeigt.