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,
- 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 
) 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.
- 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!“ 
