Si un utilisateur n’appartient pas au groupe administrateur, il voit uniquement les enregistrements qui le concerne (ceux dont il est le responsable). Exemple ci-dessous:
Le problème, c’est que cet utilisateur doit pouvoir changer le responsable si besoin. En changeant de responsable, il ne doit plus pouvoir voir l’enregistrement car il n’en est plus responsable.
Le problème, c’est que du coup, comme il n’en a plus la visibilité, au moment où il enregistre, il obtient cette erreur ci-dessous (Thomas GERAUD change le responsable. Ce n’est plus lui, mais Florent LAUZET):
Ce comportement UI est effectivement déroutant mais semble difficile à contourner. Le plus simple est de forcer l’utilisation du formulaire et du save&close,
Idéalement, j’imagine qu’il faudrait pouvoir envoyer un warning particulier dans le postValidate qui permette de demander une confirmation avant enregistrement:
save par le user
RDG dans le postValidate: si onChange => warning de confirmation
OK / Cancel par le user
Si OK => affichage de l’erreur, avec message plus user-friendly “Vous n’avez pas les droits pour accéder à ces données”
On peut forcer/retourner un javascript ou un redirect statement (vers la liste ou quelque chose d’habilité) dans le postSave si le responsable a changé et que ce n’est plus moi-même.
Interdire de modifier le responsable via l’objet directement, et créer une Action “Changer de responsable” avec un champ de confirmation FK vers un responsable + ses champs joints et une méthode back qui fait l’update et le redirect vers un truc autorisé.
J’avoue ne pas avoir tout compris. Mais j’ai essayé de set de nouveau les droits dans le postSave() en prenant la ligne actuelle en plus dans les droits. Ce qui fait que tant que l’utilisateur ne s’est pas déconnecté de sa session, il voit toujours la ligne actuelle et donc il peut la modifier.
Il semble y avoir un défaut d’implémentation qui empêche la prise en compte correcte de la solution théorique (redirectStatement dans le postSave). On investigue et on revient vers vous dès que possible.
Solution testée
package com.simplicite.objects.Demo;
import java.util.*;
import com.simplicite.util.*;
import com.simplicite.util.tools.*;
/**
* Business object DemoSupplier
*/
public class DemoSupplier extends ObjectDB {
private static final long serialVersionUID = 1L;
@Override
public void postLoad() {
setDefaultSearchSpec(getDefaultSearchSpec() + " AND sup_name LIKE '%Computers%'");
}
@Override
public String postSave() {
if(getField("demoSupName").hasChanged())
return HTMLTool.redirectStatement(HTMLTool.getListURL(this, null));
return null;
}
}
Remarque: Souvent, à l’exception du postLoad, on a tendance tendance à surcharger la defaultSearchSpec, ce sera ainsi cumulatif si l’utilisateur modifie plusieurs Pouvoirs:
Cumulatif:
setSearchSpec(getSearchSpec()+" OR t.row_id = " + this.getRowId());
Non Cumulatif:
// on repart à chaque fois de la searchSpec
setSearchSpec(getDefaultSearchSpec()+" OR t.row_id = " + this.getRowId());
