Seems like i can not associate projects to any customer out-of-the-box in Jira OnDemand. So, a customer can naturally have multiple projects, and I need to create swimlanes in Kanban and Scrum boards groupped by customers. Also user rights should be managed according to customer.
What is the best way to accomplish this? I found below link which says Project permissions can be granted based on e.g. group picker.
Should I create a custom customer-field with type "group picker (single group)", then create all customers as groups and finally somehow adjust Permission schemes according to value of the custom field?
Thank you in advance.
This feels like there's something missing from the background information because I can't quite work out what you're asking for.
When you say "associate a customer with a project" - could you explain what that actually means? Is a "customer" a user or set of users who need to be able to do certain things in a limited range of projects?
Thanks for the reply Nic, below some answers
3 users (A, B and C)
4 projects (1, 2, 3 and 4)
3 customers (X, Y and Z).
User A is supporting customer X, Y, and Z
User B is supporting customer X and Y
User C is supporting project Y and Z
Project 1 and 2 belongs to customer X
Project 3 belongs to customer Y
Project 4 belongs to customer Z
In this case, when opening Agile Board
User A should see tasks from projects 1, 2, 3 and 4 with customers X, Y and Z on swimlanes
User B should see tasks from project 1, 2 and 3 with customer X and Y on swimlanes
User C should see tasks from project 3 and 4 with customers Y and Z on swimlanes
Is this possible? Or is there any better way to give a project/task a customer information + associate support staff according to customer?
That does sound very much like you need a simple select list that says "this issue is from that customer" (Jira's custom field select lists mostly behave like "dropdowns", but I don't want to use that word because some don't)
So if you create a custom field for customer, give it the list of customers as options, and then add it to the screens so it appears for all issues, you're now capturing the right information.
That kind of solves points 1 and 2, and you can use it to help with point 3, although it's quite complex to explain, and you'll be able to do the swimlane stuff too.
However, your example implies that you might be separating projects up by customer, which leads me to think there's a more simple approach. Is it always the case that a project will belong to a single customer? Using your example, customer Y will never need to see projects 1, 2 and 4 because they belong to other customers?
Well the most important thing was to accomplish number 1 and 2, and I actually did that already how you suggested. It just seems that there is a lot of manual work and configuration, not only I need to fill values to customer select list but i have to keep swimlane JQL Query manually up to date as well. Since we have customer information also in another system, it's getting more and more difficult to manage our company's Master Data. Unless there is better automatic solution to accomplish swimlanes?
Project belongs always to one customer. One customer may have multiple projects. I just need to manage permissions of our external employees, who are not allowed to see all the customers.
I created Kanban board for Support Team. The board filter gathers tasks from all helpdesk projects and it's working ok with swimlanes. So now I need to create customer groups for each helpdesk project, wiill it filter tasks automatically if users do not have permissions to project? Or did you have another solution in mind?
That's where I was headed with the question about projects and customers. If you can use categories to represent customers then it all becomes a lot easier!
You will still have to create swimlane filters for each category/customer, but all the filters and boards can easily support "category =".
Your permission schemes become a lot more simple as well. You set up a permissions scheme to let people in by role (e.g. put your internal users into all the projects as developers, and then your customers only get added to the projects in their category)
If you use the scheme that way, you'll find the security works fine even on boards - a developer with access to all four projects will be able to see a board with all four projects included. But customer Y can look at the same board and will only see issues in project 3.
The only thing you'll need to unpick is the default security scheme which usually puts "jira users" into every project.
Badges are a great way to show off community activity, whether you’re a newbie or a Champion.Learn more
Planning and grooming sessions all come with their own sets of rules. Team members meet to estimate stories or other work items, all according to an agreed-upon process. And with every session comes ...
Connect with like-minded Atlassian users at free events near you!Find a group
Connect with like-minded Atlassian users at free events near you!
Unfortunately there are no AUG chapters near you at the moment.Start an AUG
You're one step closer to meeting fellow Atlassian users at your local meet up. Learn more about AUGs