Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[WIP] 24.2 Release testing - various workflow features #19216

Closed
wants to merge 45 commits into from

Conversation

jmchilton
Copy link
Member

@jmchilton jmchilton commented Nov 27, 2024

Will retarget against 24.2 once the activity bar has landed.

  • A few tests for the change stack - first time playing with the feature - very cool.
  • Implement a UI test for the activity bar upgrade all activity.
  • Implement an initial simple best practice test to exercise the best practice activity.

How to test the changes?

(Select all options that apply)

License

  • I agree to license these and all my past contributions to the core galaxy codebase under the MIT license.

mvdbeek and others added 8 commits November 29, 2024 16:42
@jmchilton jmchilton force-pushed the change_stack_selenium branch 2 times, most recently from 3a5fb4e to 7eab266 Compare December 2, 2024 20:10
jmchilton and others added 13 commits December 2, 2024 16:08
This is an initial/draft implementation. Some of the next steps are:
- By default, instead of the modals treating the items as selections from the current history, automatically filter items valid for the list (e.g.: for a list with csv elements, filter out csvs from the history in this list).
- In case nothing can be auto paried for `list:paired`, do not attempt to auto pair by default and simply show all items.
- In case the current history is empty and to make it clearer in general, allow history to be switched from within the modal?
- Allow files to be uploaded (and dropped) directly to either the form field or within the list builder once it is opened.

One thing I have not planned for yet is the rule builder. I can see that for `list` and `list:paired`, we get that from the `props.collectionTypes` in `FormData`. But when would we use the rule builder instead?

Fixes galaxyproject#18704
This allows a collection type `list` to be created via the collection creater from the workflow/tool form directly.
It tracks the current history changes via the new `useHistoryItemsForType` composable.
It utilises the `FormSelectMany` component to easily move items between selected and unselected for list columns.
The items in the list creator can be filtered for extension, parent datatype or all items in the history, based on whether the form field required a certain extension(s) as input for the list.
This keeps the order in which the user adds items to the selection evident in the selected column.
- Converted the file(s) to composition API and typescript
- Improved styling of the modal and its components

Still need to add `extensions` handling for cases where a certain extension is required for the collection.
The `isSubClassOfAny` was incorrect logic for implicit conversions. `isSubTypeOfAny` gives us what we want as far as filtering items that would be valid for implicit conversions goes.
Also, we concluded that the `All` option was also not acceptable as only valid extensions must be enforced in the collection creator.
Place it right next to the buttons for choosing between batch or singular collection
ahmedhamidawan and others added 17 commits December 2, 2024 16:08
- `buildCollectionModal.ts` still exists but just to create the rules collection modal, all other modals are replaced with a parent `CollectionCreatorModal`
- also added a `collectionBuilderItemsStore` that is used to store the datasets fetched for the builder; only when the builder is opened: which is when we start reacting to any changes in the `historyId`, `history.update_time` and any filter on a history selection.
`stringifyObject` does not need to be re-run for every selected value.

Co-authored-by: Laila Los <[email protected]>
In the case of `list`, they are now added directly to the final list.
In the case of `list:paired` and `paired`, they are added to the `workingElements`; the user can then manually add them.
This is all still done within the `CollectionCreator`.

Next thing to look at is to try to only allow/wait for those uploaded files to be attempted as collection additions if they are of `ok` state.
One way to do that is to maybe use a list to keep track of uploaded items in the creator, and if those uploaded items disappear from `workingElements` (meaning they are invalid) we have explicit Toasts mentioning this.
fix selector for name collection in collection builder

fix hide original items selector in collection creator

fix clear filters selector in collection creator
This fixes seleniums failing in `lib/galaxy_test/selenium/test_library_to_collections.py::TestLibraryToCollections` where the modal was in the way.
…s_to_collection_builder

[24.2] Guide users to collection builders
@jmchilton jmchilton force-pushed the change_stack_selenium branch from 7eab266 to e96593d Compare December 3, 2024 16:21
@jmchilton jmchilton changed the title [WIP] 24.2 Release testing - selenium tests for workflow editor changes stack [WIP] 24.2 Release testing - various workflow features Dec 3, 2024
@jmchilton jmchilton force-pushed the change_stack_selenium branch from e96593d to bf48bdf Compare December 3, 2024 17:46
@jmchilton jmchilton added the release-testing-24.2 Issues stemming from 24.2 release testing process and PRs to address them label Dec 5, 2024
@jmchilton jmchilton closed this Dec 8, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area/testing/selenium area/workflows kind/bug kind/enhancement release-testing-24.2 Issues stemming from 24.2 release testing process and PRs to address them
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants