Subcategories handling in /contributors/category-analysis/:id

[lepeuvedic-natixar]

Problem: In the page /contributors/category-analysis/:id the list of subcategories is just illustrative text and is not real data. The same process that is used to identify top level categories (former scopes) can be used to show subcategories.

If the data sent by the backend does not contain subcategories, the list shall be empty.

This will be especially helpful with the GHG Protocol, which has its Scope 3 divided in Upstream and Downstream, and where the subcategories make sense.

Steps to reproduce: 1 - Enter the Dashboard 2 - Navigate on Scope 1, then click on the link on the category name to enter contributors/category-analysis 3 - On the bottom left, the list of subcategories is a fake list that is purely illustrative Must be fixed before solving issue #49 because it will be difficult to observe afterwards given the currently available data.

Expected behavior: If there are no categories, nothing should be displayed. In due time, the back-end will transmit richer data describing how categories are made, based on its internal categorization. Note that subcategories should not necessarily be the third level of the category nomenclature, due to the intermediate Upstream / Downstream level in GHG Protocol. Instead subcategories shall be defined as one level below categories.

[lepeuvedic-natixar]

Le dev d'origine a écrit: Issue https://github.com/Natixar/natixar-frontend/issues/25 I see. Sure, a list of subcategories can be displayed using AlignedIndexes. The widget is: src/sections/contributor/category-analysis/CategoryCard.tsx Inside the useAsyncWork hook, one can use expandId function (or any other written one). To select the category itself (to be removed from list) and all its subcategories.

Later the derived list can be used at the list structure on line 158.

The reasoning for leaving the hardcoded data here was unclarity do subcategories exist at all._

[benjaminpeuple]

Fixed but without API data. No API is linked to this part so I can't test in real time.

See https://github.com/benjaminpeuple/natixar-front/pull/7

Conclusion: Indeed, in the CategoryCard.tsx part, I had to add a new subcategories props and I looped over it by coding a filter which deletes the main categoryId.

[lepeuvedic]

The data comes from the /data/ranges API endpoint. The same response body contains all the categories (and subcategories if any), all the entities and all the locations. As long as the front does not cache the categories, entities and locations, it will be necessary to send the whole block of data, even if it is not referenced due to filter settings. For example, we return location A even if location A did not exist in the date range picked by the user.

Currently, all the category trees returned have two levels, except Scope 3 in GHG Protocol, which is divided in Upstream and Downstream. Due to an error in the definition of a category, the current code considers that the Scope 3 categories are "Upstream" and "Downstream" and there are defacto subcategories defined there. Unfortunately, the proposed implementation fails to correctly explore the categories tree, and does not show the subcategories under Upstream, as shown here:

This subcategory question must be fixed before we fix the category bug in GHG Protocol, because once this bug is fixed, we really will not have any possibility to test the subcategories functionality.

Here is an excerpt of the response sent by the backend, showing subcategories under "Upstream":

          {
            id: 12,
            parent: 11,
            name: "Upstream",
            era: "U"
          },
          {
            id: 13,
            parent: 12,
            name: "Produits et services achetés",
            code: "3-1",
            era: "U"
          },
          {
            id: 14,
            parent: 12,
            name: "Biens immobilisés",
            code: "3-2",
            era: "U"
          },