+49 (0)7531 906010| service@combit.net

Probleme der Rechtevergabe

Hallo allerseits,

folgende zwei Probleme:

  1. Wenn ich für einen Benutzer spezielle Feldrechte einstelle, so funktionieren diese nur für die Karteikartenansicht. Sobald der User in die Listenansicht wechselt, kann er wieder alle Felder sehen und diese dort auch verändern, obwohl ihm dies gemäß den Rechten nicht gestattet sein sollte.
    Auch wenn ich eine Bedingung für Bearbeitbarkeit setze gilt diese nicht in der Listenansicht und wird völlig ignoriert.

  2. Wir haben zwei cRM Projekte mit den selben Benutzern. Wenn ich in einem Projekt Administrator Rechte vergebe, so gelten diese auch für das andere Projekt, auch wenn ich das gar nicht will. Dabei sind beide Projekte unabhängig voneinander, verschiedene Datenbanken etc.

Beide Punkte machen für mich keinen Sinn und machen die äußerst wichtigen Einstellungen der Rechtevergabe im cRM in vielen Teilen unbrauchbar - falls das tatsächlich so sein sollte.

Kann dies so jemand bestätigen, mache ich was falsch oder gibt es Abhilfe?

Ich bedanke mich mal wieder im Voraus :slight_smile:

Mit freundlichen Grüßen
Florian

Hi Florian,

  1. Wenn ich für einen Benutzer spezielle Feldrechte einstelle, so
    funktionieren diese nur für die Karteikartenansicht. Sobald der User
    in die Listenansicht wechselt, kann er wieder alle Felder sehen und
    diese dort auch verändern, obwohl ihm dies gemäß den Rechten nicht
    gestattet sein sollte. Auch wenn ich eine Bedingung für
    Bearbeitbarkeit setze gilt diese nicht in der Listenansicht und wird
    völlig ignoriert.

Das sind keine Feld-RECHTE, die du benutzt, du „missbrauchst“ (nicht
böse gemeint :slight_smile: ) die Darstellungs- und Bearbeitbarkeitsbedingungen der
Eingabemaske als „Rechte“-Verwaltung. Und da das Dinge in der
Eingabemakse sind, greifen sie nicht beim direkten Editieren in der
Übersichtsliste (Eingabemaske und Übersichtsliste sind zwei verschiedene
Paar Schuhe). Siehe auch cRM Handbuch Kapitel 3.4 „Datensatz bearbeiten“.

Schau dir mal die „echten“ Feldrechte im Handbuch in Kapitel 17.2 an.

Alternativ kannst du den Benutzern das Recht nehmen, direkt in der
Übersichtsliste Datensätze überhaupt ändern zu dürfen.

  1. Wir haben zwei cRM Projekte mit den selben Benutzern. Wenn ich in
    einem Projekt Administrator Rechte vergebe, so gelten diese auch für
    das andere Projekt, auch wenn ich das gar nicht will. Dabei sind
    beide Projekte unabhängig voneinander, verschiedene Datenbanken etc.

Jedes Projekt hat eine eindeutige ID (die GUID, die du unter
‚Konfiguration > Projekt > Eigenschaften‘ sehen kannst). Diese ist auch
der eindeutige Schlüssel für die Rechte, Konfigurationen etc. Ich bin
z.B. froh dass das so ist, weil ich so verschiedene Projekte-Dateien
konfigurations- und rechtetechnisch genau parallel fahren lassen kann
(Stichwort: Parallele Mehrsprachigkeit!).

Wenn du für deinen Fall aber jetzt halt das zweite Projekt vom ersten
nachträglich komplett „entkoppeln“ möchtest, dann musst du die .cRM
Datei (auf eigenes Risiko ) mit Notepad öffnen und an der Stelle

ec6a364392bf4b6f922c6a7f966e554a

eine andere ID eintragen. Die kannst du dir vorher im cRM per ‚Projekt >
Neu‘ kurz neu generieren lassen (über ‚Konfiguration > Projekt >
Eigenschaften‘ per Kontextmenue in die Zwischenablage kopieren und die
Projekt.-Datei dann einfach nicht speichern) und diese GUID dann nehmen…

Gruß

Alex.


CRM-Leitsatz: „Das einzige, was wirklich stört, ist der Kunde!“ :wink:

Hi Alex,

danke für deine Antwort, hat mir sehr weitergeholfen da ich zum einen mehr Verständnis für die Punkte habe und zum anderen Punkt eins komplett lösen konnte.

Bei meinem zweiten Problem allerdings komme ich noch immer nicht weiter. Wir haben vor einiger Zeit unser cRM Projekt kopiert und diese Kopie zu Testzwecken und zum Entwickeln neuer Module laufen lassen. In diesem Testprojekt sollen natürlich viele Leute testen können und benötigen somit Administratoren Rechte. In unserem „richtigen“ Projekt dagegen soll dann nur einer die neuen, getesteten Module einbauen könnne, sprich es soll nur einen einzigen Administrator geben.
Allerdings sind selbst im „richtigen“ Projekt alle Leute Administratoren, die es auch im Testprojekt sind.

Die GUID war bei beiden Projekten gleich (klar, war ja auch eine Projekt-Kopie), jetzt habe ich diese GUID vom Testprojekt geändert (habe deine GUID die du geposted hast eingegeben) aber geändert hat sich an den Rechten nichts. Wenn ich in einem Projekt etwas an den Gruppenzugehörigkeiten ändere, passiert das gleiche auch im anderen Projekt, leider.

Nur mal der Interesse halber - was genau wird denn durch diese GUID vorgegeben bzw. gespeichert? Wenn ich ein neues Projekt anlege welches die gleichen „Einstellungen“ (was da auch dazugehören mag) haben soll wie ein bereits vorhandenes, dann muss ich beim Anlegen die GUID des bereits vorhandenen Projekts eingeben, richtig? Normalerweiße wird aber eine neue GUID generiert, nur weil ich jetzt unser Projekt kopiert habe, habe ich 2x die gleiche GUID, oder?

Gruß
Flo

Hi Florian,

  1. Wenn ich für einen Benutzer spezielle Feldrechte einstelle, so
    funktionieren diese nur für die Karteikartenansicht. Sobald der User
    in die Listenansicht wechselt, kann er wieder alle Felder sehen und
    diese dort auch verändern, obwohl ihm dies gemäß den Rechten nicht
    gestattet sein sollte. Auch wenn ich eine Bedingung für
    Bearbeitbarkeit setze gilt diese nicht in der Listenansicht und wird
    völlig ignoriert.

Das sind keine Feld-RECHTE, die du benutzt, du „missbrauchst“ (nicht
böse gemeint :slight_smile: ) die Darstellungs- und Bearbeitbarkeitsbedingungen der
Eingabemaske als „Rechte“-Verwaltung. Und da das Dinge in der
Eingabemakse sind, greifen sie nicht beim direkten Editieren in der
Übersichtsliste (Eingabemaske und Übersichtsliste sind zwei verschiedene
Paar Schuhe). Siehe auch cRM Handbuch Kapitel 3.4 „Datensatz bearbeiten“.

Schau dir mal die „echten“ Feldrechte im Handbuch in Kapitel 17.2 an.

Alternativ kannst du den Benutzern das Recht nehmen, direkt in der
Übersichtsliste Datensätze überhaupt ändern zu dürfen.

  1. Wir haben zwei cRM Projekte mit den selben Benutzern. Wenn ich in
    einem Projekt Administrator Rechte vergebe, so gelten diese auch für
    das andere Projekt, auch wenn ich das gar nicht will. Dabei sind
    beide Projekte unabhängig voneinander, verschiedene Datenbanken etc.

Jedes Projekt hat eine eindeutige ID (die GUID, die du unter
‚Konfiguration > Projekt > Eigenschaften‘ sehen kannst). Diese ist auch
der eindeutige Schlüssel für die Rechte, Konfigurationen etc. Ich bin
z.B. froh dass das so ist, weil ich so verschiedene Projekte-Dateien
konfigurations- und rechtetechnisch genau parallel fahren lassen kann
(Stichwort: Parallele Mehrsprachigkeit!).

Wenn du für deinen Fall aber jetzt halt das zweite Projekt vom ersten
nachträglich komplett „entkoppeln“ möchtest, dann musst du die .cRM
Datei (auf eigenes Risiko ) mit Notepad öffnen und an der Stelle

ec6a364392bf4b6f922c6a7f966e554a

eine andere ID eintragen. Die kannst du dir vorher im cRM per ‚Projekt >
Neu‘ kurz neu generieren lassen (über ‚Konfiguration > Projekt >
Eigenschaften‘ per Kontextmenue in die Zwischenablage kopieren und die
Projekt.-Datei dann einfach nicht speichern) und diese GUID dann nehmen…

Gruß

Alex.


CRM-Leitsatz: „Das einzige, was wirklich stört, ist der Kunde!“ :wink:

Hi Flo,

Die GUID war bei beiden Projekten gleich (klar, war ja auch eine
Projekt-Kopie), jetzt habe ich diese GUID vom Testprojekt geändert
(habe deine GUID die du geposted hast eingegeben) aber geändert hat
sich an den Rechten nichts. Wenn ich in einem Projekt etwas an den
Gruppenzugehörigkeiten ändere, passiert das gleiche auch im anderen
Projekt, leider.

Die Benutzerverwaltung und somit auch die Gruppenzugehörigkeiten sind
global innerhalb des gesamten cRM-Systems. D.h. wenn du einem User die
Rolle eines Administrators gibst (Gruppenzugehörigkeit zu
‚Administratoren‘), dann gilt das immer und überall für alle Projekte.
Und Administratoren dürfen überall alles. :slight_smile:

Du musst also eine Gruppe definieren, die „DarfAllesInProjektXYZ“ heißt.
Dieser Gruppe gibst du auf der Lasche „Projekt“, „Ansichten“,
„Datensätze“ und „Felder“ volle Rechte für alles und alle Ansichten.
Dabei musst du natürlich als ‚Administrator‘ das Projekt XYZ auch gerade
geladen haben.

Dann nimmst du die betreffenden Benutzer in diese Gruppe auf und wirfst
sie aus der Gruppe der ‚Administratoren‘ raus… Das war’s.

Falls diese Benutzer aber wirklich alles (also auch die
Projekt-übergreifenden Rechte auf der Seite „Allgemein“) dürfen sollen,
aber nur für das von dir genannte „Test“-Szenario, dann brauchst du für
sie und das Szenario eine separate Installation (mit einer entsprechend
separaten zusätzlichen cRM-Lizenz), um das von deiner
Produktiv-Installation zu trennen. Anders geht es nicht, ich finde das
Grundkonzept aber auch irgendwie nachvollziehbar. Test ist Test und
Produktivbetrieb ist halt Produktivbetrieb.

Nur mal der Interesse halber - was genau wird denn durch diese GUID
vorgegeben bzw. gespeichert? Wenn ich ein neues Projekt anlege
welches die gleichen „Einstellungen“ (was da auch dazugehören mag)
haben soll wie ein bereits vorhandenes, dann muss ich beim Anlegen
die GUID des bereits vorhandenen Projekts eingeben, richtig?
Normalerweiße wird aber eine neue GUID generiert, nur weil ich jetzt
unser Projekt kopiert habe, habe ich 2x die gleiche GUID, oder?

Ja, so ist es m.W.n. ->Alle Rechte ab der Lasche „Projekte“ nach rechts
sind Projekt(-ID!)-spezifisch.

Gruß

Alex.


CRM-Leitsatz: „Das einzige, was wirklich stört, ist der Kunde!“ :wink:

© combit GmbH