401 when trying to extract GHUser#type

[Haarolean]

Hi, a code like this

new GitHubBuilder()
        .withJwtToken("token")
        .build()
        .getApp()
        .getInstallationById(githubInstallationId)
        .getAccount()
        .getType()

leads to 401:

Caused by: org.kohsuke.github.HttpException: {"message":"Bad credentials","documentation_url":"https://docs.github.com/rest"}
	at org.kohsuke.github.GitHubConnectorResponseErrorHandler$1.onError(GitHubConnectorResponseErrorHandler.java:62) ~[github-api-unbridged-1.318.jar:na]

There are a few issues here:

1. The field is already initialized as "Organization" after calling getAccount(), so populating here is not necessary, perhaps.
2. installation.getAccount().getUrl() returns https://api.github.com/users/<ORGANIZATION_LOGIN>, which perhaps is invalid, because it's an organization, not a user.

[Haarolean]

Unfortunately, I couldn't find a way to work around this by determining installation owner's account type, please let me know if there's something I missed

UPD: Found a workaround:

ghInstallation.getRoot().setConnector(HttpConnector.OFFLINE);
ghInstallation.getAccount().getType();

[bitwiseman]

Here's the problem:

github-api/src/main/java/org/kohsuke/github/GHPerson.java

Lines 342 to 344 in 3f99541

	public String getType() throws IOException {
	populate();
	return type;

populate() should only be called if type is null.

[Haarolean]

@bitwiseman got it. How should we solve this taking into consideration the fact that there are multiple fields like this? Should we track the "populated = true/false" flag for an entity or something else?

[Haarolean]

@bitwiseman bump?

[bitwiseman]

@Haarolean
In this specific case, you can guard the populate() call with if (type == null).
I think some of the classes have a populate(bool doPopulate) method or populate(Object objectToCheckForNullValue) to streamline this process.

Tracking bool isPopulated; as field could also work.
I don't like the way we currently don't know what fields we have actually loaded in an instance, but I haven't had time to ponder a better solution for the range partial fields that are returned. Maybe have the base record and then use interfaces to show what fields are present.

What are your thoughts?