Plugin amappca

Bonjour,

Je viens donc d’installer le plugin amappca sur un SPIP 3.2 et j’ai plusieurs questions quant à sa conception et sa mise en œuvre très pratique. Ce ne sont sans doute que les premières interrogations – certaines sans doute très bêtes – de nombreuses à venir…

Les producteurs sont des auteurs (statut de rédacteur ?) que l’on définit comme contacts et que l’on classe dans l’annuaire des Producteurs de l’AMAP, c’est bien cela ?

Pour créer des produits, on doit avoir des rubriques de définies ; vous aviez quoi comme idée de structure ?

Dans le document de conception, la phrase « Pour chacun des producteurs, il conviendra de renseigner le « catalogue » des produits proposées » reste assez énigmatique ; ce ne sont pas les producteurs qui réalisent la saisie ?
Chaque producteur a sa rubrique avec ses produits à ses tarifs à lui ?

Est-ce normal que l’on n’ait pas de bouton d’accès à la création de livraison ? Il s’agit bien de l’objet Distributions en fat ?
Qu’aviez-vous à l’esprit ? Depuis quels formulaires cela doit être accessible ?
Ce sont les seuls gestionnaires qui peuvent modifier cela ?
Je ne saisis pas trop le principe d’abonnement aux livraisons ; cela reste à développer ?

Voilà pour le premier jet de questions… Merci par avance !

Je viens donc d’installer le plugin amappca sur un SPIP 3.2 et j’ai plusieurs questions quant à sa conception et sa mise en œuvre très pratique. Ce ne sont sans doute que les premières interrogations – certaines sans doute très bêtes – de nombreuses à venir…

Les producteurs sont des auteurs (statut de rédacteur ?) que l’on définit comme contacts et que l’on classe dans l’annuaire des Producteurs de l’AMAP, c’est bien cela ?

On s’en fiche du statut mais dans un premier temps ayant accès à l’admin oui, sauf dans un deuxième temps à réussir à faire aussi une interface plus dédiée en partie publique pour les producteurices aussi. Ça serait le but final car pour une utilisation « métier » comme celle là, il va y avoir trop de choses non pertinents visibles et accessibles dans l’admin de SPIP pour un⋅e producteurice, du bruit qui n’a rien à voir avec ce dont ille a besoin (rubriques, articles, etc), y compris en simple compte rédac. Mais à mon avis ça c’est à faire dans un second temps en amélioration progressive, faut déjà qu’il y ait tout niveau CVT dans l’admin pour les admins complets.

Le compte utilisateur SPIP, moi je le considère quasi toujours que comme « compte », pour accéder, ça sert à avoir un login/mdp. Ensuite les infos personnelles seraient dans Contacts oui (et Coordonnées s’il faut), dans un annuaire dédié (id=producteurs ou producteurices ou prods) oui pour pouvoir les lister précisément.

Pour créer des produits, on doit avoir des rubriques de définies ; vous aviez quoi comme idée de structure ?

Absolument rien pour l’instant, la seule importante étant que chaque producteurice ait une liste de produits à soi (dont en étant « auteur » du produit), et donc en pouvant les modifier (changer son prix, sa description).

Dans le document de conception, la phrase « Pour chacun des producteurs, il conviendra de renseigner le « catalogue » des produits proposées » reste assez énigmatique ; ce ne sont pas les producteurs qui réalisent la saisie ?

Je crois qu’au départ on se disait plutôt que c’était aux admins/bénévoles de remplir ce catalogue du début, et que les producteurices ne puissent pas ajouter/supprimer des produits en permanence. Seulement modifier ceux existants (cf point d’avant, en être auteur). Ça ne signifie pas que chaque produit va se retrouver dans le bon de commande puisque seuls les produits associés à une distribution le seront, c’est vraiment un « catalogue des choses possibles » pour chaque producteurice. Et par contre c’est elleux qui vont décider pour chaque distribution quels produit il y aura (par ex pour le boulanger la brioche ça peut être qu’une semaine sur deux : il a toujours la brioche dans ses produits, mais il l’associera que aux semaines où yen a).

Chaque producteur a sa rubrique avec ses produits à ses tarifs à lui ?

Aucune idée, on peut éventuellement découper comme ça pour mieux s’y retrouver oui, mais c’est plus du rangement pour l’admin, je ne crois pas que ça change grand chose pour l’utilisation ni des producteurs ni des clients.

Est-ce normal que l’on n’ait pas de bouton d’accès à la création de livraison ? Il s’agit bien de l’objet Distributions en fat ?

Dans le graphe d’archi (qui est le plus récent) c’est bien distributions désormais (c’est mieux que livraison, on livre rien chez les gens).

Qu’aviez-vous à l’esprit ? Depuis quels formulaires cela doit être accessible ?

Ya aucune interface de codée pour l’instant, donc même si tu vois des boutons ou liens, c’est rien de prévu, c’est juste généré par la fabrique éventuellement.

De mémoire la création de distributions doit plutôt se faire par un formulaire CVT dédié pour générer DES distributions d’un coup en masse pour une « période de commande » dédiée. C’est-à-dire que d’abord on crée une période de commande, par exemple « Novembre 2021 » (chez nous c’est par mois), ou « Septembre 2021 à Février 2022 » (pour une AMAP où ce serait 6 mois d’un coup), ou « 2021-2022 » (pour une AMAP où ce serait un an d’un coup). Et ensuite quand on est dans cette période, un admin doit pouvoir générer « les distributions de cette période » en masse (tous les mercredis soirs de cette période par ex, avec les producteurices 1, 2, 3 liés déjà).

Après ça doit être une aide, ça serait sûrement galère de s’amuser à permettre des exceptions compliquées dans ce form de génération. Par ex si c’est tous les mercredis SAUF la semaine du nouvel an, bah on génère tout, et en supprime celle qui va pas après. C’est le plus simple pour l’instant il me semble.

Peut-être que ça peut être intéressant aussi de laisser la possibilité de créer des distributions une par une à l’unité oui. Mais ça ne serait pas le mode principal de leur création.

Dans tous les cas une distributions est normalement toujours DANS une période de commande. Dans si ya les deux, de toute façon ça serait dans la page d’admin d’une période : « Générer toutes les distributions » + « Ajouter une distribution ».

Ce sont les seuls gestionnaires qui peuvent modifier cela ?

Oui, les admins/bénévoles qui gèrent les périodes et les distributions. Comme dit dans le tableau, les producteurices doivent juste remplir ensuite quels produits yora pour chaque distribution (mais ça devrait pouvoir être pré-rempli par les admins aussi bien sûr ! notamment en copiant depuis des précédentes distribs). En théorie faudrait qu’ils aient une notif email les invitant à le faire, dès qu’une période est créé ou passe en statut XXX (si on veut laisser d’abord un brouillon vraiment que pour les admins, qui ensuite le passe en « À remplir » pour que là les prods soient notifiés).

Je ne saisis pas trop le principe d’abonnement aux livraisons ; cela reste à développer ?

Je n’ai pas compris de quoi tu parles. :slight_smile:

Voilà pour le premier jet de questions… Merci par avance !

Dans ma todo, avant le code, mon idée c’était de faire quelques maquettes des formulaires imaginés, ça permettrait de mieux comprendre ce qui serait possible/attendu. Mais j’ai encore jamais eu le temps. :frowning:

Ya aussi d’autres choses à voir/vérifier, y compris en conception, des boutons facilitateurs à imaginer, car nous par ex nos périodes c’est mois par mois, et on peut choisir semaine par semaine, mais pour une vraie AMAP qui est d’un an d’un coup, ça fait 52 distribs (ou moins si quelques vacances). Et d’une faut pouvoir à la fois les remplir facilement, mais aussi pour les commandes, dans ce cas il faudrait dans la config dire qu’on est en « mode vrai amap » avec une case, car dans ce cas les clients ne commandent pas des choses différentes semaine par semaine, c’est plutôt « pendant un an le produit Grand panier à 15€ ». Et donc le bon de commande doit être plus simple qu’afficher chaque semaine.

Bref plein de choses à discuter encore :slight_smile:


RastaPopoulos

Merci beaucoup pour ces retours, ça donne de quoi réfléchir, et s’inquiéter devant la tâche à accomplir si jamais je m’y colle ^^ (en fonction aussi des besoins)

Je comprends déjà mieux l’enchaînement Périodes de commandes, Distributions et Commandes.

Arf… C’est dans la troisième colonne de la deuxième ligne du tableau : Pour les producteurs, après l’ouverture des périodes et avant l’ouverture des commandes : « S’abonner aux différentes livraisons de la période de commande à venir et pour chacune d’elle sélectionner les produits proposés ».

Au vu des échanges sur IRC, j’essaie de définir une marche à suivre :

  • dans un premier temps, ajouter deux champs à Produits : la quantité disponible et l’unité de mesure (en cas de poids ou de volume) ;
  • ensuite, il convient de proposer un formulaire permettant de lier des Produits à une Distribution pour chacun des Producteur.
    Je pense à proposer une page avec une case à cocher pour l’inscription à la Distribution puis à une liste de checkbox des produits du Producteur. Ce dernier coche les produits disponible et doit modifier la quantité disponible ainsi que le prix unitaire:
    À l’enregistrement du formulaire, on doit donc :
  • utiliser l’API editer_liens (API editer_liens - SPIP) pour mettre à jour la table amap_distributions_liens avec quelque chose du genre (je dis bien du genre parce que je n’ai rien testé, juste rapidement regardé la documentation) :
objet_associer(array("distribution"=>$id_distribution), array("auteur" => $id_auteur, "produit"=>array($produits)));
  • utiliser l’API editer_objet pour mettre à jour les Produits avec quelque chose du genre :
objet_modifier('produit', $id_produit, array('prix_ht' => $prix, 'quantite' => $quantite));
  • ensuite, on s’occupe des Consommateurs : ils doivent pouvoir s’inscrire à une Distribution donnée (même principe que les Producteurs) et sélectionner les produits de tous les producteurs. On verra donc dans un second temps.
  • dans un premier temps, ajouter deux champs à Produits : la quantité disponible et l’unité de mesure (en cas de poids ou de volume) ;

Je ne pense pas que la gestion des stocks doive faire partie du scope de ce plugin (ni de Produits, ni de Amap). Il y a d’ailleurs déjà un plugin Stocks pour ça. Et le plugin Amap n’a pas à en dépendre, ça doit être rarissime de vouloir gérer leurs stocks par appli web dans le cadre d’une amap ou apparenté (99% du temps ça marche pas « panier » complet qui peut changer suivant les intempéries, rétrécir si ya eu un coup de gel, etc).

  • ensuite, il convient de proposer un formulaire permettant de lier des Produits à une Distribution pour chacun des Producteur.
    Je pense à proposer une page avec une case à cocher pour l’inscription à la Distribution

C’est vraiment deux choses différentes, à discuter mais pour le moment le fait de dire qu’à telle distribution il y aura tel et tel producteur, c’était plutôt pour les admins/bénévoles.

Et ensuite quand ils valident la Période (qu’elle contienne 1 seule, 4, ou 50 distributions), les producteurs seraient notifier qu’ils peuvent définir les produits disponibles à chaque distrib.

puis à une liste de checkbox des produits du Producteur. Ce dernier coche les produits disponible et doit modifier la quantité disponible ainsi que le prix unitaire:

À priori pour cette partie les producteurs devraient juste définir quels produits seront ok pour chaque distribution de la Période (donc afficher la liste de toutes les distribs de cette période et pour chacune dire quels produits).

Le stock c’est hors scope pour moi, c’est vraiment un cas particulier pour toi mais 99% des amap vont pas gérer de stock du tout. Et le prix c’est dans la fiche Produits, donc à mettre à jour que de temps en temps, rarement. Ça me parait bizarre de redemander le prix à chaque fois, même si c’est pré-rempli à changer. Généralement un prix ça reste le même des mois voire des années. Le pain de campagne il est toujours à 3,80 depuis des années, les 6 œufs à 2,60, etc. Et PARFOIS, rarement, ya une hausse du prix, mais dans ce cas : on clique sur le produit, on va dans sa fiche, et on le modifie avec le truc habituel. Par contre faut afficher le prix de chaque pour justement pouvoir vérifier à chaque Période si c’est toujours le bon.

Vu que dans une période ya X distribs, et que dans chaque distrib il y a plus ou moins de produits, les cases à cocher ne seront pas toujours le plus simple/efficace. Un boulanger qui a 15 pains, ça ferait 15 cases pour chaque distrib. Donc déjà il faudrait sûrement des cases quand c’est moins de X éléments (7, 10…) et un select multiple avec Select2 quand c’est plus.

Et à terme il faudrait sûrement aussi des cases à cocher ou boutons du genre « Garder ce même choix pour toutes les autres distributions », pour ne faire le truc qu’une fois et copier pareil pour toutes les autres.

Mais bon pour ce premier formulaire destiné aux producteurs, il me semble que c’est juste pour faire les liens, ya rien à éditer.

  • ensuite, on s’occupe des Consommateurs : ils doivent pouvoir s’inscrire à une Distribution donnée (même principe que les Producteurs) et sélectionner les produits de tous les producteurs. On verra donc dans un second temps.

Non, les consommateurs commandent à une Période, jamais à une Distribution. Mais tu peux très bien avoir une Période qui ne contient qu’une seule Distribution si c’est ton cas… Mais la plupart du temps, ya au moins 4 distribs (période d’un mois), ou 25 (6 mois), ou 50 (un an)…

Et donc au moment de la commande, il s’agit de dire ce qu’on veut pour la Période entière, donc potentiellement X distributions d’un coup (ou une seule chez toi). Donc faudra réfléchir à l’ergonomie la plus adapté pour ça en ayant ça en tête. :slight_smile:


RastaPopoulos

Bonjour tout le monde, bonjour Brice, bonjour Rasta,
Pour éviter la confusion et les envois de conversation à tout·es sur les usages d’un plugin isolé.

  • il serait judicieux amha de réserver la liste Dev SPIP aux questions et problèmes techniques traitants du core
  • Concernant les problèmes techniques sur un plugin, il y a les tickets ou issues des plugins sur GIT sur https://git.spip.net/
  • Et concernant la documentation, le plugin a certainement sa doc sur contrib.spip.net avec son forum adjoint et toutes les aides regroupées pour que cela profite à tous
    https://contrib.spip.net/

Bref, soit j’ai rien compris, soit y’ un souci et que l’on ne vienne pas râler ensuite que l’on ne s’y retrouve pas …
++

Je n’irais pas jusque là ^^, mais tu es peut-être passée à côté du fait que lors de la fusion des listes dev et zone, on a acté que les discussion du core et des plugins (bref les contributions au code) passeraient sur dev :slight_smile:

Ok, autant pour moi.
Un plugin = une documentation sur contrib éviterait aussi de documenter par de nombreux mails et sur cet espace.
Mais bon hein, voila voila
++

Le 26/10/2021 à 21:02, touti via Discuter de SPIP a écrit :

Un plugin = une documentation sur contrib éviterait aussi de documenter par de nombreux mails et sur cet espace.

Je suis bien d’accord mais pour le coup là il ne s’agit pas d’un plugin mais d’une amorce de plugin, avec surtout juste la conception, l’architecture, de faite pour le moment. Il n’y a donc rien à documenter « pour le public », et c’est bien un projet qui est entièrement encore « en développement ». Et pour l’instant le seul endroit pour ça c’est essentiellement « la liste de zone », fusionnée désormais avec la liste « dev ».

Ceci dit, je suis d’accord que ça pourrait être ailleurs c’est même prévu : depuis longtemps je pense que Contrib doit accueillir les « projets en cours de conception », dès leur début, quand on fait des graphes, des maquettes, etc et qu’une équipe de gens intéressés se regroupent autour. Dans la refonte en cours (lentement mais sûrement :p) qu’on a prévu avec Eric, Maieul, et d’autres (Action 8 - Typologie des articles), il a été prévu que dans un projet Contrib (= une rubrique pour un projet/plugin), on puisse gérer des articles étiquetés « conception », et les distinguer de ceux de docs. Mais ce n’est pas encore en place, alors pour l’instant, les discussions de conception, qui doivent bien avoir lieu quelque part, sont encore sur la liste email. :slight_smile:


RastaPopoulos

+100 sur cette « inclusion » des docs techniques d’études préalables dans la documentation des plugins (cela facilite parfois AUSSI la compréhension du fonctionnement du plugin !

···

Le 26/10/2021 à 22:07, RastaPopoulos via Discuter de SPIP a écrit :

RastaPopoulos
Octobre 26

Le 26/10/2021 à 21:02, touti via Discuter de SPIP a écrit :

Un plugin = une documentation sur contrib éviterait aussi de documenter par de nombreux mails et sur cet espace.

… amorce de plugin, avec surtout juste la conception, l’architecture, de faite pour le moment. … ça pourrait être ailleurs c’est même prévu : depuis longtemps je pense que Contrib doit accueillir les « projets en cours de conception », dès leur début, quand on fait des graphes, des maquettes, etc et qu’une équipe de gens intéressés se regroupent autour. Dans la refonte en cours (lentement mais sûrement :p) qu’on a prévu avec Eric, Maieul, et d’autres (Action 8 - Typologie des articles), il a été prévu que dans un projet Contrib (= une rubrique pour un projet/plugin), on puisse gérer des articles étiquetés « conception », et les distinguer de ceux de docs.

Mais il EXISTE DEJA une solution intermediaire, avec l’usage du Carnet :

  • il serait extremement facile de commencer systématiquement ces echanges sur le Carnet (comme le font deja certains),
    et à la publication du plugin,l’article de conception sera déplacé (avec un mot-clé ad’hoc ou tout autre solution rappelant l’état « draft » de celui-ci) dans la nouvelle rubrique du plugin !

La seule chose a rajouter serait peut-etre de mettre en place une notification automatique aux co-auteurs de cette equipe de développement (d’une façon analogue aux forums suivis) ; notez qu’il serait aussi possible de garder ces articles en statut « redaction » en inscrivant tous les co-developpeurs comme co-auteurs !

La seule spécificité qui me paraitrait à rajouter, ce serait le versionning de documents,pour voir en diaporama les versions successives d’une piece jointe (un schema MCD, un diagramme Use Cases…)

je m’étonne :wink: que des spipeurs éprouvent le besoin de chercher un autre outil que SPIP pour un travail de rédaction-réflexion collaborative

  • En fait, c’est juste de trouver une discipline de travail d’équipe (que j’ai pratiquée sur des SPIP internes dans plusieurs boites)

Cela pourrait déboucher sur deux plugins complémentaires (mais d’usage plus général) :

  • un plugin de diaporama liant automatiquement les versions successivement téléchargées d’un document joint
  • un plugin améliorant la saisie Wiki de #TEXTE (découpé par blocs comme Wikipedia, ou/et refixant chaque nouveau paragraphe par les initiales de l’auteur de la modification…

PS désolé de réagir en retard (je suis bcp moins présent)
sur ce, je repars en bateau ~~~~~~~~


RastaPopoulos


Voir le sujet ou répondre à ce courriel pour répondre.

Pour se désabonner de ces courriels, cliquez ici.

-- 
YannX

| | Garanti sans virus. www.avast.com |
| - | - |

http://www.spippourlesnuls.fr

et +100 de plus pour ne pas balancer la citation complète d’un échange dans un mail de réponse (ratio 2 lignes VS XX linges) :slight_smile:

1 J'aime