Différences entre les versions de « SiteWeb:Prestations »

De April MediaWiki
Aller à la navigationAller à la recherche
m
m
 
(25 versions intermédiaires par 5 utilisateurs non affichées)
Ligne 1 : Ligne 1 :
{{Site Web|une page}}
+
[[Catégorie:SiteWebHistorique|Prestations]]
  
[[Catégorie:SiteWeb|Prestations]]
+
{{Introduction|Cette page est conservée a titre historique.}}
  
 
=Mise a jour du site Drupal=
 
=Mise a jour du site Drupal=
Ligne 12 : Ligne 12 :
 
de modules Drupal.
 
de modules Drupal.
  
La page du wiki que nous avons préparé pour la migration est ici :
+
La page du wiki que nous avons préparée pour la migration est ici : [[La migration de Drupal 5 à Drupal 6]]
http://wiki.april.org/w/La_migration_de_Drupal_5_à_Drupal_6
 
  
Une page plus générale avait été commencée, pour l'aspect fonctionnalités :
+
Une page plus générale avait été commencée, pour l'aspect fonctionnalités : [[SiteWeb:V2 du site Web]]
http://wiki.april.org/w/SiteWeb:V2_du_site_Web
 
  
 
La liste des problèmes potentiels identifiés :
 
La liste des problèmes potentiels identifiés :
Ligne 22 : Ligne 20 :
 
* zen_april, le thème  
 
* zen_april, le thème  
 
* gDTC, un module interne  
 
* gDTC, un module interne  
* views, les listes générés
+
* views, les listes générées
 
* panels, pour la page d'accueil  
 
* panels, pour la page d'accueil  
 
* insert_view
 
* insert_view
Ligne 28 : Ligne 26 :
 
Le module panels ne concerne que la home page semble-t-il : http://www.april.org/
 
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 :
+
Le module views est largement utilisé. Une page récapitulative de ces views et de leur importance est ici : [[SiteWeb:Liste des views]]
http://wiki.april.org/w/SiteWeb:Liste_des_views
 
  
 
=Liste des tâches réalisées sur le site web=
 
=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 : {{Tache|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 : {{Tache|201}}
 +
*L'affichage de la photo de certaines citations : {{Tache|200}}
 +
*S'il n'y a aucun évènement le bloc "Évènements à venir " disparait complètement : {{Tache|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 : {{Tache|202}}
 +
 +
==Views==
 +
 +
Le détail sur : {{Tache|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 : {{Tache|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 : {{Tache|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 {{Tache|140}}

Dernière version du 10 février 2011 à 21:13


Cette page est conservée a titre historique.

Mise a jour du site Drupal[modifier]

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[modifier]

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[modifier]

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

La page de garde :

Problèmes actuels :

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

Revue de presse[modifier]

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

Problèmes actuels :

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

Views[modifier]

Le détail sur : Redmine.png 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 :

Insert_view[modifier]

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

Exemple de pages utilisant ce module :

Pas de module équivalent.

Plusieurs options possibles

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 : Redmine.png 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[modifier]

Les détails ici : Redmine.png 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[modifier]

Liste des nodes php : SiteWeb:Liste des pages php

Gestion des droits d'accès[modifier]

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 Redmine.png Tâche n°140