Note |
---|
This page is a work in progress and is still being updated. Please watch the page for new updates. |
Multiexcerpt | ||
---|---|---|
| ||
Project Admins: Configure Your Project to Support Partner AccessPrerequisites
|
Project permissions and user/group role mappings
In order for a partner to have access to a Jira project, the project must:
Support access by non-Red Hatters.Using Red Hat Standards (internal Red Hat page), this means that the project's permission scheme should be
|
|
|
|
- Browse issues they have access to view
- Create new issues
- Set the issue security level on issues they can access
- Be assigned to issues they have access to view
- Add comments and attachments to issues they have access to view
- Link to other issues they have access to view
- Manage watchers on issues they have access to view
ProcedureFollow this procedure if you need to support a partner's access to your Jira project.
|
|
|
Fields
Partners who should have access to a subset of the issues in a Jira project can be added to individual users in either the Contributors or Contributing Groups field. The Contributors field is globally available in projects by default, but the Contributing Groups field is not. A project admin may need to request that it be added to their project.
Issue security
Partners may not have access to all issues in a project due to the security level applied to each issue. Red Hat partners will not have access to issues with the following Red Hat Standard security levels (internal Red Hat page) applied (uncommon exceptions are noted in parentheses below):
- Red Hat Employee
- Embargoed Security Issue (unless they are explicitly added to a user picker field on the issue)
- Red Hat Engineering Authorized (unless they are the reporter or added to the Contributors field)
- Restricted (unless they are explicitly added to a user picker field on the issue)
- Team (unless they are explicitly added to a user picker field on the issue or have the Scrum Master, Developer, or Administrator project role)
In most cases, partners are given access to issues in one of two ways:
Configure your issues to support partner accessOnce the project configurations are in place, your issues can support partner access in the following ways:
|
Additional optional configurationsAutomation can help streamline access to issues in Jira. There are a few ways to go about this:
|
FAQ
I'm a partner that collaborates on issues in a particular Jira project, and I can't see any issues. Why?
This is likely because the project's permission scheme does not support non-RH access. Have a project admin check the permission scheme applied to the project, and ensure it is OJA-PRMS-002 or OJA-PRMS-003.
I'm a partner that collaborates on issues in a particular Jira project, and I can see some issues but not all of the issues I'm linked to. Why?
This is likely because the particular issues you cannot see have a security level set that prevents you from accessing it. In most cases, issues that should be accessible to a particular partner user or partner group should be restricted using the Red Hat Partner security level and have the partner user or group added to the Contributors or Contributing Groups field. Check with someone who can access the ticket whether these are set properly on the ticket.
I'm a Red Hat employee, and I can't see some of the issues partners are working on. Why?
Not all Red Hat employees are in the group that grants access to view all partner issues in Jira. This group membership is limited to Engineering and Support associates and requires approval.
Multiexcerpt include | ||||
---|---|---|---|---|
|
Multiexcerpt include | ||||
---|---|---|---|---|
|
I'm a Red Hat employee, and I want to manage partner access in my project through a group rather than individual access. What do I do?
If the partner you're working with did not have a group set up by the Engineering Partner Management group, then open a ticket to rh-issues@redhat.com providing the partner name and domain. You can request that anytime someone from that domain logs in, they get automatically added to the partner group. Then, you can map that group to a role in your project and/or add it to the Contributing Groups field on an issue to give everyone in that group access to the ticket.
I'm a Red Hat employee, and I want to share all tickets in my project with the partners I work with. Do I have to add them to every ticket?
No! If all issues should be accessible by the partner(s), you can grant the partner(s) or partner group an elevated role (like Developers) and keep the issues in the project unrestricted (no security level set). Just be sure you're using OJA-PRMS-002 or OJA-PRMS-003 (OJA-PRMS-001 does not support non-Red Hatter access).
I'm a Red Hat employee, and I want new partner-opened issues to default to visibility to that partner's group. What do I do?
Assuming all partners who might open ticket are using accounts associated with their company email addresses, open a ticket to rh-issues@redhat.com requesting that whenever someone from that domain opens a ticket, the security level defaults to Red Hat Partner and the partner group gets added to the Contributing Groups field.
I'm a Red Hat employee who works in a project that has interactions from multiple partners. How do I segregate access appropriately?
Using the Red Hat Partner security level along with adding values to the Contributors or Contributing Groups field is the best way to manage multiple partners working out of the same project. By specifying which partner users or partner groups should have access to each ticket, you are explicitly granting access to those tickets but not to others. Be sure you also use the Red Hat Employee security level on tickets that should not be accessible by anyone other than Red Hat employees.
I'm a Red Hat employee who is a project admin of a project using OJA-PRMS-001 and need it to enable partner access. What should I do?
For projects that should not be opened up publicly but that need to support partner access, we recommend migrating to OJA-PRMS-003. If you want all Red Hat Employees to maintain some access, you can grant that group a role in your project settings (the Viewers role will grant browse abilities while the Users role will grant basic create abilities. Use Developers to grant full ability to create and work on tickets). You can then also grant the partner users or groups the appropriate role based on what level of access they need. This will be be determined by whether they should have access to all tickets in the project or only some.