Hallo Andre,

für den Fall, dass die „Benutzer“ die OTOBO-Agenten sind, d.h. die „Problemlöser“, die auf index.pl arbeiten, geht das mit den Tickets indirekt über die Queues, in denen die Tickets liegen und die Gruppen, denen die Agenten angehören. Die Kunden und Kundenbenutzer sind so allerdings nicht auftrennbar.

Falls „Benutzer“ die Kundenbenutzer sind, dann ja, gibt es Kunden (Organisationen/Firmen), deren Kundenbenutzer nichts von den jeweils anderen Kunden erfahren können.

https://doc.otobo.org/manual/admin/stable/en/content/users-groups-roles.html

Viele Grüße, Sven

Die Sichtbarkeit von Kundendaten kann nur mit einem Addon (<werbung>https://feature-addons.de/znuny/Customer%20Backend/TaggedCustomerUser</werbung&gt;) gesteuert werden.

Hallo zusammen,

Ergänzung und Zusammenfassung, weil der letzte Eintrag etwas in die Irre führen kann:

Ja, OTOBO ist mandantenfähig.

Konkret:

-> OTOBO Kundenbenutzer

Kundenbenutzer sehen im OTOBO Standard im Serviceportal nur ihre eigenen Tickets. Mit der Funktion “Firmentickets” kann das System so konfiguriert werden, dass auch Tickets anderer Kundenbenutzer aus der gleichen Organisation (Mandanten) eingesehen werden können.

(Beispiel: 
Frau Müller aus der Firma Mayer sieht im Standard nur ihre eigenen Tickets.
Sind die Firmentickets aktiv, sieht sie auch die Tickets ihrer Kolleginnen Möller und Maurer (Tickets der Kundenbenutzer aus anderen Unternehmen sieht sie nicht).)

-> OTOBO Agenten

Die Servicemitarbeitenden, die die Kundenanfragen im Backend bearbeiten können nur auf Tickets und Informationen in ihrem Verantwortungsbereich (Mandanten) zugreifen. Die Rechtesteuerung erfolgt über Rollen/Gruppen.

Einzige Ausnahme: OTOBO geht im Standard davon aus, dass Kundenbenutzer und Kunden (Organisationen) immer von allen Agenten gemeinsam verwendet werden. Diese Daten sind deshalb von allen einsehbar und durchsuchbar.

Dies lässt sich durch ein Add-on verhindern: Das Add-on CustomerMultitenancy begrenzt den Zugriff von Agenten auf Kunden(benutzer). Somit können Datenquellen mit Kunden(benutzer)-Informationen aus einem bestimmten Backend auch bestimmten Agenten zugewiesen werden.

Achtung: Das Add-on hat aktuell keine Auswirkung auf die Elasticsearch-Kundensuche. Diese müsste in diesem Szenario für Kunden(benutzer) deaktiviert werden. (Gerne erweitern wir die Funktion, bei Interesse bitte eine kurze Nachricht an hallo @ otobo.io).

Noch eine Anmerkung im Bezug auf die neue CMDB in OTOBO 11
In OTOBO 11 ist eine feingranulare Berechtigungssteuerung möglich. Letztlich kann über Gruppen der Zugriff auf die gesamte CMDB, jede CMDB Klasse (ro|rw) und jede Page (Tab) in einem ConfigItem gesteuert werden.

Über das kostenfreie Feature Add-on ConfigItemMultitenancy ist es zusätzlich möglich, die Berechtigungssteuerung auf ConfigItem-Ebene zu verlagern.

(Beispiel:

Zwei getrennte IT Abteilungen setzen gemeinsam die CMDB ein und möchten beide eine Klasse “Computer” verwenden, ohne deren Informationen der jeweils anderen Abteilung zugänglich zu machen.
Die Standardlösung wäre, zwei Klassen anzulegen (Computer IT Abt. 1 und Computer IT Abt. 2). Über Gruppen wären die Klassen sauber getrennt und jede Abteilung würde nur ihre Klasse mit ihren ConfigItems sehen.

Außerdem besteht nun die Möglichkeit, eine gemeinsame Klasse “Computer” anzulegen, das Add-on ConfigItemMultitenancy zu installieren und dann jedem ConfigItem bei der Erstellung direkt eine Gruppe zuzuweisen. Somit gibt es eine übergreifende Klasse, die User können dennoch nur die „eigenen“ CIs einsehen.)

-> OTOBO Administratoren

OTOBO Admins haben grundsätzlich jederzeit die Möglichkeit auf alle “Mandanten” zuzugreifen.

Das Feature “Light-Admin” etabliert auch im Administrationsbereich von OTOBO eine gewisse Mandantenfähigkeit und grenzt z. B. die Admin-Funktionen “Vorlagen” und “Vorlagen <-> Queues” auf den eigenen Berechtigungsbereich ein. Administratoren mit vollen Rechten können aber immer auf die Daten aller Mandanten zugreifen.

• Diese Antwort wurde vor 1 Jahr von Grit Rother geändert.

Adding the English translation to what I wrote on multitenancy in OTOBO above:

Details on Multi-tenancy in OTOBO

-> OTOBO Customer Users

By default, customer users in OTOBO can only see their own tickets in the service portal.

With the feature “Company Tickets”, the system can be configured so that customer users can also view tickets created by other customer users from the same organization (tenant).

Example:
By default, Sally Smith from Shine company can only see her own tickets. If Company Tickets are activated, she can also see the tickets of her colleagues Baker and Buff. (She cannot see tickets from customer users of other companies, though.)

-> OTOBO Agents

Service staff (agents) who process customer requests in the backend can only access tickets and information within their area of responsibility (tenant). Access rights are controlled via roles and groups.

There is one exception to this: By default, OTOBO assumes that customer users and customers (organizations) are shared across all agents. Therefore, this data is visible and searchable for all agents.

This can be restricted by using the CustomerMultitenancy add-on, which limits agent access to customer (users). This allows data sources containing customer (user) information from a specific backend to be assigned to specific agents only.

Important: Currently, this add-on does not affect the Elasticsearch customer search. In such a scenario, Elasticsearch customer search must be disabled for customer (user) data. (We are happy to extend this functionality, though. Please get in touch at hello @ otobo.io, if you are interested.)

Note Regarding the New CMDB in OTOBO 11

In OTOBO 11, fine-grained permission control is possible. Using groups,you can control access on the entire CMDB, each CMDB class (read-only or read/write), and each page (tab) within a ConfigItem.

Additionally, the free feature add-on ConfigItemMultitenancy allows permissions to be controlled at the individual ConfigItem level.

Example: Two separate IT departments use the same CMDB. Both want to use a class called “Computer” but do not want to share their information with each other.

The standard solution would be to create two separate classes – Computer IT Dept. 1 and Computer IT Dept. 2. Using groups, access to those classes can be clearly separated, and each department only sees their own class and ConfigItems.

Alternative solution with ConfigItemMultitenancy: Create one shared class “Computer”, install the add-on ConfigItemMultitenancy, and assign the relevant group directly to each ConfigItem when it is created. This results in one shared class, while users can still only see their own ConfigItems.

-> OTOBO Administrators

OTODO administrators always have the ability to access all tenants.

The“Light-Admin” feature introduces limited multi-tenancy capabilities within the administration area. For example, it restricts administrative functions such as Templates and Templates <-> Queues to the administrator’s own permission scope.

However, administrators with full rights can always access the data of all tenants.

Hallo Grit, hallo zusammen,

worum handelt es sich bei dem Feature “Light-Admin” ?
Konnte im Forum und Web bei einer kurzen Suche nichts dazu finden.

Viele Grüße

Wolfgang