Visibility

Visibility is set per request, not per portal. The portal’s Default visibility decides only what a new request starts as.

Visibility	Who can see the request
Private	The requester, and every member of the workspace
Company	Everyone in the requester’s company, and the workspace
Public	Everyone signed into that portal, and the workspace

A customer with the manager role sees every request in their company whatever its visibility.

Changing it

A workspace member changes it from Portals, under Requests. The Request panel on the issue itself shows the current visibility but does not change it. No customer changes it, including a manager: visibility decides who can read a request, and that decision stays with the team.

Making a private request public shows it, and its public comments, to everyone in the portal. Making a public request private hides it again, including from customers who had already voted on it; their votes are kept and stop being counted in the visible total.

Voting

Only public requests can be voted on, one vote per customer. The count is shown to customers and to members. Votes are Pealboard’s, not GitHub’s; they appear on the issue in the Request panel, not as a reaction.

What is never visible

• Internal comments, at any visibility, to any customer, ever.
• The repository name, the issue number, the assignee, the labels and the milestone. None of them appear in a portal at any visibility.
• Another portal’s requests, even in the same workspace and the same company.

Visibility and GitHub

Visibility is a Pealboard concept. It has no effect in GitHub: an issue created by a private request is an ordinary issue in your repository, and anyone who can see the repository can see it. If the repository is public, so is the issue. Choose the destination repository accordingly.