Assistenz kann keine Kontakte anlegen?

[schroederk]

Hallound guten Morgen,

eine Assistentin der Geschäftsführung hat vom Geschäftsführer nur die Berechtigung bekommen, den Kalender und die Kontakte zu pflegen.
Den Kalender kann sie pflegen, aber die Kontakte nicht. Bei Doppelklick auf einen Kontakt erscheint die Fehlermeldung, dass sie nicht berechtigt ist.
Die Option einen neuen Kontakt anzulegen, ist erst gar nicht sichtbar.
Bei Prüfung ist zunächst aufgefallen, dass es bei allen Assistenzen und bei allen 11er Datenbanken auftritt, mit Ausnahme von 2 Datenbanken.
Hier gibt es in der ACL-Liste die Rolle [AccessContacts], bei den anderen nicht.
Also habe ich diverse Optionen versucht: Fixup, Updall hat nichts gebracht. Designupdate auch nicht. Auch nicht Schablonenwechsel zur Standard 11er Schablone (wir haben aber nur geringe Anpassungen) oder zu einem leeren Template und zurück. Ebenso eine lokale Replik.
Wenn ich aber lokal eine neue DB erstelle, dann ist die Rolle vorhanden. 
Auf dem Template selber sind die Rollen (auch) nicht zu sehen.

Wieso also fehlt die Rolle bei (fast) allen. Wieso ist sie bei den beiden dabei? Und wie bekomme ich diese Rolle hinzugefügt (eventuell über den Designer)?

[eknori]

In der Tat, die Rollen sind nicht in der ACL des Templates. Ist mir noch nie aufgefallen. Wieder was gelernt.

Ich habe mir das design der MailDb angesehen. Die Rolle AccessContacts wird irgendwann einmal per Code hinzugefügt.

Code

If userLevel =  6  Then 'owner (or administrator) has manager access; update ACL with new role, etc. 
		If Not OwnerHasRole Then				
		'if the owner already has the role, we can safely assume this process has been run already; no need to repeat it    			
			
			'add role to db if not present
			If Not dbhasrole Then
				Call dbACL.AddRole( "AccessContacts" ) 'DNT
			End If

Dumm nur, dass dazu Managerrechte benötigt werden.

Du kannst die Rolle aber als Admin auch direkt in die ACL der Datenbanken eintragen.

Das kannst Du gleich in einem Rutsch für alle Datenbanken machen.

Ob das

Code

If userLevel =  6  Then 'owner (or administrator) has manager access; update ACL with new role, etc. 

richtig ist, wage ich mal zu bezweifeln.
der Owner hat in der Regel Editor Access und der Admin sollte die DB gar nicht öffnen.

[eknori]

Vergiss es, habe es gerade einmal bei mir probiert. Funktioniert einwandfrei

[schroederk]

Vielen Dank für die Antwort, aber so richtig verstanden habe ich das noch nicht.
Insbesondere nicht, warum die Rolle nur bei Manager-Rechten hinzugefügt wird.  

Wie kann ich als Admin die Rolle bei allen hinzufügen? Ich habe mit dem Admin-Client mit vollen Adminrechten getestet und es wurde keine Rolle angelegt.
Oder meinst Du einfach die Rolle von Hand hinzufügen über Zugriffskontrolle verwalten -> Reiter Rollen -> Hinzufügen?

[schroederk]

Ich habe mich testweise mal als Manager auf einer DB eingetragen und die Zugriffe eingetragen. Hat auch keinen Unterschied gemacht. Die Rolle wurde nicht angelegt.

[eknori]

Oder meinst Du einfach die Rolle von Hand hinzufügen über Zugriffskontrolle verwalten -> Reiter Rollen -> Hinzufügen?

Genau das

[schroederk]

Prima, das hat geklappt. Nochmals vielen Dank. Somit kann ich mich jetzt behelfen und der Support darf prüfen, warum das so ist 

[eknori]

Habs noch einmal getestet. Es kommt drauf an, wie man wann und wo klickt. Kann das "nicht Hinzufügen" reproduzieren, erkenne aber noch kein wirkliches Muster.

[schroederk]

Vielen Dank, dass Du dir solche Mühe machst. Augenscheinlich muss ich es schon zweimal "richtig" gemacht haben, denn bei 2 Datenbanken war die Rolle bereits enthalten.

[CarstenH]

Wie eknori schon schrieb ist das Default-Recht für den Owner ja Editor. In diesem Fall sollten alle für die Delegierung nötigen ACL-Änderungen vom AdminP vorgenommen werden, dort würde ich demzufolge auch zuerst nach der Ursache suchen: Delegation-Request und die dazu gehörende Bestätigung suchen, ACL Protokoll prüfen, Replikation und Rechte checken falls mehrere Server involviert sind usw.

Die in den Scripten enthaltenen direkten ACL Modifikationen sind m.E. eher aus Kompatibilitätsgründen (früher gingen einige Einstellungen nur mit Designer- oder Managerrechten) und für die wenigen Ausnahmen mit Manager-Rechten drin.

Unabhängig davon mal die Frage: Hat sich hier mit V11 seit letztem Jahr (ging da noch um das gleiche Feature in V10) irgendwas getan?
Falls nicht wird die Rolle nur für ein Hide-When der Aktion beim Anlegen neuer Kontakte wirksam, auf vorhandene Kontakte dürfte sie bei lediglich öffentlichem Zugriff gar keine Auswirkungen haben da die Autorenfelder weder befüllt sein dürften noch Wirkung zeigen würden (erst ab Leser aufwärts - was bei nur-Kalender-Zugriff nicht der Fall ist).
Siehe: https://atnotes.de/index.php/topic,62632.0.html

Carsten

[schroederk]

Habs noch einmal getestet. Es kommt drauf an, wie man wann und wo klickt. Kann das "nicht Hinzufügen" reproduzieren, erkenne aber noch kein wirkliches Muster.

Möglicherweise liegt es daran, dass Kontakte synchronisieren aktiviert und mindestens einmal gelaufen sein muss?

Hab den folgenden Hinweis gefunden: https://help.hcltechsw.com/notes/11.0.1/client/con_access_t.html?hl=contacts%2Caccess%2Cdelegation

Da ich bei allen Usern schon manuell die Rolle hinzugefügt habe, kann ich es im Moment schlecht testen. Sobald der nächte Mitarbeiter auf 11 migriert wurde, werde ich das nochmal prüfen.

[mb974]

Hallo,

ich hatte gerade ein interressantes Phänomen zu dem Thema:

Unsere Mailfiles liegen auf einem Cluster und die Rolle [AccessContacts] selbst wurde durch den AdminP angelegt und den entsprechenden Benutzern zugewiesen. Soweit so gut, aber leider haben weder die LocalDomainServers noch der AdminServer die Rolle bekommen, so dass neue oder geänderte Kontakte nicht mehr repliziert wurden.

Daraufgekommen sind wir dadurch, das die Assistenz auf der einen Replik gearbeitet hat, wo der Eintrag sichtbar war und ihr Chef auf der anderen, dort hat er gefehlt.

Nachdem die Server die Rolle hatten, war der Eintrag nach der nächsten Replizierung auf allen Repliken sichtbar.