Benutzer/Rollen/Gruppen/Mandanten

Wenn Sie docs365 documents erstmalig einrichten, werden Sie zuerst die Benutzer und deren Rollen sowie Gruppen einrichten wollen. Hier können Sie auch Mandanten zuweisen.

../_images/nutzer-bereiche.png

Benutzer

In diesem Datengitter finden Sie die Übersicht über alle angelegten Benutzer inklusive der zugewiesenen Gruppen und Rollen.

../_images/nutzer-uebersicht.png

Möchten Sie einen Anwender dauerhaft ersetzen, z. B. nach einer Kündigung, muss dieser vorher durch einen anderen Anwender abgelöst werden.

In der Menüleiste finden Sie die Schaltfläche Ablösen.

Beim Ablösen werden seine Termine, Postfach-Einträge etc. auf den anderen Benutzer übertragen. Das Deaktivieren ist hier über eine Checkbox im Dialog Ablösen möglich:

../_images/nutzer-abloesen.png

Für ein erneutes Aktivieren steht ein Knopf in der Toolbar des Benutzer-Datengitters zur Verfügung:

../_images/nutzer-aktivieren.png

Wenn Sie die Schaltfläche +Neu drücken, wird Ihnen im rechten Maskenbereich der Dialog Neuen Benutzer erstellen angezeigt.

../_images/nutzer-benutzereinrichten.png

Die Felder haben folgende Bedeutung:

Benutzertyp

Pflichtfeld. Hier wählen Sie, ob es ein Standard- oder ein Dienstbenutzer ist.

Name

Pflichtfeld. Dieser Name wird unten links in der Statuszeile angezeigt oder als Anzeigename verwendet, falls in Datensätzen auf den Benutzer verwiesen wird.

E-Mail

Pflichtfeld. An diese E-Mail-Adresse werden Erinnerungen, Termine und Vorgänge geschickt.

Rollen

Rollen müssen im Rollenbereich zuerst angelegt werden, die Drop-Down-Box ist sonst leer. Die beiden praktischsten Rollen sind „Administrator“ und „Benutzer“.

Gruppen

Gruppen müssen im Gruppenbereich zuerst angelegt werden, die Drop-Down-Box ist sonst leer.

Login

Pflichtfeld. Dieser Login-Name muss später in der Login-Maske eingegeben werden.

Passwort

Pflichtfeld. Das Passwort kann im Bereich „Übersicht“ genauer definiert werden.

Dort gibt es zwei neue Konfigurationsoptionen „Minimale Passwort-Länge“ und „Minimale Passwort-Sicherheitsstufe“, um Anforderungen an die Passwort-Sicherheit zu konfigurieren.

Diese Optionen entsprechen den bereits verfügbaren Einstellungen min_password_length und min_password_score in der settings.ini, die auch weiterhin verfügbar sind. Die in der Oberfläche eingestellten Optionen überschreiben die aus der settings.ini, es ist jedoch nicht möglich, die in min_password_length eingestellte Mindestlänge für Passwörter über die Oberfläche zu unterschreiten.

Zufälliges Passwort generieren

Der Benutzer bekommt für die Erstanmeldung ein vom System erstelltes Passwort

Passwortänderung bei der nächsten Anmeldung notwendig

Der Benutzer muss sein Passwort bei der nächsten Anmeldung ändern.

Willkommens-E-Mail senden

Dem angelegten Benutzer wird eine E-Mail mit dem Hinweis, dass ein neuer Zugang angelegt wurde, an die angegebene E-Mail-Adresse gesendet.

Benutzername und Passwort werden ebenfalls mitgesendet. Daher ist das vorherige Häkchen, das Passwort bei der nächsten Anmeldung zu ändern sinnvoll.

Die Maske sieht fast genauso aus, wenn Sie vorhandene Benutzer bearbeiten. Der Bereich für die Passwortänderung ist zugeklappt und wird erst aufgeklappt, wenn Sie die Checkbox Passwort ändern anklicken.

Mit der Schaltfläche Suchen können Sie nach einem Login oder Benutzernamen suchen, wie im Kapitel Datensätze bearbeiten beschrieben. Am rechten Ende der Suchbox können Sie bestimmen, ob auch deaktivierte Benutzer angezeigt werden sollen:

../_images/nutzer-benutzersuchen.png
Zweiter Faktor

Sie können für die Anmeldung einen zweiten Faktor hinzufügen. Mehr dazu erfahren Sie im Kapitel zur 2-Faktor-Authentifizierung.

docs365 documents unterstützt neben lokalen Benutzern auch eine Authentifizierung über ein Active Directoy (AD). Näheres dazu erfahren Sie in Kapitel Active-Directory-Authentifizierung.

Vertreterregelung

Sie können als Administrator für jeden Benutzer ein Vertreter einstellen.

Wenn der Vertreter aktiv ist, werden Postfach-Einträge nicht an den ursprünglichen Benutzer, sondern an den Vertreter gesendet. Der Vertreter kann entweder dauerhaft oder für einen bestimmten Zeitraum aktiviert werden:

../_images/nutzer-verteterzeitraum.png

Diese Optionen können auch vom Benutzer selbst über das Benutzerprofil verändert werden:

../_images/nutzer-vertreter-anwenderansicht.png

Wenn der Vertreter aktiviert ist, bekommt der Benutzer nach der Anmeldung einen Hinweis:

../_images/nutzer-vertretermeldung.png

Außerdem wird die Schaltfläche für das Benutzerprofil in gelb statt weiß angezeigt.

../_images/nutzer-vertreter-iconansicht.png

Die Option „Postfacheinträge automatisch zum Vertreter senden nach XX Tagen ohne Bearbeitung“ schickt nicht bearbeitete Postfacheinträge nach einer bestimmten Liegezeit automatisch an den Vertreter weiter. Es besteht die Möglichkeit, Wochenenden bei der Weiterleitung zur Vertretung auszuschließen. Dadurch werden Postfacheinträge entweder nach einer bestimmten Anzahl von Tagen ohne Bearbeitung oder nach einer bestimmten Anzahl von Arbeitstagen automatisch an den Vertreter weitergeleitet. Bei der zweiten Option werden Wochenenden nicht berücksichtigt, wodurch sich die Zeit bis zur Weiterleitung ohne Bearbeitung im Vergleich zur vollen Woche verlängern kann.

../_images/nutzer-vertreter-weiterleitung.png

Bemerkung

Diese Option wird auch beachtet, wenn der Vertreter ansonsten nicht aktiviert ist.

Mandanten

Hier können Sie auswählen, welche Mandanten und damit welche Archive sichtbar für diesen Benutzer sind:

../_images/nutzer-zuordnung-mandanten.png

Rollen

Das Rollensystem bietet diverse Möglichkeiten an, detaillierte Rollen zu konfigurieren.

Für jedes einzelne Archiv können folgende Rechte angepasst werden:

  • Ob das Archiv für den Benutzer sichtbar ist.

  • Ob der Benutzer neue Vorgänge im Archiv anlegen darf (diese Option kann nur eingestellt werden, wenn das Archiv auch sichtbar ist).

  • Ein Filter, um die Ansicht im Archiv für bestimmte Rollen einzuschränken, ohne dass man dafür gefilterte Archive konfigurieren muss.

  • Welche Status die Benutzer im Archiv sehen dürfen.

  • Bei Archiven mit regelbasierten Workflows: Welche Übergänge ausgeführt werden dürfen.

  • Welche Befehle (z.B. “Vorgang löschen” oder “Dokumente hinzufügen”) in welchem Status ausgeführt werden dürfen.

  • Welche Datenfelder in welchem Status gesehen oder verändert werden dürfen.

Beim Upgrade wird dieses Recht in bestehenden Rolken für jeden Status aktiviert, um das alte Verhalten beizubehalten.

Bei gefilterten Archiven können ebenfalls separate Rechte konfiguriert werden, außerdem ist es nun auch möglich, in gefilterte Archive zu archivieren.

Ein Benutzer kann weiterhin zu mehreren Rollen gehören und hat dann die Summe der Rechte der einzelnen Rollen. Außerdem ist es möglich, die Rollen zu kopieren.

Globale Rechte

Das übergeordnete Recht “Administrator” ist weiterhin nötig, um sich an der Administrations-Oberfläche anzumelden und Benutzer, Rollen, Archive etc. konfigurieren zu können.

../_images/nutzer-uebergeordnete-rechte.png

Anders als in früheren Versionen gibt diese Einstellung jedoch keinen Vollzugriff auf alle Archive mehr. Somit kann es auch Administrator-Rollen geben, die keinen Zugriff auf Vorgänge in Archiven haben (auch wenn sie sich den Zugriff dann grundsätzlich selbst geben könnten).

Als Benutzer mit einer einzigen Administrator-Rolle kann man sich in der Rollenkonfiguration nun nicht mehr aus dieser entfernen und sich somit aus der Administrations-Oberfläche ausschließen. Das wird mit einer Fehlermeldung verhindert.

Archivbezogene Rechte

Im Abschnitt Archive kann zunächst eingestellt werden, ob das Archiv für die Rolle überhaupt sichtbar ist.

../_images/nutzer-archivbezogene-rechte.png

Bemerkung

Wenn man ein neues Archiv anlegt, ist es zunächst für alle Rollen unsichtbar, d.h. auch für die Administrator-Rolle, und wird daher im Viewer nicht angezeigt.

Um die Details für ein Archiv zu konfigurieren, muss es in der Tabelle ausgewählt werden, dann werden in den unteren Bereichen die Details für dieses Archiv angezeigt.

Bemerkung

Wenn ein Archiv in den Rollen für einen Benutzer auf „Unsichtbar“ eingestellt ist, aber in diesem Archiv dennoch detaillerte Rechte wie Befehle oder der Zugriff auf Felder eingestellt sind, werden diese Rechte nun bei einem Vorgang beachtet, wenn dieser sich im Postfach eines Benutzers befindet. Somit ist ein Anwendungsfall möglich, bei dem Benutzer keinen Zugriff aufs Archiv haben, sondern Vorgänge ausschließlich über das Postfach sichtbar und bearbeitbar sind.

Bemerkung

Da zusammengefasste Archive im neuen Rollensystem keine eigenen Rechte haben, sondern die der darunterliegenden Archive verwendet, kann es passieren, dass Rollen, die zwar ein zusammengefasstes Archiv sehen dürfen, aber keine einzelnen Archive, nun weniger oder gar keine Vorgänge im zusammengefassten Archiv sehen. In diesem Fall müssen die Rollen noch manuell angepasst werden.

Die direkten archivbezogenen Rechte sind folgende:

Vorgänge archivieren

../_images/nutzer-vorgaenge-archivieren.png

Bestimmt, ob man in dem Archiv neue Vorgänge erzeugen darf. Diese Option kann nur ausgewählt werden, wenn das Archiv auch sichtbar ist.

Rollenfilter

Funktioniert wie der Filter in den gefilterten Archiven und schränkt die Zahl der sichtbaren Vorgänge ein. Somit ist es möglich, verschiedenen Rollen unterschiedliche Ansichten auf ein Archiv zu geben, ohne dass man zusätzliche gefilterte Archive anlegen muss.

Bei zusammengefassten Archiven können bis auf einen zusätzlichen Filter keine gesonderten Rechte konfiguriert werden, stattdessen werden die Rechte der darunterliegenden Einzelarchive verwendet. Aus diesem Grund ist es auch dann möglich, in normalen Archiven Rechte zu konfigurieren, wenn diese gar nicht sichtbar sind. Damit ist es möglich, Benutzern ausschließlich Zugriff auf ein zusammengefasstes Archiv zu geben, ohne dass die darin verwendeten einzelnen Archive sichtbar sein müssen.

In Rollenfiltern können alle Spalten für die Filterung verwendet werden, die auch in gefilterten Archiven möglich sind, also auch die dynamisch erzeugten Spalten wie beispielsweise remarks_count und postbox_users.

Darüber hinaus werden jetzt auch Rollenfilter beachtet, die für zusammengefasste Archiven in Rollen konfiguriert sind. Bislang wurden bei zusammengefassten Archiven die Rollenfilter in den darunter liegenden Einzel-Archiven beachtet, diese werden nun jedoch ignoriert. Somit ist es möglich, einem Anwender in einem zusammengefassten Archiv durch den Rollenfilter mehr Vorgänge anzuzeigen, als direkt im Archiv sichtbar wären.

Wichtig

Durch diese Änderung kann es passieren, dass in einem zusammengefassten Archiv nach dem Update mehr Vorgänge sichtbar sind als vorher, wenn in einem der Archive des zusammengefassten Archivs ein Rollenfilter eingestellt ist. Daher sollte in diesem vor dem Update ein Rollenfilter im zusammengefassten Archiv eingerichtet werden.

In der API und den Filtern (z.B. Rollenfilter oder in gefilterten Archiven) gibt es eine neue Spalte postbox, die über true oder false angibt, ob sich der Vorgang im Postfach des aufrufenden Benutzers befindet.

So kann man beispielsweise über folgenden Rollenfilter ausschließlich diejenigen Vorgänge im Archiv sichtbar machen, die sich ohnehin gerade im Postfach des Benutzers befinden:

postbox = true

Möchte man auf ein Feld mit leerem Inhalt filtern, sollte man den Vergleichswert <empty> verwenden. Dieser steht sowohl für leer als auch für „null“.

_custom_field = <empty>

Es kann für Rollenfilter jetzt ein neuer Ausdruck accessed = true angegeben werden. Dieser Filter gibt alle Vorgänge zurück, auf die ein Benutzer schon einmal Zugriff hatte. Das ist der Fall in folgenden Situationen:

  • Man hat den Vorgang erstellt.

  • Man hatte den Vorgang selbst im Postfach, entweder direkt oder über einen Termin.

  • Man hätte den Vorgang im Postfach gehabt, es war aber gerade der Vertreter aktiv und der Vorgang Optionist direkt an diesen gegangen.

  • Man hat den Vorgang über eine Gruppe im Postfach gehabt.

Wichtig: Die Information, ob ein Benutzer schon einmal Zugriff auf einen Vorgang hatte, wird beim Upgrade anfänglich anhand der Historie befüllt und ist für Bestandsdaten daher nicht vollständig.

Filter auf Historie

In der Spaltensuche ist ein verstecktes (d.h. nicht in der Oberfläche auszuwählendes) Feld history hinzugekommen, über das man beispielsweise im Rollenfilter oder in gefilterten Archiven auf die Existenz von bestimmten Historien-Einträgen filtern kann.

history.action

Filtert auf Nachrichten, die von der Workflow-Aktionsroutine „Historieneintrag schreiben“ erzeugt wurden.

history.creation_date

Zeitpunkt des Historien-Eintrags.

history.user

Der Benutzer-Name, von dem der Historieneintrag erzeugt wurde.

history.user_id

Die interne Benutzer-ID, von dem der Historieneintrag erzeugt wurde. Diese ID wird nur bei allen ab Version 7.1.3 hinzugekommenen Historien-Einträge geschrieben.

Genau wie bei den Filtern auf Untertabellenwerte werden alle Vorgänge angezeigt, bei denen mindestens ein Historieneintrag existiert, auf den der Filter zutrifft.

Das folgende Beispiel zeigt alle Vorgänge an, bei denen der aktuelle Benutzer laut Historie beteiligt war:

history.user_id = "{user.id}"

Hinweis

Seit Version 8.0.5 sind die Filter kompakter aufrufbar. Das oben dargestellte Format ist weiterhin kompatibel.

Benutzerfilter in Rollenfiltern

Bis Version 8.0.4

Ab Version 8.0.5 (vereinfacht)

_benutzer = „{user.id}“

_benutzer = user.id

_benutzer = user

_benutzer = „{user.fullname}“

_benutzer = user.fullname

_benutzer = „{user.username}“

_benutzer = user.username

_benutzer = „{user.email}“

_benutzer = user.email

_gruppe = user.groups

Statusbezogene Rechte

Sobald man in der Archiv-Tabelle ein Archiv ausgewählt hat, kann man im Bereich Status einstellen, welche Status ein Benutzer sehen darf.

../_images/nutzer-status-berechtigungen.png

Diese Auswahl bestimmt auch, welche Status in den Tabellen von “Befehle” und “Datenfelder” angezeigt werden. Jedem Status ist eine Spalte zugeordnet und es werden nur solche angezeigt, die sichtbar sind.

../_images/rollenkonfiguration-zugriffsberechtigung-historie.png

Da die Befehle pro Status eingestellt werden können, kann man einer Rolle beispielsweise ermöglichen, einen Vorgang noch zu löschen, solange er sich im Status “Neu” befindet, aber später im Status “Archiviert” nicht mehr.

Folgende Befehle sind aktuell möglich:

Vorgänge löschen

Der Benutzer darf den gesamten Vorgang löschen (sofern ein Ablaufdatum eingestellt und erreicht ist).

Vorgänge verstecken:

Der Vorgang darf versteckt werden. Das Sichtbarmachen ist grundsätzlich nur Administratoren vorbehalten.

Vorgänge als E-Mail versenden:

Bislang war es für Anwender immer möglich, einen Vorgang als E-Mail zu verschicken. Diese Möglichkeit kann jetzt durch den Rollenbefehl „Vorgänge als E-Mail versenden“ untersagt werden.

Vorgänge in Postfach legen

Der Benutzer darf den Vorgang anderen Benutzern ins Postfach legen.

Vorgänge teilen

Neben der Möglichkeit, einzelne Dokumente zu teilen, können Sie auch einen solchen Link für einen ganzen Vorgang inklusive seiner Metadaten erzeugen. Die Bedienung ist identisch zu den einzelnen Dokumenten und es kann auch hier eine Gültigkeitsdauer festgelegt werden. Aufgerufen wird die Funktion über das Workflow-Menü in der Toolbar oder das Kontextmenü des Vorgangs.

Bemerkungen hinzufügen

Es dürfen Bemerkungen zu einem Vorgang hinzugefügt werden.

Mandant bearbeiten

Dieses Recht bestimmt, ob ein Anwender auch nachträglich den Mandanten eines Vorgang verändern darf. Bei bestehenden Rollen wird dieses Recht für alles Status erlaubt, um das aktuelle Verhalten beizubehalten.

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.

Multiedit

Es dürfen viele Vorgänge gleichzeitig bearbeitet werden (z.B. um ein Datenfeld auf den gleichen Wert zu setzen). Wenn man mehrere Vorgänge auswählt, die einen unterschiedlichen Status haben, muss Multiedit für alle ausgewählten Vorgänge erlaubt sein, sonst wird diese Option im Menü nicht angeboten.

Dokumente löschen

Die am Vorgang angehängten Dokumente dürfen gelöscht werden. Für diese Funktion ist es erforderlich, dass auch „Dokumente hinzufügen“ erlaubt ist.

Dokumente bearbeiten

Die am Vorgang angehängten Dokumente dürfen für die Bearbeitung im SmartClient ausgecheckt werden.

Dokumente hinzufügen

Die am Vorgang angehängten Dokumente dürfen umsortiert werden und es dürfen neue Dokumente angehängt werden.

Über den Bereich “Datenfelder” kann eingestellt werden, welche Datenfelder ein Benutzer in welchem Status sehen (mindestens “Nur lesen”) oder bearbeiten darf (“Vollzugriff”). Wenn ein Datenfeld in jedem Status unsichtbar ist, wird es in der Oberfläche für den Benutzer vollständig ausgeblendet. Wenn es in mindestens einem Status sichtbar ist, wird es im Datengitter und Vorgangsdialog immer angezeigt, jedoch mit einem leeren Wert für jeden Status, bei dem es als “unsichtbar” konfiguriert ist.

In den Tabellen können Optionen auch für ganze Zeilen, Spalten oder gleich die gesamte Tabelle schnell umgeschaltet werden:

../_images/nutzer-datenfelder.png
  • Mit einem Klick auf den oberen Spaltentitel für die gesamte Spalte.

  • Über den linken Zeilentitel für die gesamte Zeile.

  • Über die Zelle ganz links-oben für die gesamte Tabelle

Dokumente teilen

Über die Oberfläche können nun Links für einzelne Dokumente erzeugt werden, über die das jeweilige Dokument ohne Benutzeranmeldung aufgerufen werden kann. Diese Funktion muss in einer Rolle zunächst erlaubt werden, indem man den Befehl „Dokumente teilen“ aktiviert. Dann erscheint in der Listen-Ansicht der Dokumente ein neues Icon, das einen Dialog öffnet, um einen Link zu erzeugen.

Die Links sind intern mit dem erzeugenden Benutzer verknüpft und die Dokumente können auch nur solange über den erstellten Link aufgerufen werden, solange der Benutzer selbst noch Zugriff auf das Dokument hat. Das könnte insbesondere bei einem Statuswechsel dazu führen, dass ein erzeugter Link ungültig wird, wenn der Benutzer, der einen Dokumenten-Link erzeugt hat, im neuen Status keinen Zugriff auf den Vorgang des Dokuments mehr hat.

Über diesen Link kann das Dokument auch von Personen aufgerufen werden, die ansonsten keinen Zugang zum System haben.

Es gibt ebenfalls die Möglichkeit, einen solchen Link für einen ganzen Vorgang inklusive seiner Metadaten zu erzeugen. Die Bedienung ist identisch und es kann auch hier eine Gültigkeitsdauer festgelegt werden. Aufgerufen wird die Funktion über das Workflow-Menü in der Toolbar oder das Kontextmenü des Vorgangs.

Es ist auch möglich, diese Links über die API zu erzeugen, dies wird in der in der API-Dokumentation beschrieben.

Terminplanung

Dieses Recht ist notwendig , um auf dem Termine-Reiter Änderungen machen zu können.

Zugriffshistorie anzeigen

In der Rollenkonfiguration wurde ein neuer Befehl „Zugriffshistorie anzeigen“ hinzugefügt, über den gesteuert werden kann, ob ein Benutzer in der Historie die Zugriffprotokollierung für Vorgänge und Dokumente sehen darf.

Bei bestehenden Rollen ist dieser Befehl für alle sichtbaren Status aktiviert, damit bei einem Upgrade das frühere Verhalten unverändert bleibt.

Statuswechsel erzwingen

Dieser Befehl ist nur verfügbar, wenn das Archiv einen regelbasierten Workflow konfiguriert hat. Beim Upgrade wird bei bestehenden Archiven der Befehl in Administrator-Rollen für alle Status voreingestellt.

Bei der Auswahl der Funktion „Statuswechsel erzwingen“ im Vorgangsmenü wird ein Dialog angezeigt, der darauf hinweist, dass bei Verwendung dieser Funktion keine Aktionsroutinen des Workflows ausgeführt werden.

Darüber hinaus muss eine Begründung für den erzwungenen Statuswechsel eingegeben werden, die anschließend in der Historie vermerkt wird.

Rollenrechte für Datentabellen

In den Rollen können nun auch Rechte auf einzelne Datentabellen vergeben werden. Pro Datentabelle können die drei Optionen “Unsichtbar”, “Nur lesen” und “Vollzugriff” eingestellt werden.

../_images/nutzer-datentabellen.png

Rollen mit Administrator-Rechten haben weiterhin Vollzugriff auf alle Datentabellen.

Das Recht “Nur lesen” wird für den Lookup-Dialog benötigt. Das Recht “Vollzugriff” wird von Dienstbenutzern benötigt, die über das neue Tool für Datentabellen-Import automatisch Datentabellen befüllen.

Migration und verschobene Optionen

Beim Update auf Version 5.0 wurden die alten Rollen so migriert, dass die sichtbaren Vorgänge und erlaubten Aktionen bei allen Benutzern möglichst identisch bleiben:

  • Wenn eine Rolle vorher mindestens das Recht “Lesen” auf ein Archiv hatte, ist dieses Archiv anschließend weiterhin sichtbar.

  • Beim zusätzlichen Recht “Schreiben” wird die Option “Vorgänge archivieren” aktiviert und der Befehl “Bemerkungen hinzufügen” ist in jedem Status erlaubt.

  • Beim zusätzlichen Recht “Löschen” werden die Befehle “Vorgänge löschen” und “Vorgänge verstecken” in allen Status erlaubt.

  • Administrator-Rollen ist zusätzlich der Befehl “Multiedit” erlaubt.

  • Alle migrierten Rollen dürfen in jedem Status den Befehl “Vorgänge an Postfach senden” ausführen.

Warnung

Einige Optionen, die vorher in Archiven oder Datenfeldern eingestellt wurden, wurden nun als Rechte in die Rollen verschoben:

  • Die Archiv-Option “Vorgang erweiterbar”, die bestimmt, ob man in einem Vorgang nachträglich Dokumente hinzufügen darf, wurde in den Rollen-Befehl “Dokumente hinzufügen” verschoben. Bei der Migration bekommt die Rolle diesen Befehl für alle Status dann zugewiesen, wenn die Option im Archiv aktiviert und die Rolle mindestens Schreibrecht hatte. Wenn die Rolle vorher zusätzlich das Recht zum Löschen hatte, wird auch der Befehl “Dokumente löschen” erlaubt.

  • Die Archiv-Option “Dokumente bearbeitbar” (die bestimmt, ob man Dokumente über den SmartClient zur Bearbeitung auschecken darf) wurde in den Rollen-Befehl “Dokumente bearbeiten” verschoben. Diesen Befehl bekommt die Rolle ebenfalls dann zugewiesen, wenn sie vorher mindestens Schreibrechte hatte.

  • Die Datenfeld-Option “Änderbar” wurde ebenfalls in die Rollen verschoben. Alle Datenfelder, die diese Option aktiviert haben, werden in Rollen mit Schreibzugriff in jedem Status auf “Vollzugriff” gesetzt, ansonsten auf “Nur lesen”.

Gruppen

Es ist möglich, Dokumente im Eingang innerhalb einer Gruppe zu teilen. Dazu wird ein Dokument aus dem Eingang eines Benutzers an eine Gruppe weitergeleitet und ist von da an im Eingang aller Mitglieder der Gruppe zu sehen, so dass es von jedem dieser Mitglieder archiviert oder weitergeleitet werden kann.

Gruppen können ebenfalls als Empfänger von Terminen ausgewählt werden.

Gruppen werden in der Administrations-Oberfläche im Bereich Gruppen definiert. Einer Gruppe können beliebig viele Benutzer zugeordnet werden. Andersherum kann ein Benutzer in seinen Einstellungen einer oder mehreren Gruppen zugeordnet werden.

../_images/nutzer-gruppen.png

Um eine neue Gruppe zu erstellen, öffnen Sie den Dialog Neu in der Menüleiste:

../_images/nutzer-gruppe-erstellen.jpg

Im Feld „Name“ müssen Sie einen eindeutigen Namen für die Gruppe eingeben. Für jede Gruppe kann im Feld „Farbe“ eine Farbe eingestellt werden, so dass im Eingang leichter unterschieden werden kann, über welchen Gruppeneingang man das Dokument im Eingang sieht. Nun können Sie die zugehörigen Benutzer einfügen und bei Bedarf noch eine Beschreibung der Gruppe erstellen. Nach dem Speichern ist die Gruppe aktiv.

Um ein Dokument aus dem Eingang einer Gruppe verfügbar zu machen, wird der Button Weiterleiten verwendet. Während an dieser Stelle bisher nur an einen einzelnen Benutzer weitergeleitet werden konnte, kann hier nun auch eine Gruppe ausgewählt werden. Das Dokument erscheint dann im Eingang aller Mitglieder dieser Gruppe mit einer entsprechenden Markierung in der Spalte Gruppe. Ist der weiterleitende Benutzer selbst Teil der Gruppe, bleibt das Dokument auch im eigenen Eingang sichtbar, nun ergänzt um die Gruppen-Markierung. Andernfalls verschwindet es aus seinem Eingang, so wie sonst auch im Falle einer Weiterleitung.

In einer Gruppe kann ebenfalls eine E-Mail-Adresse eingestellt werden.

Wenn für die Gruppe eine E-Mail-Adresse konfiguriert ist, werden E-Mail-Benachrichtungen für neue Postfach-Einträge nicht mehr an alle einzelnen Mitglieder der Gruppe gesendet, sondern nur noch an die hier konfigurierte Adresse.

Auch Hotfolder können Dokumente direkt in einem Gruppeneingang ablegen. Analog zur bisherigen Syntax archiv@benutzer (legt das Dokument in den Eingang des Benutzers mit dem Anmeldenamen benutzer und setzt das Archiv mit dem Kurznamen archiv als Voreinstellung) wird das Dokument bei #Gruppenname in die Gruppe mit den Namen Gruppenname gelegt. Auch hier kann ein Archiv über den Kurznamen vor # voreingestellt werden.

Mandanten

Mandanten sind eine 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. Durch die Lizenzverwaltung können neue Mandanten nur erstellt werden, wenn ausreichend viele Mandanten lizenziert wurden. 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.

Bemerkung

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.

../_images/mandant-archive-zuordnen.png

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.

Diese Zuordnung war bisher nur für solche Archive möglich, in denen Mandanten bereits aktiviert sind. Das hatte den Nachteil, dass bereits existierende Archive nicht vorkonfiguriert werden konnten, bevor die Mandanten aktiviert wurden, so dass bei Aktivierung der Mandanten die Benutzer vorübergehend den Zugriff auf alle Vorgänge verloren, bis die Zuordnung erfolgt war.

Deshalb ist es in der Tabelle „Zuordnung“ nun möglich, über eine Checkbox auch Archive ohne aktivierte Mandanten anzuzeigen und zuzuordnen:

../_images/mandanten-zuordnung-ohne-aktivierung.png

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.

../_images/mandant-benutzer-zuordnen.png

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 Zuordnung 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.