Can the Idea in the Product Discovery GA version become parent links to Epics in Jira? Can the Product Discovery Idea (in GA version) be used for tracking progress of Epics/stories/tasks (across hierarchy) in Advanced Roadmaps and Dashboards?
@hroy it's unlikely that we will see that anytime soon. That would be a fundamental change to the information architecture in Jira and a hard change to make technically.
I'd like to pass on some questions about Stakeholder Access to shape how much can use it with our customers:
Is there any thoughts to exposing the Idea submission forms on JSM portals, potentially for portal only users?
For stakeholders who are granted access to view a JPD view:
For the ideas displayed, can we ensure they can only see the fields configured in the view, as some of the fields may have sensitive/proprietary information
From the mocked up Stakeholder view shared (attached), it seems stakeholders won't be able to change the filters. Can we assume that we can hide ideas from stakeholders via the configured filters?
Will we be able to limit the ability for stakeholders to see other stakeholder feedback without attribution (i.e. With Jira Software Cloud, you can allow voting without users seeing who voted). With my company, we're not allowed, contractually, to disclose the names of our customers with our other customers.
Is Atlassian planning on limiting the types of views (i.e., Lists, boards, matrixes, and timelines) which can be shared with Stakeholders
For the ideas displayed, can we ensure they can only see the fields configured in the view, as some of the fields may have sensitive/proprietary information
Yes
From the mocked up Stakeholder view shared (attached), it seems stakeholders won't be able to change the filters. Can we assume that we can hide ideas from stakeholders via the configured filters?
That is correct
Will we be able to limit the ability for stakeholders to see other stakeholder feedback without attribution (i.e. With Jira Software Cloud, you can allow voting without users seeing who voted). With my company, we're not allowed, contractually, to disclose the names of our customers with our other customers.
Eventually yes, but not at first. You can decide to turn off the commenting or voting features as long as it's not there, or create different views/fields for different customers (it depends on your context)
Is Atlassian planning on limiting the types of views (i.e., Lists, boards, matrixes, and timelines) which can be shared with Stakeholders
Rising Stars are recognized for providing high-quality answers to other users. Rising Stars receive a certificate of achievement and are on the path to becoming Community Leaders.
From what I am seeing, a Site Admin will need to be set up as a Creator to manage users (and their role) for a JPD project...even if they do not plan to administer the project or to create ideas. Correct?
The alternative is we delegate user management and role setting to the JPD project admins. Which means they can directly impact the licensing costs for a instance. This seems different than license cost management for the other products.
Site admins can configure project settings, which includes managing access and turning on the idea creation feature for stakeholders. I've actually tested this yesterday and that worked.
Rising Stars are recognized for providing high-quality answers to other users. Rising Stars receive a certificate of achievement and are on the path to becoming Community Leaders.
@Tanguy Crusson ...yes, I know it seems I asked this question earlier :^)
And now that I can see the actual changes it seemed unclear due to this in the role selection:
Where it seems the project admins, "Administrator" in this new role model, can add and change roles of users, and so impact licensing costs.
And...there is also a puzzling "system-administrators" user listed, which is neither a user nor a role/group in the instance. This one has been showing errors until we stripped away all permissions except Contributor. Without knowing its purpose we are reluctant to remove it from JPD.
Honestly...I was hoping the role selection would be located with all other user management, at a site admin function level, and so reduce the chance of errors in licensing impacts.
Add-on access to JPD project issues/ideas, particularly with Project access and licensing.
For example we use the 'Backbone Issue Sync For Cloud' add-on to address two use cases where 1 might get replaced by JPD:
Providing clients a "public" view and vote only copy of our product backlog project (now being moved to JPD)
Creating issues in our product backlog and syncing support requests in our JSM project
We'd want to have add-ons have the ability to view, create, and update Ideas
Presently, it doesn't seem like there's a way to look-up the system ~user accounts that are automatically created by some add-ons but I don't know if they are being treated like the 'atlassian-addons-project-access' is used in Jira Software projects.
I've been sorta able to get Backbone Issue Sync to work with our JPD project but either there's some issues or some sort of rate limiting where the add-on doesn't detect Idea updates for an hour or so after they occur.
Atlassian Team members are employees working across the company in a wide variety of roles.
May 8, 2023 edited
@Bill Sheboy it all depends on what features the site administrator has turned on.
If the site administrator made it so users can invite other users to the site (approved domains, user invites, etc.) then project administrators can indeed invite users to the site and give them product access, and so as per your definition "impact licensing costs".
If not, then the only thing that project administrators can do is add people to the project who are already in the site, and with correct product access.
Rising Stars are recognized for providing high-quality answers to other users. Rising Stars receive a certificate of achievement and are on the path to becoming Community Leaders.
Let me try a different way to explain the concern...
Jira site admins and org admins can add, enable/disable user access for products, such as JPD. This is the normal method to manage product access, and thus licensing costs.
Jira project admins can administer project settings, such as field/feature changes and user access to the project
JPD has roles of Creator (which will cost additional fees), Contributor (which is currently included in Jira license costs), and Administrator (which is a superset of Creator and project admin functions)
Often people in Creator roles need to make adjustments to fields and views, and so they are also selected as project admins with the JPD role of Administrator.
This means JPD project Administrators can impact licensing costs if they change Contributors to/from Creators. I just confirmed this behavior for a user who is a Creator and Administrator, and who is not a site admin.
The work-around seems to be: do not have Creators also be Administrators, and instead have others manage role assignments in JPD projects and any field changes needed for projects. It is the bundling of the role change and project features which I was noting.
Atlassian Team members are employees working across the company in a wide variety of roles.
May 9, 2023 edited
@Bill Sheboy I hear you, but this is only possible if the person who is a creator also has the ability to give people product access - which is what site administrators can do, or they can allow other users to do that via approved domains, user invites in admin.atlassian.com:
What project admins can do is give users "Creator" project role, even if they don't have a license. But, even in that case, it does not grant a license unless the user is able to do so (site admin, or these settings I just shared), it shows a warning.
Hi @Tanguy Crusson would it be possible to have a counter on items moving along the workflow?
This would help with transparency towards Stakeholders & Contributors.
It could be used as a reporting tool on a monthly basis for example, where we can show the success of Product discovery and the Product team.
Also, search functionality on People would be a great addition, so if i would like to review Ideas with a particular contributor, i can just show all ideas and search for their name. currently I have to be sure that every idea is correctly labeled in terms of Contributor reporter or similar, and group the whole view by that category.
Great update, although after watching I'm still not sure how we share the roadmap publicly? We can't switch from productboard unless it's a public share of the roadmap
Edit: My mistake, I misread your question. You're right, the solution we're building now is not a public roadmap, it's a way to share views with specific groups of people (but not a fully public portal where anyone can come in, see all roadmaps, etc.). We'll keep you updated if and when we move there.
Hi there, I apologize if this was answered already but I haven't seen it specifically amongst the comments.
I'm a site admin for our company and I added JPD to our Atlassian site today so that I and our project co-ordinator could try it out and see if it was a good fit. Immediately, the administration panel showed that we have three users for JPD: myself and our two org admins.
Neither of our org admins will be trying out JPD because it has nothing to do with their professional roles. I can't remove their access to JPD because they're org admins, and now it appears that the project co-ordinator can't try out JPD without triggering paid licenses for all four users, because all three of the free user spots are filled.
Any advice on how to manage product access so that we can test out JPD?
Rising Stars are recognized for providing high-quality answers to other users. Rising Stars receive a certificate of achievement and are on the path to becoming Community Leaders.
If you look at this how-to article, it includes how to remove all admins from JPD license use in Step 3. You may then optionally add individual admins using group management later, as needed.
79 comments