Accès d'un utilisateur à un domaine restreint

Sur le point 6, vous voulez dire que l'autre administrateur a fait une réservation au nom de votre utilisateur problématique et qu'alors ça bloque ?
Je viens de reproduire votre scénario, et mon utilisateur sans droits peut encore réserver. Le contenu des tables grr_entry et grr_entry_moderate est distinct : la réservation directe effectuée par l'administrateur n'y est pas et celle faite par l'utilisateur y apparaît lorsqu'elle a été validée.

Non, sur le point 6, un autre administrateur a fait une réservation dans un autre domaine pour un autre utilisateur. Et ça a bloqué à ce moment, mais c'est peut être un hasard.
D'après ce que j'ai compris, la table _entry_moderate n'est pas utilisée pour autoriser ou pas une réservation, elle ne fait que mémoriser les opérations de modération. Et le comptage des réservations, ce qui fait foirer mon utilisateur sur un domaine particulier, ne se fait que dans _entry,

Je vais re-effacer les lignes de réservation, et les remettre une à une, tranquillement, en vérifiant à chaque fois, ce qui se passe, avant validation par l'administrateur et après validation par l'administrateur.

Bon, j'ai exploré d'autres pistes, et je me suis dit que, peut être, ça ne venait pas de l'utilisateur en tant que tel, mais du fait que cet utilisateur était actif et utilisait beaucoup des ressources de ce domaine, ce que ne faisaient pas d'autres utilisateurs.

J'ai alors regardé les ressources de ce domaine. et le domaine lui-même.
La fenêtre de paramétrage du domaine avait l'air très normale; je suis allé voir dans la table _area., en comparant les colonnes à la description de la documentation.
J'y ai trouvé une colonne max_booking, qui est documentée, mais qui, sauf erreur de ma part, ne peut pas être paramètrée dans la fenêtre "modifier le domaine".
Et pour mon domaine à problèmes, la valeur n'était pas à "-1" mais à "3". J'ai remis, manuellement, dans la table, cette valeur à "-1" et ça a l'air de marcher.
Bon, c'en a l'air, nous verrons bien si ça en a la chanson.

Qu'en pensez-vous?

Bien sincèrement
JPP

Bonjour,
le champ max_booking est défini par le dernier item de la page d'édition des domaines, juste au-dessus du bouton "enregistrer"
Sur mon installation de test, je modifie cette valeur et elle est bien enregistrée en base.
À vous de vérifier que sur votre GRR l'information passe bien du formulaire à la base.
Cordialement,
YN

Bonjour

`C'est bien la page admin_edit_room.php?id_area=NUMERODUDOMAINE ? ?

Sur la version que j'ai, qui est la dernière 5.3, le libellé du dernier champ (après la configuration des créneaux) est celui de la durée de réservation maximale.

Il y a bien ensuite, un autre champ
"Nombre max. de réservations par utilisateur (-1 si pas de restriction) - Pour toutes les ressources du domaine :"
C'est certainement celui dont vous parlez, mais il n'apparait que sur 2 de mes 5 domaines, quand je les édite. Ce sont ceux qui sont en créneaux "basés sur le temps" et pas sur ceux qui sont en créneaux "intitulés pré-définis". Et, bien évidemment, il n'apparait pas sur le domaine qui a posé problème, puisqu'il est en créneaux basés sur le temps.


Bon, mon problème a l'air résolu. J'imagine que la valeur parasite est arrivée parce que j'ai saisi par erreur quand j'ai crée le domaine "créneaux sur le temps", et que, quand j'ai transformé "temps" en "prédéfini", je n'y ai plus eu accès. Et je n'avais jamais remarqué, jusqu'à maintenant, que le champ pour limiter les réservations apparaissait ou pas. Il est sans intérêt pour moi, toutes les réservations étant modérées.


Bonne journée

JPP

écrit:

Il y a bien ensuite, un autre champ
"Nombre max. de réservations par utilisateur (-1 si pas de restriction) - Pour toutes les ressources du domaine :"
C'est certainement celui dont vous parlez, mais il n'apparait que sur 2 de mes 5 domaines, quand je les édite. Et, bien évidemment, il n'apparait pas sur le domaine qui a posé problème.

Je viens de relire le code : l'affichage du champ de formulaire limitant le nombre de réservations apparaît de manière inconditionnelle. Vous devriez donc l'avoir dans tous les domaines. Avez-vous les droits d'administrateur général ? Ou seulement de site ? de domaine ?
Pour les ressources, c'est un peu différent, un gestionnaire de ressource ne voit pas ce champ, il y a seulement un message d'information si les réservations sont limitées.
Le mystère n'est pas encore élucidé...

Désolé, je n'avais pas été assez attentif. Il y a bien un bug pour les domaines définis par créneaux.
Le champ de formulaire était absent dans ce cas. Présent dans le code, mais dans une table de display:none... sans commentaire !
Je diffuse la correction de suite.
Encore toutes mes excuses pour ce couac.
Cordialement,
YN

Yan, surtout ne vous excusez pas, vous en faites assez pour qu'il soit normal que des bricoles passent à travers.

De mon côté, en tant qu'utilisateur, je n'avais jamais remarqué cette différence dans les paramètres affichés. Et si je l'avais remarquée, en voyant que ça dépendait de "créneaux en temps" ou "créneaux prédéfinis", j'aurais sans doute pensé que la limitation du nombre de réservations ne marchait que dans un cas.

Une suggestions, peut-être, serait de programmer un "vidage" de toutes les tables, excepté bien sûr les utilisateurs et les réservations. On aurait ainsi sous les yeux tous les paramètres sans être obligé d'aller à la base de données, opération qui fait toujours un peu peur à l'utilisateur lambda. Et d'avoir ainsi tous les paramètres dans une mise en page claire, ça permet de voir ce qui cloche plus rapidement.

Je dois dire, en tout cas, que après 6 mois d'utilisation, tout le monde est très content de grr. J'ai 5 domaines, une cinquantaine de ressources, donc 6 ou 7 salles utilisées tous les jours (beaucoup d'autre sont du matériel rarement utilisé), une centaine d'utilisateurs, et pas de problème.
Je passerai à la version 3.5 tranquillement pendant la pause estivale.

Merci encore pour tout, bien amicalement

JPP