Patrick Jungermann

@fstoerkle Could you illustrate how your implementation differs from the already available `userGroupMember` feature? https://backstage.io/docs/integrations/azure/org > Alternatively you can import users that are members of specific groups. For each group...

I guess the intended use was to use `group` and `userGroupMember` together and not only the latter. E.g., you might want to ingest more groups than those you use to...

I agree, naming can be hard 😄 What do you think about `includeSubGroups: boolean` as an option for `group`, defaulting to the current behavior `false`? ```yaml microsoftGraphOrg: providerId: group: filter:...

@davidfestal yes, removing the vmevent support from the backend module plugin would have been a quick option to at least unblock the use without events. As I hope that the...

@davidfestal As the changes were merged and released already, I assume that this issue could be closed, right?

@joeyweisband for clarification: Are those archived repos not removed on event-based changes only or not at all (including the full sync)? For the latter, it might be a different issue...

I just remembered issue #21553 which will add event support for the GitLab entity provider. Hence, this cannot be related to event-based updates. Hence, I assume that there is no...

@knewman23 Which permissions did you give to the credentials? The configuration looks alright, and we have it in active use.

Our setup looks similar: ```yaml integrations: bitbucketCloud: - appPassword: ${BITBUCKET_PASSWORD} username: ${BITBUCKET_USERNAME} ``` ```yaml catalog: providers: bitbucketCloud: some-name: catalogPath: catalog-info.yaml # in any dir filters: repoSlug: '^some-regex$' schedule: frequency: {...

@knewman23 Did you have a chance to look further into your issue and the used secret and its permissions?