Recherche avancée

Sur d’autres sites (6184)

• Inscriptions3 + Champs Extra

  6 août 2018

  Bonjour,

  Voici quelques points liées à l’utilisation de Champs Extra dans Inscription 3. Je vais détailler un peu mais dans l’idée, il s’agit d’adapter l’affichage de champs ou de leur valeur selon leur nature (input, radio, select ou fieldset), pour l’heure cela semble bien pensé pour les inputs et textarea, mais pour le reste ça pèche un peu.

  Page des utilisateurs (ecrire/ ?exec=inscription3_adherents) :

  Bug :
  Les champs fieldset et explication provoque une erreur alors qu’il devrait être ignorer. Il va de soit qu’on ne devrait pas cocher la colonne ’table’ pour ces champs dans la page de configuration, mais malheureusement c’est une erreur fréquente.

  Soucis d’affichage :

  1. Pour les selects, les entêtes des colonnes sont erronées, on voit par exemple ’label_nom_champs’ au lieu du nom du champs
  2. Pour les selects, on voit dans les cellules du tableau et non des valeurs
  3. Les dates sont au format SQL, pas si simple à lire pour les utilisateurs.

  Page de configuration (ecrire/ ?exec=configurer_inscription3) :

  Bug :

  • Dans la première colonne dans la partie des champs extras, le label est vide pour les checkbox, impossible de les identifier sinon par l’ordre dans la liste.
  • Idem avec les champs ’explication’
  • Il faut supprimer les cases à cocher de la colonne ’Table’ pour les champs ’explication’ et ’fieldset’, ils créés l’erreur fatales dans la page des utilisateurs.
  • Il faut supprimer les cases à cocher de la colonne ’Obligatoire’ pour les champs ’explication’ et ’fieldset’, car si ils sont cochés, le formulaire d’inscription ne pas être validé par l’utilisateur, c’est une erreur fréquente chez moi...

  Groupe de champs :

  Par le passé, j’ai voulu exploiter les fieldsets (Groupe de champs) de champs extra, pour grouper des champs...
  Malheureusement, cela ne semble pas être pris en charge par Inscription3.
  Les champs groupés disparaissent de la page de configuration, ils en deviennent inconfigurable...
  Et on perds les options d’affichage conditionnel par groupe par exemple...

  Vous pouvez compter sur moi pour des tests suite à la correction de ces bugs.

  Merci d’avance,

  Jul

• Anomalie #4155 : la fonction roles_presents ne fonctionne pas correctement

  27 juin 2018, par Michel Bystranowski

  Mmmm, à me relire, c’est vrai que je n’ai pas été clair du tout… Je réessaie :

  Pour donner les roles possible pour un lien entre deux types d’objets, la fonction roles_presents se base sur la « table des tables », qui est retournée par la fonction lister_tables_objets_sql. C’est de cette liste dont je veux parler quand je parle de « liste des tables ».

  Cette « table des tables » est très grande, donc dans mon exemple je ne montre qu’une partie : la clé "roles_objets" de la table "spip_documents". On y définit les rôles possibles pour les liens avec les autres objets éditoriaux SPIP. Il peut y avoir des index par objets éditoriaux et/ou un ’*’.

  Enfin en écrivant tout ça, je vérifie et je me rend compte que ça n’est pas un bug dans SPIP, mais dans mon plugin logos_roles. C’est lui qui utilise des index du type "spip_articles" au lieu de "articles", alors que la doc des rôles sur contrib dit l’inverse (https://contrib.spip.net/Des-roles-sur-des-liens).

  Et donc il n’y a pas de bug (dans SPIP :-)), et on peut fermer le ticket, désolé pour la fausse alerte.

• Anomalie #4155 (Fermé) : la fonction roles_presents ne fonctionne pas correctement

  26 juin 2018, par Michel Bystranowski

  Soit une liste des tables des objets de SPIP de la forme :

  array(
      /* ... */
      ’spip_documents’ => array(
          /* ... */
          ’roles_objets’ => array(
              ’*’ => array(
                  ’choix’ => array(
                      ’logo’,
                      ’logo_survol’,
                  ),
                  ’defaut’ => ’document’,
                  ’principaux’ => array(
                      ’logo’,
                      ’logo_survol’,
                  ),
              ),
              /* ... */
              ’spip_articles’ => array(
                  ’choix’ => array(
                      ’logo’,
                      ’logo_survol’,
                      ’logo_perso’,
                  ),
                  ’defaut’ => ’document’,
                  ’principaux’ => array(
                      ’logo’,
                      ’logo_survol’,
                      ’logo_perso’,
                  ),
              ),
              /* ... */
          ),
          /* ... */
      ),
      /* ... */
  ) ;
  

  dans ce cas, l’appel à la fonction :

  roles_presents(’document’, ’article’) ;
  

  devrait retourner les trois rôles, logo, logo_survol et logo_perso. Or elle ne retourne que les roles logo et logo_survol.

  Le problème se trouve ici : https://core.spip.net/projects/spip/repository/entry/spip/ecrire/inc/roles.php#L80

  La fonction a utiliser est "table_objet_sql", au lieu de "table_objet", puisque les clés du tableau sont du type "spip_blablas", et pas simplement "blablas".