[spip-dev] Proposition : champ expiration article

Bonjour, je suis amené en ce moment à devoir gérer une date supplémentaire
pour les articles spip qui puisse faire office de:
- date d'expiration pour un article
- ou date de rappel pour une éventuelle maj

Les solutions déjà proposées détournent l'usage de certains champs, ou
utilisent les champs extra.
Il ne me semble pas "bien" de détourner l'usage d'un champ, et l'utilisation
d'un blob rend difficile la gestion d'une date par le moteur de la base de
données.
Il est en effet bien de pouvoir faire faire par le moteur mysql des tris ou
des requêtes par plage sur une date.

J'ai commencé les modifications suivantes (qui fonctionnent):
- ajout d'un champ date_exp dans la table articles
- modif du fichier ecrire/articles.php3 pour afficher/gérer cette fameuse date
(argh, là, je modifie le coeur de spip)
- écriture d'une fonction (simple) qui renvoie une liste d'articles à mettre à
jour dans maintenant+nJours.

Cette modif vous semble elle utile à ajouter dans spip afin qu'elle soit dispo
dans les versions suivantes puisque je modifie le coeur?
Auquel cas, je pourrai faire encore quelques modifications pour l'intégrer
encore mieux (ajout de critère dans les boucles natives ...)

voila, Philippe.

Salut,

J'ai l'impression que spip fait *dejà* ce que tu veux...

Spip permet de publier des articles dans le futur.

As tu essayé d'afficher les articles qui sont dans le futur (ils
disparaissent donc quand la date du jour est leur date de publication ?)

Ca suffit pour ton besoin non ?

@+
BoOz

"Philippe BRESSON" <pbresson@free.fr> a écrit dans le message de
news:1084180762.409f491aae30b@imp6-q.free.fr...

Bonjour, je suis amené en ce moment à devoir gérer une date supplémentaire
pour les articles spip qui puisse faire office de:
- date d'expiration pour un article
- ou date de rappel pour une éventuelle maj

Les solutions déjà proposées détournent l'usage de certains champs, ou
utilisent les champs extra.
Il ne me semble pas "bien" de détourner l'usage d'un champ, et l'utilisation
d'un blob rend difficile la gestion d'une date par le moteur de la base de
données.
Il est en effet bien de pouvoir faire faire par le moteur mysql des tris ou
des requêtes par plage sur une date.

J'ai commencé les modifications suivantes (qui fonctionnent):
- ajout d'un champ date_exp dans la table articles
- modif du fichier ecrire/articles.php3 pour afficher/gérer cette fameuse
date
(argh, là, je modifie le coeur de spip)
- écriture d'une fonction (simple) qui renvoie une liste d'articles à mettre
à
jour dans maintenant+nJours.

Cette modif vous semble elle utile à ajouter dans spip afin qu'elle soit
dispo
dans les versions suivantes puisque je modifie le coeur?
Auquel cas, je pourrai faire encore quelques modifications pour l'intégrer
encore mieux (ajout de critère dans les boucles natives ...)

voila, Philippe.

Je ne pense pas que cela reponde au besoin, on parle ici de gerer le cycle
de vie d'un article.
C'est vrai qu'il ne manque pas grand chose à SPIP pour pouvoir jouer le role
de base documentaire, meme si ca n'est pas son but premier.
Pour cela, la date de publication ne suffit pas, il faut aussi une date de
"fin de vie".
Idéalement, on choisira donc à la publication d'un article :
- la date à laquelle il doit apparaitre
- la date à laquelle il doit disparaitre.
- le type de cycle : Selon les cas, un article est soit completement retirer
(l'annonce d'un evenement n'a plus d'interet une fois l'evenement passé),
soit à mettre à jour (une notification est envoyée par mail aux auteurs x
jours avant la date d'obsolescence de l'article)
Le deuxieme cas n'est pas facile à envisager dans SPIP, d'autant qu'on a la
possibilité de gerer plusieurs versions à l'heure actuelle.
Mais je pense qu'en mettant deja en place la fin de vie d'un article, il ne
reste pas grand chose à faire pour demander automatiquement aux redacteurs
de proposer une nouvelle version.

A mon avis, c'est à integrer dans SPIP, mais ce n'est que mon avis ...
Si il n'est pas partagé, je t'invite à faire une contrib car tu n'es pas le
premier et surement pas le dernier à avoir le besoin.
@++

PS : tu devrais jeter un oeil la dessus :
http://www.spip-contrib.net/ecrire/articles.php3?id_article=510
pour ajouter des (vrais) champs dans les tables et pouvoir les utiliser
comme critere dans les boucles ca me parait le plus adapté.

"BoOz" <caron51@wanadoo.fr> a écrit dans le message de
news:c7nig3$l4k$1@sea.gmane.org...

Salut,

J'ai l'impression que spip fait *dejà* ce que tu veux...

Spip permet de publier des articles dans le futur.

As tu essayé d'afficher les articles qui sont dans le futur (ils
disparaissent donc quand la date du jour est leur date de publication ?)

Ca suffit pour ton besoin non ?

@+
BoOz

"Philippe BRESSON" <pbresson@free.fr> a écrit dans le message de
news:1084180762.409f491aae30b@imp6-q.free.fr...

Bonjour, je suis amené en ce moment à devoir gérer une date supplémentaire
pour les articles spip qui puisse faire office de:
- date d'expiration pour un article
- ou date de rappel pour une éventuelle maj

Les solutions déjà proposées détournent l'usage de certains champs, ou
utilisent les champs extra.
Il ne me semble pas "bien" de détourner l'usage d'un champ, et

l'utilisation

d'un blob rend difficile la gestion d'une date par le moteur de la base de
données.
Il est en effet bien de pouvoir faire faire par le moteur mysql des tris

ou

des requêtes par plage sur une date.

J'ai commencé les modifications suivantes (qui fonctionnent):
- ajout d'un champ date_exp dans la table articles
- modif du fichier ecrire/articles.php3 pour afficher/gérer cette fameuse
date
(argh, là, je modifie le coeur de spip)
- écriture d'une fonction (simple) qui renvoie une liste d'articles à

mettre

"Philippe BRESSON" wrote:

Bonjour, je suis amené en ce moment à devoir gérer une date supplémentaire
pour les articles spip qui puisse faire office de:
- date d'expiration pour un article
- ou date de rappel pour une éventuelle maj

- - - - -

J'aurais aussi besoin d'un tel champ.
Dans mon cas, je pensais utiliser la date de pub. antérieure pour cela,
puisque je n'en aurai pas besoin par ailleurs.
Mais je pense qu'ajouter un champs de date en plus aux articles serait une
bonne idée..

Paolo

Content de voir que je ne suis pas le seul intéressé.
Stéphane a bien résumé le pb.
L'envoie de mails me semble difficile, mais on pourrait imaginer que chaque
rédacteur puisse avoir une petite liste avec ses articles à réviser
lorsqu'il se connecte dans l'espace privé.
Je vais proposer ce que j'ai fait en l'améliorant un petit peu.

Philippe.

"Philippe BRESSON" <pbresson@free.fr> a écrit dans le message de
news:1084180762.409f491aae30b@imp6-q.free.fr...

Bonjour, je suis amené en ce moment à devoir gérer une date supplémentaire
pour les articles spip qui puisse faire office de:
- date d'expiration pour un article
- ou date de rappel pour une éventuelle maj

Les solutions déjà proposées détournent l'usage de certains champs, ou
utilisent les champs extra.
Il ne me semble pas "bien" de détourner l'usage d'un champ, et l'utilisation
d'un blob rend difficile la gestion d'une date par le moteur de la base de
données.
Il est en effet bien de pouvoir faire faire par le moteur mysql des tris ou
des requêtes par plage sur une date.

J'ai commencé les modifications suivantes (qui fonctionnent):
- ajout d'un champ date_exp dans la table articles
- modif du fichier ecrire/articles.php3 pour afficher/gérer cette fameuse
date
(argh, là, je modifie le coeur de spip)
- écriture d'une fonction (simple) qui renvoie une liste d'articles à mettre
à
jour dans maintenant+nJours.

Cette modif vous semble elle utile à ajouter dans spip afin qu'elle soit
dispo
dans les versions suivantes puisque je modifie le coeur?
Auquel cas, je pourrai faire encore quelques modifications pour l'intégrer
encore mieux (ajout de critère dans les boucles natives ...)

voila, Philippe.

Je pense que rajouter une date de fin de vie ou de demande de vérification est important quand un site devient gros. Ça pourrait aussi être une option de rubrique. Certaines rubriques pourraient ainsi contenir des articles pérennes, et d'autres pourraient être utilisées pour des affichages à durée de validité limitée.

Je ne pense pas que ce soit liée à une utlisation déviée de Spip sous forme de base documentaire. A partir du moment où on propose plusieurs centaines d'articles, on a un problème de relecture et de màj du contenu.

cette fonction pourrait être également utilisée pour la gestion des fichiers joints. Imaginons un site qui propose de la documentation en ligne ou des formulaires à télécharger, classés par thème (commentés dans l'article. On se retrouve avec plusieurs fichiers par articles, dont certains doivent être mis à jour périodiquement (par exemple des déclarations pour l'année en cours, et seulement pour l'année en cours). L'article est pérenne, mais ces fichiers ont dans ce cas une date de fin de validité au 31 décembre de l'année en cours.