Enable adding labels if User has triage role

[blacelle]

Describe the bug Given a user with Triage access, labels are not added when creating an issue.

To Reproduce

1. Give a user Triage access to a repo
2. Create a Ticket with one label

The label is not applied.

Expected behavior Given Triage allow applying labels, I expect my label to be applied.

https://help.github.com/en/github/setting-up-and-managing-organizations-and-teams/repository-permission-levels-for-an-organization

It appears I can add the labels once the issue is created

Confirmed with 1.112

Typically, in this usecase, I sucvcessfully apply with labels with something like:

			GHIssue issue = building.create();

			labels.forEach(t -> {
				try {
					issue.addLabels(t);
				} catch (IOException e) {
					throw new UncheckedIOException(e);
				}
			});

[bitwiseman]

How does your sample code above behave differently for users with Owner vs Triage role? I'm unclear what behavior change you would like to see in the library? Does the GitHub API provide the behavior you describe?

[blacelle]

My previous procedure was like:

GHIssueBuilder labelling = issueBuilder.body(fullContent)
	.label(issueLabel)
GHIssue issue = building.create();

If Owner, the issue is open with proper labels: OK If triage, the issue is open without any labels: KO

I then turned into:

My new procedure is something like:

GHIssueBuilder labelling = issueBuilder.body(fullContent)
         // I keep label in the builder is it is the standard use of the library
	.label(issueLabel)
GHIssue issue = building.create();

// Add labels after issue creation, in case the user has Triage role
labels.forEach(t -> {
	try {
	     issue.addLabels(t);
        } catch (IOException e) {
	     throw new UncheckedIOException(e);
          }
});

I then have a clear workaround in my code around the library.

I suggest the library either:

1. Check the userRole and add labels if the user have role Triage (I don't know if this is feasible, low-cost)
2. Add labels as an implicit call to GHIssue.addLabel() right after Issue creation, so that one would not have to do it by himself (this solution is weak as it would means applying labels twice, while in 99% cases, the second label application is useless).

[bitwiseman]

It looks like this is by-design behavior in the GitHub API for "Create an Issue". If you look at the "parameters" it says:

Labels to associate with this issue. NOTE: Only users with push access can set labels for new issues. Labels are silently dropped otherwise.

There is no indication from the server that anything has gone wrong.

This same limitation is supposed to be true for "Update an Issue". So, either the create is blocking the adding labels when it shouldn't or the update is allowing adding labels when it shouldn't. Either way, in that larger sense, this is something that should be reported to GitHub and fixed on the server side.

Until that happens, you could add a work around. Checking the user role before creation (option 1) taxes everyone, so that is not good. But option 2 seems possible. The create() method could check the issue labels after creation and if they are empty manually add them. You shouldn't need to do the forEach() because the is a issue.addLabels(listOfLabelNames).

The problem is that then this library will have significantly different behavior from the standard API - if someone doesn't have sufficient permissions to add labels they will get an exception instead of silent continuing. You'd need to make this very clear in the javadoc and have plenty of tests for it.

Even then, if GitHub determines that the update shouldn't be able to add issues either then this workaround will break again.

I'd be happy to take a PR on this, but I'd be cautious about depending on this behavior at all until you've talked to GitHub to make sure current create and update behaviors are correct.

[blacelle]

I sent Github support some details and direct link to this ticket. They would provide some valuable insights. Fact is Triage role is quite new.

[atinux]

I confirm that when the collaborator has the triage role, he can add labels with GitHub.com but not from the API (we use a GitHub application for it). Any news regarding this issue?

[bitwiseman]

@Atinux ? Until GitHub fixes the API, this bug is blocked. We do have visibility into when GitHub will fix issues.

[ahoglund]

👋🏼 from the GitHub API Team. Just to confirm, is the API endpoint in question the one getting called from here?

https://github.com/hub4j/github-api/blob/9978678f276619e2bf81e6542a596e74ce1dc0cc/src/main/java/org/kohsuke/github/GHIssue.java#L374-L380

If so that I think that would correspond to the https://docs.github.com/en/rest/reference/issues#add-labels-to-an-issue endpoint. Just wanted to confirm before we look further into this.

[blacelle]

@ahoglund You pinpointed the API used for the workaround, but the faulty API is the API used to create a ticket: labels are not properly applied during creation, hence the workaround is to apply labels once the ticket created.

[gsmet]

Yeah, the problem is here: https://docs.github.com/en/rest/reference/issues#create-an-issue .

The doc says:

Labels to associate with this issue. NOTE: Only users with push access can set labels for new issues. Labels are silently dropped otherwise.

So it's properly documented but this limitation should be lifted to allow users with the triage permission to do the same.