Skip to content
Snippets Groups Projects

Compare revisions

Changes are shown as if the source revision was being merged into the target revision. Learn more about comparing revisions.

Source

Select target project
No results found

Target

Select target project
  • web-et-numerique/factory/llle_project/self-data-technical-doc
1 result
Show changes
Commits on Source (11)
version: '3.3'
version: "3.3"
services:
self_data_docs:
......@@ -11,7 +11,7 @@ services:
max-size: "2m"
max-file: "5"
# mem_limit: 512m
user: "1000"
# user: "1000"
# command: -http_port=8081
volumes:
- /etc/localtime:/etc/localtime:ro
......
......@@ -11,7 +11,7 @@ For a better state management, combineReducers(reducers) is used to split the re
| Reducer | Type | Description |
| --------- | -------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
| global | GlobalState | store global states such as: notification, type device or fluid type<br><br>GlobalState enum<br>- _screenType = ScreenType_<br>- _challengeExplorationNotification = boolean_<br>- _challengeActionNotification = boolean_<br>- _challengeDuelNotification = boolean_<br>- _analysisNotification = boolean_<br>- _fluidStatus = FluidStatus[]_<br>- _fluidTypes = FluidType[]_ |
| global | GlobalState | store global states such as: notification, type device or fluid type<br><br>GlobalState enum<br>- _screenType = ScreenType_<br>- _challengeExplorationNotification = boolean_<br>_releaseNotes = ReleaseNotes_<br>_termsStatus = TermsStatus_<br>_openPartnersIssueModal = boolean_<br>- _challengeActionNotification = boolean_<br>- _challengeDuelNotification = boolean_<br>- _analysisNotification = boolean_<br>- _fluidStatus = FluidStatus[]_<br>- _fluidTypes = FluidType[]_ |
| profile | Profile | store states about profile information such as: notification, connectionDate, profileType |
| chart | ChartState | store consumption chart states such as: timeStep, graph data<br><br>ChartState enum<br>- _selectedDate = DateTime_<br>- _currentTimeStep = TimeStep_<br>- _currentIndex = number_<br>- _currentDatachart = Datachart_<br>- _currentDatachartIndex = number_<br>- _loading = boolean_ |
| modal | ModalState | store opening state of the feedback modal <br><br>ModalState enum<br>- _isFeedbacksOpen = boolean_ |
......
# DACC
What is DACC ? A cozy blackbox where apps can send data in order to be anonymised and aggregate to provide usage stats.
## Infrastructure workflow
We have two environements, a dev one and a production. Both of them look like the following schema :
![dacc](/img/architecture/dacc.png)
On the developpement env, the 'cozy env' refers to our 'Alpha' VM.
## Service
There is a service named `aggregatorUsageEvent`, running on a daily basis, sending pre-processed data to cozy. This service is responsible for parsing traced events store in database and send them to cozy.
The service is configured to run every night at **01:00AM**.
## Usage events
This section explains how the application is tracking usage events. Here are the main step:
- All events are stored during the use of the application in the doctype **com.grandlyon.ecolyo.usageevents**
- A service is responsible of the aggregation of these events to create ANONYMIZED indicators. These indicators are then sent to a remote docType.
| Title | Tech name | target | context | startDate | result | trigger | Cozy Dacc Name |
| --- | --- | --- | --- | --- | --- | --- | --- |
| Changement d'action dans un challenge | ActionChangeEvent | Id de l'action | Id du challenge en cours | --- | --- | Chaque appui sur le bouton `selectEcogesture` dans le `ActionCard` | navigation-action-daily |
| Validation de la fin d'une action | ActionEndEvent | Id de l'ecogeste | Id du challenge en cours | Date de début de l'action | --- | Lors de l'appui sur le bouton de fin d'action | event-duration |
| Connexion d'un utilisateur | ConnectionEvent | --- | Navigateur utilisé | --- | Si c'est la première connexion `firstConnection` est stocké | A chaque chargement de l'application | connection-count-daily |
| Connecteur Classique | KonnectorConnectEvent | Slug du connecteur | --- | --- | Success ou error | Le succès dans le cas ou on a la pop-up 'félicitation', le 'error' en cas d'erreur de quelque type que ce soit (catch) | konnector-event-daily |
| Connecteur Oauth (enedis, GRDF) | KonnectorConnectEvent | Slug du connecteur | --- | --- | Success ou error | Le succès dans le cas ou on a la pop-up 'félicitation', le 'error' dans le cas ou aucun accoun n'est créé | konnector-event-daily |
| Refresh manuel du connecteur | KonnectorRefreshEvent | Slug du connecteur | --- | --- | Success ou error. Le succès est set quand l'état du trigger est a 'done' | Lors de l'appuie sur le bouton 'mettre a jour' | konnector-event-daily |
| Navigation utilisateur dans l'application | NavigationEvent | Nom de la page ( voir 1. en dessous ) | --- | --- | --- | --- | navigation-count-daily |
| Comparaison de consomation | ConsumptionCompareEvent | timestep in lowercase | fluid type in lowercase | --- | --- | --- | navigation-action-daily |
| Changement de pas de temps | ConsumptionChangeTimeStepEvent | timestep in lowercase | fluid type | --- | --- | --- | navigation-action-daily |
| Lancement d'un challenge | ChallengeLaunchEvent | challenge id | --- | --- | --- | Appuie sur le bouton de lancement de challenge dans le cas on la pop-up 'pas de fluid' ne s'affiche pas | event-duration |
| Title | Tech name | target | context | startDate | result | trigger | Cozy Dacc Name |
| Fin d'un challenge | ChallengeEndEvent | challenge id | --- | date de début du challenge | --- | Lors de la visualisation d'un challenge, si le resultat de celui-ci est a 'fini' on enregistre l'événement | event-duration |
| Début d'un duel | DuelLaunchEvent | duel id | challenge id | --- | --- | Appuie sur le bouton de lancement d'un duel | event-duration |
| Fin d'un duel | DuelEndEvent | duel id | --- | challenge start date | 'win' or 'loss' | Lors de la visualisation d'un duel, si le resultat de celui-ci est a 'fini' on enregistre l'événement | event-duration |
| Fin d'un quiz | QuizEndEvent | Quiz id | Challenge Id | Quiz start date | Resultat du quiz (de 0 a 5) | Lors de la pop-up de résultat | event-duration |
| Fin d'une exploration | ExplorationEndEvent | exploration id | challenge id | exploration start date | --- | Lors de la pop-up de résultat | event-duration |
| Changement de choix d'action | ActionChangeEvent | action id | current challenge id | --- | --- | Lors du click sur le bouton d'acceptation de l'action | navigation-action-daily |
| Fin d'une action | ActionEndEvent | action id | current challenge id | action start date | --- | Lors du click sur le bouton de validation de la page ActionDone | event-duration |
| Complétion d'un nouveau profile | ProfileSetEvent | --- | --- | --- | --- | Lors de l'affichage de la page de félicitation profileTypeFinished | navigation-action-daily |
| Consultation du nouveau bilan mensuel | ReportFromEvent | --- | 'analysis' | --- | 1 | Lorsque l'utilisateur consulte sa page analyse quand la notification est activée | summary-subscription-monthly |
1. Nom de la page, différents cas existant
| Page | target | Trigger |
| --- | --- | --- |
| Consomation | 'electricity', 'gas', 'eau', 'multifluid' | Click sur un des fluids dans la bar navigation |
| FAQ | 'faq' | Click sur la card de consultation |
| CGU | 'legalNotice' | Click sur la card de Legal Notice |
| Autres | 'consumption' 'challenges' 'ecogestures' 'analysis' 'options' | Click dans la navbar |
## Indicators
!!! warning "note"
All indicators are only sent if a user validate first version of CGU, the one containing dacc validation
### Monthly Indicators
All monthly indicators call can be found after this comment on the code
```js
// Monthly events
```
| Indicator | Trigger | value |
| --- | --- | --- |
| consumption-variation-monthly | Tous les mois si l'utilisateur a été connecté au moins une fois dans le mois | La variation de consomation par type de fluide. La paramètres différents sont le type de profile ainsi ue le nombre de mois d'anciennetée |
| summary-subscription-monthly | Tous les mois si un utilisateur a souscrit a la newsletter ou c'est désabonné | 1 si l'utilsteur est inscrit sinon 0 |
| fluid-data-granularity-monthly | Tous les mois sans condition | 1 si l'utilisateur possède de la donnée a la demi heure sur le mois. Sinon 0 |
| connection-count-monthly | Tous les mois si il y a eu au moins une connexion | Le nombre de jour unique de connexion |
| profile-count-monthly | Tous les mois si le profil a été complété au moins une fois | Le nombre de fois ou le profile a été complété |
### Daily Indicators
The daily process get all events of previous day and process them in the following indicators
| Indicator | Trigger | value |
| --- | --- | --- |
| connection-count-daily | Tous les jours | Nombre de connexion. Celle-ci sont catégorisé par type (mobile ou desktop) |
| konnector-event-daily | Tous les jours | Nombre d'essai. Ils sont catégorisé par type de connecteur, refresh/success et le status (error ou success) |
| konnector-connected-daily | Tous les jours | La valeur est 1. Les valeurs sont catégorisées par type de fluide (electricity / electricity:water ...) |
| navigation-count-daily | Tous les jours | nombre de page visualisé par type de page |
| challenge-launch-daily | Tous les jours | Nombre de défis lancés lors d'un challenge |
| session-duration | Tous les jours | Durée de la session en secondes |
| navigation-action-daily | Tous les jours | Nombre d'action sur une page donnée. Exemple sur la consomation on trace les changements de pas de temps sur chaque graph. |
| event-duration | Tous les jours | Durée entre deux événements:
1ere session et premier challenge / début de challenge et fin de challenge / début d'exploration et fin d'exploration / début d'action et fin d'action / début de duel et fin de duel |
| quiz-stars | Tous les jours | Nombre d'étoiles obtenu a la fin d'un quiz |
## Information sending
### Format
All indicator are post to a remote doctype, which will allow the application to read a defined external API. This doctype is created by Cozy itself.
The structure to send is the following :
```
{
createdBy: string
measureName: string
startDate: string
value: number | null
group1?: object
group2?: object
group3?: object
}
```
with:
- *createdBy*: contains "ecolyo" value.
- *startDate*: used to defined the start date of the indicator
- *value*: contains a value relevant to the defined indicator (example: number of page viewed on a day).
- *groups*: contains all attributes defining a indicator. Please refer to indicators definition (https://stats.cozycloud.cc/question#eyJkYXRhc2V0X3F1ZXJ5Ijp7ImRhdGFiYXNlIjo0LCJxdWVyeSI6eyJzb3VyY2UtdGFibGUiOjh9LCJ0eXBlIjoicXVlcnkifSwiZGlzcGxheSI6InRhYmxlIiwidmlzdWFsaXphdGlvbl9zZXR0aW5ncyI6e319)
- *mesureName*: contains one of the following value
| ENUM | value |
| --- | --- |
| CONNECTION_COUNT_DAILY | connection-count-daily |
| KONNECTOR_EVENT_DAILY | konnector-event-daily |
| KONNECTOR_CONNECTED_PER_DAY | konnector-connected-daily |
| NAVIGATION_COUNT_DAILY | navigation-count-daily |
| CHALLENGE_LAUNCH_EVENT_DAILY | challenge-launch-daily |
| CONSUMPTION_VARIATION_MONTHLY | consumption-variation-monthly |
| SESSION_DURATION | session-duration |
| NAVIGATION_ACTION_DAILY | navigation-action-daily |
| EVENT_DURATION | event-duration |
| QUIZ_STARS | quiz-stars |
| SUMMARY_SUBSCRIPTION_MONTHLY | summary-subscription-monthly |
| FLUID_DATA_GRANULARITY | fluid-data-granularity-monthly |
| CONNECTION_COUNT_MONTHLY | connection-count-monthly |
| PROFILE_COUNT_MONTHLY | profile-count-monthly |
### Environnements
There is two remote doctypes pointing to two differents mode. `dacc-dev` is used on alpha.
```json
"dacc": {
"type": "cc.cozycloud.dacc",
"verbs": ["ALL"]
},
"dacc-dev": {
"type": "cc.cozycloud.dacc.dev",
"verbs": ["ALL"]
},
```
## How to local test ?
First you need to modify the service in order to be able to see data in local :
- Modify dacc URL in order to see data (ligne 67)
```js
await client
.getStackClient()
.fetchJSON(
'POST',
environementService.isProduction()
? 'http://localhost:8081'
: '/remote/cc.cozycloud.dacc.dev',
{
data: JSON.stringify(indicator),
}
)
```
- Remove date protection if you want to test monthly indicators (ligne 1100)
```js
if (
profile
// &&
// DateTime.local()
// .setZone('utc', {
// keepLocalTime: true,
// })
// .startOf('day').day === profile.monthlyAnalysisDate.day
) {
```
Then you need to launch a script that will simulate dacc api's. This terminal will listen to incoming request
```sh
cd ./scripts
node server.js
```
Then you are finaly ready to test ! Just run the following :
```sh
yarn build-dev:browser; yarn run cozy-konnector-dev -m .\manifest.webapp .\build\services\fluidsPrices\ecolyo.js
```
You must see sent indicators in the previously open terminal
```json
{
data: '{"createdBy":"ecolyo","measureName":"connection-count-monthly","startDate":"2021-12-09","value":3}'
}
{
data: '{"createdBy":"ecolyo","measureName":"connection-count-monthly","startDate":"2021-12-09","value":3}'
}
```
## How to add new indicator ?
You have to reach cozy and discuss with them about new indicators. Thery will implement it for `dacc-dev` and `dacc` and you will be able to test it on alpha env. Remember you will need at least 5 data of each type to see it in metabase.
## Visualisation
All the data aggregated in the dacc can be visualized with a *Metabase* website hosted by cozy (https://stats.cozycloud.cc/).
\ No newline at end of file
......@@ -8,6 +8,39 @@ It includes different information such as icon, name, long and short description
Also, an ecogesture can be used for an action challenge.
### Model
```
Ecogesture {
id: string
shortName: string
longName: string
longDescription: string
usage: Usage
fluidTypes: FluidType[]
impactLevel: number
efficiency: number
difficulty: number
room: Room[]
season: Season
equipment: boolean
equipmentType: EquipmentType[]
equipmentInstallation: boolean
investment: string | null
action: boolean
actionName: string | null
actionDuration: number
objective: boolean
doing: boolean
}
```
### Ecogesture Status
An ecogesture can have a status according the user's choice, it can be *doing* and/or *objective* which allows the user to consult them in the related tabs in the ecogesture page.
### TODO: Add ecogesture selection rules
## All ecogestures screen
This screen display the full list of ecogestures. User can filter ecogesture by usage.
......
......@@ -46,6 +46,12 @@ Functions used to init or update the hash :
| initQuizEntity(hash: string) |
| initExplorationEntity(hash: string) |
!!! info "Exception for ecogestures"
When we update the ecogesture list in **ecogestureData.json**, we also get the previous existing list to transfer the ecogesture status (doing and/or objective) to the updated list.
### dataEntity vs userData
In the project, you'll see two versions for the same data. The dataEntity (quizEntity, challengeEntity, ...) is the data stored in the db folder and in the couchDB. These data are only edited in the couchDB when we update a challenge/quiz/duel or add a new one.
......
# Price Calculation
This section explains the price calculation process.
## Description
Since version `1.6.0` of the app, we have a database storing fluid prices evolution sincre 2012 for the following fluids :
* Elecricity
* Gas
Before this version, the app was applying a hard coded price for each fluid without taking care of the time period. Now, there is a service running every night that process fresh data in order to apply the current price to this data, but also apply the most relevant price for a fluid doctype.
## Service
### Process
The Cozy service responsible for price calculation is `fluidsPrices`. You can find the full logic in the following diagram :
```plantuml
@startuml
scale 0.8
start
repeat :Select Price (Elec, gas);
:Apply Prices on selected price;
if (There is prices in database) then (true)
:Get oldest data without price;
if (There is a doctype without price) then (Process price)
:Take founded date as time reference;
if (FluidType is elec) then (true)
repeat
:Get half-hour data by day (48 elements);
:Get price for the period;
:Apply price on each element;
:Save all elements;
:Increment date by one day;
repeat while (Date is not today)
else (false)
endif
repeat
:Get daily data by month (max 31 elements);
:Get price for the period;
:Apply price on each element;
:Save all elements;
:Increment date by one month;
repeat while (Date is not in current month)
:Start aggregation for month and year;
repeat
:Get daily data by month (max 31 elements);
:Get monthly data without price (1 element);
:Sum prices for all daily elements;
:Add price on monthly data doc;
:Save monthly element;
:Increment date by one month;
repeat while (Date is not in current month)
repeat
:Get monthly data by year (max 12 elements);
:Get yearly data without price (1 element);
:Sum prices for all monthly elements;
:Add price on yearly data doc;
:Save yearly element;
:Increment date by one year;
repeat while (Date is not in current year)
else (Stop service)
:Log error and stop process;
end
endif
else (Stop service)
:Log error and stop process;
end
endif
repeat while (All fluid are not processed)
stop
@enduml
```
This service is running every night at 02:00 AM.
!!! warning "note"
You might observe some price miscalculation if data from konnector is collect after the service runtime. Because of the hard code price, which is the current price, the user should not see any difference.
### Init
A migration job has been setup to init the database with json data store inside the app. This job should be run once and will init electricy and gas prices.
### New price
In case of price update the following procedure must be done :
* Create a migration for adding new prices
* Update hard coded price inside app in order to maintain fallback calculation
* Verify full service calculation with new data
* Verify calculation with existing data
!!! warning "note"
The service does not handle change during a month because the case does not exist anymore for Enedis and Grdf.
### Prices Data
We store in databse a collection of prices with the following info :
* StartDate
* EndDate
* fluidType
* Price
The EndDate is set to null if it's the current fluid price.
## App Price display
The app can handle the new price calculation and also keep the old calculation system.
### Regular display
If there is a price on the doctype we want to process, it will be use for display and calculation ( see analysis functionality).
### Fallback
The app take the hard code price for a given fluid and apply it to a load. This allow the app to handle prices in any case.
### How to test service ?
In a shell run a build and test service with le following command line :
```bash
yarn build-dev:browser; yarn run cozy-konnector-dev -m .\manifest.webapp .\build\services\monthlyReport\ecolyo.js
```
### Evolutions
We might consider a more dynamic process for fallback price calculation in the future:
* Get last price for a given price in database
* Use it to calculate value instead of the hard coded one
* Use it in all info pop-in for user information
This section explains the profileType creation process in order to make different comparisons between the actual user's consumtion and its profile type.
This section explains the profileType creation process in order to make different comparisons between the actual user's consumption and its profile type.
## Profile type data
......@@ -8,19 +8,21 @@ The profileType data are stored in the profile doctype and includes the followin
{
housingType: HousingType
constructionYear: ConstructionYear
area: number
area: string
occupantsNumber: number
outsideFacingWalls: OutsideFacingWalls
floor: Floor
heating: IndividualOrCollective
hotWater: IndividualOrCollective
coldWater: IndividualOrCollective
individualInsulationWork: IndividualInsulationWork
facilitiesInstallation: FacilitiesInstallation
hotWaterEquipment: HotWaterEquipment[]
warmingFluid: FluidType | null
hotWater: IndividualOrCollective
individualInsulationWork: IndividualInsulationWork[]
hasInstalledVentilation: ThreeChoicesAnswer
hasReplacedHeater: ThreeChoicesAnswer
hotWaterEquipment: HotWaterEquipment
warmingFluid: WarmingType | null
hotWaterFluid: FluidType | null
cookingFluid: FluidType
updateDate: DateTime
}
```
......@@ -33,7 +35,45 @@ Here is the flow of questions:
![ProfileTypeForm](/img/profile_type/profile_type_form.png)
## Profile type methods
## Profile types handling over time
A user can have many profileTypes, Ecolyo takes into account that one can move from his home, have more occupants, start renovating works and so on.
That's why a profileType is only active for a given time period, this is how its time logic works.
#### No filled profileType
A default profileType is loaded in redux to operate basic operations. When the user looks at its analysis or options, ecolyo suggest user to fill a more accurate profileType.
#### First profileType
The profileType will follow the form logic above (see ProfileType form section). *updateDate* field will be the current month and year.
Since this profileType will be the only one in database, *getProfileType()* method will always return it, therefore it will be used for all past time period on analysis.
#### Following profileTypes
Each new profileType form will show a calendar picking section at the end of the form.
By default, current month and year will be selected.
If current year is not yet completed (december not reached), month dropdown menu will only propose past and present months for this year.
When finishing, before the new profileType is saved. Checks if other profileTypes exist on the period between selected month/year and present day.
- If profileTypes are found, they are deleted (newest profileType always prevails on older ones, so that user had forgotten to fill some informations before, this new profiletype will be more accurate). Then save profileType on given month/year.
- If no other profileTypes are found, save profileType on given month/year.
## Profile type entity service
Here you can see the different methods provided by the profileType service. These methods allows to calculate the average consumption depending on the information gathered in user's profileType.
| Method | Description |
| ------------------------------------------------------------------------------------------------------ | ------------------------------------------------------------------------------------------------------------------- |
| getProfileType(date?: DateTime) : Promise-ProfileType, null | Returns a profiletype closest to the given param date. When no param date, returns most recent profiletype |
| getAllProfileTypes(timePeriod?: TimePeriod) : Promise-ProfileType[], null | Returns all profiletypes for given time period, if no param returns all profiletypes |
| updateProfileType(attributes: Partial-ProfileType): Promise-ProfileType, null | Saves profiletype in couchdb |
| deleteProfileTypes(profileTypes: ProfileType[]): Promise-boolean | Delete array of profileTypes |
| parseProfileTypeEntityToProfileType(profileTypeEntity: ProfileType): ProfileType | Retrieves ProfileType from the ProfileTypeEntity |
## Profile type service
Here you can see the different methods provided by the profileType service. These methods allows to calculate the average consumption depending on the information gathered in user's profileType.
......@@ -41,7 +81,7 @@ Here you can see the different methods provided by the profileType service. Thes
| ------------------------------------------------------------------------------------------------------ | ------------------------------------------------------------------------------------------------------------------- |
| getMonthlyForecast(month: number) : Promise-MonthlyForecast | Used to get the monthly forecast for a given month |
| getFluidForecast(fluidType: FluidType, month: number) : Promise-FluidForecast | Used to get the monthly forecast for a given FluidType |
| getDetailsMonthlyForecast(fluidType: FluidType, month: number): Promise-DetailsMonthlyForecast | Used to get the details of a fluidForecast. For each fluid return the related consumptions. |
| getDetailsMonthlyForecast(fluidType: FluidType, month: number): Promise-DetailsMonthlyForecast | Used to get the details of a fluidForecast. For each fluid return the related consumptions |
| getMonthColdWaterConsumption(month: number): number | Returns the cold water consumption in L for a given month |
| getMonthElectricSpecificConsumption(month: number): number | Returns the electric specific consumption in kWh for a given month |
| getMonthCookingConsumption(month: number): number | Returns the cooking consumption in kWh for a given month |
......
......@@ -13,12 +13,33 @@ The only public routes are :
- _/cgu_ : shows the CGU public page, accessible by the terms page
- _/legal_ : shows the Legal Notice public page, accessible by the terms page
### Terms managment
We check the terms acceptation in the **SplashScreen** while the application is initializing, if there is no consent (first connexion), or the consent is outdated (update of terms), the user will be redirected to the terms acceptation page.
User has to check the two checboxes (one for Data share consent, and one for CGU and Legal Notice) to unlock the terms acceptation button. Once he has accepted it, a new term doctype is created with the value _accepted_ to true. So he can access now the entire application.
For the full terms acceptation process, the user has to check the two checboxes (one for Data share consent, and one for CGU and Legal Notice) to unlock the terms acceptation button. Once he has accepted it, a new term doctype is created with the value _accepted_ to true. So he can access now the entire application.
We store in user's profile a boolean _showConsentModal_ that allows the app to know about the consent status.
If there is a consent update, two cases are possible :
- It's a major update, ex: from 1.X.X to 2.X.X, the user has to go through the entire term validation process as explained above
- It's a minor update, ex: from 1.1.X to 1.3.X or from 1.2.1 to 1.2.3, the user is just prompted with a modal with some text about the update, and a link to the legal notice, but there is no blocking acceptation input for the user.
### Version number
The version number of the last terms is stored in the **config.json** file. If this version number doesn't correspond with the last term accepted, the user won't be able to access the app and wil be prompted to accept new terms.
The version number of the last terms is stored in the **config.json** file. If this version number doesn't correspond with the last term accepted, according the update version type (minor or major), the user won't be able to access the app and will be prompted to accept new terms or will simply be prompted.
### Global state
Once the verification done in the **SplashScreen**, the last term state is stored in the redux store under the ecolyo.global state.
The model is the following :
```
termsStatus: {
accepted: boolean,
versionType: 'major' | 'minor' | 'init',
},
```
Major and minor value are only used in the case of an update. Otherwise we store the value 'init' which corresponds either to a first connexion or to case the last accepted term version is uptodate.
\ No newline at end of file
docs/img/architecture/dacc.png

59 KiB

......@@ -57,29 +57,31 @@ nav:
- Consumption Alert: ecolyo/services/consumption_alert.md
- Enedis Halfhour Monthly Analysis: ecolyo/services/enedis_halfhour_monthly_analysis.md
- Functionalities:
- Initialization: ecolyo/functionalities/initialization.md
- Analysis: ecolyo/functionalities/analysis.md
- Challenge: ecolyo/functionalities/challenge.md
- Consumption: ecolyo/functionalities/consumption.md
- Dacc: ecolyo/functionalities/dacc.md
- Ecogesture: ecolyo/functionalities/ecogesture.md
- Challenge: ecolyo/functionalities/challenge.md
- Profile Type: ecolyo/functionalities/profile_type.md
- Analysis: ecolyo/functionalities/analysis.md
- Usage events tracking: ecolyo/functionalities/usage_events_tracking.md
- Feedback: ecolyo/functionalities/feedback.md
- Initialization: ecolyo/functionalities/initialization.md
- Price Calculation: ecolyo/functionalities/prices_calculation.md
- Profile Type: ecolyo/functionalities/profile_type.md
- Terms: ecolyo/functionalities/terms.md
- Ecolyo-Agent:
- Usage events tracking: ecolyo/functionalities/usage_events_tracking.md
- Ecolyo-Agent:
- Introduction: ecolyo/ecolyo-agent/introduction.md
- Getting started:
- Setup your environment: ecolyo/ecolyo-agent/getting_started/setup_your_environment.md
- Launch the application on local: ecolyo/ecolyo-agent/getting_started/launch_local_application.md
- Libraries: ecolyo/ecolyo-agent/getting_started/libraries.md
- Setup your environment: ecolyo/ecolyo-agent/getting_started/setup_your_environment.md
- Launch the application on local: ecolyo/ecolyo-agent/getting_started/launch_local_application.md
- Libraries: ecolyo/ecolyo-agent/getting_started/libraries.md
- Functionalities:
- General: ecolyo/ecolyo-agent/functionalities/general.md
- Authentification: ecolyo/ecolyo-agent/functionalities/authentification.md
- Routes: ecolyo/ecolyo-agent/functionalities/routes.md
- General: ecolyo/ecolyo-agent/functionalities/general.md
- Authentification: ecolyo/ecolyo-agent/functionalities/authentification.md
- Routes: ecolyo/ecolyo-agent/functionalities/routes.md
- Development:
- Deploy: ecolyo/ecolyo-agent/development/deploy.md
- Handle assets: ecolyo/ecolyo-agent/development/handle_assets.md
- Backup: ecolyo/ecolyo-agent/development/backup.md
- Deploy: ecolyo/ecolyo-agent/development/deploy.md
- Handle assets: ecolyo/ecolyo-agent/development/handle_assets.md
- Backup: ecolyo/ecolyo-agent/development/backup.md
- Pilote:
- Pilote - TS - Back:
- Index: pilote/Pilote - TS - Back/index.md
......