The committers listed above are authorized under a signed CLA.

• ✅ login: Ru13en / name: Ruben Rodrigues (afb412f)

/ok-to-test

Codecov Report

❌ Patch coverage is 90.90909% with 1 line in your changes missing coverage. Please review.
✅ Project coverage is 59.73%. Comparing base (402d5c7) to head (01593b5).
⚠️ Report is 6 commits behind head on main.

@@           Coverage Diff           @@
##             main    #2726   +/-   ##
=======================================
  Coverage   59.73%   59.73%           
=======================================
  Files         210      210           
  Lines       21112    21117    +5     
=======================================
+ Hits        12611    12615    +4     
- Misses       7706     7707    +1     
  Partials      795      795           

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

@Ru13en what do you mean by service account? do you mean repo http access token as you added in PR description?

@zakisk, correct. Bitbucket DC has 3 types of HTTPS tokens. User tokens have the authentication attached to the Licensed user. Repository HTTPS token and Project HTTPS have the authentication integrated within the server and can be used as Service Account. There is no need to have an extra Bitbucket User license, when the Project and Repo token can create webooks, create repositories (for project token), commits and comments.
Example of a comment made via a MLOPS Project HTTP token:

@Ru13en I've tested this and found that you can actually use project access token with admin permission in PaC without any code changes but for repo access token we need to LICENCED_USER for checking permission of the user pushing to repo or raising PR.

@Ru13en I've tested this and found that you can actually use project access token with admin permission in PaC without any code changes but for repo access token we need to LICENCED_USER for checking permission of the user pushing to repo or raising PR.

@zakisk HTTP repository tokens with admin permission can get the members of the group necessary to check the permissions that you mention. Try with the following command:

curl -sS -H "Authorization: Bearer $REPO_ADMIN_TOKEN" <bitbucket_base_url>/rest/api/1.0/admin/groups/more-members?context=<Group_name>

Also they can get all permissions of the repository that it belongs.

curl -sS -H "Authorization: Bearer $REPO_ADMIN_TOKEN" <bitbucket_base_url>/rest/api/1.0/projects/{project_key}/repos/{repository_slug}/permissions/search

When you setup the scm-go client, if you don't drop the user, you will be forced to add an known user as a placeholder for the Repository PAC config and then this username somehow is being used...

@Ru13en yeah, you're right I tried it. but you don't need to do the changes you're doing at the moment. it's issue in ACL when org membership check fails due to lack of permission on repo http token, it's returning right from there without checking below repo collaborator permission so you can just have a condition like this to get repo token working fine:

allowed, resp, err := v.Client().Organizations.IsMember(ctx, event.Organization, event.Sender)
if err != nil && resp != nil && resp.Status != http.StatusUnauthorized {
	return false, err
}

but your token must be having repo admin permission

@zakisk these changes are only to drop the unnecessary requirement for a username if I provide a HTTP Token during the PaC Repository configuration, since you are forced to add a valid one.
For security reasons we don't want to associate users or use them as placeholders with Admin tokens.
In this PR I didn't addressed any issue related with the lack of permissions.

but if its working with repo and project access token why do you wanna remove user account check?

When you add the Repo config via GitOps we use External Secrets to inject the HTTP Tokens.
Right now we need to add a Valid Placeholder user.
We can't leave it empty or we can't add anything random.
Github configs don't need the username, why Bitbucket datacenter HTTP tokens require it?
We don't want to associate users or use them as placeholders with Admin tokens, we have a flag in the our security audits to drop such association.

why Bitbucket datacenter HTTP tokens require it?

it was implemented a while ago in this commit to ensure that token is valid 549b2d8

When you add the Repo config via GitOps we use External Secrets to inject the HTTP Tokens. Right now we need to add a Valid Placeholder user. We can't leave it empty or we can't add anything random. Github configs don't need the username, why Bitbucket datacenter HTTP tokens require it? We don't want to associate users or use them as placeholders with Admin tokens, we have a flag in the our security audits to drop such association.

it makes sense after you explained your use case!

/ok-to-test

@Ru13en please refine docs changes and we're good to go with it...

Made the changes as requested @zakisk
hope that is good enough.
BR

/agentic_review

/ok-to-test

/ok-to-test

too many E2E failures... 😕 @Ru13en BTW, it's not your PR. we're working for tests fixing

/ok-to-test

/ok-to-test

/retest

@Ru13en Thank you for contributing! 🎉