Lotus Notes / Domino 10 > ND10: Administration & Userprobleme

INFO: Bug in Feldvalidierung in Gruppenname im 10er Template

(1/1)

Tode:
Manchmal frage ich mich, ob die "großen" an die Systemtemplates nur Azubis ran lassen...

Das 10er pubnames- template lässt das Anlegen / Speichern von Gruppen NICHT zu, wenn der Vorname oder Nachname irgendeines Benutzers dem Gruppennamen entspricht.

Heisst Dein Mitarbeiter also "Hans Hamburg" und Du willst eine Gruppe mit dem namen "Hamburg" anlegen, dann kommt die Meldung, dass Gruppennamen nicht Benutzernamen entsprechen dürfen.

Im 9er Template war das in Ordnung, ist aber fehlgeschlagen, wenn ListName ein MultiValue war, im 11er Template haben sie es wieder korrigiert.

Nur falls mal wer drüber stolpert, dass man plötzlich Gruppen nach einem Template- Update auf 10 nicht mehr speichern kann mit der Meldung "A User name already exists by this name.  Group names are not allowed to match exactly a User name.  Please choose a different Group name."

eknori (retired):
ist in 11.0.1 auch so.

Allerdings funktioniert Hamburg und Hans Hamburg, nicht aber Hans Hamburg Hans Hamburg

oliK:
Mich stört eher, dass man es bis heute nicht hinbekommen hat, ein berechnetes Feld einzubauen, das die Mitgliederliste einer Gruppe sortiert im Stil "Nachname, Vorname" zusätzlich anzeigt.

Peter Klett:

--- Zitat von: oliK am 07.04.20 - 15:33:49 ---Mich stört eher, dass man es bis heute nicht hinbekommen hat, ein berechnetes Feld einzubauen, das die Mitgliederliste einer Gruppe sortiert im Stil "Nachname, Vorname" zusätzlich anzeigt.

--- Ende Zitat ---
Das liegt vermutlich daran, dass man aus dem Usernamen nicht Vor- und Nachnamen ermitteln kann, ohne über den Usernamen erst das Personendokument zu suchen. Und andere Länder haben da vielleicht auch unterschiedliche Prioritäten, so wird das schwierig allgemeingültig. Bei uns würde eine Sortierung nach Nachnamen wohl eher Verwunderung auslösen, denn man kennt sich eigentlich nur anhand des Vornamen, Nachname ist weniger wichtig.

Hast Du nicht neulich erst geschrieben, dass man die Maildatenbank einfach anpassen kann? Kann man mit dem Adressbuch ja auch. Baue Dir doch eine Aktion, die das Feld sortiert.

Übrigens: Zusätzliches berechnetes Feld bedeutet Halbierung des möglichen Feldinhaltes. Knallt das Dokument heute mit 32 kB in der Mitgliederliste, hättest Du dann zwei Felder zu 16 kB, die zum Aus führen. Es müsste dann Berechnet zur Anzeige sein, und es würde immer beim Öffnen rechnen, lange Liste = lange Laufzeit. Der Ruf nach einem INI-Eintrag, mit dem man das wieder abschalten kann, käme sicherlich schnell hinterher ...

Tode:
Wen es genauer interessiert:
Ich habe den relevanten Code mal rausgepflückt (leicht verkürzt):

9er Code:

--- Code: ---usrname:=@DbLookup("":"NoCache";server:db;"($Users)";ListName;3);
tmpusrname:=@If(@IsError(usrname);"";usrname);

@If( @LowerCase(tmpusrname) = @LowerCase(ListName); L_ERR_MSG3; "");
--- Ende Code ---

==> Ein Lookup mit allen Werten aus ListName, wenn nicht @IsError, dann Vergleich der Ergebnisses (Spalte 3 = FullName des Users), wenn identisch, dann Fehler.

10er Code:

--- Code: ---tmpusrname := @Transform(ListName; "_x"; @If(@DbLookup("":"NoCache";""; "($Users)"; _x; 3; [FailSilent]) = ""; @Nothing; _x));
@If(tmpusrname != ""; L_ERR_MSG3; "");
--- Ende Code ---

==> Pro Wert in ListName ein Lookup mit FAILSILENT- Parameter, aber der Return- Wert aus Spalte 3 wird gar nicht berücksichtigt, sondern direkt der Lookup- Wert in die Variable geschrieben... dieser Wert wird dann mit "" verglichen. Gibt es also IRGENDEINEN Match (mit einem Vornamen, Nachnamen), dann kommt der Fehler...  >:D

11er Code:

--- Code: ---tmpusrname := @Transform(@ThisValue; "_x"; @If(@LowerCase(@DbLookup("":"NoCache";""; "($Users)"; _x; 3; [FailSilent])) = @LowerCase(_x); _x; @Nothing));
sMsg := @If(tmpusrname != ""; L_ERR_MSG3; "");
--- Ende Code ---

==> Pro Wert in ListName ein Lookup mit Failsilent, das Ergebnis wird direkt mit dem Lookup- Wert verglichen, und nur wenn sie identisch sind, wird etwas zurückgeliefert. Dann kommt die Meldung...

Damit funktioniert der 11er Code so, wie der 9er gedacht war und eben auch für mehrere ListNames, was der 9er nicht konnte (wenn nicht alle ListNames gematcht haben).

Nur eine Nebenbemerkung: Im 9er Code kam die Definition der Variablen "server" und "db" erst in der Zeile NACH dem Lookup, und der Code hat nur zufälligerweise deshalb funktioniert, weil "" : "" im DBLookup identisch ist mit @Subset(@DbName;1) : @Subset(@DbName;-1).

Navigation

[0] Themen-Index