Drone and Bitbucket broken for write permission detection for drone build restart permission.

[RichardTheHouse]

Since this commit:
802e265

Changing of
path := fmt.Sprintf("rest/api/1.0/repos?size=1000&permission=REPO_WRITE&project=%s&name=%s", namespace, name)
to
path := fmt.Sprintf("rest/api/1.0/repos?size=1000&permission=REPO_WRITE&projectname=%s&name=%s", namespace, name)

Has resulted in drone not allowing users with write permission to restart drone jobs or do drone deploys. As it is not detecting the user has write permission.

Admins still work using the webhook lookup but users with only write permission can not.

[bradrydzewski]

I've carved out some time on Monday to research this further ... I will post back here to share my analysis once complete.

The reason we changed was because, according to bitbucket rest documentation, there is no project parameter (https://docs.atlassian.com/bitbucket-server/rest/5.16.0/bitbucket-rest.html#idm8296923984). The projectname parameter should prevent us from fetching the permissions for the wrong repository, when multiple repositories with the same name exist in different projects.

[bradrydzewski]

I spent some time researching this issue and it seemed to work for me. I tried to be very detailed with my testing and methodology below. Can you can take a look and provide some feedback? Perhaps there are some edge cases or scenarios that my testing does not cover?

---

First, I setup a project called foo and repository called quux and then created and granted a dummy user account access to this project. Here is a screenshot that demonstrates access granted to this repository:

Next, I made the an API call on behalf of the dummy user account using the curl command:

curl -H "Authorization: Bearer XXX" 'http:https://XXXXXX/rest/api/1.0/repos?permission=REPO_WRITE&projectname=foo'

And received the results as expected indicating write access:

{
    "size": 1,
    "limit": 1,
    "isLastPage": true,
    "values": [
        {
            "slug": "quux",
            "id": 5,
            "name": "quux",
            "scmId": "git",
            "state": "AVAILABLE",
            "statusMessage": "Available",
            "forkable": true,
            "project": {
                "key": "FOO",
                "id": 3,
                "name": "foo",
                "public": false,
                "type": "NORMAL"
            },
            "public": false
        }
    ],
    "start": 0
}

Next, I decided to login to Drone as the dummy user and sync my account. I can see the repository in my list:

Next I clicked on the repository. When you perform a repository sync, Drone purges its cache of repository access levels for the user, forcing Drone to fetch and update the access levels for each repository, on-demand. The results are cached in the database until the next time you re-sync your repository list. As part of our testing, we can confirm in the logs that Drone makes an API call to Bitbucket (using this go-smc library) which returns that the dummy user is granted write access to the repository:

Finally, I checked to make sure write access was persisted in the database and returned from the API when the user attempts to request the repository resource:

[RichardTheHouse]

Thank you for looking, I think I can see the issue and why it works for you and not us:
The project key and project name are getting mixed up, in your example you have called them both "FOO"

Try changing your project name to be different from the key in bitbucket:

{
"size": 1,
"limit": 1,
"isLastPage": true,
"values": [
{
"slug": "quux",
"id": 5,
"name": "quux",
"scmId": "git",
"state": "AVAILABLE",
"statusMessage": "Available",
"forkable": true,
"project": {
"key": "FOO",
"id": 3,
"name": "Some other Name not starting with FOO",
"public": false,
"type": "NORMAL"
},
"public": false
}
],
"start": 0
}

[RichardTheHouse]

Anyone else who comes across this bug can work around it by renaming the project to start with the key:
Project Name: FOO - Some project description
Project key: FOO

[ppodevlabs]

Hi, i think i'm hitting a similar issue in our deployment. We are running drone server 1.10.1 together with bitbucket server and even if the user has write permissions in bitbucket drone seems to not be able to recognise it.

[ppodevlabs]

Hi, i think i'm hitting a similar issue in our deployment. We are running drone server 1.10.1 together with bitbucket server and even if the user has write permissions in bitbucket drone seems to not be able to recognise it.

i've rolled back the drone server from 1.10.1 to 1.9.1 and it is working

{"id":632,"uid":"791","user_id":63,"namespace":"OPSA","name":"administration-service","slug":"OPSA/administration-service","scm":"","git_http_url":"https://bitbucket.voiceworks.com/scm/opsa/administration-service.git","git_ssh_url":"ssh:https://[email protected]/opsa/administration-service.git","link":"https://bitbucket.voiceworks.com/projects/OPSA/repos/administration-service/browse","default_branch":"master","private":true,"visibility":"private","active":true,"config_path":".drone.yml","trusted":false,"protected":false,"ignore_forks":false,"ignore_pull_requests":false,"auto_cancel_pull_requests":false,"auto_cancel_pushes":false,"timeout":60,"counter":159,"synced":1602888751,"created":1602888751,"updated":1602888751,"version":161,"permissions":{"read":true,"write":true,"admin":false}}

With 1.9.1 i get the proper permissions.

[tphoney]

With #114 we have submitted a fix and are doing a release of the library, can you check it out.

[tphoney]

thanks for your patience @RichardTheHouse