Get notified on changes related to a topic

[benel]

Description

A given user, interested in a topic, could register to a topic in order to be notified whenever a new item is described by this topic or one of this children.

What is the valuable outcome that cannot be achieved with current features?

For which stakeholder (people, role, project, domain) is it important?

Suggested by @heliacerbonne for the open-access project.

Which user action should be enabled (or restricted)? For who?

Additional details (solutions you think about, or workarounds you tried)

Deliverables status

Phase 1

• Scenarios (Gherkin)
• Mockups
• Implementation strategy

Phase 2

• Acceptance tests (Capybara)
• Implementation

Phase 3

• Screencast

[garnier5]

For "studies abroad" project, it would be interesting to be informed at the end of each semester when new courses have been add to a topic (by school, or by spacialization), especially by e-mail.

[Gaetanherry]

Cela peut être utile pour les retours d'expérience pour ne rien rater sur un topic donné

[YaellePihan]

Cela peut être utile pour les retours d'expérience pour ne rien rater sur un topic donné

Besoin identique

[benel]

Besoin identique

@YaellePihan @Hypertopic/cite-du-vitrail Pourriez-vous expliciter une situation concrète dans votre domaine ? Qui ? À propos de quoi ? Pourquoi ?

[JacquesMironneau]

Pour le groupe "EUT+" nous pensons qu'il serait intéressant de suivre des formations (exemple ISI, RT, ou autre à l'étranger) ou des domaines (informatique,...) de cette manière il pourrait on pourrait voir les ajouts de matières ou les modifications dans une formation/un domaine qui nous intéresse.

[YaellePihan]

Projet Cité du vitrail (Orienté communication) :
Nous pensons que ce ticket permettant de s’inscrire à un thème ou sous-thème de Porphyry serait intéressant pour tous les utilisateurs à la recherche de vitraux sur des thèmes spécifiques. Ils pourraient ainsi être notifiés de l’ajout de vitraux dans le portfolio.

[benel]

Nous pensons que ce ticket permettant de s’inscrire à un thème ou sous-thème de Porphyry serait intéressant pour tous les utilisateurs à la recherche de vitraux sur des thèmes spécifiques. Ils pourraient ainsi être notifiés de l’ajout de vitraux dans le portfolio.

@YaellePihan @Hypertopic/cite-du-vitrail Effectivement... Pourquoi pas... D'ici la prochaine semaine, pour votre maquette, il faudra que vous réfléchissiez à un exemple de sujet qui pourrait de manière réaliste intéresser les gens qui suivent la Cité du vitrail sur les réseaux (inspirez-vous peut-être de leurs commentaires sur Facebook ou Instagram... mais j'ai l'impression qu'ils sont assez timides et discrets...).

[lildelfino]

Pour "graine d'artiste" cela permettrait aux "spectateurs" d'être notifié que lorsque le sujet de l'oeuvre les intéressent.

[benel]

Pour "graine d'artiste" cela permettrait aux "spectateurs" d'être notifié que lorsque le sujet de l'oeuvre les intéressent.

@lildelfino @Hypertopic/graines-d-artistes-1
D'accord. N'oubliez pas de trouver un exemple (plus l'exemple sera bien choisi et plus votre fonctionnalité aura des chances d'être bien classée).

[benel]

OK @cedricleandres. C'est beaucoup plus clair.

Pour la présentation à l'oral, il faudra peut-être dire tout haut ce à quoi les gens vont penser, pour les rassurer : lorsque l'on voit la source XML du flux avec InoReader, expliciter le fait que l'affichage de ce XML n'est évidemment pas très parlant et que c'est un choix un peu surprenant de InoReader, mais que l'on peut être rassuré : on n'a pas besoin de le lire et qu'ensuite, une fois abonné, les données sont mises en forme dans une jolie interface...

[cedricleandres]

Bonjour, voici la stratégie d'implémentation à laquelle nous avons réfléchi avec @maelht :

L’idée générale pour implémenter cette fonctionnalité serait de créer un flux RSS pour chaque topic du site, afin que n’importe qui puisse les récupérer et le consulter via des agrégateurs de flux RSS comme Feedly, Ino reader, etc… .

Quelle partie du code sera impactée (classes, méthodes) ?

La première chose à faire est de créer le bouton permettant au visiteur de récupérer le flux.
Il faut donc ajouter une nouvelle classe FluxRSS afin de définir les différentes méthodes du flux. On ajoutera ensuite un bouton dans la classe Header.jsx.

Le bouton donne un lien comme https://dessins.porphyry.org/rss, qui sera une page permettant de choisir de s'abonner soit à un corpus, ou soit à un topic. Ensuite si on s’intéresse uniquement à notre fonctionnalité, et si nous nous abonnons à un topic en particulier, nous aurons un lien vers le fichier XML lié au flux RSS du topic par exemple : https://dessins.porphyry.org/rss/Lauréat.xml

Ensuite il faudra :
Écrire une fonction (probablement dans un nouveau fichier .js dans le dossier src) de création de flux (voir librairie utilisée)
Écrire une fonction qui transforme les informations d’un items en un fichier XML compatible avec un lecteur de flux RSS (voir librairie utilisée). Ainsi à chaque création d’un nouvel item la fonction sera appelée, mais aussi à chaque modification d’un item.
Cette fonction sera implémentée dans la classe Item (item.jsx) pour avoir facilement accès aux attributs et être facilement appelée quand on en a besoin. En effet, elle serait appelée dans les fonctions de construction et de modification d’un item.

Si le code est fonctionnel, un fichier xml pour le feed créé sera mis à jour à chaque modification/création d’un item, permettant, à partir d’un agrégateur de flux rss, d’avoir un aperçu de l’item et un lien vers porphyry pour constater les changements.

Y aura-t-il des difficultés d'un point de vue algorithmique ? Avez-vous des pistes pour les résoudre ?

Non, la difficulté réside plus dans l’organisation des fichiers, des classes et des méthodes que dans un quelconque algorithme.

Les données dont vous avez besoin sont-elles déjà chargées par la page ? Si oui, quelle est la structure des données et comment allez-vous récupérer précisément celles qui vous intéressent ? Si non, quelle sera la requête la plus efficace et comment allez-vous récupérer dans la structure de données précisément celles qui vous intéressent ?

Les données envoyées sont celles entrées à la création d’un item, quand l’item est créé on peut donc directement les récupérer pour créer notre flux RSS avant de les envoyer dans la bdd.
Lors de la modification d'un item, nous récupérerons le ou les topics modifiés et une variable record_modified (l'heure de modification) qui permettra d'établir une classification chronologique des items.

Existe-t-il des bibliothèques qui pourraient simplifier l'implémentation ?

Il existe la bibliothèque https://github.com/phi-jp/rss-generator . Cette bibliothèque JS permet de simplifier la génération de fichier XML adaptés aux flux RSS.

Mais pour nous allons plutôt générer le XML avec le SGBD couchdb. Il faudra donc commencer par classer la base de données par date de modification des items, pour simplifier la récupération des items qui nous intéressent. Ensuite on utilisera couchdb pour générer le fichier XML lié à un flux RSS, en fonction du topic. On créera ensuite une vue pour récupérer le lien du fichier généré sur le coup.

Doit-on intégrer des services extérieurs (ex : cartographie) ? De quelles fonctionnalités en particulier aura-t-on besoin ? Est-ce que le service choisi les propose ou doit-on passer chez un concurrent ? Comment s'utilisent ces fonctionnalités ? avec quels paramètres ?

Des services extérieurs seront nécessaires pour utiliser la fonctionnalité mais ils ne seront pas à intégrer dans notre application ; on fournit simplement le fichier permettant aux services de lire notre flux.

Des étapes préalables de développement, testables, sont-elles envisageables afin de diminuer la complexité de la livraison ? Refactoring (livrable à part entière, isofonctionnel) ? Code développable et testable de manière externe au logiciel ? Étape du scénario (non livrable en tant que tel mais dont l’effet peut être testé) ?

Le développement pourra être moins complexe, avec la possibilité avec couchdb et argos de faire de faire des tests de manière locale avec notre base de donnée de test.

[cedricleandres]

Ci-dessous la stratégie d'implémentation du back-end:

Vue Couchdb :
L'idée ici est de parcourir la base de donnée pour répérer les items modifiés et parcourir ces derniers pour récuperer de possibles topics, ainsi que la date de modification.
Créer un fichier : Argos/app/views/topic_modified/map.js

function (doc) {
if(doc.topics && doc.record.modified){
for (var t in doc.topics) {
emit([
t,doc.record.modified]);
}
}
}

Rewrite Couchdb :
L'idée ici est de configurer le fichier qui permettre de retranscrire l'uri obtenue par couchdb
Modifier le fichier Argos/app/rewrites.json

{
"from": "topic_feed/:topic",
"to": "_list/topic_feed/topic_modified",
"query": {
"include_docs": "true",
"startkey": [":topic"],
"endkey": [":topic",{}]
}
}
List Couchdb :

Créer un fichier Argos/app/list/feed/feed.js
exemple à modifier avec les balises souhaitées pour une bonne lecture rss:

function (head, req) {
start({
'headers': {
'Content-Type': 'text/xml'
}
});
uri = req.query.app;
send('<title>'Modification_topic'</title>');
send(uri);
send('Created or updated items.');
while(row = getRow()){
send(''.concat(
'',
'<title>' + row.doc.item_name + '</title>',
'Lieu : ' + row.doc.spatial + ' créé le ' + row.doc.created + '',
'' + uri + '/item/' + row.doc.item_corpus + '/' + row.id + '',
''
));
}
send('');
}

[benel]

Bonjour, voici la stratégie d'implémentation à laquelle nous avons réfléchi avec @maelht (...)

Merci @cedricleandres et @maelht pour cet essai de stratégie d'implémentation.

Cependant je suis extrèmement étonné par son contenu : c'est comme si vous ne teniez pas du tout compte :

• des choix de conception (notamment les URI des flux) et des choix technologiques effectués (vues et listes) dans le ticket TEST: Scenarios - Subscribe to a corpus (see Hypertopic#501) #517,
• de ce qui a déjà été implémenté dans ce même ticket et qui serait donc mutualisable.

[benel]

des choix de conception (notamment les URI des flux) et des choix technologiques effectués (vues et listes) dans le ticket #517,

@cedricleandres @maelht Je vous invite fortement à vous rapprocher de @sarah-ngn et @lildelfino pour qu'ils vous expliquent comment on se sert de leur code et comment ça marche (ce qui vous permettra de voir ce qu'il faudrait changer à leur code pour monter en généralité et gérer à la fois les corpus et les topics).

[benel]

@cedricleandres @maelht

Ci-dessous la stratégie d'implémentation du back-end (...)

Cette partie est mieux. Mais elle fait comme s'il fallait refaire "en double" pour les topics ce qui a été fait pour les corpus. Au contraire vous devez voir ce qu'il faudrait modifier dans ce qui a été fait pour les corpus pour monter en généralité et gérer aussi les topics.

[cedricleandres]

Bonjour, voici la stratégie d'implémentation à laquelle nous avons réfléchi avec @maelht (...)

Merci @cedricleandres et @maelht pour cet essai de stratégie d'implémentation.

Cependant je suis extrèmement étonné par son contenu : c'est comme si vous ne teniez pas du tout compte :

* des choix de conception (notamment les URI des flux) et des choix technologiques effectués (vues et listes) dans le ticket #517,

* de ce qui a déjà été implémenté dans ce même ticket et qui serait donc mutualisable.

Merci @benel pour le retour. Effectivement j'ai essayé de relire le ticket #517 pour faire un résumé de toute la discussion sur la stratégie d'impémentation, mais c'est pas encore ça. C'est pourquoi j'ai mis la stratégie particuliement sur le back end en bas, car je me suis plus appliqué a comprendre le code du back-end et l'intégrer à notre ticket avec @sarah-ngn et @lildelfino qui nous ont beaucoup aidé.

[cedricleandres]

@cedricleandres @maelht

Ci-dessous la stratégie d'implémentation du back-end (...)

Cette partie est mieux. Mais elle fait comme s'il fallait refaire "en double" pour les topics ce qui a été fait pour les corpus. Au contraire vous devez voir ce qu'il faudrait modifier dans ce qui a été fait pour les corpus pour monter en généralité et gérer aussi les topics.

Effectivement, nous avons pensé à généraliser avec ce qui a été fait pour le corpus, mais étant donné que ce ne sont pas les mêmes données qui sont retournés par exemple dans la couchdb, c'est un compliqué de tout intégrer dans la même vue, je vais tout de même continué à éssayer.

J'ai une question. dans la liste que j'ai crée, j'ai accès à ma startkey qui est un identifiant de topic. Si je veux par exemple dans la description, intégrer le nom du topic qui à été modifié et non uniquement son identifiant est-ce possible?

[benel]

@cedricleandres @maelht

Effectivement, nous avons pensé à généraliser avec ce qui a été fait pour le corpus, mais étant donné que ce ne sont pas les mêmes données qui sont retournés par exemple dans la couchdb, c'est un compliqué de tout intégrer dans la même vue, je vais tout de même continué à éssayer.

L'idée générale qui doit guider votre stratégie est de généraliser ce que vous aviez pour un corpus afin que ça marche aussi pour un topic. Donc, en particulier, à chaque fois que vous aviez un identifiant de corpus, vous aurez un identifiant "d'objet" (corpus ou topic).

[benel]

@cedricleandres @maelht

J'ai une question. dans la liste que j'ai crée, j'ai accès à ma startkey qui est un identifiant de topic. Si je veux par exemple dans la description, intégrer le nom du topic qui à été modifié et non uniquement son identifiant est-ce possible?

C'est faisable a priori avec une technique Map/Reduce appelée "collation" (on se sert du tri des clés pour mettre à côté des données provenant d'objets différents).
Commencez sans le nom et, une fois que ce sera fait, je vous montrerai comment faire pour ajouter le nom.

[cedricleandres]

Ci-dessous la nouvelle stratégie. Merci à @lildelfino de nous avoir aidé à mutualiser les fichiers.

Vue Couchdb :
Nous avons gardé le fichier map.js, ce qui nous permettra de ressortir soit le corpus et le topic en fonction de la demande
Créer un fichier : Argos/app/views/modified/map.js

function (doc) {
  if (doc.item_corpus && doc.record.modified) {
    emit([doc.item_corpus, doc.record.modified]);
    if(doc.topics && doc.record.modified){
      for (var t in doc.topics){
        emit([t, doc.record.modified]);
      }
    }
  }
}

Rewrite Couchdb :
L'idée ici est de configurer le fichier qui permettre de retranscrire l'uri obtenue par couchdb
Pas de modifications à ce niveau, dans le fichier Argos/app/rewrites.json

 {
    "from": "feed/:corpus",
    "to": "_list/feed/modified",
    "query": {
      "include_docs": "true",
      "startkey": [":corpus"],
      "endkey": [":corpus",{}]
    }
  }

List Couchdb :

Nous avons décidé de concerver le fichier Argos/app/lists/feed.js, en intégrant des modifications permettant de ressortir les résultats en fonction de la demande dans l'uri.
exemple à modifier avec les balises souhaitées pour une bonne lecture rss:

function (head, req) {
  start({
    'headers': {
      'Content-Type': 'text/xml'
    }
  });
  uri = req.query.app;
  send('<rss><channel><title>' + req.query.startkey + '</title><link>');
  send(uri);
  send('</link><description>Created or updated items.</description>');
  while(row = getRow()){
      var i=0;
      var topic="";
      for (var t in row.doc.topics){
        topic+=t+", ";
      }
      send(''.concat(
      '<item>',
      '<title>' + row.doc.item_name + '</title>',
      '<description> Lieu : ' + row.doc.spatial + ' Créé le : ' + row.doc.created  + ' Catégorie(s) : ' + topic + '</description>',
      '<link>' + uri + '/item/' + row.doc.item_corpus + '/' + row.id + '</link>',
      '</item>'
    ));
  }
 send('</channel></rss>');
}

[benel]

@cedricleandres Pouvez-vous utiliser le mode de coloration syntaxique de GitHub ?

Si vous écrivez par exemple :

```js
for (;;) {
  console.log('Hello World!');
}
```

ça donnera :

for (;;) {
  console.log('Hello World!');
}

Ça rendra la relecture beaucoup plus facile...

[cedricleandres]

@benel

@cedricleandres Pouvez-vous utiliser le mode de coloration syntaxique de GitHub ?

Si vous écrivez par exemple :

```js
for (;;) {
  console.log('Hello World!');
}

ça donnera :

```js
for (;;) {
  console.log('Hello World!');
}

Ça rendra la relecture beaucoup plus facile...

@benel c'est fait.