- Deprecation warnings using Django 1.8 are resolved.
- Deprecation warnings using Django 1.11 are resolved.
- Admin: grappelli is no longer used.
- Upgrade to django-autocomplete-light v3 (v2 is not 1.11 compatible).
* autocomplete.modelform_factory being dropped, code uses dal Select2
views and widgets.
K-Fêt
- Integrate wagtail to serve "static" pages of old K-Fêt website
- Fixture "kfetcms/kfet_wagtail_17_05" contains a copy of old website
(as in May 2017).
- Media files can be got until end of June 17 at
http://partage.eleves.ens.fr//files/604e6dea2ceebc66b1936c6b3f911744/kfet_media.tar.gz
Login/logout
- Update package django_cas_ng to last version.
- Clean COFCASBackend.
- Change CAS version to 3 (version used on eleves.ens). This enables
the logout redirection (for CAS ofc).
- Add messages and clean existing ones on login/logout (for both
outsider and cas users).
Misc
- Update settings to bypass an incompability between debug-toolbar and
wagtailmenus packages.
- Better management of dev/test-specific urls (if debug-toolbar wasn't in
INSTALLED_APPS, media files were not served).
- UI improvements.
`member.profile` was not up-to-date where we used to send the success
message => move it to the place where the success var is set tu `True`
and remove the success var was which becomes irrelevant.
Sometime `uid` is not set in the objects fetched from the LDAP. This
case has to be handled. Also, the `.uid` and `.cn` attributes of these
objects in the python abstractions have a `.value` method which we
should use.
It is obviously a bad idea to fail silently if something go wrong
when the connection with the mail server is being established. This was
enabled in the `_traitement_post` method.
The list `proposed_mails` is a list of elements of the kind
`(User, (mail_object, mail_body))` but it was handled as if it were
`(User, mail_body)` in the function `_traitement_post`.
Sometimes the `errors` variable is `None` in `_finalize_traitement`.
It was not an issue when it was just used in the templates but now we
have to handle this in the view. Basically, we shall consider it is an
empty list when it occurs.
The `registration` view was referencing this file using
`"gestioncof/registration_form.html"` whereas the `registration_post`
templated was referencing it in the global namespace
`"registration_form.html"`.
We choose the `gestioncof/` folder in order to avoid further conflicts
with other apps.
- Utilise une version à jour de jquery via un cdn
- Traite les messages
- Remplace les vieux simili-messages par des messages en utilisant le
framework messages de Django
- Drop `%` in favour of `.format` which has a better specification
- Remove a string concatenation
- Remove the trailing slashes according to the PEP8:
https://www.python.org/dev/peps/pep-0008/#maximum-line-length
NB. We let some which will disappear in the next commit.
- Remove an unused import and change the imports order
- 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
Create fixtures for kfet application:
- Add a bunch of non-cof profiles whose "last_name" is "Romain";
- Add k-fet articles using the real ones as a template;
- Add LIQ account;
- Add groups K-fet Chef and K-fet Girl;
- Add "caisse".
We also added some template for future tests (well, actually it's the script
used to generate the fixtures…).
- 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
GestioCOF définit une fonction `render_template` qui permet de calculer
l'interpolation d'un gabarit en une chaîne de caractères, par exemple
pour l'envoi de mails. Ce patch supprime cette fonction et remplace son
utilisation par la fonction `django.template.loader.render_to_string` au
comportement identique.
Le CAS de l'ENS autorise les logins avec des espaces/une casse variable, par
exemple il considere equivalents les logins ' bCLeMeNt ' et 'bclement'. Ceci
peut etre la cause de creation de doublons sur gestioCOF en cas de faute de
frappe (ou utilisateur malicieux ;-) )
Ce patch normalise les logins a la sortie du CAS (strip + lowercase) pour
eviter des desagrements.
Les valeurs de champs FROM, REPLY-TO et BCC des mails envoyés par
GestioCOF sont enregistrées dans un dictionnaire `settings.MAIL_DATA`
plutôt que d'être toutes enregistrées comme variables indépendantes
Meilleure gestion des permissions
Il n'est plus possible de modifier l'attribut `is_superuser` dans
l'interface admin. les membres du burô ne doivent plus être super-
utilisateurs en prévision de l'arrivée de l'appli K-Fêt.
Pour donner les permissions adéquates au burô, il faut créer un groupe
COF avec tous les droits sur les applis `gestioncof` et `bda` ainsi que
les droits sur les d'utilisateurs et ajouter les membres du burô à ce groupe.
Fix#62
See merge request !75
Seul les superusers ont le contrôle sur les groupes et permissions.
Un membre du burô est automatiquement ajouté au groupe COF, lui même
créé automatiquement s'il n'existe pas.
Il n'est plus possible de modifier l'attribut `is_superuser` dans
l'interface admin. les membres du burô ne doivent plus être super-
utilisateurs en prévision de l'arrivée de l'appli K-Fêt.
Pour donner les permissions adéquates au burô, il faut créer un groupe
COF avec tous les droits sur les applis `gestioncof` et `bda` ainsi que
les droits sur les d'utilisateurs et ajouter les membres du burô à ce groupe.
À l'inscription on contraint les noms d'utilisateurs à dépasser 8
caractères seulement à la création de nouveaux utilisateurs pour
garantir la rétrocompatibilité.
On peut inscrire les utilisateurs aux différents clubs du COF. Le
formulaire d'inscription est inclus dans la page
“inscription d'un nouveau membre”.
À réfléchir comment ajouter des infos supplémentaires : chèque des caution,
commentaires, etc.
Lors de la création d'un compte exté via la vue `/registration` (i.e. compte
non associé à un clipper), deux champs sont ajoutés au formulaire pour la
création d'un mot de passe.
Il est toujours possible de changer ce mot de passe via l'admin s'il est perdu
par l'utilisateur.
- Ajout d'un FIXME dans `gestioncof/forms.py` au niveua de la surcharge de
la méthode privée `_construct_form` : ce trick ne sera plus nécessaire à
partir de Django 1.9
- Utilisation correcte des `form.is_valid` dans `gestioncof.views.registration`
- Changements mineurs dans `AdminEventForm`
- Ajout d'une base pour le formset : `BaseEventRegistrationFormset`
- Adaptation des vues de l'inscription et suppression d'une vue inutile.
- Le lien vers l'inscription à un tirage BdA disparaît après sa fermeture
- Les liens “mes places” et “revente” n'apparaissent qu'après la fermeture du
tirage.
- Le lien vers les ratios des demandes est déplacé dans la partie “Gestion des
tirages” pour servir d'archive au BdA.
Fixes#55
- La vue d'édition du profil n'est plus accessible aux non-COF
- Le calendrier dynamique étant réservé aux adhérents, le lien vers
l'inscription est caché aux non-adhérents.
- Séparation du compte root des autres comptes
- Mise à jour en fonction des derniers changements de la BDD :
- Les dates des events deviennent des datetime
- Changement de nom dans bda.models.Tirage : token -> tokens
- Changement dans les dates de spectacles pour se situer dans l'année
2016-2017
Ajout d'un calendrier dynamique
Ce patch propose aux adhérents du COF de télécharger un calendrier
dynamique (`.ics`).
Il est configurable :
- On peut s'abonner ou non aux événements du COF.
- On peut choisir les spectacles auxquels on veut s'abonner.
- Une checkbox permet d'ajouter d'un coup les spectacles pour lesquels on a obtenu une place
- On peut en ajouter d'autres
Pour faire fonctionner ce patch, il faut installer la bibliothèque python `icalendar` :
pip install --upgrade -r requirements.txt
Fixes#20Fixes#14
See merge request !63
- Indique a l'utilisateur comment utiliser le calendrier
- Utilise l'ORM Django plutôt que des `set` python pour avoir la bonne
liste des spectacles.
- Rajoute un lien vers le calendrier sur la page “mes places”
Plus besoin de s'authentifier pour accéder au calendrier : il suffit
d'entrer la bonne url qui contient un token aléatoire propre à chaque
utilisateur.
Ce token ne change pas lorsqu'on modifie son inscription
- Typos dans les modèles
- Choix d'un `OneToOneField` dans `CalendarSubscription`
- Suppressions d'un `except` catch-all
- Amélioration de la vue calendar
`gestioncof.views.registration` was using an `event` variable that was
not properly defined. Due to a semantics oddity of python2, the value
used was from a previous and (somewhat) unrelated list comprehension.
Ce patch propose aux adhérents du COF de télécharger un calendrier
dynamique (`.ics`).
Il est configurable :
- On peut s'abonner ou non aux événements du COF.
- On peut choisir les spectacles auxquels on veut s'abonner.
Rend GestioCOF compatible avec python 3. En particulier, il s'agit de :
- Utiliser la version "fonction" de `print` dans `sync_clipper` et
`tirage_bda`, avec le `from __future__ import print_function` pour
garder la compatibilité avec python 2
- Utiliser de l'unicode par défaut, même en python 2, avec
`from __future__ import unicode_literals` et le décorateur de
compatibilité `python_2_unicode_compatible` de Django pour les
modèles, comme décrit à
https://docs.djangoproject.com/en/1.9/topics/python3/#str-and-unicode-methods
- Utiliser `six.text_type` à la place de `unicode`
Fixes#2.
