Rex Dri issueshttps://gitlab.utc.fr/rex-dri/rex-dri/-/issues2019-02-21T17:56:19Zhttps://gitlab.utc.fr/rex-dri/rex-dri/-/issues/48Remove custom REST API behavior2019-02-21T17:56:19ZFlorent ChehabRemove custom REST API behaviorRemove the custom behavior of the REST API that returns an object instead of a list.
It was handy, but let's stay with the standard behavior.Remove the custom behavior of the REST API that returns an object instead of a list.
It was handy, but let's stay with the standard behavior.Pre start PRFlorent ChehabFlorent Chehabhttps://gitlab.utc.fr/rex-dri/rex-dri/-/issues/47Fix linting warning2019-02-21T17:56:19ZFlorent ChehabFix linting warningFollowing #40
Fix linting warnings and when done change the linting config to throw errors instead of warnings.Following #40
Fix linting warnings and when done change the linting config to throw errors instead of warnings.Pre start PRhttps://gitlab.utc.fr/rex-dri/rex-dri/-/issues/25Change frontend generation2019-02-07T21:27:43ZFlorent ChehabChange frontend generationAdd an object that stores the fetching functions and make sure not to fetch the same thing successively because redux is too slow (ex : land directly on the univ page).Add an object that stores the fetching functions and make sure not to fetch the same thing successively because redux is too slow (ex : land directly on the univ page).Pre start PRhttps://gitlab.utc.fr/rex-dri/rex-dri/-/issues/192Stats explorer2020-06-14T19:16:22ZFlorent ChehabStats explorerFollowup to #184
We are close to having the following data collected everyday on REX-DRI:
1. How many users connected to the plateforme, with a 24h granularity.
2. Information about exchange related contributions with a 24h granulari...Followup to #184
We are close to having the following data collected everyday on REX-DRI:
1. How many users connected to the plateforme, with a 24h granularity.
2. Information about exchange related contributions with a 24h granularity.
## Example data
Here is a preview how what the two tables might contain:
1. ex:
| *id* | date | nb_connections |
| ---- | ------------------------- | -------------- |
| 1 | 2020-05-01T00:00:00:0001Z | 5 |
| 2 | 2020-05-02T00:00:00:0001Z | 10 |
| 3 | 2020-05-03T00:00:00:0001Z | 3 |
2. ex:
| *id* | date | major | minor | exhange_semester | university | nb_contributions |
| ---- | ------------------------- | ----- | ----- | ---------------- | ---------- | ---------------- |
| 1 | 2020-05-01T00:00:00:0001Z | IM | CMI | P2020 | EPFL | 2 |
| 2 | 2020-05-01T00:00:00:0001Z | IM | MAT | A2020 | EPFL | 1 |
| 3 | 2020-05-03T00:00:00:0001Z | GI | FDD | A2020 | Tokyo | 1 |
*N.B. 'university' will actually be a foreign key to the univ model in the database.*
## Objectives
Those tables enable us to answer the following questions:
1. Questions:
* How many user connected to the site in the last 30 days?
* How many user connected to the site between date1 and date2?
* Can we plot the number of user that connected to site between date1 and date2?
* Etc.
2. Questions (here there are a lot of possibilities -- plus either count or plot):
* How many exchange related contributions between date1 and date2?
* What is the distribution of contributions between majors?
* ... between minors inside a major?
* etc. etc. etc.
## Technical feasibility
### Request
In the frontend, we want to:
* Be able to plot data or display it as a table,
* Be able to export tables as CSV,
* Be able to filter data,
* Be able to "groupby" data,
* Be able to combine the last two settings in whatever configuration,
* Be able to share a reproductible page (filter, groupby, etc.) only with a URL.
### Constraints
* There are a lot of filtering/groupby possibilities, our tool has to be generic enough to cover every possibility.
* The solution should be highly maintainable.
* We must have a strict control about what query is performed in the database.
* We can assume that the end user has some data wrangling knowledge.
* It should be implementable under ~2 weeks.
### Conclusion
How to do it?PR-P20Estelle VeisemburgerEstelle Veisemburgerhttps://gitlab.utc.fr/rex-dri/rex-dri/-/issues/191Use Material-ui pagination component2020-06-13T09:11:10ZFlorent ChehabUse Material-ui pagination componentTo be done after #188
https://material-ui.com/components/pagination/To be done after #188
https://material-ui.com/components/pagination/PR-P20Imane MisrarImane Misrarhttps://gitlab.utc.fr/rex-dri/rex-dri/-/issues/184Add stats regarding feedback completion2020-06-14T13:25:19ZFlorent ChehabAdd stats regarding feedback completionCompute basics statistics (dayly) regarding what is the percentage of exchange with feedbacks, how many new feedbacks, etc.Compute basics statistics (dayly) regarding what is the percentage of exchange with feedbacks, how many new feedbacks, etc.PR-P20Maxime EmschwillerMaxime Emschwillerhttps://gitlab.utc.fr/rex-dri/rex-dri/-/issues/177Filter: give more suggestions & merge IM, GSM, GM ?2020-05-24T18:53:21ZFlorent ChehabFilter: give more suggestions & merge IM, GSM, GM ?> Dans la recherche, si je commence à taper « IM » dans le filtre par branche, seules quelques filières apparaissent. Je ne trouve pas « IM-CMI ». Il faut taper CMI pour faire apparaître IM-CMI et GSM-CMI (nécessité de garder les deux ?)> Dans la recherche, si je commence à taper « IM » dans le filtre par branche, seules quelques filières apparaissent. Je ne trouve pas « IM-CMI ». Il faut taper CMI pour faire apparaître IM-CMI et GSM-CMI (nécessité de garder les deux ?)PR-P20Estelle VeisemburgerEstelle Veisemburgerhttps://gitlab.utc.fr/rex-dri/rex-dri/-/issues/176Add switch to only show exchanges with feedback on univ page2020-05-11T07:19:41ZFlorent ChehabAdd switch to only show exchanges with feedback on univ pageAs we can see on the screenshot bellow, most of exchanges are 'empty': nossing was contributed by the student concerned by the exchange.
The objective here is to add a switch next to `branch` to show only exchanges with contributions.
(...As we can see on the screenshot bellow, most of exchanges are 'empty': nossing was contributed by the student concerned by the exchange.
The objective here is to add a switch next to `branch` to show only exchanges with contributions.
(the switch should be active by default and if no exchanges match add a button to easily switch back it off)
:warning: think about the behavior we want when coming back to the page, etc.
![Screenshot_from_2020-04-04_13-29-40](/uploads/0fd9561aa15731381873df583ea9be05/Screenshot_from_2020-04-04_13-29-40.png)PR-P20Imane MisrarImane Misrarhttps://gitlab.utc.fr/rex-dri/rex-dri/-/issues/175map: add legend2020-04-25T16:44:44ZFlorent Chehabmap: add legendAdd legend to explain what are the two colors.
* [ ] Create a legend component
* [ ] Overlay on top of the map
* [ ] Works for both in dark and light mode
![Screenshot_from_2020-04-04_12-56-46](/uploads/00f54ed50444817f8103ca5289e8a7f7...Add legend to explain what are the two colors.
* [ ] Create a legend component
* [ ] Overlay on top of the map
* [ ] Works for both in dark and light mode
![Screenshot_from_2020-04-04_12-56-46](/uploads/00f54ed50444817f8103ca5289e8a7f7/Screenshot_from_2020-04-04_12-56-46.png)
PR-P20Estelle VeisemburgerEstelle Veisemburgerhttps://gitlab.utc.fr/rex-dri/rex-dri/-/issues/159Fix useless READ MORE markdown2020-05-03T15:45:13ZFlorent ChehabFix useless READ MORE markdownIn some cases, the "Read more button" is clearly useless (eg: https://rex.dri.utc.fr/app/university/203/previous-exchanges).
Before button click:
![Screenshot_from_2020-04-04_13-00-36](/uploads/07bf1d46f75d9e5b81da75e518543112/Screensho...In some cases, the "Read more button" is clearly useless (eg: https://rex.dri.utc.fr/app/university/203/previous-exchanges).
Before button click:
![Screenshot_from_2020-04-04_13-00-36](/uploads/07bf1d46f75d9e5b81da75e518543112/Screenshot_from_2020-04-04_13-00-36.png)
After button click:
![Screenshot_from_2020-04-04_13-00-46](/uploads/92c2f70c2f6b2f2d90ebed5e9188bf28/Screenshot_from_2020-04-04_13-00-46.png)
We need a better heuristic on when to hide the button (and show the whole text) and when to do the opposite.PR-P20Estelle VeisemburgerEstelle Veisemburgerhttps://gitlab.utc.fr/rex-dri/rex-dri/-/issues/149Last visited universities2020-06-07T12:16:19ZFlorent ChehabLast visited universitieshttps://gitlab.utc.fr/rex-dri/rex-dri/issues/149
Backend:
1. Create an intermediate model (LastVisitedUniversity) between the user and university models
* This model contains 3 fields : one for user (foreign key) , one for universi...https://gitlab.utc.fr/rex-dri/rex-dri/issues/149
Backend:
1. Create an intermediate model (LastVisitedUniversity) between the user and university models
* This model contains 3 fields : one for user (foreign key) , one for university (foreign key) and one for lastClickOnUniversity (DateTimeField: auto_now = True)
2. Create a viewset to update the previous model when a user looks at a university (get inspired by https://gitlab.utc.fr/rex-dri/rex-dri/-/blob/dev/backend/backend_app/viewsets.py#L316).
Endpoint: /lastVisitedUniversities
req POST endpoint/<pk_univ> => Create LastVisitedUniversity(user=req.user, university=University.get(pk=<pk_univ>), ~~ts=now()~~)
req GET endpoint => return List[LastVisitedUniversity.where(user=req.user).orderby(ts DESC).first(5)] (list[int] === List[<pk_univ>])
SQL:
```sql
SELECT university, max(ts) as ts
FROM LastVisitedUniversity
WHERE
USER = <req.user.pk>
GROUP BY university
ORDER BY ts DESC
LIMIT 5;
```
other => Return 404
Frontend:
1. When visiting university: make POST request (https://gitlab.utc.fr/rex-dri/rex-dri/-/blob/dev/frontend/src/components/recommendation/view/View.jsx#L676 use the useApiCreate() hook)
2. Create component to show last visited univ (and mention REX-DRI private)
PR-P20Imane MisrarImane Misrarhttps://gitlab.utc.fr/rex-dri/rex-dri/-/issues/148Filter only on currently available destinations2020-05-17T15:54:44ZFlorent ChehabFilter only on currently available destinations## Objective
* Being able to filter only on open destinations, [on the map and search pages (it's the same component)](https://rex.dri.utc.fr/app/map/)
## Context
### Back
* Every night, the UTC DRI data are copied from the DSI to RE...## Objective
* Being able to filter only on open destinations, [on the map and search pages (it's the same component)](https://rex.dri.utc.fr/app/map/)
## Context
### Back
* Every night, the UTC DRI data are copied from the DSI to REX-DRI [source](https://gitlab.utc.fr/rex-dri/rex-dri/-/blob/dev/backend/cron_tasks.py#L38)
* You should be able to plug yourself in the [`__import_opened_destinations` method](https://gitlab.utc.fr/rex-dri/rex-dri/-/blob/dev/backend/external_data/management/commands/utils.py#L199) and the [`update` method](https://gitlab.utc.fr/rex-dri/rex-dri/-/blob/dev/backend/external_data/management/commands/utils.py#L76), to track which partners are "open" on the UTC ENT.
* You should also know (and maybe use -- it's up to you) that some denormalized data is updated every night on the [`University` model](https://gitlab.utc.fr/rex-dri/rex-dri/-/blob/dev/backend/backend_app/models/university.py#L72). This is the data that is used for filtering.
### Front
* The filter Component is [here][https://gitlab.utc.fr/rex-dri/rex-dri/-/blob/dev/frontend/src/components/filter/Filter.jsx)
* The filtering itself is handled within the [`FilteringService` class](https://gitlab.utc.fr/rex-dri/rex-dri/-/blob/dev/frontend/src/services/FilterService.js)
Have fun :tada:
Bonus point if you throw some [transaction](https://docs.djangoproject.com/fr/2.2/topics/db/transactions/#controlling-transactions-explicitly) somewhere :rolling_eyes: PR-P20Imane MisrarImane Misrarhttps://gitlab.utc.fr/rex-dri/rex-dri/-/issues/137Drop the city and campus model to simplify things a bit2020-06-19T14:20:56ZFlorent ChehabDrop the city and campus model to simplify things a bitAs you can see here https://rex-dri.gitlab.utc.fr/rex-dri/documentation/generated/architecture.svg the backend models architecture is a bit complicated.
To simplify things a bit, we want to:
* [ ] Drop the city model
* [ ] Drop the c...As you can see here https://rex-dri.gitlab.utc.fr/rex-dri/documentation/generated/architecture.svg the backend models architecture is a bit complicated.
To simplify things a bit, we want to:
* [ ] Drop the city model
* [ ] Drop the campus model
* [ ] All these information should be moved back to the `University`.
* [ ] There are also big changes to perform to the frontend.
This will be a big help for #187
How to do it?
1. Create a migration to add the missing columns to the University model,
2. Create a script to transfer the data from the city / campus models in the new columns,
-----
3. Update the backend serializers and viewsets,
5. Update the frontend.
-----
4. Delete the old models.PR-P20Gautier DauresGautier Daureshttps://gitlab.utc.fr/rex-dri/rex-dri/-/issues/34Recommendation list2019-06-22T12:03:38ZFlorent ChehabRecommendation listEnable the user to create list of universities.
:warning: The backend architecture might need an update. I would highly recommend starting by building the frontend for this. :warning:
- A user can create multiple lists of universities...Enable the user to create list of universities.
:warning: The backend architecture might need an update. I would highly recommend starting by building the frontend for this. :warning:
- A user can create multiple lists of universities,
- Each list can contain each university at most once,
- For each university, the user can add a markdown comment and "grades" (to determine),
- Users can reorder the list,
- Users can add "block" of markdown comment.
- The list can either be private or public (shareable -> useful for teachers). Therefore, some backend checks will be needed to verify that a user as read access to the list.
You can think of a list as something close to a Jupyter Notebook with "university blocks" and "comment blocks".PR nowSolene AboudSolene Aboudhttps://gitlab.utc.fr/rex-dri/rex-dri/-/issues/32Ask the student to give the information of the course language when evaluating2019-06-27T20:03:58ZFlorent ChehabAsk the student to give the information of the course language when evaluatingAllow up to two languages per course (one might be null).
Following #29
This information might be used to search universities by teaching language at some point.
Linked to #116
Allow up to two languages per course (one might be null).
Following #29
This information might be used to search universities by teaching language at some point.
Linked to #116
PR nextSegolene BrisemeurSegolene Brisemeurhttps://gitlab.utc.fr/rex-dri/rex-dri/-/issues/29Handle feedback on courses.2019-06-27T20:03:58ZFlorent ChehabHandle feedback on courses.# Backend
:warning: Review/update the backend structure for this matter. :warning:
Currently we have the following architecture:
![Screenshot_from_2019-02-24_21-27-57](/uploads/e65271dc964ae850796765acad4cfa15/Screenshot_from_2019-02-...# Backend
:warning: Review/update the backend structure for this matter. :warning:
Currently we have the following architecture:
![Screenshot_from_2019-02-24_21-27-57](/uploads/e65271dc964ae850796765acad4cfa15/Screenshot_from_2019-02-24_21-27-57.png)
Several notes:
- One possible design to do (or not to do) is to create a model that contains the feedback for one course and that is link to an exchange.
- If you do so don't forget to modify your queryset to prefetch all the feedback (ask @chehabfl) for better performances.
- If you do so, you can put the general feedback of the user on the exchange model (aka PreviousDeparture)
- The other possibility, is to stick to JSON, but I think the one above is better to start with.
You have to keep in mind that:
- The courses followed by a student will automatically created (and updated) given the data from the UTC database.
Some questions have to be resolved for this issue:
- What do you grade on each course (for now: adequation and quality; I don't recall why I chose "integration")
- #59
Of course, don't forget about security:
- the info should be readable by everyone, but editable only by the user (and eventually a moderator (and above level)).
- For now, you can use a versioned model (that will automatically compress the successive version by the user, but will allow to keep track if an admin modify something).
# Frontend
Well, then you need to build the front for this.
First display information, then add the possibility to edit.
You might want to wait for #51 to be fixed first, but that's not necessary. PR nowSegolene BrisemeurSegolene Brisemeurhttps://gitlab.utc.fr/rex-dri/rex-dri/-/issues/189Smarter withNetworkWrapper2020-04-13T19:54:47ZFlorent ChehabSmarter withNetworkWrapperHandle reloading from the wrapper itself on props change.Handle reloading from the wrapper itself on props change.Florent ChehabFlorent Chehabhttps://gitlab.utc.fr/rex-dri/rex-dri/-/issues/181Create a feature checklist for the frontend2020-04-22T18:51:11ZFlorent ChehabCreate a feature checklist for the frontendList all the features of the app that need to be checked to see if everything is workingList all the features of the app that need to be checked to see if everything is workingFlorent ChehabFlorent Chehabhttps://gitlab.utc.fr/rex-dri/rex-dri/-/issues/180Update documentation about api interactions frontend / backend2020-04-14T19:46:00ZFlorent ChehabUpdate documentation about api interactions frontend / backendFlorent ChehabFlorent Chehabhttps://gitlab.utc.fr/rex-dri/rex-dri/-/issues/179Add services to documentation2020-04-14T19:46:00ZFlorent ChehabAdd services to documentationFlorent ChehabFlorent Chehab