Edit wizard directly on dashboard

[abbyhu2000]

Description

Edit wizard directly on dashboard following the steps:

1. choose a dashboard
2. click Edit button on the top nav bar of the dashboard
3. select the setting button on the top right of a wizard on that dashboard
4. click edit wizard

When finish editing wizard, there are some different options for saving that wizard, this PR ensures the below five different flows for editing wizard all work as expected:

1. Save and return button on top nav bar --> will save the original wizard and return back to the dashboard without displaying an additional save modal
2. Save as button on top nav bar --> will open a save modal
   • save as new wizard toggle on + add to dashboard after saving toggle on + Save and return button
   • save as new wizard toggle on + add to dashboard after saving toggle off + Save button
   • save as new wizard toggle off + return to dashboard after saving toggle on + Save and return button
   • save as new wizard toggle off + return to dashboard after saving toggle off + Save button

Issues Resolved

#2382

Check List

• All tests pass
  • yarn test:jest
  • yarn test:jest_integration
  • yarn test:ftr
• New functionality includes testing.
• New functionality has been documented.
• Update CHANGELOG.md
• Commits are signed per the DCO using --signoff

[codecov-commenter]

Codecov Report

Merging #2508 (55bffea) into main (ac07159) will decrease coverage by 0.01%.
The diff coverage is 12.50%.

@@            Coverage Diff             @@
##             main    #2508      +/-   ##
==========================================
- Coverage   66.74%   66.72%   -0.02%     
==========================================
  Files        3201     3201              
  Lines       60948    60955       +7     
  Branches     9267     9271       +4     
==========================================
- Hits        40679    40675       -4     
- Misses      18052    18062      +10     
- Partials     2217     2218       +1     

Impacted Files	Coverage Δ
...rd/public/application/utils/get_top_nav_config.tsx	56.52% <12.50%> (-10.15%)	⬇️
...ared/static/forms/hook_form_lib/hooks/use_field.ts	65.70% <0.00%> (-0.97%)	⬇️
...ic/application/models/sense_editor/sense_editor.ts	64.00% <0.00%> (-0.89%)	⬇️

Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here.

[joshuarrrr]

Now that we have some test coverage for saving and loading (thanks!), we should also include unit tests for this flow, particularly because there are five separate user flows that are a little confusing to mentally model.

[abbyhu2000]

Now that we have some test coverage for saving and loading (thanks!), we should also include unit tests for this flow, particularly because there are five separate user flows that are a little confusing to mentally model.

@joshuarrrr Yea i agree. Do you think it is more appropriate to write functional tests for these flows? Since it involves with user clicking different button and toggle.

Also when i was writing the unit tests for get_top_nav_config() function, i included a unit test for the edit logic there.

OpenSearch-Dashboards/src/plugins/wizard/public/application/utils/get_top_nav_config.test.tsx

Line 140 in b75e07d

test('edit an exising wizard from dashboard', async () => {

[ashwin-pc]

@joshuarrrr yeah there is a functional test we plan on adding for this flow.

[ashwin-pc]

Now that we have some test coverage for saving and loading (thanks!), we should also include unit tests for this flow, particularly because there are five separate user flows that are a little confusing to mentally model.

@joshuarrrr Yea i agree. Do you think it is more appropriate to write functional tests for these flows? Since it involves with user clicking different button and toggle.

Also when i was writing the unit tests for get_top_nav_config() function, i included a unit test for the edit logic there.

OpenSearch-Dashboards/src/plugins/wizard/public/application/utils/get_top_nav_config.test.tsx

Line 140 in b75e07d

test('edit an exising wizard from dashboard', async () => {

@abbyhu2000 how was that test for the edit flow previously passing if the change is being made here?

[abbyhu2000]

Now that we have some test coverage for saving and loading (thanks!), we should also include unit tests for this flow, particularly because there are five separate user flows that are a little confusing to mentally model.

@joshuarrrr Yea i agree. Do you think it is more appropriate to write functional tests for these flows? Since it involves with user clicking different button and toggle.
Also when i was writing the unit tests for get_top_nav_config() function, i included a unit test for the edit logic there.

OpenSearch-Dashboards/src/plugins/wizard/public/application/utils/get_top_nav_config.test.tsx

Line 140 in b75e07d

test('edit an exising wizard from dashboard', async () => {

@abbyhu2000 how was that test for the edit flow previously passing if the change is being made here?

@ashwin-pc When i am writing my last PR(create wizard directly from dashboard), i include the editing logic in the onSave() function. So when i am writing unit tests for onSave(), i am able to mock the props of onSave and test that part of the logic. However, in order for editing wizard from dashboard to work, the logic that's needed inside the topNavConfig constant to call that onSave() function with the correct props are still missing, so this PR added those logics. Previously when we try to edit wizard directly from dashboard, the changes were not being saved after we click Save.

[ananzh]

LGTM

[kavilla]

NIT: Casing is off on this one.

[opensearch-trigger-bot]

The backport to 2.x failed:

The process '/usr/bin/git' failed with exit code 1

To backport manually, run these commands in your terminal:

# Fetch latest updates from GitHub
git fetch
# Create a new working tree
git worktree add .worktrees/backport-2.x 2.x
# Navigate to the new working tree
cd .worktrees/backport-2.x
# Create a new branch
git switch --create backport/backport-2508-to-2.x
# Cherry-pick the merged commit of this pull request and resolve the conflicts
git cherry-pick -x --mainline 1 d6197a7827cc6858fb31af98154f8e8324b80fe3
# Push it to GitHub
git push --set-upstream origin backport/backport-2508-to-2.x
# Go back to the original working tree
cd ../..
# Delete the working tree
git worktree remove .worktrees/backport-2.x

Then, create a pull request where the base branch is 2.x and the compare/head branch is backport/backport-2508-to-2.x.