As reported in Issue #92, changes in Gitlab's search functionality since 14.10 can cause Ghostflow project initialization to fail with GitlabServiceError::NoSuchUser errors when:
- members of the project (direct or from group) are in state
blockedorldap_blocked - the ghostflow user does not have admin permissions on the Gitlab instance
Blocked members will still show up in the project/group member lists returned but the API, but their data can no longer be accessed through the user API endpoint via username (User ID does work).
This is a very rough draft MR to sketch a possible solution - the User struct for the gitlab handler has a UserState enum added. That enum is taken pretty much as-is from rust-gitlab, and should be populated accordingly (if I understand serde conversions correctly...) when generating the vector of project/group members.
The conversion of that vector of Users to vector of Memberships has a filter stage added to remove any members whose state is blocked or ldap_blocked. Given that blocked users can't interact with the instance as far as I know, this shouldn't impact other functionality, but this hasn't been tested fully yet - hence the Draft MR to get early feedback and direction (I'm very much a Rust newbie) especially on the testing side.