Why do users with the Contributor role have access to everything in JPD?

Thank you for your quick reply!

It makes sense that users other than admins can add filters to views in addition to the view filters, but cannot remove filters added by the admin.
(Without this restriction, view-specific access rights would be meaningless – i.e., in the current situation.)

Another critical point is that even if a user does not have the right to remove view-specific filters or edit tasks, that user group should still be able to add, comment on, and vote on tasks in that specific view (=Contributor).

Those are currently the only blockers preventing us from using the Contributor role and thus taking full advantage of JPD.

Gotcha - we'll let you know when this ships! I just chatted with the team and it's not a big change. We'll prioritise it. 

That's great news! Thanks!

Update: the team started working on it this week!

Thank you very much for the information! I look forward to trying this out.

Hi! Any updates on this?

The rollout is going to start very soon - expect an article from @Olga Springer with the details

Hello @Jarmo Valli 

This change should already be available on your site. Please verify it in your instance and let me know if it solves your needs!

What changed:

Base filters on views are now locked for contributors, which means:

• Contributors will clearly see which filters are locked and won’t be able to change or remove them.

• They’ll still be able to add extra filters for their own temporary use, but those will reset when the view is refreshed.

More details:
📣 Coming Soon: Enhanced view restrictions with Locked Filters for Contributors

Best,

Olga Springer

Hi @Olga Springer & @Tanguy Crusson 

The solution you have implemented does not solve the problem itself, because users with the Contributor role can still see ALL tasks in the space through the Filters views.

Furthermore, your solution does not lock the filter for the "Type" field.

At the same time, I noticed that copying a view is also a dangerous operation, because it does not copy the view lock; instead, when copied, the restricted view becomes public to all users of the space.

In addition to the above, is there another way for a user with the contributor role to see ALL issues in Space?

Hi @Jarmo Valli , what do you mean by "the Contributor role can still see ALL tasks in the space through the Filters views"?

The way this feature works: 

• You create a view, you configure it. As part of that you define the filter. 
• Contributors can open that view and can see the ideas based on that filter
• they can only add more filters (not change the existing ones)

So to restrict access to data you'd need to do 2 things:

1. Configure the views you want to share with them
2. Use view restrictions (lock icon top right of the view) to decide which views they can open

What are you seeing for the "Type" field? this is what I see: 

@Tanguy Crusson @Olga Springer 

We didn’t achieve the outcome we were aiming for—namely, restricting contributor users' visibility to the JPD project’s ideas.

I’ll try again, using the attached screenshots, to explain why the view-specific restriction settings you’ve implemented have no use for us (or for anyone else with this same need, which, as far as I can know, is quite universal).

I’m not holding my breath on this matter, but I’d be happy if you could confirm that you’ve read and understood my message; if there’s already some hidden solution to this within JPD, I’d be very pleased to know that as well.

(Of course, if we can make this work, it will significantly change the value that JPD brings to our organization.)

@Jarmo Valli Okay, I see. In that case, I can think of one solution:

To achieve this you'll need to make your space private (space settings > access), only invite people you're working with closely in the space. For everyone else you'll need to publish a view.

This way no one but the people you specifically selected will be able to see all ideas - and the others will only be able to see the ideas you've published, with the fields you've selected, and only from the published view (not from the Jira search).

To publish a view: from the view > Share > Publish tab. 

Would that work? 

@Tanguy Crusson Thanks for the quick reply!

However, this isn't what we need, because publishing a view only grants view-only access to that view.

So we’re looking for “Contributor”-type access to only certain views—in other words, we need the Contributor role to have the ability to vote and comment.

(In an ideal solution, comments made by users with the Contributor role would be separate from those made by users with the Creator role—that is, users with the “Contributor” role would only see comments left by other Contributors, while users with the “Creator” role would see all comments and could choose, on a comment-by-comment basis, whether a comment left by a “Creator” should also be visible to “Contributors.” In other words, “internal” comments and “external” comments.)

Yep OK I get that. We're currently working on improving published views so stakeholders can participate better - send feedback, vote and comment (instead of just read-only). It looks like that's the solution you'd need vs what we support now.

OK, here are two relevant use cases that need to be addressed:

1. Sharing view ideas with limited data and view-only permissions, but including the ability to vote and comment (Contributors can only see their own comments). (e.g., contributor roles outside the organization)

=> Solution: via view publication

2. Sharing ideas in a view with extensive data (all/selected fields, read-only), including insights and attachments, but with the ability to vote and comment. (e.g., internal contributor roles within the organization)

=> Solutions: project access (Contributor) + view-specific restrictions on settings, such that view restrictions also apply to the “Filters” views in the left-hand menu.

Correct. For #2 we're not going to change the access model though (at least not in the medium term, it would be a massive undertaking to change the Jira permission model for that) - if you invite contributors to the space, they'll have access to all ideas in that space. You can limit what they see somewhat by making views private - but under the hood they have permissions to see all ideas in the space

OK. Is there any information on when the “Publish Views” feature might include any functionality related to voting and/or commenting?

We don't share release dates for features unless they're close to the finish line. What I can share is that we've wrapped up a bunch of technical spikes for how to solve this, they proved conclusive, and now we're in the middle of prototyping the target experience. So still a few months away.

Ok, thanks!