erikbocks opened a new pull request, #13065:
URL: https://github.com/apache/cloudstack/pull/13065
### Description
PR #12502 introduced a generic method to retrieve untranslated UUIDs
received as command parameters, without having to query the database during the
command processing workflow. A validation using `UUID.parseString` was included
before storing them in the context to ensure that they were valid UUIDs.
However, it was previously possible to set the UUID of some entities to values
that are not valid UUIDs, which got broken by this validation.
This PR removes the validation in order to support back the usage of
arbitrary values as resource UUIDs.
### Types of changes
- [ ] Breaking change (fix or feature that would cause existing
functionality to change)
- [ ] New feature (non-breaking change which adds functionality)
- [X] Bug fix (non-breaking change which fixes an issue)
- [ ] Enhancement (improves an existing feature and functionality)
- [ ] Cleanup (Code refactoring and cleanup, that may add test cases)
- [ ] Build/CI
- [ ] Test (unit or integration test code)
### Feature/Enhancement Scale or Bug Severity
#### Bug Severity
- [ ] BLOCKER
- [ ] Critical
- [X] Major
- [ ] Minor
- [ ] Trivial
### Screenshots (if appropriate):
### How Has This Been Tested?
After changing the code, I built it with Maven and validated that no error
occurred during the build. The unit tests were not skipped for the build
process.
After installing the packages with the changes to my environment, I created
a account with `nonuuidvalue` as its UUID. Then, I listed the registered
accounts with the `listAccounts` API. With this, I validated that the error
from parsing the `id` attribute value was fixed.
<details><summary><code>listAccounts</code> API result</summary>
```
(all-in-one) 🐋 > list accounts id=nonuuidvalue details=min
{
"account": [
{
"accounttype": 0,
"apikeyaccess": "INHERIT",
"created": "2026-04-23T14:37:52+0000",
"domain": "ROOT",
"domainid": "ee564f54-13df-11f1-9489-464a3dd4490d",
"domainpath": "ROOT",
"groups": [],
"id": "nonuuidvalue",
"isdefault": false,
"name": "b",
"roleid": "fe5eecbe-13e1-11f1-9dfe-464a3dd4490d",
"rolename": "User",
"roletype": "User",
"secondarystoragetotal": 0,
"state": "disabled",
"user": [
{
"account": "b",
"accountid": "nonuuidvalue",
"accounttype": 0,
"created": "2026-04-23T14:37:55+0000",
"domain": "ROOT",
"domainid": "ee564f54-13df-11f1-9489-464a3dd4490d",
"email": "b",
"firstname": "b",
"id": "b164a13c-0dcd-4604-b06e-954ec1ca452a",
"is2faenabled": false,
"is2famandated": false,
"iscallerchilddomain": false,
"isdefault": false,
"lastname": "b",
"roleid": "fe5eecbe-13e1-11f1-9dfe-464a3dd4490d",
"rolename": "User",
"roletype": "User",
"state": "enabled",
"username": "b",
"usersource": "native"
}
]
}
],
"count": 1
}
```
</details>
I also validated that the UUID obtention for events description was not
affected by the changes. In order to test this, I disabled two different
accounts: the one with the `nonuuidvalue` value as UUID, and an account that I
created for this test. After inspecting the events, it was possible to validate
that the resources' UUIDs were still being displayed correctly.
<details><summary>Events description</summary>
```
MariaDB [cloud]> select type, state, description, account_id from event
where type = "ACCOUNT.DISABLE" and state = "Scheduled";
+-----------------+-----------+-----------------------------------------------------------------+------------+
| type | state | description
| account_id |
+-----------------+-----------+-----------------------------------------------------------------+------------+
| ACCOUNT.DISABLE | Scheduled | Disabling Account with ID:
a4ae3004-19b6-4152-9a1a-4d18f24410da | 6 |
| ACCOUNT.DISABLE | Scheduled | Disabling Account with ID: nonuuidvalue
| 5 |
+-----------------+-----------+-----------------------------------------------------------------+------------+
```
</details>
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
