Module: Entitlements

Defined in:: lib/entitlements/backend/github_org/controller.rb,
lib/version.rb,
lib/entitlements/service/github.rb,
lib/entitlements/backend/github_org.rb,
lib/entitlements/backend/github_org/service.rb,
lib/entitlements/backend/github_org/provider.rb,
lib/entitlements/backend/github_team/service.rb,
lib/entitlements/backend/github_team/provider.rb,
lib/entitlements/backend/github_team/controller.rb,
lib/entitlements/backend/github_team/models/team.rb

Overview

TL;DR: There are multiple shenanigans here, so please read this wall of text.

This controller is different from many of the others because it has 2 mutually-exclusive entitlements that convey access to the same thing (a GitHub organization) with a different parameter (role). As such, this controller calculates the specific reconciliation actions and passes them along to the service. (Normally, the controller passes groups to the service, which figures out changes.) Taking the approach here allows less passing back and forth of data structures, such as “the set of all users we’ve seen”.

This controller also supports per-OU feature flags, settable in the configuration. It is possible to disable inviting new members to the organization, and removing old members from the organization, if there’s already a process in place to manage that.

Available features (defined in an array named ‘features` which can be empty):

invite: Invite a non-member to the organization
remove: Remove a non-member (or no-longer-known-to-entitlements user) from the organization

If ‘features` is undefined, all available features will be applied. If you want to include neither of these features, set `features` to the empty array (`[]`) in the configuration. Note that moving an existing member of an organization from one role to another is always enabled, regardless of feature flag settings.

But wait, there’s even more. When a user gets added to a GitHub organization for the first time, they are not actually added to the member list right away, but instead they’re invited and need to accept an invitation by e-mail before they show up in the list. We don’t want to add (invite) a member via Entitlements and then have them showing up as a “needs to be added” diff on every single deploy until they accept the invitation. So, we will fudge an invited user to be “exactly the permissions Entitlements thinks they have” when they show up on the pending list. Unfortunately the pending list doesn’t show whether they’re invited as an admin or a member, so there’s a potential gap between when they accept the invitation and the next Entitlements deploy where they could have the wrong privilege if they were invited as one thing but their role changed in Entitlements before they accepted the invite. This could be addressed by exposing their role on the pending member list in the GraphQL API.

The mapping we need to implement looks like this:

Defined Under Namespace

Modules: Version Classes: Backend, Service