Produits Entr'ouvert » Combo

Ça n'a rien à faire dans combo/data/, trop spécifique. Comme c'est du paiement, je verrais plutôt ça dans lingo.

('auth', '0006_require_contenttypes_0002'), → ça oblige django 1.8, à éviter.

combo/public/static/css/tipi.css, tas de règles inutiles; on doit déjà avoir par ailleurs le style à appliquer sur les champs email, sur les erreurs, etc.

Le js, j'imagine copié d'un truc jamais relu, un peu d'esprit critique dessus avant de le soumettre ?

        <input type='text' id='exer' maxlength=4 size=4 tabindex="2" onkeyup="checkLen(this, this.value)" placeholder="2017" />

Sur une même balise avoir des attributs avec des single quotes, des double quotes, et rien du tout, un record ?

regies = models.TextField(_('Regies'), help_text=_('multiline, with "regie identifier" per line'))

Pas vraiment compréhensible, sur chacune des lignes il faut inclure des guillemets ? Pourquoi pas simplement avoir une ligne avec les identifiants séparés par des virgules ?

<option value="{{ id }}">{{ id }}</option>, c'est bien moche de demander à l'usager de choisir dans des identifiants, il n'y a pas moyen d'associer un libellé à ceux-ci ?

<input type="text" id="exer" maxlength="4" size="4" placeholder="2017" /> - l'idée c'est un commit en 2018 pour changer ça ?

return des point-virgules, please.

var re = /^(([^<>()[\]\\.,;:\s\"]+(\.[^<>()[\]\\.,;:\s@\"]+)*)|(\".+\"))((\[[0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}\])|(([a-zA-Z\-0-9]+\.)+[a-zA-Z]{2,}))$/; rly? on ne peut pas juste se dire que type=email suffit ?

Plutôt qu'avoir des libellés et des champs mal alignées, passer les champs à la ligne, comme on le fait généralement ? Notre balisage pour les formulaires, c'est .as_p(), ici ça ressemble plutôt à du .as_ul(). (→ reste du css à virer)

Je préférerais que les erreurs soient cachées par défaut, plutôt qu'attendre que le js le fasse.

Your email : on évite de préfixer par "Your " les différents champs.

Aussi, mais je laisse pisser pour cette fois, l'utilisation de placeholder, ce n'est pas terrible vu que ça s'efface dès que tu commences à taper, c'est mieux d'avoir un affichage permanent sous le champ.

name@domain.com pour les exemples, il y a des domaines dédiés.

onclick, plutôt avoir le js qui fasse un on('submit', ... sur le formulaire. Et on a commencé à utiliser <button> pour les boutons.

Oui, c'est mieux mais il manque des styles pour les formulaires en front.

Ne pas hésiter à créer un ticket dans publik-base-theme disant ce qu'il manque.

Ici je préfere garder le onsubmit sur le form, au lieu de le faire dans jquery car je passe dans le template des paramètres qui sont envoyés à la fonction call_tipi.

Je trouve ça moche et bien mieux si ces paramètres étaient simplement posés sous forme de data-url, data-saisie, etc. Ça permettrait aussi d'éviter un pesv2|lower compliqué à comprendre.

combo/public/static/css/tipi.css, taper le style="display: none" directement dans l'html, pour gagner une requête.

$('#' + id + '_error').toggle(); (et les autres .toggle()); comme l'idée est d'afficher, .show() me semble plus lisible.

if(!valid) espace. À d'autres endroits aussi (if(popup.closed)).

popup = window.open ; si Firefox bloque l'ouverture de la popup, ça sera null. Et checkpopup éclatera. Si popup est null, je ne désactiverais pas les champs, je ne lancerais pas le setInterval, j'afficherais un message à l'usager pour l'avertir.

{% if title %}<h2>{{ title }}</h2>{% endif %}

J'incluerais tout le temps un titre, c'est compliqué de styler de manière correcte sinon. Et taper le contenu dans un <div>, et ça devrait régler le problème de padding mentionné dans #15222.

→ "Your browser is blocking popups but they are required to start the payment, you should make sure they are allowed for this site.", genre.

saisie = models.CharField(_('Saisie'), choices=TIPI_SAISIES, max_length=1, default='M')

Il y a bien sûr le "Saisie" qui est du français qu'on demander à traduire; mais le sens de ce paramètre même m'échappe.

Ce paramétre saisie a toujours la valeur M (manuel) pour un formulaire de paiement auquel l'usager transmet les références de la facture à payer.
En dehors de cela il y a également le mode test saisie=T ou n'importe quelle valeur peut être saisie dans la référence de la facture: TIPI acceptera et simulera le paiement.
Et la valeur saisie=X est nécessaire uniquement pour l'activation des paiements.

Je veux donc avoir les 3 modes, pour pouvoir l'utiliser en mode test (T)sur la recette et M sur la prod.

Ce paramétre saisie a toujours la valeur M (manuel) pour un formulaire de paiement auquel l'usager transmet les références de la facture à payer.

Le template présent, il gère uniquement des formulaires de paiement en ligne; ce serait donc toujours cette valeur ?

En dehors de cela il y a également le mode test saisie=T ou n'importe quelle valeur peut être saisie dans la référence de la facture: TIPI acceptera et simulera le paiement.

Cela même avec l'URL b'https://www.tipi.budget.gouv.fr/tpa/paiement.web de TIPI ? Si c'est le cas, pourquoi l'URL est un paramètre ? Et si le paramétrage est donc la présence d'un mode de test, ça m'irait mieux d'avoir une case à cocher "Utiliser le mode test de TIPI", genre.

Et la valeur saisie=X est nécessaire uniquement pour l'activation des paiements.

Pas la moindre idée de ce que ça veut dire.

Frédéric Péters a écrit :

Cela même avec l'URL b'https://www.tipi.budget.gouv.fr/tpa/paiement.web de TIPI ? Si c'est le cas, pourquoi l'URL est un paramètre ? Et si le paramétrage est donc la présence d'un mode de test, ça m'irait mieux d'avoir une case à cocher "Utiliser le mode test de TIPI", genre.

Oui, le mode test fonctionne avec la même URL. Je l'ai mis en paramètre car certaines villes utilisent d'autres adresses qui semblent être des alias vers le même système de paiement. A Clisson c'est par exemple: https://www.jepaiemesserviceslocaux.dgfip.finances.gouv.fr/tpa/paiement.web

Et la valeur saisie=X est nécessaire uniquement pour l'activation des paiements.

Pas la moindre idée de ce que ça veut dire.

C'est lié au fonctionnement de TIPI, laissons tomber pour l'instant.

var popup;
var timer;

Vu le côté très générique, taper ça dans un namespace, ou nommer de manière vraiment plus précise, pour éviter les clashs lors d'intégrations utilisant du js extérieur. Pareil pour les fonctions, taper le maximum dans le namespace ouvert par $(function() {

    def is_visible(self, user=None):
        return True

Il faut suivre le paramétrage fait par l'admin, i.e. je virerais ce is_visible().

Je ne vois pas comment on peut avoir le mode de saisie X qui permet de passer en prod ? Ne faudrait-il pas avoir un menu avec choix de saisie, prod, test et validation dans la cellule ?

Et la valeur saisie=X est nécessaire uniquement pour l'activation des paiements.

Pas la moindre idée de ce que ça veut dire.

Peut-être qu'il fallait lire "validation" plutôt que "activation", et même encore pour moi là ça n'aurait pas été clair.

Bref, s'il y a trois modes qui ont tous un sens, faut juste de bien meilleurs libellés à ce qui était mis avant :

TIPI_SAISIES = (
    ('M', _('Manual')),
    ('T', _('Test')),
    ('X', _('Activation')),
)

(genre "environnement TIPI", "production" / "validation" / "test") ?

L'activation du mode production (avec le flag X) peut se faire manuellement, donc pas besoin de la cellule pour ça.
Comme discuté plus haut, on utilise par défaut le mode "manuel" M avec le mode "test" T activable via une option.

Il y a encore mille trucs à dire sur le js,

• commencer par deux lignes vides ?
• ajouter des commentaires pour qu'on comprenne un peu ce qui doit se passer.
• for (var i=0;i<element.attr('maxLength')-value.length;i++) espaces.
• etc.

Ce code reste pour moi bien trop moche mais on verra à corriger ça un jour de pluie, ok.

(regret aussi pour les id arbitraires pour control_protocol, je pensais qu'ils venaient de tipi mais même pas, c'est juste nous qui nous mettons des codes sans raison)

Je parlais de :

TIPI_CONTROL_PROCOTOLS = (
    ('1', _('Indigo/PES v2')),
    ('2', _('ROLMRE')),
)

qui fait que

context['pesv2'] = (self.control_protocol == '1')

alors que ça pourrait être

context['pesv2'] = (self.control_protocol == 'pesv2')

Ce code reste pour moi bien trop moche mais on verra à corriger ça un jour de pluie, ok.

C'était pour dire que j'avais plus trop envie de regarder ce js, que c'était ack ainsi, sans tester. (

Paf le jenkins.