Skip to content

Related to fnd 200 bugs - #24571

Closed
klaustopher wants to merge 4 commits into
fix-FND-200from
related-to-fnd-200-bugs
Closed

Related to fnd 200 bugs#24571
klaustopher wants to merge 4 commits into
fix-FND-200from
related-to-fnd-200-bugs

Conversation

@klaustopher

Copy link
Copy Markdown
Contributor

Related bugs to FND-200, identified and fixed by Claude, needs further investigation

FND-200 fixed the project field on the global create form, but the same
mismatch existed wherever a type id meets work_packages.type_id: users pick
the type they see while a project's work packages carry whichever member of
the family that project runs.

The family SQL now lives on Type, so the shape exists once:

  in_families_of / roots_of / family_ids / root_ids  - resolution from ids,
      records or a relation, in a single query
  root_id_expression / root_id_subquery              - the root of a joined
      types row, or of a bare type_id column
  same_family_condition                              - two joined types rows
  family_setting_expression                          - a setting as it applies
      to the family, for inherited core settings and for position

Fixed with it:

- Backlogs excluded types matched exactly, so excluding a type in a project
  running its variant excluded nothing.
- The bulk move form warned that a type is unavailable in the target project
  when that project runs a sibling variant, blocking a move the backend
  completes.
- Custom action type conditions never fired on work packages of a variant;
  conditions and actions now offer roots and fold configured variants into
  them.
- Cost report type filters missed variant-typed work packages and listed
  variant names.
- The work package type filter expanded a root to its variants but not a
  variant to its family, and only accepted root ids outside a project.
- Type.milestone read the variant's own is_milestone column rather than the
  root's, which is where the flag lives.
- Grouping by type produced one group per family member, all captioned
  identically; sorting by type used the variant's position, which is append
  order within its family and no display order at all.
- Relation-to-type columns were generated per family member.
- BCF exposed variant names as topic types and matched imports against them.
- The workflow summary listed variants under the root's name, now their
  composite name, as variants configure their own workflows.
- Type's default scope ordered by an unqualified position, which is ambiguous
  as soon as types is self-joined for a parent.

Left alone deliberately: grouping a cost report by type still groups per
family member. That engine prefixes group fields with a table name, so an
expression cannot be injected without rewriting its aggregation layer, and
the numbers per row stay correct.
The relation-to-type column is now generated per family, but the count is
computed in the browser by comparing the target work package's type href
against the column's, and a work package carries whichever member of the
family its project runs. So the column named after the type users see counted
nothing for the projects running a variant.

The column now carries every type it counts as _links.types, letting the
client widen the comparison without loading a type per relation, and keys its
cache on the whole family so gaining a variant is picked up. The client falls
back to the single type link when types is absent.
Query#available_columns generates the relation columns from Type.roots since
the columns are per type family. The caching spec stubbed Type.all with a
plain array, which a scope cannot execute against.
@klaustopher klaustopher closed this Aug 6, 2026
@klaustopher
klaustopher deleted the related-to-fnd-200-bugs branch August 6, 2026 12:38
@github-actions github-actions Bot locked and limited conversation to collaborators Aug 6, 2026
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.

Labels

None yet

Development

Successfully merging this pull request may close these issues.

1 participant