FEATURE: Add ressource to an item (See Hypertopic#142)

[ThomasRitaine]

Content

Avec @xelocks, nous avons implémenté une première version du ticket n°142. Nous attendons vos retours.

Cordialement, Jérémy et Thomas pour l'équipe études à l'étranger.

---

Checklist

Please check that your pull request is correct:

• Each commit:
  • [X] corresponds to a contribution that should be notified to users,
  • [X] does not generate new errors or warnings at compile or test time,
  • [X] must be attributed to its real authors (with correct GitHub IDs and correct syntax for multiple authors).
• The title of a commit should:
  • [X] begin with a contribution type
    • FEATURE for a behaviour allowing a user to do something new,
    • FIX for a behaviour which has been changed in order to meet user’s expectations,
    • TEST when it concerns an acceptance test,
    • PROCESS for a change in the way the software is built, tested, deployed,
    • DOC when it concerns only internal documentation (however it is better to combine it with the contribution that required this documentation change),
  • [X] be followed by a colon (:) with one space after and no space before,
  • [X] be followed by a title (written in English) as short, as user-centered and as explicit as possible
    • If it is a feature, the title must be the user action (beginning with a verb, and please not manage),
    • If it is a fix, the title must describe the intended behavior (with should).
  • [X] ends with a reference to the corresponding ticket with the following syntax:
    • (closes #xx) if xx is a feature ticket (and the commit is a complete implementation),
    • (fixes #xx) if xx is a fix ticket (and the commit is a complete fix),
    • (see #xx) otherwise,
• Each committed line is:
  • [x] useful (it would not work if removed)
    • if it is a comment line, its information could not be conveyed by better variables and function naming, better code structuring, or better commit message,
  • [X] related to this very contribution (feature, fix...),
  • [X] in English (with the exception of Gherkin scenarios in French and resulting steps),
  • [X] without any typo in variable, class or function names,
  • [X] correctly indented (spaces rather than tabs, same number of characters as in the rest of the file).

[benel]

Merci @ThomasRitaine... Cependant, je suis désolé, je ne comprends pas ce que vous essayez de faire avec le champ resource...

On est d'accord que la stratégie d'implémentation de @GuenaultAlexandre et de @Nicflx portait, pour le ticket #142, sur les pièces jointes (attachment) de CouchDB ?

[ThomasRitaine]

@benel, Nous avons remis au propre notre historique GitHub

[benel]

Nous avons remis au propre notre historique GitHub

Merci @ThomasRitaine.

Pour des tests un peu systématiques, une intégration dans la branche maître et une mise en production dans la journée, ça ne sera évidemment pas possible.

Mais bien entendu, vous pouvez faire vos vidéos avec votre code local de Porphyry et la configuration de production (Argos de production avec les données de production). OK ?