Skip to content

fix: resolve project member update by username and sync update/create wrappers#909

Open
dev-aditya-hub wants to merge 1 commit into
goharbor:mainfrom
dev-aditya-hub:fix/member-update-and-update-symmetry
Open

fix: resolve project member update by username and sync update/create wrappers#909
dev-aditya-hub wants to merge 1 commit into
goharbor:mainfrom
dev-aditya-hub:fix/member-update-and-update-symmetry

Conversation

@dev-aditya-hub
Copy link
Copy Markdown

Summary

Found three sibling-symmetry bugs while looking around the member, scanner, and webhook handlers — in each case a fix or normalization exists on the create path but was never replicated on the update path, so an update silently produces a wrong result.

Changes

project member update --member <name> was targeting the wrong row

cmd/harbor/root/project/member/update.go was resolving --member <name> via api.GetUsersIdByName, which returns a user ID, and passing it as Mid into UpdateProjectMember — but Harbor's API expects the project member ID (project_members.id). These are different rows and only line up by accident.

Introduced api.UpdateMemberByUsername (mirroring the existing DeleteMemberByUsername) which calls ListMembers and matches on EntityName, then routes the cmd through it. The numeric [memberName] positional and the interactive picker still use the existing UpdateMember path.

scanner update --auth None was leaving the scanner with unrecognized auth

pkg/api/scanner_handler.go::CreateScanner normalizes \"None\" -> \"\"; UpdateScanner did not. Both the --auth flag and the interactive view surface the literal string \"None\", so an update would persist that as the auth method and the scanner adapter could no longer authenticate. Added the same normalization to UpdateScanner.

webhook update was not trimming the endpoint URL

pkg/api/webhook_handler.go::CreateWebhook calls strings.TrimSpace on the endpoint URL; UpdateWebhook did not. A trailing newline/space pasted into --endpoint-url would be stored verbatim. Added the trim.

Test plan

  • harbor project member update <p> --member <user> --roleid 2 updates the role of <user> (and not whichever member happens to share that user's ID)
  • harbor project member update <p> <memberID> --roleid 2 still works (positional path unchanged)
  • harbor scanner update <name> --auth None no longer leaves the scanner with Auth: \"None\" in Harbor
  • harbor webhook update ... --endpoint-url \"https://example.com/hook \" stores the URL without trailing whitespace

… create

- project member update --member <name> now resolves the project_members.id via
  ListMembers (mirroring DeleteMemberByUsername) instead of misusing user_id
  as the member id, which silently targeted the wrong member when ids did not
  coincide.
- scanner UpdateScanner normalizes Auth "None" to "" the same way CreateScanner
  does, so updates that set --auth None no longer leave the scanner with an
  unrecognized auth method.
- webhook UpdateWebhook trims whitespace from the endpoint URL the same way
  CreateWebhook does.

Signed-off-by: Aditya@8767 <premjadhvar95@gmail.com>
@dev-aditya-hub
Copy link
Copy Markdown
Author

@qcserestipy gentle ping — would appreciate a look here when you have a slot.

This one is a follow-up sweep after #908: same shape of bug (a fix lives on the create path, the matching update path was missed), three different commands. The biggest of the three is the member update --member <name> path — it was passing a user ID where Harbor expects a project-member row ID, so on any non-toy tenant the role change lands on the wrong member while the CLI still prints success.

@qcserestipy qcserestipy added wontfix This will not be worked on no-issue This PR has now issue that has been discussed on the scope of the PR labels May 10, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

no-issue This PR has now issue that has been discussed on the scope of the PR wontfix This will not be worked on

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants