Repository navigation
server: remove user-project mappings when delete a project - #14150
weizhouapache wants to merge 3 commits into
Conversation
Codecov Report❌ Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## 4.20 #14150 +/- ##
============================================
+ Coverage 16.37% 16.42% +0.04%
- Complexity 13614 13675 +61
============================================
Files 5669 5669
Lines 501527 501629 +102
Branches 60922 60938 +16
============================================
+ Hits 82148 82397 +249
+ Misses 410171 409994 -177
- Partials 9208 9238 +30
Flags with carried forward coverage won't be shown. Click here to find out more. ☔ View full report in Codecov by Harness. 🚀 New features to boost your workflow:
|
There was a problem hiding this comment.
🟡 Changes recommended
Add regression tests covering removal of user-specific mappings during project cleanup.
Get a fresh assessment by requesting another Copilot review.
Pull request overview
Fixes project cleanup so user-specific project mappings are removed when deleting a project, allowing associated accounts to be deleted.
Changes:
- Allows nullable
userIdlookups in the project-account DAO. - Uses account-wide lookup during project cleanup.
- Updates the DAO contract.
File summaries
| File | Summary |
|---|---|
server/src/main/java/com/cloud/projects/ProjectManagerImpl.java |
Removes mappings regardless of user association during cleanup. |
engine/schema/src/main/java/com/cloud/projects/dao/ProjectAccountDaoImpl.java |
Implements optional user filtering. |
engine/schema/src/main/java/com/cloud/projects/dao/ProjectAccountDao.java |
Updates the DAO method signature. |
Review details
Suppressed comments (1)
engine/schema/src/main/java/com/cloud/projects/dao/ProjectAccountDaoImpl.java:116
- Please add a regression test for the new nullable path. The current tests exercise user-specific lookups but do not verify that a user-specific
project_accountrow is found and removed whenuserIdis null; without that coverage, the fix for #12601 can regress to the old account-level-only lookup unnoticed.
if (userId != null) {
sc.setParameters("userId", userId);
}
- Files reviewed: 3/3 changed files
- Comments generated: 1
- Review effort level: Lite
💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.
| @Override | ||
| public boolean unassignAccountFromProject(long projectId, long accountId) { | ||
| ProjectAccountVO projectAccount = _projectAccountDao.findByProjectIdAccountId(projectId, accountId); | ||
| ProjectAccountVO projectAccount = _projectAccountDao.findByProjectIdUserId(projectId, accountId, null); |
DaanHoogland
left a comment
There was a problem hiding this comment.
clgtm, can you generate some tests @weizhouapache ?
9099c91 to
506fbc0
Compare
I tried to add some unit tests, it worked with 4.23 |
| @Override | ||
| public boolean unassignAccountFromProject(long projectId, long accountId) { | ||
| ProjectAccountVO projectAccount = _projectAccountDao.findByProjectIdAccountId(projectId, accountId); | ||
| ProjectAccountVO projectAccount = _projectAccountDao.findByProjectIdUserId(projectId, accountId, null); |
There was a problem hiding this comment.
what about projects deleted before this fix? their leftover user rows still block deleting the account, should the upgrade clean those up too?
There was a problem hiding this comment.
yes, but I am hesitated to do it, as it needs to be added to all upgrade files (4.20, 4.22, 24.0)
| SearchCriteria<ProjectAccountVO> sc = AllFieldsSearch.create(); | ||
| sc.setParameters("projectId", projectId); | ||
| sc.setParameters("userId", userId); | ||
| if (userId != null) { |
There was a problem hiding this comment.
can we keep this lookup as is and remove each row by its id in the cleanup loop instead? the loop already has the row
There was a problem hiding this comment.
added a new method removeByProjectIdAccountId to remove all records by projectid and accountid
This reverts commit 506fbc0.
unassignAccountFromProject looked up a single project_account row with userId IS NULL and removed at most that one. Mappings created for users, and extra users of the same account, were left behind when a project was cleaned up. unassignAccountFromProject now removes every project_account row matching the project and account through ProjectAccountDao.removeByProjectIdAccountId. cleanupProject keeps its per-row loop and therefore covers user mappings too.
|
@blueorangutan package |
|
@weizhouapache a [SL] Jenkins job has been kicked to build packages. It will be bundled with KVM, XenServer and VMware SystemVM templates. I'll keep you posted as I make progress. |
|
Packaging result [SF]: ✔️ el8 ✔️ el9 ✔️ el10 ✔️ debian ✔️ suse15. SL-JID 19749 |
|
@blueorangutan test |
|
@weizhouapache a [SL] Trillian-Jenkins test job (ol8 mgmt + kvm-ol8) has been kicked to run smoke tests |
Description
This PR fixes #12601
When an account is added to a project with a project role (e.g. via addUserToProject), the resulting project_account row has a non-null user_id. Project cleanup (deleteProject ... cleanup=true) unassigns every account from the project via ProjectAccountDaoImpl#findByProjectIdUserId(projectId, accountId, null), expecting a null userId to mean "match this account regardless of which user_id the row has".
Types of changes
Feature/Enhancement Scale or Bug Severity
Feature/Enhancement Scale
Bug Severity
Screenshots (if appropriate):
How Has This Been Tested?
Verified on a live 2-node management server deployment:
How did you try to break this feature and the system with this change?