Remove gender option of matmatronche & update gender settings
Afin de se mettre à jour il est dorénavant possible de ne pas définir son genre sexué sur l'édit de son profil. D'ailleurs j'ai découvert que de base pour un profil random le sexe était défini sur "Homme" maintenant il est en "-------" !
De plus afin que personnes n'utilisent l'outil matmatronche à des fins de site de rencontres en cherchant uniquement les "Homme" ou les "Femme" d'une promo etc... Le choix du sexe dans la recherche a été supprimé.
C'est la première fois que je fais une modification en solo alors n'hésitez pas à me casser en deux et m'expliquer si j'ai fauté :D
See merge request ae/Sith!264
core: create TzAwareDateTimeField to replace forms.DateTimeField
Follow up of !267. I read about Gitlab's slash and merge just after I did my own kind by resetting back to the original commit and creating one commit manually. Sublime merge helps but I still need more practice. :)
What was the right way to group every commit under one?
See merge request ae/Sith!270
Sexy search
The goal of this MR is to solve the search issue #96. Let's assume we have a user with firstname `Jean-François`, lastname `Du Pont` and nickname `Ai'gnan`. Here is a list of search that did not include him previously but now includes him (was and still is case-insensitive):
* `jean françois` (missing -) ;
* `jean-francois` (missing ç) ;
* `jean francois` (both) ;
* `dupont` (space) ;
* `françois` (not the start of his name) ;
* `aignan` (missing ').
You get it, there are a lot of mistakes that humans can do. It also sorts results by `User.last_update` to avoid putting old accounts at the top of common requests (such as firstname-only or lastname-only requests).
### How it works
For those who don't know, the search is handled by Xapian (the search backend) through the haystack library which provides a Django-friendly interface to multiple search backends. Xapian maintains kind of a duplicate of the database (only for models against which we want to search something) which is optimised for search operations. Its "models" are called "indexes" (see `core.search_indexes.UserIndex` for the user model).
Every time a user is created or modified, it is indexed (through a signal handler) so that Xapian knows about it. For the user search, what is indexed is the string outputted by the `core/templates/search/indexes/core/user_auto.txt` template. For our example from above, it looks like this:
```
jean francois
du pont
aignan
jeanfrancois
dupont
jeanfrancoisdupont
```
As you can see, unicode is removed. There also are kind-of duplicates with different spacing as we are using an autocomplete algorithm: it searches from the beginning of words.
The one I am not sure about is the last one. Its goal is to allow searching without putting a space between the firstname and lastname. Is this useful?
The prod will have to do a `./manage.py update_index`, not sure it does it in the upgrade script.
See merge request ae/Sith!269
Settings: Added new subscription for the new CA offer
This year we made a new deal with the CA: if a student open an account, they give us 50€ and the student 80€ with on year of subscription.
See merge request ae/Sith!276
core: add ./manage.py check_front command and call it on runserver
See #92 and !268.
This simplifies checking that front-end dependencies are up to date. It does not allow one to update an outdated dependency. That must be done manually (would otherwise require depending on a CDN or add npm as a dependency). A manual update will make sure changelogs are read and changes will be made appropriately.
We add a `check_front` command to `manage.py` and run it on calls to `runserver`.
This MR does not update any dependency as it is not its goal. MR incoming!
Should doc be added? It seems pretty simple and I don't see what should be documented: if it's red, update it.
~"Review TODO" @sli
See merge request ae/Sith!271
This makes the whole click page load only once for a normal click
workflow. The current basket is now rendered client side with Vue.JS,
and the backend view is able to answer with JSON if asked to.
This should lighten the workflow a lot on the client side, especially
with poor connectivity, and the server should also feel lighter during
big events, due to far less complex Jinja pages to render.
This will lighten the pages and make the functionality directly
accessible without ever scrolling the header garbage that is never
needed on those pages.
