Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.
Note

This page is a work in progress and is still being updated. Please watch the page for new updates. 


Introduction

Partners collaborate with Red Hatters across many products and Jira projects, which requires secure access controls in place in order to grant access to the appropriate projects and tickets.

This page outlines the configurations a project admin must put in place in order to support partner access, plus what to check in the case that a partner cannot access a particular issue.

Table of Contents
maxLevel3

Multiexcerpt
MultiExcerptNameConfigure Project Access for Partners

Configure

Your Project to Support Partner Access

your project to support partner access

Prerequisites

  1. Ask if the partner you're granting access to your project previously created a Bugzilla account and is managed in partner groups in Bugzilla. If not, ask if the partner users have existing Jira accounts.

  2. Identify the issue security scheme your project is using and note if it is not OJA-ISS-001 or OJA-ISS-002. These two issue security schemes contain the Red Hat Partner security level.
  3. Identify the permission scheme your project is using and note if it is not OJA-PRMS-002 or OJA-PRMS-003. These two permission schemes allow partner access, whereas OJA-PRMS-001 does not.
  4. Determine the level of permissions the partner users should have. There are two sets of permissions to choose from:
    1. Limited partner permissions: when added to the Contributing Groups Limited Access field, partner users can view issues (but not edit, transition, close, etc.) and add attachments and comments
    2. Broader partner permissions: when added to the Contributing Groups field, partner users can view, edit, transition, and close issues and add attachments and comments

Procedure

Follow this procedure if you need to support a partner's access to your Jira project.

  1. If your project is not already using OJA-PRMS-002 or OJA-PRMS-003, change the permission scheme using the Delegated Project Admin plugin.
    Note: Use OJA-PRMS-002 if your project is or should be publicly browseable. Use OJA-PRMS-003 if not.

  2. Email rh-issues@redhat.com, requesting to enable partner access in your project, and include the following information:
    1. Whether the partner you need to onboard into your Jira project has a Bugzilla account and partner group*. All partner accounts in Bugzilla are already synced into Jira.
    2. If not, the name of your partner group, which will be used to create a Jira group with the following syntax: <partner name>-partners. Also include their email domain (e.g. redhat.com) and whether any partner users have existing Jira accounts that need to be added to the new partner group. 
    3. Whether you need the issue security scheme in your project updated to either OJA-ISS-001 or OJA-ISS-002. See the Prerequisites section for more information.
    4. Whether your partners need limited or broader permissions (See 4b of the Prerequisites section for more information). This will determine whether Contributing Groups or Contributing Groups Limited Access is added to your project.

  3. After the rh-issues ticket is fulfilled, if your partners are new to Jira, ask each partner user that needs access to create a Jira account. If their accounts use the same domain name as provided in step 2b, they will be automatically added to their respective partner group.

  4. After the rh-issues ticket is fulfilled, update the user role mappings, giving the partner group the Users or Developers role, depending on the level of access the partners need.
    1. Users role: browse, watch, link to, and add comments and attachments to issues they can access + create new issues and be assigned to issues
    2. Developers role: completely manage tickets, from creating to editing and transitioning through the workflow to resolving and closing, + start and complete sprints

Configure your issues

to support

for partner access

Now that your project can support partner access, here's how you enable partner access on the issue level:

  1. If the partner/partner group should have access to all issues in the project, simply leave the issues unrestricted with no security level set.
  2. If the partner/partner group should have access to only some issues in the project, then:
    1. Apply the Red Hat Employee security level to the issues they should not be able to access
    2. Apply the Red Hat Partner security level* and add the partner/partner group to the ContributorsContributing Groups, or Contributing Groups Limited Access field to issues they should be able to access
      Info

      *A note on the Red Hat Partner security level

      Because Jira users can only set the security level of an issue to levels that they have access to, it's possible that not everyone will see Red Hat Partner as an option in the Security Level field. If a Red Hatter cannot set the issue to Red Hat Partner or see an issue where the security level is set to Red Hat Partner, it's likely because they are not in the proper group. More details follow:

      Multiexcerpt include
      MultiExcerptNamePartner_Bugs_Group
      PageWithExcerptPartner bugs

      Multiexcerpt include
      MultiExcerptNamePartner_Bugs_BZ
      PageWithExcerptPartner bugs

      See Partner bugs for more details about the restrictions in place for broad access to partner issues in Jira.

Additional optional configurations

Automation can help streamline access to issues in Jira. There are a few ways to go about this:

  1. If the partners working in your project use their partner company email addresses for their Jira accounts, PME can enable automation that automatically sets the security level to Red Hat Partner and automatically sets the Contributing Groups field to the appropriate partner group when a person from the same domain opens a new Jira ticket. See Managing partner interactions in Jira (internal Red Hat page) for more details.
  2. Project admins can create custom automation rules to set the security level to Red Hat Partner and the Contributors and/or Contributing Groups field as appropriate based on a specific trigger.



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
MultiExcerptNamePartner_Bugs_Group
PageWithExcerptPartner bugs
Multiexcerpt include
MultiExcerptNamePartner_Bugs_BZ
PageWithExcerptPartner bugs

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.