pb avec les options de réservations

Bonjour,
j'ai également le multisite activé dans ma base...
je pense que le bug vient de la base de Joshua. Est-elle grosse ? Je demande cela pour savoir si son analyse est réaliste.
Cordialement,
YN

Bon, j'ai regardé d’où cela vient sur la version 4.0.3 (en cours de dev).
Dans view_entry.php à la ligne 513 nous ne remplissons pas les conditions pour modifier. S'est l'appel de la fonction getWritable() qui retourne 0 (pas les droits en modification).

Dans la fonction suivante  on a authGetUserLevel() qui ne passe pas. Il semble que dans la fonction il faut un >= au lieu de >
function getWritable($beneficiaire, $user, $id){
$id_room = grr_sql_query1("SELECT room_id FROM ".TABLE_PREFIX."_entry WHERE id='".protect_data_sql($id)."'");
        // Modifications permises si l'utilisateur a les droits suffisants
    if (Settings::get("allow_gestionnaire_modify_del") == 0)
        $temp = 3; // on passe ici 
  else        $temp = 2;
     // Dans notre cas authGetUserLevel($user,$id_room) = 3    // $ temp = 3
    if (authGetUserLevel($user,$id_room) >= $temp)
        return 1;

Yan, pourrais tu contrôler mes dires ? La fonction étant critique sur la gestion de GRR, je préfère avoir un deuxième avis.

 

Bonjour,
je regarde cela de plus près dès maintenant.
À plus,
YN

Le problème ne se situe pas à ce niveau-là. détermine si "Un gestionnaire d'une ressource ne peut pas supprimer ou modifier les réservations effectuées sur la ressource, sauf celles dont il est l'auteur."
Sinon, cette valeur est 0, il faut être administrateur (de domaine, niveau 4; de site, niveau 5 ou général, niveau 6).
Si oui, cette valeur est 1, il faut être gestionnaire de la ressource (niveau 3).
Le test strict est donc correct.
Ensuite, sur la version 3.5.0, fichier functions.inc.php du $Date: 2022-09-13 11:39$, lignes 3277 et suivantes, on étudie si l'utilisateur connecté est bénéficiaire ou créateur de la réservation et s'il a le droit de modifier une réservation... je pense que le problème vient de là.
Page de gestion d'une ressource, la case "Ne pas permettre aux utilisateurs (hormis les gestionnaires et les administrateurs) de modifier ou de supprimer leurs propres réservations." est-elle cochée ?
J'ai l'impression d'avoir oublié le cas de figure où l'utilisateur est gestionnaire de la ressource...
À confirmer

Bonjour à vous deux,
Merci pour vos retours,
effectivement l'utilisateur est gestionnaire de la ressource
après vérification l'option suivante n'est pas cochée :
Ne pas permettre aux utilisateurs (hormis les gestionnaires et les administrateurs) de modifier ou de supprimer leurs propres réservations.

bien cordialement,

Pouvez-vous vérifier le champ dont_allow_modify dans la base de données, table grr_room, pour la ressource concernée ? Car je reproduis le dysfonctionnement que vous avez décrit uniquement dans le cas où c'est "y".

Pour avoir un fonctionnement conforme sur ma base de tests, j'ai fait cette modification github.com/JeromeDevome/GRR/commit/51b19...c65390991755ad15e018 en espérant que ça marchera pour vous aussi.

Bonjour,

pour la ressource concernée la valeur est définie à "n" pour le champ
dont_allow_modify

cdlt

Bonjour,
avez-vous testé le fichier modifié ?
Votre gestionnaire est-il bénéficiaire ou créateur de la réservation ?
La ressource est-elle à accès restreint ?
Cordialement,
YN
P.S.: le fichier à tester est conçu pour la version 3.5.0. Si vous avez changé de version, merci de le faire savoir. Je porterai la modification.

Bonjour,
actuellement
je n'ai pas pu tester le fichier modifié,
le gestionnaire est créateur
effectivement la ressource est en accès restreint.
le plus simple est peut être de mettre GRR à jour ?
vous parliez d'une nouvelle version dans l'échange.

Cordialement,