You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Is your proposal related to a problem?
Currently, Decidim uses two identical models for defining Scopes and Areas, leading to duplicate code. We aim to streamline this by using a single model for different taxonomies, not limited to Scopes and Areas.
Describe the solution you'd like
Develop a unified model that is flexible enough to define various taxonomies within Decidim. This model should replace the current separate Scope, Area and Category models, reducing code redundancy and enhancing maintainability.
Describe alternatives you've considered
N/A - the current approach of using separate models is inefficient and maintaining two identical models is not sustainable.
Given that I'm a developer working on Decidim, when I work with taxonomies, then I should be able to use a single unified model for all types.
Given that the unified model is implemented, when I examine Scopes, Areas or Categories, then they should be instances of this single model.
Given the new model is in use, when I extend Decidim to include new taxonomies, then I should be able to do so using the unified model without needing to create additional models.
Given that I'm an administrator on Decidim, when I navigate to Settings > Taxonomies, then I should be able to define and manage Geographic Scopes, Thematic Areas, Categories and any other taxonomy using the unified model.
Is your proposal related to a problem?
Currently, Decidim uses two identical models for defining Scopes and Areas, leading to duplicate code. We aim to streamline this by using a single model for different taxonomies, not limited to Scopes and Areas.
Describe the solution you'd like
Develop a unified model that is flexible enough to define various taxonomies within Decidim. This model should replace the current separate Scope, Area and Category models, reducing code redundancy and enhancing maintainability.
Describe alternatives you've considered
N/A - the current approach of using separate models is inefficient and maintaining two identical models is not sustainable.
Additional context
#2709
#3517
#3540 (comment)
Acceptance criteria