[4.20] Fix account deletion blocked by deleted project admin mappings

[SURYAS1306]

Description

Backport of #12607 to the 4.20 branch.

This change fixes an issue where account deletion was blocked if the account
was listed as an administrator of projects that were already removed
(removed is not null).

The fix ensures that only active projects are considered when checking
whether an account manages projects, allowing deletion when only deleted
projects are associated.

Includes the same defensive check and unit test added in the main branch.

Rebased to 4.20 as requested by @DaanHoogland

Fixes #12601

Types of changes

• Bug fix (non-breaking change which fixes an issue)
• Test (unit test code)

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 4.15%. Comparing base (a0f35a1) to head (7f3fd1f).
⚠️ Report is 4 commits behind head on 4.20.

❗ There is a different number of reports uploaded between BASE (a0f35a1) and HEAD (7f3fd1f). Click for more details.

HEAD has 1 upload less than BASE

Flag	BASE (a0f35a1)	HEAD (7f3fd1f)
unittests	1	0

Additional details and impacted files

@@              Coverage Diff              @@
##               4.20   #12615       +/-   ##
=============================================
- Coverage     16.27%    4.15%   -12.12%     
=============================================
  Files          5662      404     -5258     
  Lines        500033    32965   -467068     
  Branches      60717     5893    -54824     
=============================================
- Hits          81368     1370    -79998     
+ Misses       409591    31419   -378172     
+ Partials       9074      176     -8898     

Flag	Coverage Δ
uitests	4.15% <ø> (ø)
unittests	?

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[SURYAS1306]

Hi @DaanHoogland

This PR backports the fix from #12607 to the 4.20 branch.

It contains the same change and unit test as the main/4.22 fix, adjusted for the 4.20 codebase.

Please let me know if any additional changes are needed for the backport.

[DaanHoogland]

@blueorangutan package

[blueorangutan]

@DaanHoogland 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.

[blueorangutan]

Packaging result [SF]: ✖️ el8 ✖️ el9 ✖️ debian ✖️ suse15. SL-JID 16761

[sureshanaparti]

@SURYAS1306 please check the build error.

Error:  /home/runner/work/cloudstack/cloudstack/server/src/test/java/com/cloud/user/AccountManagerImplTest.java:[1601,21] error: cannot find symbol
Error:    symbol:   variable projectAccountDao
Error:    location: class AccountManagerImplTest
Error:  /home/runner/work/cloudstack/cloudstack/server/src/test/java/com/cloud/user/AccountManagerImplTest.java:[1607,21] error: cannot find symbol
Error:    symbol:   variable projectDao
Error:    location: class AccountManagerImplTest
Error:  /home/runner/work/cloudstack/cloudstack/server/src/test/java/com/cloud/user/AccountManagerImplTest.java:[1610,8] error: cannot find symbol
Error:    symbol:   variable accountManager
Error:    location: class AccountManagerImplTest

[SURYAS1306]

Hi @sureshanaparti ,

The build issue was caused by incorrect mocks in AccountManagerImplTest.
I’ve updated the test to use the injected _projectAccountDao and _projectDao fields and pushed the fix.

Could you please re-run the workflows when convenient?

[SURYAS1306]

Hi @sureshanaparti

The previous build failure was due to missing imports (ProjectAccountDao, ProjectDao, InjectMocks) in AccountManagerImplTest.

I’ve added the required imports and pushed the fix in the latest commit.

Could you please re-run the workflows when possible?

[DaanHoogland]

@SURYAS1306 , a new error. please see https://github.com/apache/cloudstack/actions/runs/21867500572/job/63118078002?pr=12615#step:7:11366 ?

[SURYAS1306]

Hi @DaanHoogland,

I see the new failure is a Mockito NotAMockException caused by an incorrect @SPY and @Injectmocks annotation order in AccountManagerImplTest.
I’ve fixed this by applying @SPY before @Injectmocks on AccountManagerImpl and pushed the update.

I’m re-checking the remaining test failures locally and will follow up shortly.

[SURYAS1306]

Hi @DaanHoogland,

I’ve updated the spy initialization in AccountManagerImplTest to ensure proper injection order and pushed the fix.
This should address the NullPointerException seen in the previous run.

[DaanHoogland]

sorry @SURYAS1306 , another lint/checkstyle error: https://github.com/apache/cloudstack/actions/runs/21910909861/job/63274656053?pr=12615#step:11:6378

[SURYAS1306]

Thanks @DaanHoogland ,
Fixed the checkstyle issue (unused import) and pushed the update.

[SURYAS1306]

Hi @DaanHoogland,

I'm still seeing persistent NotMock errors in AccountManagerImplTest. All failures point to:

AccountManagerImplTest.beforeTest:164 NotMock
Argument passed to when() is not a mock

So far I’ve:

• Added the missing _projectDao mock

• Updated usages to match production field names

• Fixed the accountManager → accountManagerImpl typo

• Added Mockito.spy(accountManagerImpl) in setUp()

I suspect this might be due to:

• Having two @before methods with no guaranteed execution order

• Or possibly overwriting mocks inside setUp() with manual Mockito.mock() calls

Would you recommend consolidating the @before methods into one, or removing the manual Mockito.mock() calls and relying only on @mock annotations?

Since this test extends AccountManagetImplTestBase, I want to ensure I’m aligning with the existing pattern.

I’ll update based on your feedback.

[DaanHoogland]

AccountManagerImplTest.beforeTest:164 NotMock Argument passed to when() is not a mock

• Having two @before methods with no guaranteed execution order

One of them should probably be @before and the other @BeforeClass

• Or possibly overwriting mocks inside setUp() with manual Mockito.mock() calls

I think no explicit Mocks should have to be created. @InitMocks should take care of injections.

Would you recommend consolidating the @before methods into one, or removing the manual Mockito.mock() calls and relying only on @mock annotations?

no and yes, see above.

Since this test extends AccountManagetImplTestBase, I want to ensure I’m aligning with the existing pattern.

The existing pattern may have gone through Mockito upgrades and is not necessarily the best. @vishesh92 , could you have a look as well?

[SURYAS1306]

Hi @DaanHoogland,
I’ve removed the manual Mockito.mock calls and now rely on @mock injection.
If it still fails, I’ll try consolidating the two @before methods next.

[DaanHoogland]

If it still fails, I’ll try consolidating the two @before methods next.

Don't, one of them should be a @BeforeClass method!

[SURYAS1306]

Hi @DaanHoogland,
I moved the one-time initialization to @BeforeClass and kept only a single @before for per-test stubbing. This removes the lifecycle ordering issue between setup phases.