Conversation
Since the AGILE-432 fix a row added without a value is left out of the request, so a form that the response morphs (Meetings) renders it hidden again. The controller now marks such rows and stops the morph from hiding them, instead of sending an empty value the server rejects as an invalid filter. A restored page drops the marked rows again, as Turbo snapshots them before the controller disconnects. An empty date range counts as no value, so a fresh "Dates interval" row is kept the same way. Restores the Meeting status example in meetings_index_spec. https://community.openproject.org/wp/AGILE-432
Replaces the stored bound handlers for the clear button and the morph guard with one AbortController that disconnect aborts. Drops the second getElementById lookup and the initialize-time bindings those needed.
The variant examples added in #25525 still set workflows_source and read form_configuration_source. The workflow extraction removed both (DropWorkflowsAspectLink, and linked aspects in place of the per-aspect sources), so the shared_let raised NoMethodError while the suite was being set up, failing four examples and erroring outside of examples on dev. The owned variant now shares its source variant's named workflow, and the variant that owns its workflow gets a project-owned one. The narrowing example links the form configuration aspect before excluding an element, since exclusions only apply to a linked aspect, and asserts that the copy is still linked.
The helper only touches the row it is given and never reads controller state, so it lives as a module function next to the pending marker it serves rather than as a private method.
A row that now carries a value is the server's to render from here on, so its marker is dropped before the request goes out. The method name says so; the inline block in sendForm did not.
Dropping an unsent row on a restored page resets its control values, but primer-multi-input keeps the active picker in hidden and disabled attributes that a value reset does not touch. Adding the filter again then showed the range picker under the default operator. The row now re-applies the operator's visibility after the reset.
The operator change submits behind a 300 ms debounce while the idle wait returned after 50 ms of quiet, so the list and URL assertions ran before any request could have gone out and passed either way.
Guarding only the row's hidden attribute and marker let a response that does not know the row put its operator, draft value and active picker back to server defaults. A user who had picked "does not contain" would then submit "contains". A pending row is now skipped by the morph as a whole; the add-filter option keeps its own guard.
…utowork-311-copy-spec-named-workflows
tangopium
changed the base branch from
dev
to
bug/agile-432-keep-added-filter-row-visible
September 24, 2026 08:43
tangopium
changed the base branch from
bug/agile-432-keep-added-filter-row-visible
to
dev
September 24, 2026 08:43
Collaborator
Author
oliverguenther
deleted the
bug/autowork-311-copy-spec-named-workflows
branch
September 30, 2026 08:29
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Ticket
https://community.openproject.org/work_packages/AUTOWORK-311
Follow-up to #25525.
Stacked on #25519: merge that first. It fixes the other failure on
dev,modules/meeting/spec/features/meetings_index_spec.rb:203, which the unit failures have hidden since they stop CI before the feature tests. This branch merges #25519's branch so that CI runs with both fixes. #25519's branch is behinddev, so this PR targetsdevand lists #25519's three files until it is merged.What are you trying to accomplish?
devis red: the Test suite fails four examples inspec/services/projects/copy_service_integration_spec.rband reports an error outside of examples, on every branch that mergesdev. The first failing run is 35872628006, on the merge of #25525, and everydevrun since has failed the same way.The variant examples added in #25525 still set
workflows_source:on a type variant and readform_configuration_source. The workflow extraction removed both before #25525 was merged:DropWorkflowsAspectLinkdrops theworkflows_source_idcolumn in favour of named workflows (TypeVariant#workflow), and linked aspects (TypeVariant#linked_aspects) replace the per-aspect sources. Theshared_letbuilding the owned variant therefore raisedNoMethodErrorduring suite setup.To reproduce on
dev:Before:
78 examples, 4 failures, 1 pending, 1 error occurred outside of examples. After:78 examples, 0 failures, 1 pending.What approach did you choose and why?
Only the spec changes, rewritten for the current model:
workflow: workflow_source.workflow), which is whatworkflows_source:expressed. The source variant gets its own named workflow, so a copy that fell back to the type's default workflow would fail the example.create(:project_owned_workflow, project: source)), which is whatworkflows_source: nilexpressed.source_foron both variants instead would comparenilwithnilwhenever the aspect is not linked.@oliverguenther, one thing for you: the pending example "copies the project" still fails, now with
PG::NotNullViolationonproject_types.variant_idwhen the source variant owns a project-owned workflow, so copying such a project does not carry the workflow across. Its old pending reason ("Blocked until variants reference named workflows") no longer described the blocker, so it now reads "Blocked until project copying supports project-owned workflows". I left it pending rather than guess the intended copy behaviour.Merge checklist