bug: Inconsistent behavior from Harbor API after deleting a retention policy

[rizul2108]

BUG: Inconsistent behavior in Harbor after deleting a retention policy.

Description
When deleting a retention policy using harbor-cli, the retention ID remains associated with the project metadata even after the policy is deleted. This leads to inconsistent behavior from the Harbor API when handling projects with deleted retention policies.

Steps to Reproduce

1. Create a project asdfghj using harbor-cli. (used the API: createProject)
2. Add a tag retention rule to the project. (used the API: createRetention)
3. Delete the retention policy using harbor-cli. (used the API: deleteRetention)
4. Fetch project details using the Harbor API. (used the API: getProject)

Expected Behavior

• The retention ID should be removed from the project metadata after the retention policy is deleted.

Actual Behavior

• The API response for fetching project details still includes the retention ID of the deleted policy.
• This causes errors when handling projects with deleted retention policies as the retention ID references a non-existent policy.

Possible Cause

• The retention policy ID is not being properly disassociated from the project metadata after deletion.

[bupd]

needs design. TLDR: Harbor's retention deletion is incomplete: It removes the policy, but leaves the project's link to it, causing errors.

[bupd]

As a user, I expect that deleting a retention policy should also remove its association with the project, but that doesn't happen. As a result, the route doesn’t fully implement the intended functionality. https://demo.goharbor.io/#/Retention/deleteRetention - making this route non functional.

[rizul2108]

I was thinking that maybe we can do the following

• first get the projectID from 'ref' field from scope of that retention policy to be deleted
• update metadata of the project with that projectID with the below API