Skip to content

Assigner target validation to service is too tight #168

@matt-beanland

Description

@matt-beanland

Found it. In lib/diffo/provider/assigner/assigner.ex:68-72:

defp check_lifecycle(%{type: :service, service_state: state})
when state not in [:active, :inactive],
do: {:error, "cannot assign: service state is ... must be :active or :inactive"}
You're right — for services, the Assigner only permits :active or :inactive.

This is too restrictive as sometimes resources need to be acquired or held in other state, such as feasibility,

Metadata

Metadata

Assignees

No one assigned

    Labels

    bugSomething isn't working

    Type

    No type
    No fields configured for issues without a type.

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions