Accès d'un utilisateur à un domaine restreint

Ah, c'était ça?

Tout était à "-1", c'est à dire, en principe, pas de restrictions.
J'ai remplacé tous les "-1" par "100" dans le général, le domaine en cause, et une ressource du domaine qui bloquait à la modification..
Et ça n'a rien changé, ni dans les affichages month, week et day, ni dans edit_entry.

Le fait que plusieurs pages PHP coincent nous laissent penser que soit c'est dans une table SQL, soit un script utilisé par toutes ces pages qui est buggy? Mais là, j'atteins mon plafond de compétence…
Dans les deux cas, grr refuse l'accès à "edit_entry.php', dans un cas en n'affichant pas la croix pour cliquer dessus, dans l'autre cas, celui de la modification, en affichant un "compt : 0"..
Il doit y avoir un script qui met les croix dans les cases libres, et qui affiche la bulle "cliquez pour effectuer une réservation", est ce que ça pourrait venir de lui?

Bonne soirée

JPP

Bonjour,;
lorsque vous tentez une modification, vous passez du planning à la page view_entry, puis edit_entry déclenche l'affichage d'une page commençant ainsi le zéro est normal lorsqu'on tente une modification, il n'y a pas création d'une nouvelle réservation, le compteur de bouge pas.
Lorsque vous affichez un planning (day, week, week_all, month, month_all2), le "+" ne s'affiche pas.
Il y a un point commun à tous ces scénarios : la fonction UserRoomMaxBooking(). Avec les données de votre base, vous pourrez peut-être comprendre ce qui fait que la fonction rend 0 pour cet utilisateur dans la ressource ou le domaine en jeu.
Cordialement,
YN

Bonjour
J'ai regardé la fonction en question, et la suivante. J'ai passé en revue la présence de mon utilisateur dans toutes les tables utilisées par ces fonctions, sans résultat. Du coup, j'ai cherché mon utilisateur dans l'ensemble des tables, et je n'ai rien trouvé d'anormal.

Ayant déjà enlevé la restriction du domaine, puis remis la restriction, sans effet, ce ne peut pas être lié aux droit sur le domaine, j'imagine. La seule explication est donc un comptage des réservations faites par cet utilisateur, mais je ne vois rien d'anormal ni dans _entry ni dans _entry_moderate. Il y avait un commentaire de modération dans cette dernière, je l'ai enlevé, sans résultat. Il n'y a, de toute façon, que 32 lignes, dont seulement 3 sur le domaine qui coince. J'ai constaté une discordance être _entry et _entry_moderate. Il y a plus d'items dans _entry que dans _entry_moderate, ça doit venir du fait que je me suis substitué à l'utilisateur dans certains cas.
Bon, je vais virer manuellement, dans la base directement, toutes les entrées, modérées ou pas, pour ce domaine, je verrai bien ce que ça donne.

Bonne journée

JPP

Peut-être vérifier qu'on ne fait pas fausse route en provoquant un affichage du résultat de UserRoomMaxBooking ? Dans le planning, ça me paraît plus simple.

Euh "provoquer l'affichage du résultat de UserRoomMaxBooking", je ne sais pas faire, par plus que provoquer l'affichage du résultat d'une autre fonction, d'ailleurs…

J'imagine qu'il faut glisser dans la fonction, quelque part un "écho" quelque chose, mais je n'en sais pas plus. Si vous me donnez le code à copier, je veux bien tenter le coup.

Bien sincèrement

JPP

Dans le fichier day.php, version du 2022-04-24 16:07, il suffit d'insérer entre les lignes 484 et 485 la ligne Doit alors s'afficher 0 si vous avez épuisé votre droit à tirage ou 1 sinon (et alors aussi le "+").

Re bonjour

Effectivement, j'ai ajouté la ligne écho dans dan.php, et j'ai bien 1 et la PLUS bleu, mais 0 dans le domaine qui pose problème.

Donc nous ne faisons pas fausse route, l'erreur est bien là.

Est-ce que je vire manuellement toutes les réservations de mon utilisateur dans ce domaine, pour voir ce que ça donne?

Au plaisir
JPP

Une méthode plus soft serait de recréer un utilisateur bis avec les mêmes droits que l'utilisateur bloqué, puis vérifier que le bis a tous ses droits, enfin supprimer l'ancien utilisateur lorsque ses réservations seront passées.

Oui, c'est la solution dans tous les cas, mais alors je perd l'historique des utilisations de ressources, et ça me gène.
De plus, les utilisateurs ont un login "significatif", ce qui m'oblige à supprimer d'abord, puis à re-créer ensuite avec le même login et le même password, puis à remonter une trentaine de lignes d'historique, manuellement.
Alors que si je supprime juste ce qui relève du domaine concerné par le problème, ça ne me fait que quelques lignes à ressaisir.

Je viens de virer toutes les lignes.

1) Je vire toutes les lignes
2) L'utilisateur peut à nouveau accéder à la réservation
3) Je fais trois réservations avec l'id de l'utilisateur, sans problème., je me connecte en tant qu'administrateur et je les valide
4) Après ces trois réservations, les problèmes recommencent, avec l'impossibilité de réserver à nouveau, mais, quand même, l'affichage normal pour modification des réservations déjà faites.
5) Je vérifie les tables _entry et _entry_moderate, les trois lignes y sont, à l'identique, a priori sans problème.
6) Je note que, entre temps, un autre administrateur à enregistré une réservation qui est directement dans _entry sans être passée par _entry_moderate. Le problème pourrait-il venir d'un problème de comptage différent dans les deux tables, qui bloque donc le dernier utilisateur dans _entry qui n'est pas dans _entry_moderate? Et sur le dernier domaine de ressources utilisé?
7) Et, après avoir rajouté des réservations pour le compte de l'utilisateur, mais en tant qu'administrateur, la ressource réservée n'est plus évitable. Et dans day.php, les "0" et le "1" ne s'affichent plus pour l'utilisateur en question, et même ils ne s'affichent plus pour personne!