Good way to get User UUIDs and why that functionality was removed?

[act-mreeves]

First of all thanks for all your hard work!

I see in this commit that we removed the ability to lookup a user by their account_id which is a lot easier to discover than uuid.

  * `uuid` - (Optional) The UUID that bitbucket users to connect a user to various objects
- * `account_id` - (Optional) The user's Atlassian account ID.

https://github.com/DrFaust92/terraform-provider-bitbucket/commit/13d3b555ca37a6433980023e7e9b0ac94f4188bb#diff-7baf6eee56eb0c675831f04289b3b3786aba9f1df3aa8f0ed0588c1c1873ac4aL26

I am guessing this is due to a bitbucket api change?

I want to use specify the users in a group with group_membership but it's very difficult to figure out a user's uuid.

resource "bitbucket_group_membership" "test" {
  workspace  = bitbucket_group.test.workspace
  group_slug = bitbucket_group.test.slug
  uuid       = data.bitbucket_current_user.test.id
}

See https://stackoverflow.com/questions/53983942/how-to-find-bitbucket-account-uuid.

Is there a way to somehow leverage https://registry.terraform.io/providers/DrFaust92/bitbucket/latest/docs/data-sources/workspace_members and https://registry.terraform.io/providers/DrFaust92/bitbucket/latest/docs/data-sources/user together to get a sort of inventory of users in a given workspace?

[act-mreeves]

I discovered a hack to at least look up uuids for a given workspace. I keep this in its own directory and run terraform refresh to see the output.

data "bitbucket_workspace_members" "your_members" {
  workspace = var.bitbucket_your_workspace_id
}

data "bitbucket_user" "your_users" {
  count = length(data.bitbucket_workspace_members.your_members.members)
  uuid = tolist(data.bitbucket_workspace_members.your_members.members)[count.index]
}

output "bitbucket_user_your_users" {
  description = "Uuid to display name map (cannot use display name as key because there are duplicates)"
  value = { for _, user in data.bitbucket_user.your_users:  user.uuid => user.display_name }
  # Below only works with 2.20.0
  # Ref: https://registry.terraform.io/providers/DrFaust92/bitbucket/2.20.0/docs/data-sources/user
  # value = {for _, user in data.bitbucket_user.your_users:  user.uuid => "${user.display_name}, ${user.nickname}, ${user.account_status}"} 
}

This is quite crippled because the user object has very little useful information.

[rquadling]

My approach (as I'm getting over 40 repos all related to infrastructure under control).

All cobbled together from bits I'm working on, so please tolerate any bits missing ... I can put them in.

variable "owner" {
  description = "The owner of the project"
  type        = string
}

data "bitbucket_workspace" "workspace" {
  workspace = var.owner
}

data "bitbucket_workspace_members" "members" {
  workspace = data.bitbucket_workspace.workspace.slug
}

data "bitbucket_user" "users" {
  for_each = data.bitbucket_workspace_members.members.members
  uuid     = each.value
}

locals {
  mapped_workspace_users = {
    for user in data.bitbucket_user.users :
    (user.uuid) => user
  }
  workspace_users = {
    for member_uuid in data.bitbucket_workspace_members.members.members :
    (member_uuid) => local.mapped_workspace_users[member_uuid]
  }
}

I also do something similar for the groups and group membership. This is then all converted to a README so we have a project overview in a repo as a README generated by Terraform with the BitBucket provider ... or will do when I've finished!

And more importantly, see the inconsistent setups on the different repos simply when someone wanted something different and then no one knew why. Small things, but it is what it is. And adding a new repo with all the standard setups is now a LOT easier!!! ... again ... will be when I've finished.

Overall, very similar to the approach by @act-mreeves. Just a stylistic difference. I don't like resources with index numbers as they are not expected to be addressed singularly. I use a map and so preserve a uniqueness for the TFstate and so every resource is fully accessible regardless of how it originated. Sometimes a little more effort to achieve that, but that's my style. Use what is comfortable for you.

[kidpooh1608]

I have the same use case and face the issue of Bitbucket request limit (1000 per hour). api-request-limits so it'll hit limitation if the member of workspace is over than that number. it's better if bitbucket_workspace_members can also return uuid and display_name in a map instead of set of uuid only. https://github.com/DrFaust92/terraform-provider-bitbucket/blob/master/bitbucket/data_workspace_members.go#L57

[DrFaust92]

sounds good kidpooh1608, let me try