Ref: BSC06
Is your feature request related to a problem? Please describe.
Currently, the Decidim API does not offer all the data collected by the platform, due to the addition of new functionalities in recent years that generate new data. Therefore, it is necessary to update the API's functionality so that it can collect all the available data on the platform.
Describe the solution you'd like
All models and their fields published within the platform's participant interface will be reviewed, and a comparison will be made to determine which of these are available in the API. If any fields are found to be unavailable, the addition of these models and/or fields to the API will be developed.
Describe alternatives you've considered
To have some kind of contract in the models/schemas that could ease-up this kind of discovery of new fields.
To have a better review process when we introduce new fields.
To have a CI mechanism to detect when there’s a new table/column in the database so we can allow-list this new field (after it was added in the CSVs/API).
To regularly make this same task (yearly or every two years)
Additional context
A similar process was already done in the past during 2020: https://github.com/decidim/decidim/pulls?q=sort%3Aupdated-desc+is%3Apr++label%3Agraphql-api+created%3A2019-12-01..2020-10-01
This is related to BSC06, MGOV05 and MGOV06, as the problem is the same. The main difference is that:
- BSC06 (this issue): is focused in API GraphQL for researchers (public interface)
- MGOV05: is focused in CSV for administrators (private interface) only for spaces
- MGOV06: is focused in CSV for administrators (private interface) only for components
Does this issue could impact on users private data?
Yes, some of these fields could be user related so we should be extra careful about which tables/fields we will publish.
Acceptance criteria
Ref: BSC06
Is your feature request related to a problem? Please describe.
Currently, the Decidim API does not offer all the data collected by the platform, due to the addition of new functionalities in recent years that generate new data. Therefore, it is necessary to update the API's functionality so that it can collect all the available data on the platform.
Describe the solution you'd like
All models and their fields published within the platform's participant interface will be reviewed, and a comparison will be made to determine which of these are available in the API. If any fields are found to be unavailable, the addition of these models and/or fields to the API will be developed.
Describe alternatives you've considered
To have some kind of contract in the models/schemas that could ease-up this kind of discovery of new fields.
To have a better review process when we introduce new fields.
To have a CI mechanism to detect when there’s a new table/column in the database so we can allow-list this new field (after it was added in the CSVs/API).
To regularly make this same task (yearly or every two years)
Additional context
A similar process was already done in the past during 2020: https://github.com/decidim/decidim/pulls?q=sort%3Aupdated-desc+is%3Apr++label%3Agraphql-api+created%3A2019-12-01..2020-10-01
This is related to BSC06, MGOV05 and MGOV06, as the problem is the same. The main difference is that:
Does this issue could impact on users private data?
Yes, some of these fields could be user related so we should be extra careful about which tables/fields we will publish.
Acceptance criteria
I have a CSV file for each module with all the fields from the generated db/schema.rb of the development_app
With the columns
table, column, api_published, api_to_be_publisheThe modules:decidim-accountabilityGraphQL API #14326decidim-assembliesGraphQL API #14329decidim-blogsGraphQL API #14327decidim-budgetsGraphQL API #14328decidim-conferencesGraphQL API #14330decidim-debatesGraphQL API #14331And I visit /api
Then I can see new fields in this page