SiteWeb:Prestations

Cette page est conservée a titre historique.

Mise a jour du site Drupal

Les problèmes principaux du site sont récapitulés sur cette page : http://www.april.org/fr/reunion-de-travail-sur-le-site-web-lors-de-lag-2008

Elle peut servir de base pour les améliorations fonctionnelles souhaitées et qui n'ont pas été résolues pour la plupart vu les problèmes créés par l'ajout de modules Drupal.

La page du wiki que nous avons préparée pour la migration est ici : La migration de Drupal 5 à Drupal 6

Une page plus générale avait été commencée, pour l'aspect fonctionnalités : SiteWeb:V2 du site Web

La liste des problèmes potentiels identifiés :

• zen_april, le thème
• gDTC, un module interne
• views, les listes générées
• panels, pour la page d'accueil
• insert_view

Le module panels ne concerne que la home page semble-t-il : http://www.april.org/

Le module views est largement utilisé. Une page récapitulative de ces views et de leur importance est ici : SiteWeb:Liste des views

Liste des tâches réalisées sur le site web

Test de mise a jour du site vers Drupal 6 en cours.

Détails ici : SiteWeb:Tests de la migration Drupal 6

Procédure utilisée : SiteWeb:Procédure de migration Drupal 5 à Drupal 6

Page de garde

Les détails sur :  Tâche n°144

La page de garde :

• http://www.april.org/
• http://staging.april.org/

Problèmes actuels :

• Les blocs sous les citations ne s'affichent pas sur deux colonnes mais sur une seule sur la home :  Tâche n°201
• L'affichage de la photo de certaines citations :  Tâche n°200
• S'il n'y a aucun évènement le bloc "Évènements à venir " disparait complètement :  Tâche n°144

Revue de presse

Vérification de la conversion de la revue de presse :

• http://www.april.org/siteduzerocom-le-jeu-ryzom-enfin-libre
• http://staging.april.org/siteduzerocom-le-jeu-ryzom-enfin-libre

Problèmes actuels :

• L'affichage des nodes de type revue de presse n'est pas conforme au niveau de la première phrase :  Tâche n°202

Views

Le détail sur :  Tâche n°143

Vérification manuelle a prévoir. Modifications possibles sur staging.april.org puis importation dans le nouveau site.

Essai de conversion des views :

• http://www.april.org/fr/revue-de-presse
• http://staging.april.org/fr/revue-de-presse

Insert_view

Problème avec le module insert view qui n'est plus maintenu : http://drupal.org/project/insert_view

Exemple de pages utilisant ce module :

• http://www.april.org/fr/articles/bibliographie.html
• http://staging.april.org/fr/articles/bibliographie.html

Pas de module équivalent.

Plusieurs options possibles

• Utiliser insert_view malgré le problème de sécurité
• Utiliser http://drupal.org/project/viewreference et customizer l'affichage (via le thème), il faut voir si c'est compatible avec les usages de insert_view
• Créer un module dédié qui fourni les pages nécessaires
• Utiliser la fonction views_embed_view (http://api.lullabot.com/views_embed_view) dans les nodes en autorisant du PHP dans le corps de node (comme c'est actuellement fait pour http://www.april.org/fr/trombinoscope.php par exemple)

Cette dernière option me semble la plus pratique. Le désavantage c'est qu'il faut donner le droit de mettre du code PHP tous les contributeurs qui doivent pouvoir éditer les pages embarquant des views.

Voir la note sur :  Tâche n°142

Un code PHP est mis en place pour palier ce problème en attendant une solution par un module. Le script de migration remplace les usage de [view:...] par du code PHP au résultat similaire (à 95%).

Re-configuration des blocs multilingues

Les détails ici :  Tâche n°145

Modification manuelle des blocs prévoir. Tests possibles sur staging.april.org mais attendre le nouveau site pour les faire.

Nodes avec du code php

Liste des nodes php : SiteWeb:Liste des pages php

Gestion des droits d'accès

La situation actuelle/le besoin pour la migration

Nous utilisons sur le site web actuellement en production (Drupal 5) les modules "Organic groups", "Organic groups access control" et "Organic groups panels". L'objectif de départ était d'utiliser ces modules pour la fonctionnalité "groupes" et pour faire du contrôle d'accès sur les pages. Mais au final on a pas réellement besoin de la fonctionnalité "groupes" et côté contrôle d'accès on a eu de grosses merdes. Il a donc été décidé de supprimer ces modules et de chercher un remplaçant pour le site en version Drupal 6.

Pour comprendre le besoin voyons les "acteurs" pouvant accéder et/ou modifier du contenu sur le site web :

1/ les visiteurs peuvent accéder à tout contenu public

2/ les adhérents peuvent accéder à du contenu réservé aux membres de l'April (par ex, un compte-rendu interne)

3/ les membres du conseil d'administration (CA) peuvent accéder à du contenu réservé au CA (par ex, un compte-rendu interne du CA)

Dans la version actuelle du site, les droits d'accès 2/ et 3/ sont gérés via les modules "Organic groups". Une page réservée aux adhérents est affectée au groupe "Espace Membres" et et une page réservée au CA est affectée au groupe "CA".

Le module de remplacement doit permettre de mettre en place un système équivalent de restriction d'accès. Le module doit être compatible avec le module views (qu'une view ne donne pas accès à un contenu normalement restreint).

Le module doit être également compatible avec la partie traduction.

En plus (si possible)

De temps en temps nous rédigeons à plusieurs structures des textes (communiqué de presse par exemple). Il serait utile dans ce cas là, pour la phase de validation finale (le brouillon étant généralement rédigé via un etherpad), de pouvoir donner accès en lecture et écriture à une page (un node) précise pour un utilisateur précis.

Limites actuelles du système de contrôle d'accès de base

Dans la version Drupal 5 du site outre "Organic groups" nous n'utilisons que la gestion de contrôle d'accès fournie de base avec Drupal. Nous avons défini différents rôles permettant de donner différents droits d'accès. Par exemple le rôle "traducteur" a les droits adéquats pour le module translation.

Nous avons aussi défini différents types de contenu, par exemple "Actualité" pour du contenu qui sera sur la home page de l'April et dans les flux rss; "Bibliographie" pour du contenu de type bibliographie (avec des champs spécifiques) ou encore "Revue de presse". Si on prend l'exemple de la revue de presse on a un "use case" non implémenté actuellement sur le site :

- un utilisateur a un rôle lui donnant les droits nécessaires pour créer une page de type "Revue de presse" (create revue_de_presse content). Cet utilisateur peut donc créer une page de type "Revue de presse". Dans le format du type "Revue de presse" partie "Workflow / Options par défaut" l'option "Publié" n'est pas activée. Il faut donc, une fois la page créée, qu'un admin du site publie la page.

Si dans le format du type "Revue de presse" partie "Workflow / Options par défaut" l'option "Publié" est activée alors l'utilisateur peut créer la page mais celle-ci est publiée immédiatement.

Il n'y a donc pas de possibilité pour un utilisateur de : créer une page "Revue de presse" sans qu'elle soit immédiatement publiée; puis modifier la page; et ultérieurement pouvoir publier lui-même la page.

Ce "use case" pose donc la question de savoir comment avoir un workflow de publication différent en fonction du type de contenu.

Modules possibles

"Taxonomy Access", "Taxonomy Access Lite", "Content access"

Voir la  Tâche n°140