[SPIP Zone] Commit 113124 sur agenda

Archives Zone
1

Salut,

deux choses à propose de ce commit :

1/ je ne l'ai pas vu passer par mail, de même que 113121, 113125 et 113126

Je consulte par le newsgroupe gmane, est ce que par mail sur la liste vous les avez reçus ?

2/ tu supprimes complètement la constante, c'est peut être un peu violent non ?
Si des gens utilisaient le plugin avec cette constante positionnée, ils se retrouvent avec un plugin non fonctionnel suite à un simple z+1

https://zone.spip.net/trac/spip-zone/changeset/113124/spip-zone

--
nicod_

2

Le 26/12/2018 à 20:03, nicod_ a écrit :

2/ tu supprimes complètement la constante, c'est peut être un peu violent non ?
Si des gens utilisaient le plugin avec cette constante positionnée, ils se retrouvent avec un plugin non fonctionnel suite à un simple z+1

https://zone.spip.net/trac/spip-zone/changeset/113124/spip-zone

La constante a été ajoutée il y a deux ans :
https://zone.spip.net/trac/spip-zone/changeset/100118/spip-zone

Probable qu'il y ait des usages en cours.
Les gens vont se retrouver avec des événements qu'ils ne pourront pas modifier (ni créer).

--
nicod_

3

PS : manquent aussi les chaines de langues.

Et "Mode expert"... hum... Nomenklatura ?

--
nicod_

4

AH mais surtout JE NE VEUX PAS que ce soit une configuration du plugin !

Je vais revert car déjà la constante ne me plaisait pas, je l’ai laissé passé en me disant, fuck démerdez vous avec les bugs, mais au moins c’est le webmestre qui change ça et qui fait son squelette en conséquence et qui gère les problèmes après.

Mais que ça devienne une fonction officielle du plugin, sur laquelle il va falloir faire du support alors qu’il n’a jamais été conçu pour ça, c’est niet.
Les évènements n’ont pas de statut, ne sont pas prévus pour être autonomes et c’est comme ça qu’est conçu le plugin.
Il y a déjà un fork pour mettre des évènements partouts (que je n’ai pas suivi)

Donc peut-être il va falloir que je m’y colle vraiment pour faire une grosse revue de code, un merge, un refactoring complet ou je ne sais quoi, mais en l’état les évènements orphelins doivent rester un hack sous la resonsabilité du webmestre, pas une configuration ni une feature officielle du plugin.

--
Cédric
Le 26 déc. 2018 à 20:03 +0100, nicod_ <nicod@lerebooteux.fr>, a écrit :

Salut,

deux choses à propose de ce commit :

1/ je ne l'ai pas vu passer par mail, de même que 113121, 113125 et 113126

Je consulte par le newsgroupe gmane, est ce que par mail sur la liste
vous les avez reçus ?

2/ tu supprimes complètement la constante, c'est peut être un peu
violent non ?
Si des gens utilisaient le plugin avec cette constante positionnée, ils
se retrouvent avec un plugin non fonctionnel suite à un simple z+1

https://zone.spip.net/trac/spip-zone/changeset/113124/spip-zone

--
nicod_
----
spip-zone@rezo.net - https://listes.rezo.net/mailman/listinfo/spip-zone

5

Et je revert aussi
https://zone.spip.net/trac/spip-zone/changeset/113125/spip-zone

qui est totalement buggué puisqu’il supprime donc TOUS les évènements liés à un article si on a activé le mode orphelin
et du coup aussi
https://zone.spip.net/trac/spip-zone/changeset/113126/spip-zone
qui n’a plus lieu d’être, et je réincrémente un coup au cas où il y aurait des versions dans la nature.

Merci de discuter de tout cela sur la zone avant, car cela modifie fondamentalement la nature et le fonctionnement du plugin.

(On a vu passer aucun de ces commits, il y a un soucis avec le notification ?)

--
Cédric
Le 27 déc. 2018 à 10:21 +0100, Cerdic <cedric@yterium.com>, a écrit :

AH mais surtout JE NE VEUX PAS que ce soit une configuration du plugin !

Je vais revert car déjà la constante ne me plaisait pas, je l’ai laissé passé en me disant, fuck démerdez vous avec les bugs, mais au moins c’est le webmestre qui change ça et qui fait son squelette en conséquence et qui gère les problèmes après.

Mais que ça devienne une fonction officielle du plugin, sur laquelle il va falloir faire du support alors qu’il n’a jamais été conçu pour ça, c’est niet.
Les évènements n’ont pas de statut, ne sont pas prévus pour être autonomes et c’est comme ça qu’est conçu le plugin.
Il y a déjà un fork pour mettre des évènements partouts (que je n’ai pas suivi)

Donc peut-être il va falloir que je m’y colle vraiment pour faire une grosse revue de code, un merge, un refactoring complet ou je ne sais quoi, mais en l’état les évènements orphelins doivent rester un hack sous la resonsabilité du webmestre, pas une configuration ni une feature officielle du plugin.

--
Cédric
Le 26 déc. 2018 à 20:03 +0100, nicod_ <nicod@lerebooteux.fr>, a écrit :
> Salut,
>
> deux choses à propose de ce commit :
>
> 1/ je ne l'ai pas vu passer par mail, de même que 113121, 113125 et 113126
>
> Je consulte par le newsgroupe gmane, est ce que par mail sur la liste
> vous les avez reçus ?
>
> 2/ tu supprimes complètement la constante, c'est peut être un peu
> violent non ?
> Si des gens utilisaient le plugin avec cette constante positionnée, ils
> se retrouvent avec un plugin non fonctionnel suite à un simple z+1
>
> https://zone.spip.net/trac/spip-zone/changeset/113124/spip-zone
>
>
> --
> nicod_
> ----
> spip-zone@rezo.net - https://listes.rezo.net/mailman/listinfo/spip-zone
----
spip-zone@rezo.net - https://listes.rezo.net/mailman/listinfo/spip-zone

6

AH mais non : Tout ça a été ajouté ces derniers jours

On a donc deux gros problèmes :

* la modif brutale et non discutée du principe même du fonctionnement du plugin sur la zone (je crois comprendre que c’est un report de je sais plus quelle branche, si ça n’était pas dans le trunk c’est bien pour une bonne raison)

* l’absence totale de notifications

sans le message de nicod je passais totalement à travers et ce truc était gravé dans le marbre !

J’ai l’impression que c’est lié à tes commits uniquement, Camille, peut-être un soucis lié à git-svn/subgit ou whatever tu utilises ?

--
Cédric
Le 27 déc. 2018 à 10:29 +0100, Cerdic <cedric@yterium.com>, a écrit :

Et je revert aussi
https://zone.spip.net/trac/spip-zone/changeset/113125/spip-zone

qui est totalement buggué puisqu’il supprime donc TOUS les évènements liés à un article si on a activé le mode orphelin
et du coup aussi
https://zone.spip.net/trac/spip-zone/changeset/113126/spip-zone
qui n’a plus lieu d’être, et je réincrémente un coup au cas où il y aurait des versions dans la nature.

Merci de discuter de tout cela sur la zone avant, car cela modifie fondamentalement la nature et le fonctionnement du plugin.

(On a vu passer aucun de ces commits, il y a un soucis avec le notification ?)

--
Cédric
Le 27 déc. 2018 à 10:21 +0100, Cerdic <cedric@yterium.com>, a écrit :
> AH mais surtout JE NE VEUX PAS que ce soit une configuration du plugin !
>
> Je vais revert car déjà la constante ne me plaisait pas, je l’ai laissé passé en me disant, fuck démerdez vous avec les bugs, mais au moins c’est le webmestre qui change ça et qui fait son squelette en conséquence et qui gère les problèmes après.
>
> Mais que ça devienne une fonction officielle du plugin, sur laquelle il va falloir faire du support alors qu’il n’a jamais été conçu pour ça, c’est niet.
> Les évènements n’ont pas de statut, ne sont pas prévus pour être autonomes et c’est comme ça qu’est conçu le plugin.
> Il y a déjà un fork pour mettre des évènements partouts (que je n’ai pas suivi)
>
> Donc peut-être il va falloir que je m’y colle vraiment pour faire une grosse revue de code, un merge, un refactoring complet ou je ne sais quoi, mais en l’état les évènements orphelins doivent rester un hack sous la resonsabilité du webmestre, pas une configuration ni une feature officielle du plugin.
>
> --
> Cédric
> Le 26 déc. 2018 à 20:03 +0100, nicod_ <nicod@lerebooteux.fr>, a écrit :
> > Salut,
> >
> > deux choses à propose de ce commit :
> >
> > 1/ je ne l'ai pas vu passer par mail, de même que 113121, 113125 et 113126
> >
> > Je consulte par le newsgroupe gmane, est ce que par mail sur la liste
> > vous les avez reçus ?
> >
> > 2/ tu supprimes complètement la constante, c'est peut être un peu
> > violent non ?
> > Si des gens utilisaient le plugin avec cette constante positionnée, ils
> > se retrouvent avec un plugin non fonctionnel suite à un simple z+1
> >
> > https://zone.spip.net/trac/spip-zone/changeset/113124/spip-zone
> >
> >
> > --
> > nicod_
> > ----
> > spip-zone@rezo.net - https://listes.rezo.net/mailman/listinfo/spip-zone
> ----
> spip-zone@rezo.net - https://listes.rezo.net/mailman/listinfo/spip-zone
----
spip-zone@rezo.net - https://listes.rezo.net/mailman/listinfo/spip-zone

7

Revert par https://zone.spip.org/trac/spip-zone/changeset/113130 donc, désolé

--
Cédric
Le 27 déc. 2018 à 10:37 +0100, Cerdic <cedric@yterium.com>, a écrit :

AH mais non : Tout ça a été ajouté ces derniers jours

On a donc deux gros problèmes :

* la modif brutale et non discutée du principe même du fonctionnement du plugin sur la zone (je crois comprendre que c’est un report de je sais plus quelle branche, si ça n’était pas dans le trunk c’est bien pour une bonne raison)

* l’absence totale de notifications

sans le message de nicod je passais totalement à travers et ce truc était gravé dans le marbre !

J’ai l’impression que c’est lié à tes commits uniquement, Camille, peut-être un soucis lié à git-svn/subgit ou whatever tu utilises ?

--
Cédric
Le 27 déc. 2018 à 10:29 +0100, Cerdic <cedric@yterium.com>, a écrit :
> Et je revert aussi
> https://zone.spip.net/trac/spip-zone/changeset/113125/spip-zone
>
> qui est totalement buggué puisqu’il supprime donc TOUS les évènements liés à un article si on a activé le mode orphelin
> et du coup aussi
> https://zone.spip.net/trac/spip-zone/changeset/113126/spip-zone
> qui n’a plus lieu d’être, et je réincrémente un coup au cas où il y aurait des versions dans la nature.
>
> Merci de discuter de tout cela sur la zone avant, car cela modifie fondamentalement la nature et le fonctionnement du plugin.
>
> (On a vu passer aucun de ces commits, il y a un soucis avec le notification ?)
>
> --
> Cédric
> Le 27 déc. 2018 à 10:21 +0100, Cerdic <cedric@yterium.com>, a écrit :
> > AH mais surtout JE NE VEUX PAS que ce soit une configuration du plugin !
> >
> > Je vais revert car déjà la constante ne me plaisait pas, je l’ai laissé passé en me disant, fuck démerdez vous avec les bugs, mais au moins c’est le webmestre qui change ça et qui fait son squelette en conséquence et qui gère les problèmes après.
> >
> > Mais que ça devienne une fonction officielle du plugin, sur laquelle il va falloir faire du support alors qu’il n’a jamais été conçu pour ça, c’est niet.
> > Les évènements n’ont pas de statut, ne sont pas prévus pour être autonomes et c’est comme ça qu’est conçu le plugin.
> > Il y a déjà un fork pour mettre des évènements partouts (que je n’ai pas suivi)
> >
> > Donc peut-être il va falloir que je m’y colle vraiment pour faire une grosse revue de code, un merge, un refactoring complet ou je ne sais quoi, mais en l’état les évènements orphelins doivent rester un hack sous la resonsabilité du webmestre, pas une configuration ni une feature officielle du plugin.
> >
> > --
> > Cédric
> > Le 26 déc. 2018 à 20:03 +0100, nicod_ <nicod@lerebooteux.fr>, a écrit :
> > > Salut,
> > >
> > > deux choses à propose de ce commit :
> > >
> > > 1/ je ne l'ai pas vu passer par mail, de même que 113121, 113125 et 113126
> > >
> > > Je consulte par le newsgroupe gmane, est ce que par mail sur la liste
> > > vous les avez reçus ?
> > >
> > > 2/ tu supprimes complètement la constante, c'est peut être un peu
> > > violent non ?
> > > Si des gens utilisaient le plugin avec cette constante positionnée, ils
> > > se retrouvent avec un plugin non fonctionnel suite à un simple z+1
> > >
> > > https://zone.spip.net/trac/spip-zone/changeset/113124/spip-zone
> > >
> > >
> > > --
> > > nicod_
> > > ----
> > > spip-zone@rezo.net - https://listes.rezo.net/mailman/listinfo/spip-zone
> > ----
> > spip-zone@rezo.net - https://listes.rezo.net/mailman/listinfo/spip-zone
> ----
> spip-zone@rezo.net - https://listes.rezo.net/mailman/listinfo/spip-zone
----
spip-zone@rezo.net - https://listes.rezo.net/mailman/listinfo/spip-zone

8

Salut

Pour l'absence des mails je regarde ce qu'il se passe. Le hook qui
gère les notifications s'occupe aussi de shiraz et les notifications
IRC sont bien passées.

Avant de reporter la branche sur le trunk j'ai tenté de la remettre à
niveau, il y a avait trop de retard pour que ce soit possible. Il
était plus propre de faire dans l'autre sens, les modifications étant
plutôt mineures. Il me semblait donc moins risqué d'intégrer cette
fonctionnalité que chercher à maintenir un fork moisi.
Je note aussi que le fait d'avoir abandonner cette fonctionnalité, la
fusion a révélé des régressions qu'on n'aurait pas eu si dès le début
on avait pris en compte ce besoin.

La conversion du define fait suite à 2 points, la branche d'origine
est morte (non modifiée depuis des années, numéro de version
incohérent, ...) donc avec une probabilité d'usage actif faible et la
problématique de https://core.spip.net/issues/4102 qui bloque l'usage
propre des define. Enfin convertir un define en config est
relativement facile cela ne m'a pas pas semblé bloquant.

Je ne suis pas d'accord sur le choix arbitraire de forcer un événement
à un article, et je ne suis pas le seul vu que le fork existe.
L'expérience montre que la logique de parenté forcée peut poser des
problèmes et des réponses imparfaites (page unique par exemple).

Comme le besoin est licite comment faire pour intégrer intelligemment
cette réponse et que tout le monde s'y retrouve ?

Camille

9

Le 27/12/2018 à 10:21, Cerdic a écrit :

Donc peut-être il va falloir que je m’y colle vraiment pour faire une grosse revue de code, un merge, un refactoring complet ou je ne sais quoi, mais en l’état les évènements orphelins doivent rester un hack sous la resonsabilité du webmestre, pas une configuration ni une feature officielle du plugin.

C'est un besoin régulièrement exprimé, et je ne suis pas sûr qu'il faille s'acharner sur ce "vieux" code.
Je pense qu'il faudrait repartir from scratch sur un nouveau plugin ou une nouvelle version, avec un objet éditorial à part entière (avec son statut et ses urls propres), et récupérer les filtres et les critères existant.
Ça me parait pas énorme et je m'y collerais bien.

Il faudrait surtout se mettre d'accord sur le cahier des charges.
Est ce que ça devrait être compatible avec l'actuel, c'est à dire prévoir une migration des données ?
C'est à dire continuer à gérer des rubriques agenda et des événements liés à des articles ?
C'était une contrainte historique, ça ne l'est plus, et cette logique éditoriale est trop contraignante.
Dans cette optique, je serais plus pour faire un nouveau plugin (pas une nouvelle version).

Des avis ?

--
nicod_

10

Le 27/12/2018 à 15:23, nicod_ a écrit :

Il faudrait surtout se mettre d'accord sur le cahier des charges.
Est ce que ça devrait être compatible avec l'actuel, c'est à dire prévoir une migration des données ?
C'est à dire continuer à gérer des rubriques agenda et des événements liés à des articles ?
C'était une contrainte historique, ça ne l'est plus, et cette logique éditoriale est trop contraignante.
Dans cette optique, je serais plus pour faire un nouveau plugin (pas une nouvelle version).

Ou pas. Avec une table evenements_liens, on peut reproduire le fonctionnement historique et faire une migration pour les habitués, tout en ayant plus de souplesse pour faire des événements autonomes.

--
nicod_

11

S'il est possible de faire évoluer en maintenant la rétro-compatiblité
ça me semble mieux, plutôt qu'un nouveau plugin qui fait presque tout
pareil mais qui ne serait pas le même.
En tout cas je me joins à la demande d'évènements autonomes :slight_smile:

Le 27/12/2018 à 15:38, nicod_ a écrit :

Ou pas. Avec une table evenements_liens, on peut reproduire le
fonctionnement historique et faire une migration pour les habitués,
tout en ayant plus de souplesse pour faire des événements autonomes.

12

Salut,

gros utilisateur du plugin Agenda (sites de structures culturelles avec programmation d'événements par saison), je suis plutôt garder la compatibilité aussi et, s'il y a nouveau cahier des charges, je veux bien y apporter mes 2 sous...

             jean marie

Le 27/12/2018 à 15:46, Charles Razack a écrit :

S'il est possible de faire évoluer en maintenant la rétro-compatiblité
ça me semble mieux, plutôt qu'un nouveau plugin qui fait presque tout
pareil mais qui ne serait pas le même.
En tout cas je me joins à la demande d'évènements autonomes :slight_smile:

Le 27/12/2018 à 15:38, nicod_ a écrit :

Ou pas. Avec une table evenements_liens, on peut reproduire le
fonctionnement historique et faire une migration pour les habitués,
tout en ayant plus de souplesse pour faire des événements autonomes.

13

Le 27/12/2018 à 16:25, Jean Marie Grall a écrit :

gros utilisateur du plugin Agenda (sites de structures culturelles avec programmation d'événements par saison), je suis plutôt garder la compatibilité aussi et, s'il y a nouveau cahier des charges, je veux bien y apporter mes 2 sous...

Le cahier des charges serait donc de pouvoir gérer des événements comme objets autonomes, avec statuts et urls propres, avec une table de liens qui permette de les attacher à d'autres objets (articles, rubriques, patates...), et une reprise iso-fonctionnelle avec migration des données de l'existant.
Ça me parait déjà un objectif assez conséquent pour une première nouvelle version :slight_smile:

--
nicod_

14

Le jeu. 27 déc. 2018 à 16:46, nicod_ <nicod@lerebooteux.fr> a écrit :

Le 27/12/2018 à 16:25, Jean Marie Grall a écrit :

gros utilisateur du plugin Agenda (sites de structures culturelles avec
programmation d’événements par saison), je suis plutôt garder la
compatibilité aussi et, s’il y a nouveau cahier des charges, je veux
bien y apporter mes 2 sous…

Le cahier des charges serait donc de pouvoir gérer des événements comme
objets autonomes, avec statuts et urls propres, avec une table de liens
qui permette de les attacher à d’autres objets (articles, rubriques,
patates…), et une reprise iso-fonctionnelle avec migration des données
de l’existant.
Ça me parait déjà un objectif assez conséquent pour une première
nouvelle version :slight_smile:

Hello,
Le tout est de savoir le préfixe et le nom de ce nouveau plugin. Doit-on garder le même nom des tables ?

Ybbet.

–
nicod_

spip-zone@rezo.net - https://listes.rezo.net/mailman/listinfo/spip-zone

15

Le 27/12/2018 à 17:23, Ybbet Spip a écrit :

Hello,
Le tout est de savoir le préfixe et le nom de ce nouveau plugin. Doit-on garder le même nom des tables ?

Non, je concluais que ce serait mieux de faire une v4.0 justement, avec compat ascendante.
Mais refaite from scratch.

--
nicod_

16

Hello,

je suis d’accord que repartir d’une base propre/neuve/fabrique pour l’objet éditorial évènement sera une bonne chose, rendant conforme un certain nombre de choses.

La migration des données à l’install du plugin, c’est assez easy.

Ensuite ce qui risque de prendre pas mal de temps c’est gérer
* les particularités d’interface,
* le cas particulier du statut : actuellement un évènement lié à un article publié est automatiquement publié, doit on conserver cet automatisme historique ou décider qu’on devra faire double publication ?
* assurer la compat des boucles existantes (jointures et critères) pour ne pas casser les squelettes. Probablement que pour ce point il serait judicieux de collecter dans un dossier des squelettes de test avec les usages que chacun a fait des boucle EVENEMENTS et des critères du plugin, pour avoir une couverture fonctionnelle assez large et permettre de tester tous ces cas (typiquement 2 sites en parallèle, bases de départ identiques et ancienne vs nouvelle version du plugin et comparer les sorties)

L’idéal étant qu’on puisse faire un upgrade de plugin vers la nouvelle v4 toute neuve sans impact sur un site existant, même si, ensuite, le fonctionnement dans le back-office change un peu.

Donc bref, un peu de boulot, oui :slight_smile:

Mais pour répondre à la question initiale de Camille, ça me parait en effet le seul chemin d'évolution viable, car commencer à patcher le plugin actuel pour rendre les évènements autonomes ne va que conduire à un entrelas de bugs dans les différentes situations, parce que le plugin est de base explicitement conçu pour des évènements non autonomes.

--
Cédric
Le 27 déc. 2018 à 16:45 +0100, nicod_ <nicod@lerebooteux.fr>, a écrit :

Le 27/12/2018 à 16:25, Jean Marie Grall a écrit :
> gros utilisateur du plugin Agenda (sites de structures culturelles avec
> programmation d'événements par saison), je suis plutôt garder la
> compatibilité aussi et, s'il y a nouveau cahier des charges, je veux
> bien y apporter mes 2 sous...

Le cahier des charges serait donc de pouvoir gérer des événements comme
objets autonomes, avec statuts et urls propres, avec une table de liens
qui permette de les attacher à d'autres objets (articles, rubriques,
patates...), et une reprise iso-fonctionnelle avec migration des données
de l'existant.
Ça me parait déjà un objectif assez conséquent pour une première
nouvelle version :slight_smile:

--
nicod_
----
spip-zone@rezo.net - https://listes.rezo.net/mailman/listinfo/spip-zone

17

Le 28/12/2018 à 10:02, Cerdic a écrit :

* le cas particulier du statut : actuellement un évènement lié à un
article publié est automatiquement publié, doit on conserver cet
automatisme historique ou décider qu’on devra faire double publication ?

Pour ce point, peut-être que ça pourrait être une option dans la config
du plugin (là à priori dans l'interface, car c'est un choix éditorial,
pas juste technique). Ils auraient un champ de statut autonome, que l'on
peut modifier, mais il y aurait une option
- Les événements sont publiés automatiquement si liés à au moins un
contenu publié
Ou inversement, si on veut que ce soit le défaut
- Les événements ne suivent pas la publication des contenus liés

Et on continue de pouvoir le modifier après coup, si on veut en
dépublier un unitairement.

--
RastaPopoulos

18

Le 28/12/2018 à 12:55, RastaPopoulos a écrit :

Le 28/12/2018 à 10:02, Cerdic a écrit :

* le cas particulier du statut : actuellement un évènement lié à un
article publié est automatiquement publié, doit on conserver cet
automatisme historique ou décider qu’on devra faire double publication ?

Pour ce point, peut-être que ça pourrait être une option dans la config
du plugin (là à priori dans l'interface, car c'est un choix éditorial,
pas juste technique). Ils auraient un champ de statut autonome, que l'on
peut modifier, mais il y aurait une option
- Les événements sont publiés automatiquement si liés à au moins un
contenu publié
Ou inversement, si on veut que ce soit le défaut
- Les événements ne suivent pas la publication des contenus liés

Effectivement, c'est un choix éditorial et ça demanderait une config, je m'étais fait la même réflexion.

En même temps, est il logique qu'un événement publié lié à un article non publié soit quand même visible sur le site ?
Oui, si on prend le parallèle avec les documents ou les auteurs publiés, associés à des articles non publiés.

Et on continue de pouvoir le modifier après coup, si on veut en
dépublier un unitairement.

Dans les deux cas de config donc, puisque les événements auraient un statut indépendant.
Ce qui me semble complet.

C'était un message du F.L.E. [1]

[1] : Front de Libération des Evénements

--
nicod_

19

Salut,

Le 27/12/2018 à 16:45, nicod_ a écrit :

Le 27/12/2018 à 16:25, Jean Marie Grall a écrit :

gros utilisateur du plugin Agenda (sites de structures culturelles avec programmation d'événements par saison), je suis plutôt garder la compatibilité aussi et, s'il y a nouveau cahier des charges, je veux bien y apporter mes 2 sous...

Le cahier des charges serait donc de pouvoir gérer des événements comme objets autonomes, avec statuts et urls propres, avec une table de liens qui permette de les attacher à d'autres objets (articles, rubriques, patates...), et une reprise iso-fonctionnelle avec migration des données de l'existant.
Ça me parait déjà un objectif assez conséquent pour une première nouvelle version :slight_smile:

c'est déjà un bon début, effectivement :slight_smile:

Mais j'ai déjà qqs questions qui me viennent :

Comment seront gérés les récurrences ou les événements qui ont lieu plusieurs fois ?
Je me rends bien compte que je mélange le terme événement au sens SPIP et au sens plus commun, donc si je reformule : comment gère-t'on les spectacles qui jouent plusieurs fois sans avoir à dupliquer les contenus dans plusieurs objets événements (au sens SPIP) ? Aussi, il faut que sur la page d'un spectacle, je puisse voir toutes les dates.

Jusqu'à présent, j'avais un article avec le contenu (nom du spectacle, description, visuel...) et un ou des événement(s) lié(s) pour chaque représentation.

Autre question (sans doute plus accessoire) : comment conserver la notion de saisons/années ?
Pour une structure culturelle, il y a 2 besoins : voir les prochains spectacles (= les spectacles à venir) et voir les spectacles de la saison (= tous les spectacles de la saison, même ceux déjà passés). Un saison correspond généralement à une année scolaire (septembre > aout), mais peut importe.

Jusqu'à présent, je rangeais les articles par rubrique et chaque rubrique correspondait à une saison.

Voilà pour mes qqs interrogations...

Le fonctionnement actuel (articles + événements) peut être contre-intuitif pour l'utilisateur : le nom du spectacle va dans l'article ou dans l'événement ? Idem pour le lieu... donc un fonctionnement par objet événement me parait pertinent mais pose (à minima) ces 2 questions.

Bon week end,

             jeanmarie
20

Le 29/12/2018 à 11:37, Jean Marie Grall a écrit :

comment gère-t'on les spectacles qui jouent plusieurs fois sans avoir à
dupliquer les contenus dans plusieurs objets événements (au sens SPIP) ?
Aussi, il faut que sur la page d'un spectacle, je puisse voir toutes les
dates.

Jusqu'à présent, j'avais un article avec le contenu (nom du spectacle,
description, visuel...) et un ou des événement(s) lié(s) pour chaque
représentation.

Bé t'es pas obligé de faire ça… Ya déjà une notion de multi-date là pour
l'objet événement, avec le même événement.

Le problème c'est qu'on ne peut que mettre des *jours* différents mais
il faut que tout le reste soit pareil, si jamais ya des *heures*
différentes aussi là c'est pas possible.

--
RastaPopoulos