- Typo
- Removes old comments
- Moves the template debug context processor back to the common file: it
won't be loaded anyway if `DEBUG=False`.
- Ddt's middleware should be loaded first
We reproduce what has been done here:
https://github.com/dissemin/dissemin
The following files can be found under `cof/settings/`
- `common.py`: the settings that are shared by all the environments we
have + the secrets (see below).
- `dev.py`: the settings used by the vagrant VM for local development.
- `prod.py`: the production settings (for both www.cof.ens.fr and
dev.cof.ens.fr)
There is also a notion of "secrets". Some settings like the `SECRET_KEY`
or the database's credentials are loaded from an untracked files called
`secret.py` in the same directory. This secrets are loaded by the common
settings file.
- Cache use db #1 of redis.
- Channel layer (of channels) use db #0 of redis.
- `settings` try getting redis connection variables from environment.
- Drop memcached system
Old configuration(/settings), based on Settings model, system is
deleted: SettingsForm, Settings.
New system use `django-djconfig` module.
- `kfet.config` module provides `kfet_config` to access configuration concerning
kfet app.
- Views, forms, models, etc now use this object to retrieve conf values.
- Views no longer add config values to context, instead templates use
`kfet_config` provided by a new context_processor.
- Enhance list and update views of settings.
- Fix: settings can directly be used without having to visit a specific
page...
Misc
- Delete some py2/3 imports
- Delete unused imports in kfet.models and kfet.views
- Some PEP8 compliance
- The models are moved to the `gestion` app
- A new field `associations` is added
- The location and datetime fields are removed in favour of a new model
`EventTimeSlot`
- The old events are migrated to the new app and linked to the
`cof_buro` association
Write modern-style urls
- Proper use of include
- Defining namespaces (I do not use them for now because many urls are
going to change)
- Do not try to reverse with old-style references: 'cof.views.XXX'
See merge request !178
Django-autocomplete-light does not support the `modelform_factory`
anymore in recent versions. We are actually using an old version of dal
because of this.
This had to be dropped at some point… So now is a good time
- Proper use of include
- Defining namespaces (I do not use them for now because many urls are
going to change)
- Do not try to reverse with old-style references: 'cof.views.XXX'
- The autocompletion feature works again
- The template is a bit more readable (indentation)
- The `options` variable in the template is no longer a integer but a
boolean.
- Move the model
- Add some BDS-related fields
- Add an `associations` fields to be able to separate the clubs between
the different associations using groups
- The login views are in `gestion/`
- The templates are under `gestion/templates/gestion/`
- `cof/shared.py` moves to `gestion/` and is splitted into 3 files:
- The auth backends are in `backends.py`.
- The context_processor is in `context_processor.py`
- The LOCK/UNLOCK functions remain in `shared.py`
- remove is_buro from the database in the same way we did for is_cof
- make a decent migration that *SHOULD* take into account is_cof for old
databases. note, this has been tested only through unittests.
- make unittests pass again accordin=gly fixing views.
Note: we should make a method for filtering with specific group members,
something like
map(lambda x: x.profile.cof, filter… group…)
Rmeove the is_cof flag to check permission and start implementing
a group and a permission for the respective cof members.
XXX. note: migrations do NOT add old is_cof members to the new group
(as actually they're just on the tests…)
- 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
Virtualenv
Ce patch introduit un virtualenv dans le setup de dev. Cela permet notamment de passer à python 3 sans
avoir à remplacer toutes ses commandes `python manage.py ...` par `python3 manage.py ...`.
Il faut relancer le provisionning de la VM pour appliquer ce patch : `vagrant reload --provision`
See merge request !109
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.
- Suppression de la variable `ALLOWED_HOSTS` de `cof/settings.dev` de
sorte quand django utilise le default (qui est adapté à notre usage)
- Correction d'indentation
- Suppression d'un "-e" dans le fichier `requirements.txt`
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
- Suppression du dossier `apache` devenu inutile.
- On utilise `cof.settings` dans le fichier `asgi.py` par défaut
- Correction dans les urls du fichier de settings en lien avec les
nouvelles urls en `/gestion/...`
On fait tourner GestioCOF avec daphne derrière un reverse-proxy Apache
sur la VM Vagrant tout comme sur le serveur de production. On peut tester
en local GestioCOF en “conditions réelles”.
Le serveur lancé avec `python manage.py runserver 0.0.0.0:8000` est toujours
accessible à la même url `localhost:8000`.
Le (nouveau) serveur apache est accessible à `localhost:8080`.
Pour appliquer les changements dans le code au serveur type prod, il faut
relancer le worker : `sudo supervisorctl restart worker`. Alors que le serveur
de dev se relance tout seul.
NB important : ce patch supprime le mot de passe sur le serveur redis en dev,
pour faire marcher ce nouveau setup avec un version précédente de la VM, il faut
lancer `sudo redis-cli config set requirepass ""`
- Le backend d'auth K-Fêt est étendu pour aussi identifier une personne
dans le cas dans d'un formulaire en récupérant le password contenu
dans l'input de nom `KFETPASSWORD`
- Le middleware d'auth K-Fêt enregistre l'utilisateur connecté de
manière normale dans `request.real_user`
- Ajout d'un processeurs de contextes `kfet.context_processors.auth` qui
qui remplace `user` et `perms` par l'utilisateur connecté de manière
normale (`request.real_user`) et non celui connecté temporairement
- Modification de la vue de modif d'un compte pour s'adapter à l'auth
- Modification du template de modification d'un compte pour utiliser ce
moyen d'authentification
- Séparation du JS conservant le côté gauche d'une page à l'écran
- Séparation de l'encart gauche contenant les infos d'un comtpe dans un
autre template (`left_account`) pour l'utiliser dans `account_read` et `account_update`
- `base_nav` utilise user (qui est donc le vrai utilisateur connecté) au
lieu de `request.user` qui peut aussi bien être le vrai utilisateur
qu'un utilisateur temporaire
Si une (des) permission(s) sont nécessaires pour enregistrer/annuler des
opérations, une demande d'authentification apparaît où l'utilisateur
doit mettre le mot de passe d'un compte ayant la (les) permission(s)
requise(s).
Ce mot de passe est envoyé dans la requête AJAX via le header
`KFetPassword`.
Le middleware `KFetAuthenticationPassword` est appelée à chaque requête.
Il appelle lui même le backend `KFetBackend` qui est chargé de
retrouver le user dont le compte K-Fêt correspond au mot de passe défini
dans le header `KFETPASSWORD`.
Si le header n'est pas présent ou
qu'aucun utilisateur ne correspond à ce mot de passe, le middleware ne
fait... rien !
Dans le cas où un user est trouvé, il est "chargé" dans
`request.user` permettant ainsi de connecter l'utilisateur pour ce cycle
requête/réponse sans déconnecter l'utilisateur connecté de manière
normale.
