Open verm opened 4 days ago
Email domains aren't indicative of an organization that a contributor belongs to. Is there any other API feature we can use to get contributor organizations?
Orginisations in GitLab are an experimental feature with no interface other than the API to get to it. There is no other unique identifier. I agree that it's not ideal nore a good indicator the only other option is to remove it completely but this at least gives us something that may be useful.
I did it this way as it seemed the least invasive to support this until Orginisation is settled as a public feature.
We use the Users API to get the Organization, not the Organizations API. As I understand it, it's just the API that's experimental, and Organizations are part of GitLab to stay.
We use the Users API to get the Organization, not the Organizations API. As I understand it, it's just the API that's experimental, and Organizations are part of GitLab to stay.
Yes they are here to stay the way GitLab wants you to set them up is using groups which don't exist in GitHub. If you go to GitLab docs they just want you to setup groups -- this is not what the API being used is it's an entirely new concept for Orginizations similar to how GitHub has them.
The concept of 'orginization' does not exist in GitLab yet it is only exposed via an API and it's all experimental.
This is why in nearly every case using this API right now is going to return an empty string. The web UI isn't even enabled for it:
To summerise: The only way you're going to get a user with an orgnization is if you enable experimental flags and use the API directly. It won't show up anywhere on the web UI nore can you edit it. You can also see here that all of the feature flags are disabled by default for orginization:
This fixes Contributors.
Currently organisations are an experimental features in GitLab this change makes it use the users email domain as a pseudo organisation. The domains are anonymised as these are printed as part of the report and shouldn't be exposed.
It's uncertain if the uptake in organisation will be large considering GitLab users are used to using groups for this purpose.
What kind of change does this PR introduce?
Fixes a bug where Contributors were always set to 0 I did not see an open issue for this.
What is the current behavior?
Contributors will always be 0.
What is the new behavior (if this is a feature change)?**
Which issue(s) this PR fixes
NONE
Special notes for your reviewer
What I've done here is used the email domains as a pseudo orginisation and anonymomised it using the slice index as
gitlab-N
. This lets Contributors give somewhat useful data and in the future when Orginisation is no longer experimental we'll be able to remove this. I found this to be the least invasive method of handling the situation.Does this PR introduce a user-facing change?
NONE