• We collect Jira Service Desk feedback from various sources, and we evaluate what we've collected when planning our product roadmap. To understand how this piece of feedback will be reviewed, see our Implementation of New Features Policy.

      NOTE: This suggestion is for JIRA Service Desk Server. Using JIRA Service Desk Cloud? See the corresponding suggestion.

      Service Desk allows users to have KBs linked to Service Desks. However, the customers in the new billing model cannot be given permission to Confluence and will not be able to access the KB unless it is public.

      As a user, since this KB is directly connected to the Service Desk, I'd like to be able to have my customers access the KB, even though it is private. Either allowing them to access Confluence somehow, or only the KBs.

      Partial work around

      Where possible a 2-legged OAuth applink with a real Confluence user specified can be used to restrict access to Confluence while maintaining search functionality for Service Desk Customers. All searches will be made as the user specificed in the "Execute as" text box in the OAuth application link configuration. The application link cannot be use 2-legged OAuth impersonation as Service Desk Customers do not have Confluence user accounts.

            [JSDSERVER-916] Allow Service Desk customers access to private Service Desk KB's

            Katherine Yabut made changes -
            Workflow Original: JAC Suggestion Workflow [ 3012214 ] New: JAC Suggestion Workflow 3 [ 3649670 ]
            Status Original: RESOLVED [ 5 ] New: Closed [ 6 ]
            Owen made changes -
            Workflow Original: Confluence Workflow - Public Facing v4 [ 2665896 ] New: JAC Suggestion Workflow [ 3012214 ]
            Owen made changes -
            Workflow Original: JSD Suggestion Workflow - TEMP [ 2322071 ] New: Confluence Workflow - Public Facing v4 [ 2665896 ]
            Status Original: Closed [ 6 ] New: Resolved [ 5 ]
            Katherine Yabut made changes -
            Workflow Original: JSD Suggestion Workflow [ 2052070 ] New: JSD Suggestion Workflow - TEMP [ 2322071 ]
            Katherine Yabut made changes -
            Workflow Original: JSD Suggestion Workflow - TEMP [ 2047522 ] New: JSD Suggestion Workflow [ 2052070 ]
            Katherine Yabut made changes -
            Workflow Original: JSD Suggestion Workflow [ 1280475 ] New: JSD Suggestion Workflow - TEMP [ 2047522 ]
            jonah (Inactive) made changes -
            Description Original: Service Desk allows users to have KBs linked to Service Desks. However, the customers in the new billing model cannot be given permission to Confluence and will not be able to access the KB unless it is public.

            As a user, since this KB is directly connected to the Service Desk, I'd like to be able to have my customers access the KB, even though it is private. Either allowing them to access Confluence somehow, or only the KBs.

            h3. Partial work around
            Where possible a 2-legged OAuth applink with a real Confluence user specified can be used to restrict access to Confluence while maintaining search functionality for Service Desk Customers. All searches will be made as the user specificed in the "Execute as" text box in the OAuth application link configuration. The application link cannot be use 2-legged OAuth impersonation as Service Desk Customers do not have Confluence user accounts.
            New: {panel:bgColor=#e7f4fa}
              *NOTE:* This suggestion is for *JIRA Service Desk Server*. Using *JIRA Service Desk Cloud*? [See the corresponding suggestion|http://jira.atlassian.com/browse/JSDCLOUD-916].
              {panel}

            Service Desk allows users to have KBs linked to Service Desks. However, the customers in the new billing model cannot be given permission to Confluence and will not be able to access the KB unless it is public.

            As a user, since this KB is directly connected to the Service Desk, I'd like to be able to have my customers access the KB, even though it is private. Either allowing them to access Confluence somehow, or only the KBs.

            h3. Partial work around
            Where possible a 2-legged OAuth applink with a real Confluence user specified can be used to restrict access to Confluence while maintaining search functionality for Service Desk Customers. All searches will be made as the user specificed in the "Execute as" text box in the OAuth application link configuration. The application link cannot be use 2-legged OAuth impersonation as Service Desk Customers do not have Confluence user accounts.
            jonah (Inactive) made changes -
            Link New: This issue relates to JSDCLOUD-916 [ JSDCLOUD-916 ]
            Confluence Escalation Bot (Inactive) made changes -
            Labels Original: affects-cloud New: affects-cloud affects-server
            Confluence Escalation Bot (Inactive) made changes -
            Labels New: affects-cloud

              Unassigned Unassigned
              jsilveira Jaime S
              Votes:
              48 Vote for this issue
              Watchers:
              59 Start watching this issue

                Created:
                Updated:
                Resolved: