I'm configuring our new premium instance of JSM.
Our product development teams need to each have a separate project for their product, but we do need transparency and visibility across the 5 product dev. teams, as sometimes an issue can affect other products. If all 5 of these projects belong to the same product category can this provide that visibility that they can all see each other projects, or would I have to add all devs to all projects for that?
Many thanks
Cathy
Hi @Cathy,
Just to answer to your question first and foremost: project category does not impact access to projects in any way. It is mainly useful to:
To specify the last statement: you can search for issues in projects sharing a project category like this:
Category = "Product Development"
Rather than:
Project in ("Product A", "Product B", "Product C", "Product E")
and so on.
To manage permissions, you set this up separately for each project.
On a side note - if you are setting op Jira for product development, are you sure you want to set up JSM rather than Jira Software? That question does not have impact on your question about project categories and permissions, but it does in terms of functionality.
Thanks @Walter Buggenhout :)
OK, so is there a way that I can provide access for each of these projects to view each others service desk projects issues and comment internally to enable visibility and collaboration between these 5 projects, but still be able to keep them as individual team projects for the purpose of reporting and notifications?
We are considering next step JS for product change development, however JSM is good for us now for internal business and technical support. So these product dev teams are picking up incident & service request support from the business customers for their products.
Many thanks,
Cathy
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Yes, definitely.
You basically set up 5 different projects. In each project you grant access to your users in Project Settings / People by assigning them to the Service Desk Team role.
For more details, check out related documentation for your internal users and (for the sake of completeness) documentation on customer permissions
Hope this helps,
Walter
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Thanks @Walter Buggenhout
I think I am understanding that you are suggesting adding all devs to all projects that they need to be able to search and view issues, but to use project permission schemes to define permissions on what each agent can do within each project? Is that right?
Appreciate your help :)
Cathy
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Your JSM project already have a permission scheme where - by default - the permissions to collaborate internally are granted to the Service Desk Team role. Assigning your internal people to that role will grant them the permissions they need.
One caveat though - which is why I mentioned Jira Software. Your users need a license to collaborate. That may be a JSM license, which grants them agent permissions automatically as well. If you only purchased JSM, then that's what you'll have to work with. Or that may be a Jira Software license. Users with a JSW license that you add to the Service Desk Team role in a JSM project will have limited permissions (view tickets, comment internally mainly). That is the setup usually applied for developers.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Online forums and learning are now in one easy-to-use experience.
By continuing, you accept the updated Community Terms of Use and acknowledge the Privacy Policy. Your public name, photo, and achievements may be publicly visible and available in search engines.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.