Der lokale Administrator (LA)
Der lokale Administrator einer org ist dazu berufen, den strukturellen Aufbau seiner org, durch die Einrichtung von entsprechenden oeen, im productNameAbbr abzubil‐ den. Seine grundlegende Aufgabe ist es, die behördeninternen oeen und Benutzer zu verwalten. Loggen Sie sich im Administrationsbereich des productNameAbbr ein. Eingangs gelangen Sie zu einer Übersicht mit den Rubriken »Stammdaten«, »oeen« und »Benutzer« Ihrer org. Hier haben Sie die Möglichkeit die hinterlegten Datensätze in den Rubriken einzusehen und entsprechende organisatorische Änderungen vorzunehmen. Oben links können Sie mittels der Schaltfläche [Deaktivieren] die ganze org ruhenlas‐ sen. Ist das bereits der Fall, so steht dort die Schaltfläche [Aktivieren] zur Verfügung.
Abbildung: Administrationssicht einer Beispiel‐org ‐ Stammdaten
Abbildung: Administrationssicht einer Beispiel‐org ‐ oeen
Abbildung: Administrationssicht einer Beispiel‐org ‐ Benutzer
Innerbehördliche oeen handhaben
oeen einrichten
Um eine oe anzulegen navigieren Sie in die Rubrik »Organisationseinhei‐ ten« und betätigen die Schaltfläche [Hinzufügen].
Übersicht von innerbehördlichen oeen
Sie gelangen in die Stammdatenerfassung für die neu anzulegende oe, welche sich in die Themenfelder „Identifikationsdaten“ und „Adresse“ aufgliedert.
Identifikationsdaten
Für die Identifikationsdaten ist der Name notwendig, der daher verpflichtend angegeben werden muss. Hingegen ist eine kurze Beschreibung der neuen OE, ebenso wie die Hinter‐ legung einer E‐Mailadresse für diese Einheit, fakultativ.
Adresse
Das Thema Adresse kann ohne Eintrag übergangen werden, sofern die neue OE im gleichen Standort beheimatet ist, wie die org zu der sie gehört. Liegt eine abweichende Örtlichkeit vor, so ist diese hier einzutragen.
Initiale Stammdatenerfassungsmaske für oeen
Durch das Betätigen der Schaltfläche [Anlegen] wird die OE mit den hinterlegten Stamm‐ daten gespeichert und Sie erhalten eine Quittung.
Quittierung der Neuanlage einer OE
Durch Klicken auf die [org_pluralbezeichnung] in der Navigationsleiste gelangen Sie zurück in die org_pluralübersicht, wo unter anderem die neue OE angezeigt wird und weitere OEn hizugefügt werden können.
oeen deaktivieren
Um eine oe zu deaktivieren klicken Sie in der org_pluralübersicht unter »oeen« auf die entsprechende [Zeile der gewünschten OE]. Die hinter‐ legten Stammdaten der OE werden Ihnen wie beim Anlegen angezeigt. Im linken oberen Bereich können Sie durch betätigen der Schaltfläche [Deaktivieren] die entsprechende OE auf inaktiv setzen.
Schaltfläche »Deaktivieren« von OEn
Gehen mittels eines Klicks auf die [org_pluralbezeichnung] in der Navigationsleiste zurück in die org_pluralübersicht, wo unter anderem die deaktivierte OE angezeigt wird.
Deaktivierte OE in der Übersicht
oeen löschen
Um eine oe zu löschen, gehen Sie wie zuvor unter Kapitel 4.1.1.2 in die Detailansicht der gewünschten OE, wobei es in diesem Zusammenhang irrelevant ist, ob die oe aktuell aktiv ist oder deaktiviert wurde. Betätigen Sie jetzt links oben die Schaltfläche [Löschen].
Schaltfläche »Löschen« von OEn
Zu Verifikationszwecken erscheint ein Zwischenbildschirm, der erneut mit einem Klick auf den Knopf [Löschen] zu bestätigen ist.
Verifikationsabfrage beim Löschen von OEn
Grundsätzlich können nun zwei unterschiedliche Ereignisse eintreten:
- Sollten mit der entsprechenden oe keine processes.name_plural (mehr) verknüpft sein, so wird diese nun umgehend gelöscht und das Ereignis quittiert. Anschließend befin‐ den Sie sich wieder in der org_pluralübersicht; die OE wird dort nicht mehr angezeigt.
Quittierung der Löschung einer OE
- Gibt es hingegen noch Abhängigkeiten zu Benutzern und/oder processes.name_pluraln von dieser oe, so erscheint ein Fehlerprotokoll, das zunächst abzuarbeiten ist, be‐ vor der Löschvorgang fortgesetzt werden kann.
Beispiel Fehlerprotokoll bei einer OE Löschung - die Löschung blockierende Benutzer
Beispiel Fehlerprotokoll bei einer OE Löschung - die Löschung blockierende processes.name_plural
Zur Behebung dieser die Löschung blockierenden Gründen müssten processes.name_plural beispielsweise an andere Einheiten oder das Archiv übergeben werden und Zugriffsrechte von Nutzern wären entsprechend anzupassen/abzuwählen. Im Nachgang ist der Löschvorgang für die OE erneut einzuleiten.
Nutzerverwaltung
Nutzer einrichten Um einen Benutzer anzulegen navigieren Sie in die Rubrik »Benutzer« und betätigen die Schaltfläche [Hinzufügen].
Übersicht von Nutzerkonten
Sie gelangen in die Stammdatenerfassung für den neu anzulegenden Benutzer, welche sich in die Themenfelder »Identifikationsdaten«, »Rollen«, »Zugehörigkeit zu Organisationsein‐ heiten« und »Abonnements für Abfragen« aufgliedert.
Identifikationsdaten
Für die Identifikation tragen Sie bitte den Vor‐ und Nachnamen des neuen Teilnehmers ein. Jene Angaben sind ebenso notwendig und daher verpflichtend, wie die Hinterlegung der nutzerspezifischen E‐Mailadresse. Da diese eineindeutig sein muss, kann sie nur einmalig programmweit vergeben werden, weshalb prinzipiell auch eine personenbezogene statt einer funktionsbezogenen E‐Mailadresse erwartet wird. Um Rücksprachen zu ermöglichen ist ferner die Telefonnummer im internationalen Format anzugeben (+ mit Landesvorwahl, Ortsvorwahl, Rufnummer und Durchwahl, jeweils getrennt durch ein Leerzeichen und ohne Verwendung weiterer Zeichen. Beispiel: +49 228 99610 1177). Die org, worunter der neue Nutzer angelegt wird, ist standardmäßig bereits vorgeblendet. Auch beim Benutzernamen sind keine Eintragungen notwendig. Hier erfolgt die automatische Anzeige, sobald der Benutzer seinen Zugang zum productNameAbbr aktiviert hat.
Rollenzuweisung
Im Themenfeld Rollen wird anschließend der Funktionszuschnitt des Nutzers bestimmt. Abhängig von der hinterlegten Hauptrolle der eigenen org (ZBSt oder BT) zeigt sich die Administrationsmaske etwas unterschiedlich. Der Grund dafür ist, dass „Beschafferrollen“ auch nur bei zentralen Beschaffungsstellen vorgesehen sind.
Initiale Stammdatenerfassungsmaske für Nutzer
Der funktonale Inhalt der einzelnen Rollen und deren Bezeichnung basiert weitgehend auf dem Rechte‐ und Rollenkonzept des productNameAbbr in der Version vom Januar 2018 (vergleiche ebenda). Die Rechteintensität der einzelnen Rollen ist als Schieberegler ausgeprägt. Ihr Startpunkt liegt immer links und bedeutet „keine Rechte in der entsprechenden Rolle“. Mit der Ver‐ schiebung der Regler nach rechts nimmt der Rechteumfang in der jeweiligen Rolle zu. Ein Nutzer ohne zugewiesene Rollen kann sich an keinem Frontend anmelden.
Der Regler »Bedarfsmelder«
Unter diesem Regler werden die Rechte für „Bedarfsmelder“ und „Bedarfsträger“ gemein‐ sam verwaltet. Sie werden im Wesentlichen definiert als Nutzer einer org, die Bedarfsträger ist und
- welche für die org an allen Bedarfsvermutungen, offenen Bedarfserhebungen und an den an sie adressierten beschränkten Bedarfserhebungen teilnehmen. Sie sind dann nicht nur berechtigt die behördliche Bedarfseinschätzung abzugeben, sondern ebenso die behördliche Bedarfsrückmeldung und können diesbezüglich auch Teilbedarfserhebungen durchführen. Sie legen sowohl ex-ante Meldungen, processes.BM.plural als auch processes.PV.plural initial an.
- welche für ihre oe an Teilbedarfserhebungen und an den an sie adressierten beschränkten Bedarfserhebungen teilnehmen. Sie sind dann berechtigt (Teil‐) Bedarfsrückmeldungen abzugeben.
Die Rechte können nur „lesend“ vergeben werden. Genauso ist es möglich einen behörden‐ weiten Zugriff nur lesend zu erteilen, wobei dann ‐ über die dem Nutzer konkret zugeordne‐ ten oeen hinaus ‐ in alle Bedarfsträgervorgänge der org Einsicht genommen werden kann. Wird dieses Recht als Vollzugriff erteilt, so bedeutet das nur die Arbeitsbefähigung für die dem Nutzer konkret zugeordneten oeen. Darüber hinaus besteht weiterhin nur Leserecht. Der behördenweite Zugriff ist nur für org_pluralleitungen und Koordinierungsstellen vorgesehen.
Der Regler »Beschaffer«
Unter diesem Regler werden die Rechte für „Bedarfserheber“ und „Beschaffer“ bzw. „Fach‐ betreuer“ gemeinsam verwaltet. Sie werden im Wesentlichen definiert als Nutzer einer org, die Beschaffungsstelle ist und
- welche sämtliche processes.targetProcess.filterIndicatorLabelen von Bedarfsabfragen initial anlegen, diese ändern und freigeben bzw. veröffentlichen können. Ferner obliegt ihnen die Bearbeitung von Bedarfsmitteilun‐ gen aller Art.
Die Rechte können nur „lesend“ vergeben werden. Genauso ist es möglich einen behörden‐ weiten Zugriff nur lesend zu erteilen, wobei dann ‐ über die dem Nutzer konkret zugeordne‐ ten oeen hinaus ‐ in alle Beschaffer‐processes.name_plural der org Einsicht genommen werden kann. Wird dieses Recht als Vollzugriff erteilt, so bedeutet das nur die Arbeitsbefähigung für die dem Nutzer konkret zugeordneten oeen. Darüber hinaus besteht weiterhin nur Leserecht. Der behördenweite Zugriff ist nur für org_pluralleitungen und Koordinierungsstellen vorgesehen.
Der Regler »Admin«
Unter diesem Regler werden die Rechte für Administratoren verwaltet. Sie umfassen die in diesem Handbuch beschriebenen Fähigkeiten und Zugriffrechte. Höhere Rechte, als die des lokalen Administrators können ausschließlich durch die Globaladministration (BeschA) vergeben werden und sind auf lokaler Ebene ausgegraut bzw. nicht verfügbar.
Grundsätzlich erfolgt die Festlegung der Rolle für die Nutzer einer org durch den dort ansässigen, lokalen Administrator. Gibt es die org_pluralstruktur her und wurde eine zentrale Administration organisatorisch vereinbart, so kann die Aufgabe auch an dieser Stelle ausge‐ führt werden.
HINWEIS: Wurde einmal das lokale Administrationsrecht an einen Nutzer vergeben, so kann es nur dann wieder entzogen werden, wenn noch mindestens ein weiterer lokaler Admin in der org existiert. Dies hat den Grund, dass eine org ohne lokalen Admin ab einem bestimm‐ ten Zeitpunkt (Änderungen der Organisation, Nutzerverwaltung) nicht mehr arbeitsfähig wäre.Entsprechend der oben beschriebenen Rollenfestlegung ist ein rein lesender Zugriff stets an eine konkrete Rolle gebunden. Durch das Anlegen eines Nutzers mit einer oder mehreren Rollen, kann dieser auch lesend im productName aktiv sein. Voraussetzung dafür ist, dass der Nutzer dies weiß bzw. dies organisatorisch so festgehalten wird.
Zuweisung von oeen
Im darunter nachfolgenden Themenfeld »Zugehörigkeit zu oeen« werden dem neuen Benutzer diejenigen OEn durch Anhaken zugeordnet, für die dieser in Zukunft handeln darf. Ein Nutzer ohne Zugehörigkeit zu einer oe kann sich an keinem processes.name im productNameAbbr aktiv beteiligen. In welcher Form die Zugehörigkeit ausgeprägt ist (lesend oder bearbeitend), wurde bereits im vorhergehenden Schritt festgelegt und besitzt hier keine weitere Relevanz.
Exemplarische OE‐Zuweisungstabelle für Nutzer
Abonnements für Abfragen
Das letzte Themenfeld zu den Abonnements des neuen Benutzers ist für den Administrator ein reines Informationsfeld und initial selbstverständlich leer, da die Abonnements nur vom Benutzer selbst geändert werden können.
Initiale Abonnement Anzeige eines Nutzers
Sofern der neue Nutzer später Abonnements eingerichtet hat, werden diese hier nach aktu‐
ellem Stand angezeigt.
Exemplarische, spätere Anzeige einer umfangreichen Abonnementwahl
Durch Betätigen der Schaltfläche [Anlegen und Einladen] wird der neue Nutzer angelegt.
Schaltfläche Anlegen und Einladen
Er erscheint namentlich oben rechts neben der org_pluralanzeige mit dem Status „einge‐ laden“ während sich das angezeigte Schaltflächenset ändert.
Schaltflächenansicht nach der Anlage eines Nutzers
Zeitgleich erhält der neue Nutzer eine E‐Mail mit der Einladung zur Teilnahme am productNameAbbr, worin sich auch ein Link (Token) befindet. Dieser Link führt zur passenden Programmseite des productNameAbbr, auf der die Aktivierung des individuellen Zugangs durchgeführt werden kann. Der im Link enthaltene Token ist nach dem Versenden genau 7 Tage gültig.
Exemplarische Einladungs‐E‐Mail mit Token zur Aktivierung des Zugangs
Die Einladungs‐E‐Mail kann durch den lokalen Admin – anhand der Schaltfläche [Erneut einladen] in den Stammdaten des Nutzers – wiederholt an den Benutzer verschickt werden, bis dieser seinen Zugang aktiviert hat. Dabei ist zu beachten, dass jeder Link (Token) in einer neu versandten Einladungs‐E‐Mail alle vorherigen Links (Token) älterer Einladungen umge‐ hend ungültig macht, selbst wenn die Ablauffrist noch nicht erreicht sein sollte. Die Links enthalten Einmal‐Token, so dass auch die erfolgreiche Verwendung eines Token durch den Nutzer diese ebenfalls unmittelbar ungültig werden lässt.
Registrierungsanfrage bearbeiten
Wenn die Initiative einer Registrierung von einem Nutzer selber ausgeht, hat dieser die Möglichkeit eine Registrierungsanfrage zu stellen. Zu finden ist die Registrierungsmaske unter der gewöhnlichen Adresse zum productNameAbbr Programm einstieg (Startseite). In der Anmeldemaske muss dafür rechts auf den Schriftzug »Registrie‐ rung« geklickt werden. Danach sind die dargebotenen Felder auszufüllen und der processes.name ist mit [Registrieren] abzuschließen.
Als lokaler Admin werden Sie über den Eingang einer solchen Anfrage per E‐Mail informiert und gelangen über den darin befindlichen Link direkt in das temporär angelegte Nutzerkonto des Anfragenden; es hat den Status „registriert“. Hier können Stammdaten ergänzt und dem anfragenden Nutzer, mittels der Schaltfläche [Erneut einladen], eine Einladungs‐E‐Mail zugesandt werden. Diese E‐Mail ermöglicht dem Nutzer die Aktivierung seines Kontos mit Festlegung des Benutzernamens und des Passwortes.
Exemplarische Info‐E‐Mail zur Registrierung neuer Nutzer
Stammdatenergänzung registrierter Nutzer
Gesperrten Nutzerzugang entsperren
Um einen Benutzer nach dessen Sperrung durch dreimalige Eingabe eines falschen Pass‐ wortes (siehe auch Hinweis in Kapitel 3.3.4.2) wieder freizuschalten, wählen Sie in der Navigationsleiste des Adminbereichs den Eintrag »Benutzer« und suchen Sie danach über das Eingabefeld [Suche] nach dem Benutzernamen oder Namen des Kandidaten. Alternativ navigieren lokale Administratoren in der ihnen angezeigten org_pluralansicht ganz nach unten, wo sich ebenfalls der Bereich »Benutzer« befindet und wo analog über ein Suchfeld selektiert werden kann.
Benutzerübersicht in einer org_pluralansicht (unten)
Sollte sich der Nutzer durch Eingabe eines falschen Passworts ausgesperrt haben, werden Sie per E‐Mail darüber informiert. In dieser E‐Mail wird Ihnen auch der entsprechende Name des Nutzers angezeigt, sodass Sie diesen in der Suche wiederfinden können. Alternativ finden Sie den Status der Benutzer in der ganz rechten Spalte der Übersichtsliste. Die Spalte kann bei langen Listen auch unterstützend sortiert werden, indem der Spaltenkopf [Status] ein‐ oder mehrfach angeklickt wird. Um den Benutzer freizuschalten gehen Sie in sein Konto, indem Sie auf die [Zeile mit dem Namen] des entsprechenden Nutzers klicken. Durch Betätigung der Schaltfläche [Entsperren E‐Mail senden] wird vom System eine E‐Mail an den Benutzer versandt, in der ein Einmal‐ Link (Token) enthalten ist, welcher zu einer bestimmten Programmseite des productNameAbbr führt. Dort besteht nun für den Benutzer die Möglichkeit ein neues Passwort vergeben und somit seinen Zugang wieder freizuschalten. Dieser Link (Token) ist aus Sicherheitsgründen nur 30 Minuten gültig; danach muss ein neuer Token angefordert werden.
Benutzer entsperren
Als Admin können Sie die E‐Mail zur Entsperrung solange wiederholt verschicken, bis der Nutzer seinen Zugang entsperrt hat. Dabei ist zu beachten, dass jeder Link (Token) in einer erneut versandten E‐Mail gleichen Ursprungs, alle vorherigen Links (Token) älterer E‐Mails mit demselben Ursprung umgehend ungültig macht, selbst wenn die Ablauffrist noch nicht erreicht sein sollte. Die Links enthalten Einmal‐Token, so dass auch die erfolgreiche Verwendung eines Token durch den Nutzer diese ebenfalls unmittelbar ungültig werden lässt. Nach der Entsperrung durch den Benutzer, kann sich dieser mit dem von ihm neu vergeben‐ en Passwort wieder am productNameAbbr anmelden.
Nutzerzugang deaktivieren
Um einen Benutzer zu deaktivieren, wählen Sie in der Navigationsleiste des Adminbereichs den Eintrag »Benutzer« und klicken anschließend in der Gesamtübersicht auf die entsprech‐ ende [Zeile des gewünschten Benutzers]. Alternativ navigieren lokale Administratoren in der ihnen angezeigten org_pluralansicht ganz nach unten, wo sich ebenfalls der Bereich »Benutzer« befindet und klicken dort analog auf die entsprechende [Zeile des gewünschten Benutzers]. Sie sind in der bekannten Stammdatenansicht des Nutzerkontos. Sofern der Nutzer nicht bereits den Status „deaktiviert“ hat oder „gesperrt“ ist, findet sich oben links die Funktions‐ schaltfläche [Deaktivieren]. Klicken Sie diese an, um den entsprechenden Benutzer auf inaktiv zu setzen.
Benutzer deaktivieren
Der Status des Nutzers ändert sich in „deaktiviert“. Gleichzeitig werden die Funktionsbuttons ausgetauscht und der Knopf [Aktivieren] steht Ihnen nunmehr zur Verfügung. Würden Sie jetzt diesen Knopf bedienen, hätten Sie den Ursprungszustand wieder hergestellt.
Anzeige eines deaktivierter Benutzer
Ab dem Zeitpunkt, zu dem ein Benutzerkonto den Status „deaktiviert“ aufweist, kann sich
der betreffende Nutzer nicht mehr am productNameAbbr anmelden.
Benutzer deren Konto deaktiviert wurde, bekommen automatisch eine E‐Mail mit der ent‐
sprechenden Information. Wird der processes.name [Aktivieren] ausgeführt, so verhält sich das
System analog.
Nutzer löschen
Um einen Benutzer zu löschen, wählen Sie in der Navigationsleiste des Adminbereichs den Eintrag »Benutzer« und klicken anschließend in der Gesamtübersicht auf die entsprechende [Zeile des gewünschten Benutzers].
HINWEIS: Alle processes.name_plural eines deaktivierten Benutzers sind für andere berechtigte Nutzer in den Übersichten und Detailansichten weiterhin sichtbar und können innerhalb der org weiter bearbeitet werden.Alternativ navigieren lokale Administratoren in der ihnen angezeigten org_pluralansicht ganz nach unten, wo sich ebenfalls der Bereich »Benutzer« befindet und klicken dort analog auf die entsprechende [Zeile des gewünschten Benutzers]. Sie sind in der bekannten Stammdatenansicht des Nutzerkontos, wo sich oben links die rote Funktionsschaltfläche [Löschen] befindet, durch deren Betätigung die Löschung des productNameAbbr Teilnehmers eingeleitet wird. Der aktuelle Status des Nutzerkontos spielt dabei keine Rolle.
Benutzer löschen
Es erscheint eine Verifikationsabfrage, die erneut mit einem Klick auf den Knopf [Löschen] zu bestätigen ist.
Verifikationsabfrage beim Löschen von Nutzern
Grundsätzlich können nun zwei unterschiedliche Ereignisse eintreten:
- Sollten mit dem entsprechenden Nutzer keine processes.name_plural (mehr) verknüpft sein, so wird dieser nun umgehend gelöscht und das Ereignis quittiert. Anschließend befinden Sie sich wieder in der org_pluralübersicht; der Benutzer wird dort nicht mehr angezeigt.
Quittierung der Löschung eines Benutzers
- Gibt es hingegen noch Abhängigkeiten zu processes.name_pluraln, so erscheint ein Fehlerprotokoll, das zunächst abzuarbeiten ist, bevor der Löschvorgang fortgesetzt werden kann.
Beispiel Fehlerprotokoll bei einer Nutzer‐Löschung - blockierende processes.name_plural
Hierzu müssten die processes.name_plural beispielsweise an andere Nutzer oder das Archiv übergeben bzw. von Nutzern der gleichen OE übernommen werden. Im Nachgang ist der Löschvorgang für den Benutzer erneut einzuleiten.
Um eine ganze Reihe von Nutzern gleichzeitig zu löschen, kann der Administrator in der Benutzerübersicht auch die Registerkarte den »Löschmodus« anwählen. Wählen Sie dann die Kandidaten aus, die gelöscht werden sollen, indem Sie die betreffenden Zeilen links anhaken und drücken Sie anschließendauf die nach dem Aktivieren des Löschmodus erscheinende Schaltfläche [Löschen]. Eventuell auftretende Fehlerlisten sind auch hier entsprechend abzuarbeiten, gefolgt von einem erneuten Löschvorgang.
Aktivierung des Multi-Löschmodus in Benutzerlisten
Löschen in Benutzerlisten mit aktiviertem Mulit-Löschmodus