C'est entièrement de ta faute. Fallait livrer l'appli avec une webcam, un miroir derrière l'utilisateur pour que la webcam voie le moniteur, et un module qui remplace « n'existe pas » par « n'existe plus » quand l'utilisateur a traité le message.

Ces programmateurs, tous des bons à rien.

Faut rajouter un message qui clignote en rouge police 40 en haut du mail :

Attention ce message s'autodétruira après lecture !!!

programmateurs*
;)

J'imagine qu'il se plaint également de ne pas retrouver, mémorisée dans la base de données, l'erreur "perte de connexion à la base de données" ...

Je suis mit-mit sur celui-là. Autant l'utilisateur (tel que décrit) semble con, autant en dessous du lien (dans le mail, donc), le programmeur peut ajouter quelque chose comme : « Attention, ce lien ne sera plus valide après lecture ».
Du coup, je m'abstiens bien de voter.

Ca n'arriverait pas si l'appli gérait des suppressions logiques, ou pour économiser de la place une suppression physique (comme à l'heure actuelle) mais en gardant dans une table l'identifiant de l'enregistrement supprimé. Ca permet d'afficher un message du genre "ce rapport a été supprimé automatiquement après résolution de l'erreur".
La suppression logique permet également de garder une trace de l'erreur, ça peut-être utile pour voir si une même erreur revient souvent, auquel cas on peut prévoir une action en conséquence (formation des utilisateurs, redéveloppement d'un module pas très intuitif, ...).

C'est comme remplacer la roue de sa voiture suite à crevaison, puis constater que la roue de secours n'est pas dans son rangement habituel !

c'était probablement volontaire ;) sarcasme, tout ça... C'est un concept un peu nouveau sur internet :p

J'ai voté CTLP parce que l'application est mal foutue dès le départ. Je ne comprends pas qu'on ait commencé par faire un système qui supprime les rapports plutôt que de les archiver.
Chaque fois que je conçois un système ou une appli, la règle est "pas de suppression". On flag "deleted", mais la suppression effective des données ne doit s'effectuer que par une demande explicite.

Bon, sinon l'utilisateur est un peu con aussi, c'est vrai :)

CTLP : "l'utilisateur clique sur le lien" = requête HTTP GET.
Et d'après http://www.w3schools.com/tags/ref_httpmethods.asp une requête GET doit être "Harmless", comprendre "peut être répétée indéfiniment sans impacter les données".
Donc déjà, tu ne respectes pas les bonnes pratiques liées au protocole.
CTLP++ : précises-tu que l'enregistrement est supprimé après lecture que l'utilisateur n'accède à la ressource kamikase ? Et pour en rajouter : _*AVANT*_ qu'il ne clique sur le lien ?
CTLP+=2 : quand bien même tu le précises, quel est l'intérêt ? Tu le dis toi-même, il y a un dev en cours pour conserver les données, alors pourquoi ne pas avoir gardé les rapports dès le début ?
CTLP+=3 : Suppression automatique sur un simple accès HTTP ? Même pas de confirmation ? De petit bouton "traité" ? Et si je clique sur le lien et que le PC s'éteint suite à une attaque de poney sur les lignes à haute tension ?
CTLP-- : bon, si l'utilisateur a le cas systématiquement et qu'il persiste, faut admettre qu'il a un petit problème... Fool me once, shame on you ; fool me twice, shame on me !

Le client a ses exigences, le dev les implémente.

Le GET ne supprime pas le rapport. Il l'affiche, avec les boutons "Retry" et "Delete".
Le lien dans l'email ne pointe alors plus sur une ressource existante.

Même réponse que plus haut, si ce n'est pas archivé, c'est que le client n'a pas demandé ça.

So true.

Des clients m'ont obligé des fois à faire des choses qui m'empêchent toujours de dormir la nuit...

Donc on en est à un CTLP lvl5 ?

Je ne sais pas mais pour quelqu'un qui se fait appeler TrollW3C Ta gestion des ++ et des += laisse à désirer...

En résumé, CTLP+=5 et une belle erreur de syntaxe sur la décrémentation (CTLP-- et pas CTLP- pour ceux qui ne suivent pas)
Sinon, le dev n'est pas la pour juger du cahier des charges, juste pour coder, donc CNEPTLP.

@mini: nous y sommes tous confrontés. Le plus difficile étant de se faire entendre. Mais toujous se couvrir (même par un simple mail).

TrollW3C CTLP sur toute la ligne.

Soit, si c'est le client qui le demande, c'est pas ta faute, il n'a qu'à s'en prendre à lui-même.
Et même gros PEBKAC, vu qu'il a demandé la fonctionnalité dont il se plaint.

Pas contre, en relisant le PEBKAC et ton commentaire, j'ai du mal à comprendre : le fait d'afficher le rapport ne fait rien d'autre, oui ou non ?
D'après ce dernier message, il ne ferait que l'afficher avec les boutons adéquats, mais d'après le PEBKAC, je comprends plutôt "une fois la page chargée, elle n'est plus accessible, sans que l'utilisateur n'ai à confirmer le traitement de l'erreur"...

"L'utilisateur clique sur le lien ET s'occupe du rapport d'erreur."
Les deux actions s'enchaînent, mais ne sont pas liées. Il peut également y accéder par l'interface en visionnant la liste des rapports en cours.

Donc non, elles ne sont pas liées.

@Ygnobl : on peut juger, mais c'est le client qui décide quoi payer (donc implémenter) pour les prochaines versions.

Ce qui me gêne c'est la gestion de l'erreur. Ne devrait-il pas y avoir un message suffisamment explicite indiquant que si l'enregistrement n'existe pas c'est qu'il a probablement déjà été traité ? A la lecture je n'en ai pas l'impression. En attendant, je m'abstiens.

Non en effet, c'est un message d'erreur générique.

Si un forum comporte une url du style "viewtopic/532/23" pour voir le 23e message du sujet 532, alors si l'utilisateur modifie à la main pour voir le sujet 34757394, celui n'existera bien sûr pas, et l'erreur sera affichée en conséquence.

Même topo ici, l'application comporte de nombreux types de données, et il n'est pas possible de deviner si elle a jamais existé quand on ne la trouve pas. Sauf à ne pas les effacer et les archiver bien sûr.

Je maintiens que la gestion d'erreur peut-être améliorée. Il faut toujours prendre l'utilisateur pour plus bête qu'il l'est vraiment : il est capable de rentrer des lettres dans un champ numérique, ou de modifier à la main une adresse sur laquelle il a cliqué une deuxième fois inutilement, même si on lui a dit de ne pas le faire.
Dans le cas présent, je pense qu'un message indiquant que "le rapport XXX a déjà été traité ou n'existe pas" diminuerait le risque d'appel de l'utilisateur.
L'utilisateur restant un PEBKAC, je vote neutre.

Non, car cela tient du bon sens.
C'est LUI qui a demandé une application se comportant ainsi, il doit dont connaître les conséquences de ses actions.

Partant, nous facturons toujours les quelques heures perdues à répondre à ce genre de problème. Cela en limite le nombre.

En fait j'ai lu programmeurs (mon enfoiré de cerveau à corrigé tout seul), et je voulais justement faire de l'humour en corrigeant. Mais je me suis vautré lamentablement -_-'