Champs Lecteur et Auteur

[Michael DELIQUE]

re $Readers ou $Authors sont dans le doc

pour @now = @now hormis ralentir affreusement le refresh de ta vue... ça fera pas grand chose vue que c'est toujours vrai.

oui oui, pas de souci avec plusieur champs auteurs/lecteurs tu as vérifié que ton groupe avait acces dans la LCA ?

[stloje]

Deux questions : il est bien possible d'avoir deux champs Lecteurs et deux champs Auteurs dans un même masque ? D'ailleurs, lorsque je remplis ces deux champs par des noms d'utilisateurs, cela marche très bien...

Oui, c'est possible et même préférable. il faut toujours garder un champ dédié de type auteur pour le groupe "LocalDomainServers" lorsqu'on utilise des champs de type lecteur.

A faire attention : par programmation Lotus Script, on peut créer plusieurs champs ayant le même nom, mais pas les mêmes valeurs.

[jeulin]

Comment affiche-t-on $Readers ou $Authors ?

J'ai tout rebalayé ; j'ai même changé de groupe. Le nouveau contient bien le nom de l'utilisateur ; il est bien "Multi-purpose ; il est bien référencé dans la LCD ; il s'inscrit bien dans le champ de type Readers à la création du document, champ qui lui-même est "multi-valué" (mange pas de pain !)

Le groupe a-t-il un nom long (CN=... / OU =... ) ou doit-il être exprimé sous son nom court ?

Merci déjà pour vos réponses très rapides !

[Michael DELIQUE]

que ce soit les nom d'utilisateur ou de groupe toujours lonf : canonique

pour les champ $reader et $author tu peux les voir via les propriétés du document dans la liste des champs

[jeulin]

Et bien semble-t-il que non car, revenu au nom court pour ce groupe, cela marche !!! ?!?

Par contre, je n'ai pas de champs "système" $reader et $author dans les propriétés du document ?!? Bon, je suis en 6.5 ; serait-ce lié à cela ?!?

En tout cas, merci pour toutes vos réponses. Je viens rarement sur ce forum mais je ne suis jamais déçu !!! La qualité, la réactivité et le sens de l'entraide sont vraiment au rendez-vous ! Cela fait du bien dans ce monde de brutes !

[Michael DELIQUE]

re,

le nom court fonctionne sans problème mais ça pose quelque souci si :

- tu as plusieurs organisations et des homonyme dedans.
- si tu dois renommer ou changer d'organisation un utilisateur.
- les traitements en back-end ne fonctionnent qu'avec les noms canonique

j'ai plus d'une fois été confronté aux 3 cas. c'est pour moi largement suffisant pour que le nom canonique soit TOUJOURS utilisé

[jeulin]

Ah je suis tout à fait d'accord ; je suis également partisan des noms longs, fondement de l'architecture Notes.

Mais je constate que cela ne marche pas pour mes noms de groupe alors que cela fonctionne avec leurs noms courts... (j'ai refait un "aller-et-retour"..).

Peut-être est-ce que j'associe ces noms courts de groupe à des noms longs inexacts ?!? J'ai repris la même syntaxe que pour moi, même OU et même O. Serait-ce une stupidité ?

[Michael DELIQUE]

regarde le nom long du groupe sur sa fiche dans le names.

ne jamais recréé un nom long comme ça, beaucoup trop dangereux et source d'erreurs, aller plustot a la source rechercher le nom au moins là on est certain de pas se louper

[stloje]

Michael,

Les champs $Reader et $Author, c'est pas les champs qui correspondent aux propriétés d'accès au masque en tant que lecteur et auteur?

[Michael DELIQUE]

normalement oui, mais je l'ai ai déjà vu renseigné avec tout un tas de truc dedans

[roubech]

les groupes n'ont pas forcément de "nom long"

[jeulin]

C'est exact, ces groupes ne semblent pas avoir (?) de noms longs... Bon, tout marche très bien depuis plusieurs semaines ! Merci !