Skip to content

Proposal States do not generate consistent, predictable tokens making many operations unusable for admins #15637

@microstudi

Description

@microstudi

Describe the bug

Certain operations in Decidim use the attribute token of the model ProposalState.
This token is generated when the state is created by the admin before saving the model:

before_validation :generate_token, on: :create

def generate_token
        self.token = ensure_unique_token(token.presence || translated_attribute(title).parameterize(separator: "_"))
end

As you can see, the default value will depend on the "title" attribute, which can be anything written by the user.
To be honest, I don't see the point on having this attribute token at all as it is not predictable.

The problem

One action that uses the value of the token to perform operations is when you want to import proposals into budgets:

Image

This action uses the scope "accepted" in the Proposal model:

scope :accepted, -> { state_published.only_status(:accepted)
scope :rejected, -> { state_published.only_status(:rejected) }
scope :evaluating, -> { state_published.only_status(:evaluating) }

I think this statuses must be refactored in order to make them language independent. They are many decidims that do not use english at all.

Possible solutions.

  1. never to use this token value, instead always present a "select" everywhere a operation regarding filtering proposals by state is required. For instance, instead of a checkbox "import all accepted proposals", add a select with "import proposals with state X1, ...". This would be the most agnostic solution.
  2. Add a fixed type of state for admins to choose when creating a states, between "this state represents: accepted, rejected, evaluating, other". This solution would be easier to implement but les agnostic and kind of "hacky" in my opinion.

To Reproduce

  1. Go to a proposals component, remove states by default if existing. Create new ones without the word "accepted", but representing the action of acceptation (just do not write in English)
  2. Create some proposals, accept them.
  3. Create a budged component, add a item, edit it, import proposals with the checkbox "import accepted proposals"
  4. See that 0 proposals are imported.

Expected behavior

I'd expect for admins not to need to be aware of the internal keys for generation relationships between components and actions in order to perform operations.

Workraounds

You can get away with this bug by entering the rails console from time to time and executing this operation:

Decidim::Proposals::ProposalState.where(token: "aceptada").update_all(token: "accepted")

note the the word "aceptada" needs to be replaced by the one used in you organization with that meaning (that will depend on the language).
See all your existing tokens with this operation:

Decidim::proposals::ProposalState.pluck :token, :title

Screenshots

No response

Stacktrace

No response

Extra data

  • Device: Any
  • Device OS: Any
  • Browser: Any
  • Decidim Version: Since the introduction of ProposalState
  • Decidim installation: any

Additional context

No response

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    Projects

    Status

    Backlog

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions