github
Map Mannequins during migration
Description
As an enterprise customer, we have over 7000 engineers actively using GHES. Emailing all 7000 to re-attribute is toilsome, especially when we already have GH Connect enabled and all of the on-prem identities are already linked to GHEC identities.
Request to implement previous features from ECI and legacy import tooling that allowed mapping/matching of mannequins either through a user.csv or other mapping file DURING import, rather than having to re-attribute them all later to claim mannequins.
Are you familiar with the generate-mannequin-csv and reclaim-mannequin commands? They let you do it in bulk, and if the target uses EMU you can add the —skip-invitation flag to skip the emails.
Are you familiar with the generate-mannequin-csv and reclaim-mannequin commands? They let you do it in bulk, and if the target uses EMU you can add the —skip-invitation flag to skip the emails.
Hey Dylan,
Familiar with the EMU side but EMU isn't an option for us unfortunately, and I would argue a lot of Enterprises that use EMU still need a GHEC Enterprise as well due to needing to handle open source and other caveats that EMU doesn't support.
My understanding is the commands you mention will still require non EMU enterprises have every individual user accept the reclaim email. Please let me know if I misunderstood that though!
This is asking for functionality that existed in previous tooling, whether ECI, or the GraphQL endpoints that required a Services Engineer engagement in the past.
Again, with GH Connect, the connection already exists that links on prem identities to GHEC identities, so I'm hoping y'all can tap into that to implement this.
At the least, allowing for an optional flag to pass in a mapping.csv as you could in prior tools would be greatly appreciated.
My understanding is the commands you mention will still require non EMU enterprises have every individual user accept the reclaim email. Please let me know if I misunderstood that though!
there is a --no-prompt flag which you can use
--skip-invitation --force --no-prompt
My understanding is the commands you mention will still require non EMU enterprises have every individual user accept the reclaim email. Please let me know if I misunderstood that though!
there is a --no-prompt flag which you can use
--skip-invitation --force --no-prompt
Where is this documented? Official docs don't seem to reference it
Hey mate, the documentation doesn't have a ll the flags but if you run gh gei reclaim-mannequin --help you should be able to see it.
--skip-invitation Reclaim mannequins immediately without sending an invitation to the user. Only available for Enterprise Managed Users (EMU) organizations. Warning: this is irreversible!
It seems to be available only for the EMU
Adding some recent feedback we've got about mannequin claiming:
(...) to automate the reclaim of the mannequin users. I have to say, the new process is extraordinarily clunky. Before (using ECI), the mapping was instant and attributed the right users to the correct imported user (email address stays the same, so joining on that was trivial.) Now, it emails users to accept the mannequin user. Extraordinarily frustrating to spam users needlessly. Please register my dissatisfaction with this new process. It's anti-user and anti-automation.
Thanks for the +1 @stoe and good to see you 😄 :octocat:
@dylan-smith any other insight into this potentially getting on the roadmap? It's a very toilsome process compared to the old way.
I'm not sure how ECI did it, but forcing an email acceptance was an intentional design decision. So a change to that would have to be a PM decision. The design does make sense to me though, because for non-EMU accounts those are owned by the individual not the company, and I wouldn't want a company associating my personal GitHub account with their enterprise without my permission.
PS: I'm no longer on the migration tools team, but I'll ping them with this conversation.
Hey @IAmHughes. I'm the product manager for GitHub’s migration tooling. Thanks for raising this, I really appreciate you taking the time to share your thoughts.
As @dylan-smith mentioned, this was a conscious design choice based on the differences in ownership models between EMU and non-EMU accounts. EMU accounts are owned by the Enterprise, while non-EMU accounts are owned by individual users, which creates different obligations regarding user permissions and approvals. This design ensures that Enterprises cannot associate GitHub activity with accounts they don’t own without explicit user acknowledgment, which aligns with our commitment to user privacy and control.
That said, I completely understand how this might introduce friction to your workflow relative to ECI, particularly in cases where both GHES and GHEC enterprises are using the same identify provider. If you’d like, I’d be happy to connect directly to further explore potential ways of improving this flow, while balancing security and user trust. Please feel free to share any additional details here or reach out to me directly.
Thank you for the explanation. No need to discuss further, but I think an enhancement would meet both requirements of ownership and ease of use:
Allow for a specific domain name for emails to be automatically enrolled/mapped to enterprise users.
All of the user emails in our export/import were in our @company.domain. There is no question from our perspective of ownership of those email addresses and the corresponding enterprise users. There may be a situation where users registered their company email address but for a personal GitHub account, but we can deal with those separately by simply removing them from the mappings.csv file.
We've already gone through the extra step of having users claim their mannequin accounts, so these enhancements will not affect us at this point. But it was odd for us to see a useful feature be removed from the tool from one version to the next.
Hey @IAmHughes. I'm the product manager for GitHub’s migration tooling. Thanks for raising this, I really appreciate you taking the time to share your thoughts.
As @dylan-smith mentioned, this was a conscious design choice based on the differences in ownership models between EMU and non-EMU accounts. EMU accounts are owned by the Enterprise, while non-EMU accounts are owned by individual users, which creates different obligations regarding user permissions and approvals. This design ensures that Enterprises cannot associate GitHub activity with accounts they don’t own without explicit user acknowledgment, which aligns with our commitment to user privacy and control.
That said, I completely understand how this might introduce friction to your workflow relative to ECI, particularly in cases where both GHES and GHEC enterprises are using the same identify provider. If you’d like, I’d be happy to connect directly to further explore potential ways of improving this flow, while balancing security and user trust. Please feel free to share any additional details here or reach out to me directly.
Hey @boylejj thanks for reaching out. Unfortunately @jfine edited my comment (hope you're doing well Jared!) and it seems @stoe 's was removed entirely (likely due to a named customer from a services engagement), but I hope that seeing at least some of the quote from @stoe in this comment can show that this is a request from other enterprise users as well.
I'll give a +1 to @lonestriker - if the dotcom user has a verified domain, we should be able to associate them. EMU existed in the previous tooling before ECI took over and dropped a bunch of features like this one. I know the mannequin mapping process and the general conflicts.csv process was a bit toilsome for some, and often flakey, but I hope that flakiness doesn't necessitate finding a reason to drop the feature entirely 😅
I can understand if I was trying to automatically associate commits made within my enterprise to a random dotcom user, however if they are a member of my current GHEC Enterprise with a verified email that is part of my verified domain, this should be taken care of. As noted by @stoe 's note and I'm sure anyone else that's noted this in what I assume would be listed in the github/customer-feedback repo, this new process is very toilsome and not scalable for an enterprise with thousands of users. The user with a personal account would've already accepted joining the enterprise, going through SSO, verifying their email with a verified domain, etc. So the privacy and control comment seems a bit moot, no? The commits don't effect their public profile at all, except in showing activity on their profile's activity graph, in which all data is obfuscated unless you also have access to the enterprise/repos where the activity was conducted.
We have a githubcustomer Slack workspace you can find me in if you'd like to chat specifically, but I don't know if it's overly necessary as I think the full context is in this thread 😄 👍