How can I connect permissions in page with JIRA?

[Tony Montana]

How can I connect permissions in page with JIRA?

What I mean:

• - We're have JIRA and Confluence Instances with Integrations Links between
• - Confluence for HR Database candidates
• - JIRA for HR Vacancies
• - Under JIRA Vacancy HR created sub-task with LINK on confluence page with HR Candidate

Question: How to make a person see only this page, and the neighboring ones do not?

I suggest several variants:

• 1 Open Confluence page look like iFrame
• 2 Confluence or JIRA can check permissions of page or fields.

But. How can I do that?

[Nic Brough -Adaptavist-]

Jira and Confluence are separate services with separate permissions.  Although most of us do use shared user and group directories, sharing permissions is done on each application separately.  It is not uncommon to see things like "member of group X can use project X in Jira and use space X in Confluence", but that is two separate settings.

Assuming that

• you are looking only at one space and one project initially (to keep it simple) 
• the group called "HR" can use the space and project
• the user directory is shared

then,

• In Confluence, use "page restrictions" to limit who can see a page you want to protect
• In Jira, use "issue security" to limit who can see issues

Each application will respect the security of the other too.  If a person is restricted from seeing "HR Sensitive page" in Confluence, then if there is a Jira issue that they can see that references it, Jira will not show them anything about the page, as they can't see it.

[Tony Montana]

Unfortunately, Confluence shows all child pages with a similar resolution from different requests in JIRA. For example, we have two Technical Experts who should see salary wishes only from the proposed employees. But Confluence will show absolutely all resumes.

[Nic Brough -Adaptavist-]

Yes, I know, this is a bit of a pain.

There are four factors here

• Jira and Confluence are separate.  Even if you've got the same user directories enabled and shared, and even when SSO is enabled.  They're separate systems.
• They have different permissions.  Jira has "project roles", Confluence does not.  Jira has 30-something things you might do, only some of which map to Confluence and the ability to embed even more, based on a whole range of things Confluence doesn't have, including roles and project roles and even custom fields. 
• You have to set up the equivalences you need every time.
• The data is often structured differently.

The third is probably the most difficult to solve and horribly frustrating.   Given your example, let's imagine someone called Bob has an account, there is a project with key XYZ and a space XYZ.  For the most simple case, we have to give Bob "browse project" in Jira and "use space" in Confluence.  To make that a bit more simple, we could put Bob in a group that has browse and use, and name that in the permission scheme/page, but it's not a lot better.

The fourth is not much better.  In your example, let's say we have two Technical Experts that you have in a group.  You give the group "browse project" and "use space".  So they now can see all the proposed employees in the space.  To fix that, you need to split your Confluence tree into two parts - "tech experts can see" and "they can't see", then restrict the second one.  Which has little or no relationship to a Jira project or even the Jira security scheme.

I'm going to say that this does give us huge flexibility.  But, you're absolutely right in that's it's a bloody nightmare in terms of access control.  (Sorry, those are my words, you did not say that, I'm projecting how I feel about it)

[Tony Montana]

Pain - it's nav admin menu in confluence. Why they can't build once style for all atl. products?

[Nic Brough -Adaptavist-]

Because they are different applications with different needs.  As I said before:

They have different permissions. Jira has "project roles", Confluence does not. Jira has 30-something things you might do, only some of which map to Confluence and the ability to embed even more, based on a whole range of things Confluence doesn't have, including roles and project roles and even custom fields.

You can't use the same menus for systems that are totally different.  That would be a bit like trying to use a car's steering system for your roller skates.  Different systems.