State changed as code fixing the issue is committed (714aa46f)

State changed as build OD-6133 is successful

This looks good. Is there also a possibility to disable considering certain groups for this? Some general-purpose groups you would not want to autocomplete

This feature is reverted. OneDev is designed to be used inside a company or for personal use, and such limitation can be very inconvenient.

This feature is reverted. OneDev is designed to be used inside a company or for personal use, and such limitation can be very inconvenient.

I can understand this, but in an organization, you may not want a list of all employees or accounts visible, which is my use case.

There are cases where you may need to grant external auditors or contractors access to certain internal codebases.

Maybe the auto-complete/mention scope should be limited to all users participating in a project. This feature will be reconsidered if OneDev introduces project collaborators in future versions.

Maybe the auto-complete/mention scope should be limited to all users participating in a project. This feature will be reconsidered if OneDev introduces project collaborators in future versions.

This sounds good.

I am experiencing a same situation now where it would be helpful if certain users can not see other users outside of the project (or group?) scope.

Another option would be a list of "allowed users" on the profile (same as "belonging groups" and "authorized projects"), but I doubt if that's a good idea.

@robin at the moment I have two concrete situations and I thought it would be useful to add them here for clarification.

The first one is where other developers have to contribute to a single project, but they are not involved in other projects and should not have interaction with other users. In the issues/comments they are able to assign/mention users (and service users) that are not on the project at all, which makes it confusing.

The other situation is a client that wants access to the issue board of the project to view and create/edit issues. This client should only interact with users that are assigned to that project, so he can not assign the issue to another developer outside the project. Consider it a "guest" user.

I don't want to put pressure on you, but is project collaboration something that is planned in the (near) future, or is it a feature somewhere on the backlog? I would like to know if I need to come up with an alternative solution for these situations.

Thanks for the clarification. I’m considering introducing a project collaborator or team concept, but it needs to be carefully evaluated together with the existing group concept. I also need to consider feature priorities and how certain capabilities should be offered as part of paid plans, so I can’t commit to a timeline yet.

Thank you for the explanation, and it is understandable that you want to look into this thoroughly.