Show volume UUIDs in the backup details page
Description
When accessing the details of a backup in the UI, all the volumes that are part of the backup are listed. However, the listing displays a UUID that does not identify the volume, but it's path in the storage, which can cause confusion for users. This PR changed the listing details to display the UUID of the volumes.
Types of changes
- [ ] Breaking change (fix or feature that would cause existing functionality to change)
- [ ] New feature (non-breaking change which adds functionality)
- [ ] Bug fix (non-breaking change which fixes an issue)
- [ ] Enhancement (improves an existing feature and functionality)
- [X] Cleanup (Code refactoring and cleanup, that may add test cases)
- [ ] Build/CI
- [ ] Test (unit or integration test code)
Feature/Enhancement Scale or Bug Severity
Feature/Enhancement Scale
- [ ] Major
- [X] Minor
Screenshots (if appropriate):
Backup volumes before changes:
Volume path:
Backup volume:
Backup volumes after changes:
Volume path:
Backup volume:
How Has This Been Tested?
I created a VM to perform the tests and assigned it a backup offering. After that I created a backup and verified that the volumes UUID had been changed to their respective UUID in the backup details.
How did you try to break this feature and the system with this change?
Congratulations on your first Pull Request and welcome to the Apache CloudStack community! If you have any issues or are unsure about any anything please check our Contribution Guide (https://github.com/apache/cloudstack/blob/main/CONTRIBUTING.md) Here are some useful points:
- In case of a new feature add useful documentation (raise doc PR at https://github.com/apache/cloudstack-documentation)
- Be patient and persistent. It might take some time to get a review or get the final approval from the committers.
- Pay attention to the quality of your code, ensure tests are passing and your PR doesn't have conflicts.
- Please follow ASF Code of Conduct for all communication including (but not limited to) comments on Pull Requests, Issues, Mailing list and Slack.
- Be sure to read the CloudStack Coding Conventions. Apache CloudStack is a community-driven project and together we are making it better 🚀. In case of doubts contact the developers at: Mailing List: [email protected] (https://cloudstack.apache.org/mailing-lists.html) Slack: https://apachecloudstack.slack.com/
Codecov Report
:white_check_mark: All modified and coverable lines are covered by tests.
:white_check_mark: Project coverage is 17.46%. Comparing base (a50de02) to head (a963cc3).
:warning: Report is 54 commits behind head on main.
Additional details and impacted files
@@ Coverage Diff @@
## main #12156 +/- ##
============================================
- Coverage 17.56% 17.46% -0.10%
+ Complexity 15540 15514 -26
============================================
Files 5909 5913 +4
Lines 529059 529385 +326
Branches 64617 64679 +62
============================================
- Hits 92919 92451 -468
- Misses 425687 426516 +829
+ Partials 10453 10418 -35
| Flag | Coverage Δ | |
|---|---|---|
| uitests | 3.58% <ø> (+<0.01%) |
:arrow_up: |
| unittests | 18.52% <ø> (-0.11%) |
:arrow_down: |
Flags with carried forward coverage won't be shown. Click here to find out more.
:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.
:rocket: New features to boost your workflow:
- :snowflake: Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
- :package: JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.
IMO simply replacing path with uuid might cause more confusion for people who are used to it. And displaying just uuid is not useful for someone who wants to look at the backup file on storage. One can still go to the volume and get the uuid by clicking on the volume in backup details.
If the confusion is about what the string represents, can we prefix it with "path: "
@abh1sar the path displayed in the GUI is not the backup file path, but the volume path. Furthermore, end users do not have access to the storage to "check the files"; thus, this information is not very valuable to them. On the other hand, displaying the volume UUID is much more useful, as it facilitates API usage.
this change should not cause regressions in GHA
retrying