Interdire suppression d'une PJ - texte riche

[aurely]

Bonjour

Je n'y connais rien en dvpt lotus ; mais on m'a demandé dans notre base communication d'interdire la suppression de piece jointe, un certain nombre d'utilisateur éditeur peuvent etre amené a créer un document en insérant un PJ mais nous ne voulons pas qu'il puisse supprimer la PJ, un fois le document créer.
Par default les 3/4 des utilisateurs sont en lecture donc il ne peuvent rien faire mais les editeurs peuvent supprimer le contenu du champs qui est un texte riche

merci

[Michael DELIQUE]

salut

le plus simple tu colle ton champ rich text dans une section as acces controlé et hop pour la section tu ne donne les droit qu'a un role ou un groupe

[aurely]

Dsl mais c kopi as access

[Michael DELIQUE]

oups tapé trop vite

une section à accès controlé !

[oguruma]

Dsl mais c kopi as access

Juste une remarque : ici on ne s'exprime pas en SMS sauf de rares exceptions et les smiley - Merci -

[oguruma]

je pense tout simplement qu'il faut revoir la sécurité de l'application, étudier une nouvelle version de la LCA, sans doute réécrire le formulaire, mettre des champs Lecteurs et Auteurs, définir des rôles autorisant certaines action ; comme cela a été dit une section à accès contrôlé qui entraînera certainement une refonte de la sécurité.
Il faut savoir dès que l'utilisateur aura le document en modification il pourra supprimer la pièce jointe sauf si celle-ci est protégée par un élément de Design extérieur (cf. Section)

[oguruma]

un petit complément de solution mais il va falloir coder et s'aventurer dans le traitement des champs RT qui ne sont pas simples à gérer pour des développeur LS débutants (voir notre doc en ligne sur le sujet)

Le masque devra comporter deux champs RT
- un pour le contenu
- un pour les pj
celui pour les pj sera placé dans un sous-masque (deux sous masques en fait)
- un sous masque autorisant la suppression de la pj : le champ sera donc en modification
- un sous masque interdisant la suppression de la pj : le champ sera mis en lecture (champ calculé)

Au moment de la sauvegarde du document (en création et maj) on veillera à ce que aucune pj ne soit dans le RT1 - si tle est le cas le document ne sera pas enregistré et affichage d'un message d'erreur
Il faudra certainement placer du code dans l'événement QuerySave et peut-être dans le PostSave

Le masque appelera le sous masque de manière calculée en fonction d'un rôle attribué l'utilisateur, exemple SUPP_PJ
Il faudra par conséquent revoir la LCA de la base

Pour conclure, il faudra aussi développer un agent de conversion de documents afin de passer tous les pièces jointes du champ RT actuel dans le RT réservé aux PJ

Bien entendu pour vérifier cela :
- faire une copie de la base prod
- à partir de cette copie faire un nouveau modèle
- développer les nouveaux composants
- tester les nouvelles fonctionnalités sur la base copie
- et terminer par une recette grandeur nature

[billbock]

tout cela n'est valable qu'en client lourd biensur!!!

[oguruma]

oui il n'y aucun doute...
et il faudre aussi remonter ses manche pour celui qui sera charger de cela sauf si quelqu'un voit une meilleure solution
une bonne sauvegarde de la base avant migration est vivement recommandée
avant opération de migration aussi pour travailler une base bien propre faire un fixup -L "ne mange pas de pain"
après l'opération de migration je conseillerai aussi une suppression des index par compact -D puis demandér leur recontruction avec le client et laisser faire le serveur
et également refaire un updall -r -b pour une reconstruction des index de vue....
attention si la base est lourde faire cela serveur arrêter....
(l'updall est confort bien entendu) mais on on repart sur du neuf