TL;DR: Additional restrictions for issues and wikis?

Consider having 3 groups of people: me, customer_1, customer_2. Is there any way to restrict created issues by e.g. customer_1 to only be visible to me and customer_1 by default? Possibly even making the issue visible to customer_2 at some point, but not by default. Remember that customer_1 and customer_2 should be allowed to create issues on their own at all.

Looks to me like this is not possible and even if it would, doesn’t look like wikis support something like that as well. So in the end, customers could write each other things within the wiki and stuff like that.

Context

My company maintains software for various different customers sharing some source business logic among all of those customers, but resulting in pretty custom deployments in 99 % of use-cases. Those deployments contain of binaries, textual source code files, lots of configurations and is simply some directory with lots of different files without any install process or alike. Copy and use, that’s why things will be maintained as GIT-repos in future.

Am doing so for other software and customers using SVN for years already, works great. Additionally, and that’s the important part for my question, GitLab not only provides the repo itself for deployments, but a project specific issue tracker and wiki as well. Some customers are pretty interested in using both in addition to the repos.

Current approach

While some source is shared amongst customers and projects, deployments are pretty customized most likely. Though, that seems to fit pretty well into how GitLab works anyway: Customers simply become groups on their own and within each customer each individual deployment will become an individual project with one repo, issue tracker and wiki. Customers get user accounts, are being assigned to their groups and inherit project membership as well that way. Having individual issue tracker and wiki makes sense most of the time as well, because the customized deployments are pretty individual overall projects in the end. Even with some shared issue tracker each of those projects would become some kind of individual larger topic, category, label or whatever, so distinguishing on project level seems to make sense.

Exception from the rule

Of course there are some exceptions: There’s currently one known project which is shared by multiple different customers and all of those use pretty much the same deployment. I have two choices know: Either create individual groups and project per customer and introduce some kind of redundancy this way or create some customer-independent group and project and give all customers access to that.

Having some redundancy means storing the same repo data multiple times, maybe a few hundred MiBs most likely, not too much. What I’m more concerned is diverging deployment code base, I might need to maintain updates in multiple repos in the end. Though, with GITs support for multiple remotes, that shouldn’t bee too difficult in theory, as I’m able to merge branches or cherry-pick from multiple different repos.

OTOH, avoiding that kind of work by having one shared project only sounds useful as well. People could possibly share knowledge using the same wiki, issue tracker and stuff. Though, especially in the issue tracker there surely will occur things which I don’t want to share amongst customers. Simply think of telling one customer how much money it costs to implement feature XY while trying to sell the same to another customer. Or not fixing the bug for one customer, but for a different one because that customer is more promising or whatever. You get the idea…

Overall advices?

Best thing would be to keep individual projects per customers instead of sharing, wouldn’t it? Or did i miss something?

Thanks!