We have a public issue tracker that is used by our customers who submit feature requests. It's based on redmine at the moment, but we develop the code within Gitlab project. It's a bit inconvenient as we need to cross our issues with redmine system.
Proposal
It would be great if we could create a project in gitlab, but limit code repository browsing/commits/etc. to developers group for example. Reporters/guests would only see the issue tracker/wiki without access to the repository code.
Links / references
Thanks
Designs
Child items
...
Show closed items
Linked items
0
Link issues together to show that they're related or that one is blocking others.
Learn more.
@maxraab not the case, I think. The idea is to provide public access to issues without access to the repository/code. So registered members could post issues but neither see the code, nor anything related to the repository itself.
@vbezruchkin And if you create a public repo for the issues and a private one for the code. Than you can reference your issues like: gitlab-org/gitlab-ce#22165?
This is certainly a feature I'd love - I work for an SME Company that decided to invest in an new EDI system. The team here decided to use Gitlab for it's fantastic integration for development & deployment. Which I have high praises for, it's been brilliant.
After a successful launch, began the stage of Maintenance and Evolution of our EDI System. Staff members often email & ring to ask for a new feature - this isn't being documented! Despite Gitlab being on the Intranet for the company & all very IT literate; it's a very developer oriented system. Even Markdown, despite it's elegance - can seen to be alien for some.
As mentioned above, I don't want to expose Code, Branches, Files & Tags to our staff members - but rather just the issues and the Wiki for easy 'FAQ'.
Albeit, I may be straying away from Gitlab's core goal here, but having a more public friendly section to a particular project, I think integrates that last stage of development more.
@maxraab The problem that I have (and I assume others do as well) with that solution is that even if I create a new repo just for public issues, and cross reference them, people still must register for a GitLab account & log in to submit a bug.
While the fixes made so far in #19734 (closed) are a step in the right direction for making parts of projects public and other parts private, it still hasn't address the anonymous issue creation (although there has been recent discussion about whether that work is done). Anonymous/public issue creation looks like it's also been requested before in #560 (closed), #19574 (closed), & #23725 (closed).
It's possible that the intention right now is to not have public/anonymous issues, and if we want that maybe we should look at another product for issue tracking. But I'd really like to have everything in one place, for integration, and because GitLab looks so much better than the rest of them. And it seems that there is at least some user interest in having public/anonymous issue trackers/wikis.
In my case it's not important if they are logged in users or guests, it's more about a code protection. I like the idea of being a registered user in order to post a new issue or edit wiki. It gives more control & the things look organized in better way. Gitlab provides an easy integration with 3rd party socials and github, so registration is an easy move.
I guess it's my due to inform that I was able achieve this in my Gitlab installation. RIP Redmine issue tracker now :))
I created a new group (visibility public), and added all my developers in that group. Of course as developers.
Then I created a new project within that group. Here are the settings for a project:
That did the trick for me. I have access to issue tracking & wiki. Guests can read it, authorized members can report issues - but they all don't have access to the repository. There are some improvements for project activity page, but I guess it's going to be a separate story.
Uh.. pretty sure your project is still visible in some way if it's set to "Public". I vaguely remember reading one of the devs mentioning something about the URL being accessible and thus can be copy/pasted in order to clone it.
Regardless, many of us would rather chew glass than set a private repository to "public" even if this does work somehow. And even if it does, it needs to be simplified, thus #24083 (moved)
@vbezruchkin , using separate projects for the issue manager and the sources could do the trick, but as soon as you set a project visibility to "Public" then "the project can be cloned without any authentication".
I highlighted it here, and @JobV agreed it shouldn't be happening here. So IMHO #19734 (closed) was closed without fully achieve it's original purpose.
Then I created #23725 (closed) and @markglenfletcher closed it redirecting me to this issue. So I fail to understand why you close it.
Yes, the project repository is still available through the direct URL so I was unhappy to get back to Redmine :( This issue is reopened, anyhow it seems the discussion has been migrated to #24083 (moved) as we discuss the same idea there.
I'm curious has anyone tried to create a UI for the issue traacker? https://docs.gitlab.com/ee/api/issues.html meaning have some textfields on their website that create a ticket.
This has been repeated in issues for years: #24083 (moved)
But it keeps getting closed because it's technically possible to do, you just have to set your repo to Public in order to make it private: gitlab#201770 (comment 283225423)
Do you happen to know if doing that still retains the property of a Public repository which makes anyone able to use the repo link to clone it, even though we'd set the access to "Repository" for developers only?