Uploaded image for project: 'Jira Service Management Cloud'
  1. Jira Service Management Cloud
  2. JSDCLOUD-9044

Allow JIRA service desk customer to view the issue via JIRA issue macro and team calendar

    • 38
    • 1
    • Our product teams collect and evaluate feedback from a number of different sources. To learn more about how we use customer feedback in the planning process, check out our new feature policy.

      Description

      If the user is a JIRA service desk customer which is not counted toward the JIRA license and trying to access a page that contains JIRA issue macro or team calendar in an integrated knowledge base, the user will not able to view the JIRA issue.

      This is because the JIRA issue macro and team calendar will check if the user is a valid JIRA license user and also check if the user has the browse project permission. The JIRA service desk customer only has the permission to access the portal and not the project.

      Suggestion

      Allow the JIRA service desk customer to view the JIRA ticket in confluence via JIRA issue macro and Team calendar.

          Form Name

            [JSDCLOUD-9044] Allow JIRA service desk customer to view the issue via JIRA issue macro and team calendar

            Happy New Year, everyone! May it be filled with joy, success, and - who knows - maybe even some miracles. Like Atlassian resolving to fix this bug. We can dream, right?

            Tobias Bosshard added a comment - Happy New Year, everyone! May it be filled with joy, success, and - who knows - maybe even some miracles. Like Atlassian resolving to fix this bug. We can dream, right?

            +1 Much needed

            Shaham Kampala added a comment - +1 Much needed

            +1

            +1

            Scott Ferguson added a comment - +1

            I want to allow unlicensed Portal Only Users to view some predefined Fields from Jira Issues within the Jira Confluence Marco on a Confluence Page which is accessed via JSM Customer Portal.

            I am sure this is a good frontend solution to communicate Progress to Customers / Users without giving wider Access to the related Jira Projects. This will help other Atlassian Users as well.

            To detail it out a bit more...

            What we want to achieve:

            • Serve our internal Software Users with a Knowledgebase called “User-Wiki”
            • The User-Wiki contains a lot of internal information on procedures of our Organisation, because this is the purpose of the Software: Support our Employees in many steps of their daily work, to make work more efficient.
            • The Software is – in the same way as the Work of our Employees – evolving continuously.
            • This makes it necessary, to communicate ongoing and planned improvements or known - and yet unsolved - Bugs.
            • We have this Information ready on hand because our Developers working in our Jira Site.
            • We want to show this to our Users right from our planning tool Jira by using Jira-Confluence-Macro within a Customer Portal.
            • With help of Labels, we will be able to show related Issues or Improvement right below the knowledgebase articles, which are explaining the related part of the Software. (i.e. There is an open Bug at a Statistic Dropdown for which there is a Workaround, shown below the explanation how to use this Dropdown.)

             What we expect from Customer Portal and Jira-Confluence-Macro:

            • Our Software Users do not have a License for Confluence or Jira hence they will.
            • We want to be able to give our “internal” customers the permission to see exactly the Information on Jira issues, which were configured in the Confluence Macro.
            • Issues included in the Marco will be in different Jira-Projects
            • Following Fields should be show in the Macro Lists View (Example):
              • Issue type
              • Issue key
              • Summary
              • Workaround / interim Instruction (Custom Field)
              • Issue Status
            • Customers should not be able to open the Issue directly within Jira, because they do not need to see all the details of our development work. 

            What we expect from the Atlassian Product Permissions (additional functionality):

            • We want to be able to give Customer Portal Users Permission to see (read only) some Project Details, but not all.
            • The Jira-Confluence-Macro seem to be a good frontend solution for this, because it could be configured individually for many contexts.
            • As Admin, I would prefer to grand a “View predefined Issue Fields” Permission on certain Jira-Projects instead of a Browse Project Permission.
            • As Admin, I want to define which Jira Fields of a Project will be unveiled to a user, when “View predefined Issue Fields” Permissions were granted for a Project. That will secure any secret Field Information to be included accidently by Creators of an Article.

            Jerome Arnoldi added a comment - I want to allow unlicensed Portal Only Users to view some predefined Fields from Jira Issues within the Jira Confluence Marco on a Confluence Page which is accessed via JSM Customer Portal. I am sure this is a good frontend solution to communicate Progress to Customers / Users without giving wider Access to the related Jira Projects. This will help other Atlassian Users as well. To detail it out a bit more... What we want to achieve: Serve our internal Software Users with a Knowledgebase called “User-Wiki” The User-Wiki contains a lot of internal information on procedures of our Organisation, because this is the purpose of the Software: Support our Employees in many steps of their daily work, to make work more efficient. The Software is – in the same way as the Work of our Employees – evolving continuously. This makes it necessary, to communicate ongoing and planned improvements or known - and yet unsolved - Bugs. We have this Information ready on hand because our Developers working in our Jira Site. We want to show this to our Users right from our planning tool Jira by using Jira-Confluence-Macro within a Customer Portal. With help of Labels, we will be able to show related Issues or Improvement right below the knowledgebase articles, which are explaining the related part of the Software. (i.e. There is an open Bug at a Statistic Dropdown for which there is a Workaround, shown below the explanation how to use this Dropdown.)   What we expect from Customer Portal and Jira-Confluence-Macro: Our Software Users do not have a License for Confluence or Jira hence they will. We want to be able to give our “internal” customers the permission to see exactly the Information on Jira issues, which were configured in the Confluence Macro. Issues included in the Marco will be in different Jira-Projects Following Fields should be show in the Macro Lists View (Example): Issue type Issue key Summary Workaround / interim Instruction (Custom Field) Issue Status Customers should not be able to open the Issue directly within Jira, because they do not need to see all the details of our development work.  What we expect from the Atlassian Product Permissions (additional functionality): We want to be able to give Customer Portal Users Permission to see (read only) some Project Details, but not all. The Jira-Confluence-Macro seem to be a good frontend solution for this, because it could be configured individually for many contexts. As Admin, I would prefer to grand a “View predefined Issue Fields” Permission on certain Jira-Projects instead of a Browse Project Permission. As Admin, I want to define which Jira Fields of a Project will be unveiled to a user, when “View predefined Issue Fields” Permissions were granted for a Project. That will secure any secret Field Information to be included accidently by Creators of an Article.

            No need to reiterate this, but here it goes - 

            Confluence and Jira are key Atlassian products, which for obvious reasons require a tight integration. If you have customers using both products (JSM and Confluence), it simply does not make sense to not be able to share reports via Confluence. Besides, the Jira Macro is already there - it just needs to be tweaked to identify portal vs. licensed users and still show results for portal users pointing to the portal version of the tickets.

            This is a fairly simple change that will go a long way with your customers (and their customers), Atlassian.

            Please prioritize this!

            Ricardo.Gomes added a comment - No need to reiterate this, but here it goes -  Confluence and Jira are key Atlassian products, which for obvious reasons require a tight integration. If you have customers using both products (JSM and Confluence), it simply does not make sense to not be able to share reports via Confluence. Besides, the Jira Macro is already there - it just needs to be tweaked to identify portal vs. licensed users and still show results for portal users pointing to the portal version of the tickets. This is a fairly simple change that will go a long way with your customers (and their customers), Atlassian. Please prioritize this!

            +1

            Ka Silveira added a comment - +1

            I am constantly dealing with customers who need to filter on the issues raised in their portal and export them to CSV/Excel. We use Jira Service Management to interact with our clients, with most clients having their own bespoke portal as the requests vary from client to client. Just about all our clients have requested this functionality. This is a big gap in Jira Service Management.

            Nicole Bowman added a comment - I am constantly dealing with customers who need to filter on the issues raised in their portal and export them to CSV/Excel. We use Jira Service Management to interact with our clients, with most clients having their own bespoke portal as the requests vary from client to client. Just about all our clients have requested this functionality. This is a big gap in Jira Service Management.

            Anthony Martin added a comment - - edited

            This is a really important functionality, I'm surprised there isn't far more support for this.  It resolves many other issues.

            This would allow us to put ticket data into Service Project KBAs allowing some semblance (albeit not a great one) of a Dashboard functionality for non-licensed Customers.  Customers, of course, require some level of reports to see statuses of issues across various Filters, of course  (e.g. Logistics Director needs to see a Filter of Logistics-related issues).  We should not need to get Agent licenses for everyone in our company to be able to see ticket data via a Filter - this is a little absurd (and no other ticket system I've ever heard of would require this).

            Granting Dashboards to Customers would be far better, of course (which is blocked by exactly the same thing).

            Customers require read-only visibility of Dashboards and Filters, including widgets/gadgets in Confluence.  I think any answer other than this is going to be a pretty big deal-breaker for any serious company interested in using JSM.

            Anthony Martin added a comment - - edited This is a really important functionality, I'm surprised there isn't far more support for this.  It resolves many other issues. This would allow us to put ticket data into Service Project KBAs allowing some semblance (albeit not a great one) of a Dashboard functionality for non-licensed Customers.  Customers, of course, require some level of reports to see statuses of issues across various Filters, of course  (e.g. Logistics Director needs to see a Filter of Logistics-related issues).  We should not need to get Agent licenses for everyone in our company to be able to see ticket data via a Filter - this is a little absurd (and no other ticket system I've ever heard of would require this). Granting Dashboards to Customers would be far better, of course (which is blocked by exactly the same thing). Customers require  read-only visibility of Dashboards and Filters, including widgets/gadgets in Confluence.  I think any answer other than this is going to be a pretty big deal-breaker for any serious company interested in using JSM.

              6cf75f652d57 Joseph
              lng@atlassian.com Lipkent Ng
              Votes:
              98 Vote for this issue
              Watchers:
              71 Start watching this issue

                Created:
                Updated: