In iteration 1 of Credentials Inventory for GitLab.com we identified some concerns with project and group access tokens support. It was originally written only for self-managed where the same concerns don't exist. For this iteration, we will address the concerns with project and group access tokens and ship support. There doesn't appear to be a performant enough way to query for project bots and subsequently project and group access tokens at this time. There are tradeoffs we can make but a choice made for Group Credentials Inventory has negative effects on instance Credentials Inventory and vice versa. The smallest iteration that will allow us to deliver this feature with the least side effects is to add a `bot_namespace` column to `user_details` and then backfill the ownership data. Here's the current planned MR breakdown. Items 1 and 2 can happen concurrently. 2, 3 and 4 can be in development concurrently but each must be merged prior to the next being merged. 1. :white_check_mark: https://gitlab.com/gitlab-org/gitlab/-/merge_requests/170277+ Allow querying for both Group and Project Namespaces in the `self_and_descendants` linear traversal methods. Without this change there's not a good way to query for these users. 2. :white_check_mark: https://gitlab.com/gitlab-org/gitlab/-/merge_requests/170309+ Add `bot_namespace` column to `user_details` along with associated foreign key and any needed indexes. 3. :white_check_mark: https://gitlab.com/gitlab-org/gitlab/-/merge_requests/170999+ Populate column for new project and group access token users 4. :white_check_mark: https://gitlab.com/gitlab-org/gitlab/-/merge_requests/171326+ Backfill `bot_namespace` with the Group or Project Namespace that owns the bot user. This will be a background migration. 5. :white_check_mark: https://gitlab.com/gitlab-org/gitlab/-/merge_requests/169338+ Modify Group Credential Inventory to query for bot users with bot_namespace ID in group hierarchy. Once the last MR is merged and deployed, the feature will be available on GitLab.com. If something goes wrong, we will need to disable https://gitlab.com/gitlab-org/gitlab/-/issues/485659+ The database team says we can do all this in one milestone - we don't have any requirement to, for example, add the column in one milestone and then add the backfill migration in the next milestone. I will ensure we get lots of people involved to evaluate the backfill plan so we ensure the migration is both accurate and doesn't cause any incidents for customers.