fundraiser_url field

[cbeauchesne]

Sorry for the french

Version lisible

• Pour les régions, points de passages de type climbing_outdoor avec équipements P1 et P1+, et les itis escalade et rocher haute montagne, on rajoute un champ "contribuer à la maintenance".
• Ce champ peut etre hérité du point de passage principal ou de la région
• Ce champ ne peut etre édité que par les modos

Version technique

API

• Rajouter aux régions, points de passages et itinéraires un champ en base de donnée: fundraiser_url.
• Ce champ n'est editable que par les modos
• Rajouter dans les points de passages et itinéraires un champ calculé can_have_fundraiser selon l'algo suivant:
  • TRUE pour les points de passage de type climbing_outdoor ET ayant des équipements P1 ou P1+
  • TRUE Pour les itinéraires de type mountain_climbing ou rock_climbing
  • FALSE dans tous les autres cas
• Rajouter dans les régions, points de passages et itinéraires un champ calculé computed_fundraiser_url selon l'algo suivant:
  • Pour les régions, c'est directement le champ fundraiser_url
  • Pour les points de passage dont can_have_fundraiser=TRUE, c'est, par ordre de priorité:
    1. le champ fundraiser_url du point de passage
    2. Sinon celui d'une région parent de type range (premier trouvé si plusieurs)
    3. Sinon celui d'une région parent de type admin_limit (premier trouvé si plusieurs)
    4. Sinon celui d'une région parent de type country (premier trouvé si plusieurs)
  • Pour les itinéraires dont can_have_fundraiser=TRUE:
    1. le champ fundraiser_url de l'itinéraire
       2; Sinon le champ computed_fundraiser_url du point de passage principal
  • Pour tous les autres cas, computed_fundraiser_url est vide.

[cbeauchesne]

Some changes in the spec :

---

The way the API works implies that a field not valid for a certain doc is emptied at edit if the edition makes the field invalid.
For instance, if a contributor changes a waypoint from climbing_outdoor to summit, all fields related to are empty.
For this field, it would mean that contributor can empty it, which is something we do not want at all.

So: whatever the value of can_have_fundraiser is, the field is present, and untouched during an edition (except for moderators if they need to) => it's the UI responsibility to display it or not regarding the value of can_have_fundraiser.

[cbeauchesne]

Another change in the spec:

After fighting playing with the cache, it appears that I'm a little bit afraid of the dynamics of a computed properties that takes inputs from several documents.

In consequence, I'll let the UI handle the computed_fundraiser_url property for now. When I'll be more confortable with the API, I may be back on the workbench.