Managing access to your service project

Go to Project settings > Customer permissions to choose who can raise requests in your service project and who your customers can share requests with.

このページの内容

リクエストを送信できるユーザーの選択

People need to be customers to raise requests in your service project. You can let your team control who becomes a customer, or let customers create their own accounts.

リクエストを送信できるユーザー説明
プロジェクトに追加されたカスタマーチームはカスタマーページを通じて、またはカスタマーの代わりにリクエストを出すことによって、カスタマーをプロジェクトに追加します。
Jira サイトにアカウントがあるユーザーは自動的に顧客リストに追加され、リクエストを送信できます。
Anyone can email the service project or raise a request in the portal
  • New customers can create their own accounts in your service project via the customer portal.
  • 電子メール リクエストにより、送信者のアカウントが自動的に作成されます。
  • カスタマーがリクエストを共有できるようにした場合、リクエストを共有するユーザーもカスタマーになり、リクエストを送信できます。
  • スパムボットによってカスタマー ポータルからアカウントが作成されるのを防ぐため、ハニーポット技術が有効化されています。

If this option is disabled, then your Jira administrator has not turned on public signup for service project on this Jira site. Learn more 

When you choose this option, you have no control over who can create an account and raise requests. We strongly recommend that you use the Customers who have an account on this Jira site option instead, unless the requirement for a Jira account won’t work for your use case.

Read more in our security advice

リクエストを共有できるカスタマーの選択

You can allow customers to share requests with their organizations, anyone in the service project, or people who aren't customers yet. The people customers share with become participants in the request. Request participants can comment on and share requests, and receive the same notifications from Jira Service Management as the reporter. Learn more about request participants.

次の表は、カスタマーがリクエストを共有できる方法の説明です。

カスタマーが共有できるユーザー説明
組織内の他のカスタマー
  • カスタマーは組織とのリクエストの共有、またはプライベート リクエストの送信が可能です。
  • カスタマーは共有する相手を組織内で検索できます。
     
  • 組織に所属していないカスタマーはリクエストを共有できません。
メールアドレスを知っている相手

Customers can share requests with other customers in their organization (like in the option above), and also:

  • Share requests with anyone in the service project, if they know their email address
  • If anyone can email the service project or raise a request in the portal, then customers can also share requests with people who aren’t customers yet. They can provide email addresses of these people and Jira will create accounts for them. Such unregistered email addresses can only be entered in the Share this request or Raise this request on behalf of fields, but not regular user picker fields.
このプロジェクト内で検索されるカスタマーまたは組織
  • Customers can share their requests with anyone in the project. They can also search the service project for people to share with.
  • If anyone can email the service project or raise a request in the portal, then customers can also share requests with people who aren’t customers yet. They can provide email addresses of these people and Jira will create accounts for them. Such unregistered email addresses can only be entered in the Share this request or Raise this request on behalf of fields, but not regular user picker fields.

If your service project uses user picker custom fields, such as the Approvers field, choose this setting to make sure customers can select users.

Choose whether customers can vote for requests

You can allow customers to vote for requests directly in the customer portal. This lets them cast their votes for requests they'd like to see done without having user accounts on your Jira instance. 

To enable voting in the portal, you need to have global voting enabled for your Jira instance.

The following table describes different options for this setting:

Can customers vote in the portal?説明
Yes, any customer with portal access can vote directly in the portal

Customers will see an extra option to vote when they view a request in the portal. They can then add their vote or remove it.

No, customers can't vote directly in the portal

If the global voting is enabled, users with accounts on your Jira instance will still be able to vote for requests if they view them directly in Jira. Customers might not have such accounts, so this option will essentially limit voting to your agents.



チームに最適な設定の選択

チームに権限を設定する方法が不明ですか? 以下にカスタマー権限を効果的に設定する方法について、いくつか提案を示します。

状況リクエストを送信できるユーザーカスタマーが共有できるユーザーCan customers vote?
You have a service project that handles contractors' leave requests. Only contractors can use the service project, and you don't want non-contractors to get confused about where to request leave. プロジェクトに追加されたカスタマー組織内の他のカスタマー

No, as contractors probably don't need to vote for their leave requests.

会社に IT サービスデスクがあり、全従業員が自分自身のアカウントを作成してリクエストをメールで送信できるようにしたい。 この Jira サイトにアカウントがあるカスタマーこのプロジェクト内で検索されるカスタマーまたは組織

No, if your team is mostly handling requests for individual employees, such as "I need a new monitor".

Yes, if your team is handling requests for general improvements. For example, employees could vote for what they'd like to be added to their office.

Your team provides software support for individuals. For example, if your company makes a free SAAS application that individuals use to manage finances, you can let your customers email bugs and questions to your service project email channel.Anyone can email the service project or raise a request in the portalメールアドレスを知っている相手Yes, it might be useful for individuals to vote for bugs or requests they'd like to see fixed first.

Security advice: Choosing who can raise requests

This is a security advice regarding the option Who can raise requests.

When allowing anyone to create and raise requests, we strongly recommend that you use a separate domain for your incoming email account and configure this account to filter against automatic emails by blocking the addresses with a local-part, such as “no-reply”, “support”, “servicedesk”, and so on.

理由

Configuring your Jira Service Management instance using an incoming email address with a domain at your company level can result in bad actors abusing the system to gain access to restricted services.

For example, assume that your domain is http://mycompany.com, and you have set up a customer portal with an incoming email support@mycompany.com, allowing anyone to create and raise requests. Now, let’s say a bad actor is trying to gain access to teamsinspace.com for which your company already has an account (e.g. admin@mycompany.com).

If the bad actor creates a new ticket in your customer portal and adds no-reply@teamsinspace.com as a participant, they can now go to teamsinspace.com and open an account for support@mycompany.com and provide a team name including the ticket number. Since teamsinspace.com includes the team name in their confirmation emails (and other websites might include other details), such an email will be sent to your incoming email address in Jira Service Management, and added as a comment to the ticket. By clicking on the confirmation email, the bad actor could open an account on teamsinspace.com on behalf of your company.

Mitigating this issue

Using a separate domain or sub-domain dedicated for your customer portal will help prevent this as long as you make sure to not sign up to services using that domain. What’s more, adding filters against automatic emails (e.g. “no-reply”) at the incoming email account level will further help mitigate the issue because no-reply emails will be blocked.


最終更新日 2021 年 6 月 28 日

この内容はお役に立ちましたか?

はい
いいえ
この記事についてのフィードバックを送信する
Powered by Confluence and Scroll Viewport.