https://dev.entrouvert.org/https://dev.entrouvert.org/favicon.ico?15861920342018-12-06T16:51:29ZRedmine Entr’ouvertw.c.s. - Bug #15379: crash suite à écrasement d'un formulaire, crash lié au format SQLhttps://dev.entrouvert.org/issues/15379?journal_id=1425262018-12-06T16:51:29ZThomas Noël
<ul></ul><p>Le cas se produit quand même régulièrement, les gens cochent sur "Overwrite nevertheless" et hop...</p>
<pre> get_request().method = 'GET'
get_request().form = {}
form = Form(enctype='multipart/form-data', use_tokens=False)
if different_type_fields:
form.widgets.append(HtmlWidget('<div class="errornotice"><p>%s</p></div>' % _(
'The form has incompatible fields, it may cause data corruption and bugs.')))
form.add(CheckboxWidget, 'force', title=_('Overwrite nevertheless'))
else:
form.add_hidden('force', 'ok')
form.add_hidden('new_formdef', ET.tostring(new_formdef.export_to_xml(include_id=True)))
form.add_submit('submit', _('Submit'))
form.add_submit('cancel', _('Cancel'))
r += form.render()
</pre>
<p>Il faut être plus violent, et ne plus proposer l'overwrite en cas de different_type_fields.</p> w.c.s. - Bug #15379: crash suite à écrasement d'un formulaire, crash lié au format SQLhttps://dev.entrouvert.org/issues/15379?journal_id=1425432018-12-06T17:04:42ZFrédéric Pétersfpeters@entrouvert.com
<ul></ul><blockquote>
<p>régulièrement</p>
</blockquote>
<p>Par rapport à combien de fois où forcer les choses "marche" ? (grep POST.*overwrite sur les access.log, ça pourrait nous donner une indication ?)</p> w.c.s. - Bug #15379: crash suite à écrasement d'un formulaire, crash lié au format SQLhttps://dev.entrouvert.org/issues/15379?journal_id=1425542018-12-06T17:54:42ZThomas Noël
<ul></ul><p>Frédéric Péters a écrit :</p>
<blockquote><blockquote>
<p>régulièrement</p>
</blockquote>
<p>Par rapport à combien de fois où forcer les choses "marche" ? (grep POST.*overwrite sur les access.log, ça pourrait nous donner une indication ?)</p>
</blockquote>
<p>Ok, j'ai exagéré, vous me connaissez. Régulièrement = 2 fois cette semaine, dont une fois en prod avec du jeu de backup pas funky, et ça me suffit pour dire qu'il faut interdire cette manip et c'est tout.</p> w.c.s. - Bug #15379: crash suite à écrasement d'un formulaire, crash lié au format SQLhttps://dev.entrouvert.org/issues/15379?journal_id=1426012018-12-07T09:26:49ZBenjamin Dauvergne
<ul></ul><p>Et générer des id de field uniques plutôt ?</p>
<pre>
In [5]: 'f' + base64.urlsafe_b64encode(os.urandom(8)).strip('=')
Out[5]: 'f5FR91ww4FFs'
</pre>
<p>Aucune chance qu'en cas de fork d'un formulaire un ré-import crée une collision.</p> w.c.s. - Bug #15379: crash suite à écrasement d'un formulaire, crash lié au format SQLhttps://dev.entrouvert.org/issues/15379?journal_id=1426022018-12-07T09:28:23ZBenjamin Dauvergne
<ul></ul><p>Plutôt de l'encodage base32 pour éviter les problèmes de casse (je ne sais pas si on quote ou pas les noms de colonne dans la partie SQL, mais le mieux c'est d'éviter le problème).</p> w.c.s. - Bug #15379: crash suite à écrasement d'un formulaire, crash lié au format SQLhttps://dev.entrouvert.org/issues/15379?journal_id=1426372018-12-07T10:12:21ZThomas Noël
<ul></ul><p>En fait on pourrait juste prendre des nouveaux fNNN pour ces champs en conflit.</p>
<p>Mais en fait, ces conflits de champs, ils traduisent une mauvaise procédure de travail (normalement on bosse sur une copie du formulaire en prod, et il est impossible de changer le type d'un champ, donc ça peut pas arriver). C'est pour ça que je pense vraiment juste interdire l'overwrite, et que la personne doive reprendre son travail correctement.</p> w.c.s. - Bug #15379: crash suite à écrasement d'un formulaire, crash lié au format SQLhttps://dev.entrouvert.org/issues/15379?journal_id=1426472018-12-07T10:38:30ZBenjamin Dauvergne
<ul></ul><p>Thomas Noël a écrit :</p>
<blockquote>
<p>En fait on pourrait juste prendre des nouveaux fNNN pour ces champs en conflit.</p>
<p>Mais en fait, ces conflits de champs, ils traduisent une mauvaise procédure de travail (normalement on bosse sur une copie du formulaire en prod, et il est impossible de changer le type d'un champ, donc ça peut pas arriver). C'est pour ça que je pense vraiment juste interdire l'overwrite, et que la personne doive reprendre son travail correctement.</p>
</blockquote>
<p>Sauf que c'est inexplicable aux gens (vous avez forké, et donc on a généré des id identiques pour des champs différents découlant d'un travail sur deux plate-formes différentes). Si on interdit de forcer l'overwrite sans rien faire de plus, on aura des tickets de support pour "j'arrive pas à mettre à jour" en pagaille.<br />Si on force l'overwrite et qu'on génère des id globalement uniques, on évite les problèmes et on permet aux gens de travailler (et de faire vraisemblablement de la merde quand ils verront qu'un champ x créé des deux cotés ne reprend pas les données du champ en prod, mais ça c'est le boulot de l'écran de dire les données du champs X vont être perdu, are you ok ? vous devriez partir d'un export d'un formulaire avant de le modifier pour éviter ces problèmes).</p> w.c.s. - Bug #15379: crash suite à écrasement d'un formulaire, crash lié au format SQLhttps://dev.entrouvert.org/issues/15379?journal_id=1427062018-12-07T13:15:13ZThomas Noël
<ul></ul><blockquote>
<p>mais ça c'est le boulot de l'écran de dire les données du champs X vont être perdu, are you ok ?</p>
</blockquote>
<p>C'est déjà le cas on affiche déjà des warning, mais "les gens" (dont nous) cliquent sur "oui oui vazy je m'en fous", et boum. Moi j'ai vraiment plus envie, jamais, d'avoir à faire le pompier en prod sur ce genre de soucis, aussi petit soit-il (et parce qu'en plus, il ne peut être visible que x jours après).</p>
<p>Si on met pas le bouton, alors les gens sont bien obligés de lire ce qui est écrit, et on peut éventuellement rappeler la procédure (repartir du formulaire actuel).</p>
<p>En tout cas moi, je préfère ça, et si on le fait pas la prochaine fois c'est toi qui remonte les backups :)</p> w.c.s. - Bug #15379: crash suite à écrasement d'un formulaire, crash lié au format SQLhttps://dev.entrouvert.org/issues/15379?journal_id=1452712018-12-19T08:51:29ZBenjamin Dauvergne
<ul></ul><p>Encore un exemple, <a class="issue tracker-1 status-5 priority-4 priority-default closed" title="Bug: crash suite à écrasement d'un formulaire, crash lié au format SQL (Fermé)" href="https://dev.entrouvert.org/issues/15379">#15379</a>, je crois qu'il faudrait déjà informer les CPFs des écueils avec la situation actuelle, parce que quand je signale à Mike qu'il faut respecter un certain workflow entre test et prod il n'était visiblement pas au courant.</p>
<p>Vraiment je ne vois pas ce que nous apporter les identifiants séquentiels (en fait on pourrait même avoir les deux si on veut conserver une sorte de timestamp virtuel sur l'ordre de création des champs, genre <code>f{counter}_{hash}</code>).</p> w.c.s. - Bug #15379: crash suite à écrasement d'un formulaire, crash lié au format SQLhttps://dev.entrouvert.org/issues/15379?journal_id=1452772018-12-19T09:10:17ZMikaël Atesmates@entrouvert.com
<ul></ul><p>Je ne travail que sur la recette (pour mon cas présent) et pas souvenir qu'on est parlé de wf prod/recette (pour mon cas présent).</p>
<p>J'ai un formulaire avec des zones de formulaires qui se répètent, des contacts par exemple. Ma pratique c'est d'exporter le formulaire, dans un éditeur de texte de copier-coller mon ensemble de champs. De faire un rechercher remplacer sur mes variables _contact1 pour les remplacer par _contact2. Je lance ensuite un petit script sur mon fichier pour renuméroter tous les champs :</p>
<pre>
import sys
import xml.etree.ElementTree as ET
fn = sys.argv[1]
print "Renumbering..."
tree = ET.parse(fn)
root = tree.getroot()
i = 1
for elem in root.iter('id'):
elem.text = str(i)
i += 1
tree.write(fn)
print "Done"
</pre>
<p>J'écrase ensuite mon formulaire avec un nouvel import.</p> w.c.s. - Bug #15379: crash suite à écrasement d'un formulaire, crash lié au format SQLhttps://dev.entrouvert.org/issues/15379?journal_id=1452782018-12-19T09:12:34ZBenjamin Dauvergne
<ul></ul><p>Un truc en passant aussi, dans ce code de wcs/admin/forms.py:FormDefPage :<br /><pre>
def overwrite_by_formdef(self, new_formdef):
# keep current formdef id, url_name, internal identifier and sql table name
new_formdef.id = self.formdef.id
new_formdef.internal_identifier = self.formdef.internal_identifier
new_formdef.url_name = self.formdef.url_name
new_formdef.table_name = self.formdef.table_name
# keep currently assigned category and workflow
new_formdef.category_id = self.formdef.category_id
new_formdef.workflow_id = self.formdef.workflow_id
# keep currently assigned roles
new_formdef.workflow_roles = self.formdef.workflow_roles
new_formdef.backoffice_submission_roles = self.formdef.backoffice_submission_roles
new_formdef.roles = self.formdef.roles
self.formdef = new_formdef
self.formdef.store()
</pre></p>
<p>Je me demande si on ne devrait pas aussi reprendre max_field_id de cette manière:<br /><pre>
new_formdef.max_field_id = max(self.formdef.max_field_id, new_formdef.max_field_id)
</pre></p>
<p>histoire de toujours rester "en avance".</p> w.c.s. - Bug #15379: crash suite à écrasement d'un formulaire, crash lié au format SQLhttps://dev.entrouvert.org/issues/15379?journal_id=1452792018-12-19T09:13:09ZFrédéric Pétersfpeters@entrouvert.com
<ul></ul><blockquote>
<p>J'écrase ensuite mon formulaire avec un nouvel import.</p>
</blockquote>
<p>Et tu n'as pas d'avertissement (attention champs incompatibles, ne faites pas ça.) ?</p> w.c.s. - Bug #15379: crash suite à écrasement d'un formulaire, crash lié au format SQLhttps://dev.entrouvert.org/issues/15379?journal_id=1452852018-12-19T09:28:19ZMikaël Atesmates@entrouvert.com
<ul></ul><p>(Dans cette phase de développement en recette je n'ai pas besoin des formdata. Je vais donc supprimer l'ancien formulaire et en créer un par import plutôt que de faire écraser avec un nouvel import sur le formulaire existant.)</p> w.c.s. - Bug #15379: crash suite à écrasement d'un formulaire, crash lié au format SQLhttps://dev.entrouvert.org/issues/15379?journal_id=1951062019-10-06T17:26:49ZFrédéric Pétersfpeters@entrouvert.com
<ul><li><strong>Lié à</strong> <i><a class="issue tracker-2 status-5 priority-4 priority-default closed" href="/issues/36711">Development #36711</a>: "écraser avec un nouvel import", "sans danger"</i> ajouté</li></ul> w.c.s. - Bug #15379: crash suite à écrasement d'un formulaire, crash lié au format SQLhttps://dev.entrouvert.org/issues/15379?journal_id=1987002019-10-25T08:47:45ZFrédéric Pétersfpeters@entrouvert.com
<ul><li><strong>Statut</strong> changé de <i>Nouveau</i> à <i>Fermé</i></li></ul><p>Traité via <a class="issue tracker-2 status-5 priority-4 priority-default closed" title="Development: "écraser avec un nouvel import", "sans danger" (Fermé)" href="https://dev.entrouvert.org/issues/36711">#36711</a>.</p>