- Fewer requests on choicesreventes and tabular inlines (of
attributions)
- User and tirage cannot be updated if updating a participant instance.
- Tabular inlines are fixed:
- the one which is used for spectacles with listing only propose
choices in spectacle with listing
- same with the other (spectacles without listing)
- Still does too much request (because of tabularinlines)
- New attribution form issue less queries
- Spectacle and Participant are readonly if updating an attribution.
ReadOnlyMixin allows to set readonly fields only while updating an
object.
bda.algorithm
- use iterator to find max_groups, instead of a db request
bda.views.do_tirage
- select_related() are now focused on some relationships (they were
taking useless relationships)
- bda-revente filling takes 1 request (each save and add was issuing
1 request)
bda.views.etat_places
- Use select_related on spectacles_set, avoid query issue for each spectacle.
- `slots__sum` is computed in view, instead of a query.
- Cleaner code (and avoid useless computations).
bda.views.places
- Add select_related on places, avoid query issue for each spectacle.
bda.views.inscription
- 1 query for spectacle field choices, instead of (#forms in formset *
#spectacles)
- Delete BaseBdaFormSet. The validation was redundant with
`unique_together` of ChoixSpectacle model.
- No string concatenations
- Use `get_object_or_404` instead of performing a `.get` and catching
the eventual exception.
- More accurate error messages when a bad request is detected.
- More accurate error handling
- Sites, surveys, events and petits cours demands/subjects are still
loaded from fixtures
- The users and their subscriptions to petits cours are loaded using the
`loaddevdata` command
- The sub command `loadbdadevdata` is called by `loaddevdata` and
populates the database with BdA related stuff :
- 2 tirages
- Show places
- Shows
- subscriptions
C'est un workaround, j'ai juste ajouté les fichiers JS absent dans
`bda/static/bda/js/`. Ces fichiers sont un peu outdated et le code
mériterait peut-être une modernisation mais au moins on peu s'inscrire
au tirage sans problème.
Fixes#124
- Le nombre total de demandes affiché est désormais le nombre de places
demandées et non le nombre de personnes ayant fait des demandes. Ainsi
ce nombre correspond à la somme des totaux par spectacle affiché
- Au passage, on déplace le template de cette vue dans un dossier plus
adéquat et on ajoute une docstring sur la vue.
- La migration qui supprime le vieux modèle gestioncof.CustomMail est
ajoutée
- Les mails de GestioCOF sont dans un json qui est chargé par la commande
`python manage.py syncmails`
Voir l'aide de la commande pour plus 'information
- On installe le package depuis le dépôt COF-Geek
- On supprime tous les fichiers texte des mails
- On charge dans la bdd les mails nécessaires au fonctionnement de
GestioCOF
- On supprime le modèle CustomMail obsolète de gestioncof
Améliore les mails automatiques du BdA
Les mails du BdA sont maintenant tous chargés depuis des templates gérés par le système de templates de Django, et plus par de l'interpolation de chaîne de caractères. Ceci permet en particulier d'utiliser (et de configurer) la localisation de Django afin d'afficher les dates de façon uniforme (et sans "hack" à la `date_no_seconds`) dans un format comportant un "à" entre le jour et l'heure.
See merge request !113
Configure la localisation (i10n) de Django afin d’afficher un format
plus user-friendly par défaut pour les dates (par exemple, afficher
"21 septembre 2016 à 15:00" plutôt que "21 septembre 2016
15:00"). Ceci permet d’éliminer les utilisations de `date_no_seconds`
pour simplement les remplacer par l’affichage de la date, le format
par défaut étant maintenant satisfaisant.
Attention : le bon fonctionnement de ceci nécessite de changer les
settings afin d’utiliser le module `cof.locale` comme module de
localisation (définir `FORMAT_MODULE_PATH = "cof.locale"`). Le module
`cof.locale` définit le format d’affichage des dates+heures
(`DATETIME_FORMAT`) afin d’incorporer le "à" qui n'est pas présent
dans la localisation française de Django.
La méthode `bda.models.Spectacle.__repr__` est buggée (elle retourne
une chaîne unicode alors que `__repr__` doit *toujours* renvoyer une
chaîne ASCII) et pose des problèmes de crash lors de l’affichage
d’objets `Spectacle` dans le REPL python. La méthode `__repr__`
héritée de `django.db.models.Model` devrait être suffisante.
Il restait un unique email (envoyé lors de l’achat d’une place au
shotgun) dont le texte est inscrit en dur dans `bda.views`. Pour
éviter d’avoir trop de systèmes d’envoi de mails différents, il
utilise maintenant une template dans `bda/mails` comme le reste des
emails envoyés par l’application bda.
