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

RUN-2193, RUN-2194, RUN-2195: :nextUI: convert forecast page #9121

Open
wants to merge 5 commits into
base: main
Choose a base branch
from

Conversation

smartinellibenedetti
Copy link
Contributor

@smartinellibenedetti smartinellibenedetti commented May 15, 2024

Is this a bugfix, or an enhancement? Please describe.

This PR is part of the changes necessary for the vue conversion of the schedule forecast page (RUN-2193, RUN-2194 and RUN-2195).

Update the project select dropdown to allow multiple selections.

Describe the solution you've implemented

ProjectSelect accepts now a mode prop, whose value will determine its behavior. If "single", projectSelect will render links that upon click will take the user to the project page, if "multi", ProjectSelect will emit an array with the names of the selected projects.

Also, ProjectSelectButton can render a label in accordance to the number of projects selected.

Describe alternatives you've considered

Adapt vue-multiselect, which was asked to change in prol of reusing the projectSelect.

Additional context

Will add tests in a separate PR along with the tests for the full component behavior.

@smartinellibenedetti smartinellibenedetti added this to the 5.4.0 milestone May 15, 2024
@pd-snyk-integration
Copy link

🎉 Snyk hasn't found any issues so far.

code/snyk check is completed. No issues were found. (View Details)

Copy link
Member

@gschueler gschueler left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

changes to the API (adding averageDuration to the forecast info) should be put behind a new API version.

Additionally, perhaps the API change should be separated from the UI change here, so it can be tested separately

@smartinellibenedetti
Copy link
Contributor Author

changes to the API (adding averageDuration to the forecast info) should be put behind a new API version.

Additionally, perhaps the API change should be separated from the UI change here, so it can be tested separately

Questions:

  • should the API version be bumped upon any change on the APIs? Or the gist is, new params should bump the version, while fixes should not?
  • happy to separate this PR into a second one, but this will make it harder to test the pro changes until at least one of them get merged. Is that okay?

@gschueler
Copy link
Member

@smartinellibenedetti a) yes, functional changes should increase API version so users of older API versions have old behavior. Bug fixes would not require that. b) yes let's do 2 prs

@smartinellibenedetti
Copy link
Contributor Author

@gschueler PR for api changes are here: #9143 and updated this PR to just have the component changes

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants