[OSM-dev-fr] Un utilisateur fantome

[Philippe Verdy]

Différentes raisons peuvent expliquer un changeset vide, même sans aucune
erreur réseau.

Par exemple un utilisateur modifie ou supprime un chemin ou une relation et
veut l'envoyer, ce sera la première transaction du changeset: il ouvre un
changeset (qui est alors vide), puis envoie l'objet à modifier ou supprimer.

Et là le serveur détecte un conflit d'édition. L'utilisateur peut mettre
des heures à gérer le conflit et réparer son envoi. Pendant ce temps-là, le
changet n'aura toujours aucune transaction valide, et le serveur pourra
même le fermer prématurément.

L'utilisateur peut aussi décider d'abandonner sa modif et ne rien faire
d'autre que fermer le changeset (CTRL+ALT+Q dans JOSM), et jeter ses modifs
en cours. Le changeset est là aussi fermé et reste vide.

Dans les deux cas, ce changeset vide reste dans le journal de l'utilisateur
mais ne sert à personne, même pas à son auteur. Car même si l'auteur n'a
pas abandonné ses données locales, s'il veut les envoyer après avoir résolu
le conflit d'édition, il devra ouvrir un nouveau changeset (l'ancien a été
fermé).

Un changeset peut rester vide et ouvert pendant assez longtemps avant que
le serveur le ferme automatiquement (plusieurs heures ?). Ce n'est pas une
anomalie donc d'avoir un changeset vide visible tant qu'il est ouvert, mais
ça l'est si le changeset est fermé.

Le changeset étant lié à un utilisateur, si cet utilisateur est supprimé,
cela ne peut pas se faire avec un changeset associé encore ouvert : ce
changeset doit d'abord être fermé. Ce changeset peut alors être purgé
(puisqu'il est vide), et l'utilisateur supprimé quand les autres changesets
non vides de cet utilisateur ont été modifiés pour aller dans un compte
utilisateur "poubelle" (là il faut lancer un processus de nettoyage comme
pour le changement de licence, selon la validité des données associées qui
restent dans la base, si leur licence était valide et si les données
n'étaient pas abusives ou des déchets).

Le cas pourrait concerner des comptes utilisateurs bannis par le DWG, ou
supprimés à la demande de l'utilisateur, quand les données bien que valides
au plan de la licence pourraient être nuisibles à l'utilisateur sur sa vie
privée ou celle des autres (imaginez qu'on trouve dans OSM des
localisations précises des points de rassemblements LGBT en Russie ou en
Iran, avec les dates et heures, ou listes de personnes attendues, ou leur
numéros de téléphone, adresses mail, pages Facebook ou Twitter, ou des
liens vers des documents compromettants, y compris des photos publiées par
erreur ou mal anonymisées, etc. Imaginez aussi les liens nuisibles de type
spam vers des sites redirecteurs, généralement on ne veut pas des
"shortURL" anonymisées chez des fournisseurs qui n'ont aucun système de
filtrage des abus).




Le 14 janvier 2014 06:49, Philippe Verdy <verdy_p at wanadoo.fr> a écrit :

> Le 12 janvier 2014 21:33, Pierre Béland <pierzenh at yahoo.fr> a écrit :
>
> Ce peut être un problème de communication entre ID et l'API. Mais de toute
>> façon, il y a un problème d'enregistrement des informations par l'API. On
>> ne devrait pas y enregister un  changeset sans transaction de données. Et
>> encore moins avec un usager inexistant.
>>
>
> Tous les changeset sont créés initialement vides avant qu'on y injecte des
> transactions dans des requêtes séparées.
>
> Cependant les changesets sont ensuite autmatiquement fermés par le s'il
> n'y a plus d'autres transaction pendant un certain temps.
>
> A ce moment-là (ou lorsque le changeset est fermé explicitement par une
> transaction "close"), s'il n'y a aucune transaction dedans, le serveur
> pourrait le supprimer aussitôt de la base (et aussi de l'historique de
> l'utilisateur, même s'il y a d'autres attributs comme un commentaire).
>
>
-------------- section suivante --------------
Une pièce jointe HTML a été nettoyée...
URL: <http://lists.openstreetmap.org/pipermail/dev-fr/attachments/20140114/1b8e5c6f/attachment.html>