When in my product board's Backlog view, I have noticed that my team members can edit fields or perform actions on an issue directly without opening up the issues details view (including Epics and "Close") that I cannot. How can I configure the options that appear on the ". . ." button to allow me to add things like "Epic" and "Close" the way other team members do?
snapshot.PNG
The options on the list are mostly controlled by the project permissions. If you want to log work on an issue for example, you have to have "work log" permission. Check the permission scheme for the project(s)
All project permissions are exactly the same (we have one default) and I have access to everything but Developer tools in project & issue permissions, so I'm not sure that is the cause.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Permissions are the only thing that control the items on that list. It doesn't matter that you only have one scheme, what matters is what it says - do you match the rule that says "can log work" for example?
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
It does matter in that my colleague + I are both JIRA admins with the same permissions, and we both tested against the same project, and she was able to assign epics or close tickets directly on the backlog. Also, the Permissions section does not have any permissions available for tracking Epics or closing issues specifically, so I'm not sure how you would change those permissions to enable those actions if permissions are what's driving that view.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
No, I'm sorry, I'm not explaining this very well.
You need to look at the permission scheme. That controls what you can do, but not by "having the same permissions", it's by a set of roles in the permission scheme. Permissions don't usually get given to users directly (it is an option, but one most people avoid).
The permission scheme will say something like "assign issue to people: role (developer)". If that is the case, you will find that your colleague is in the role of developer in that project, but you are not. You may have other rules such as "only the assignee can do this", or "users and dave-from-accounts can do this". But you have to read the permission scheme directly.
Again, the permissions are the only thing that control these options in the menu.
There is a second set of stuff to look at for transitions, such as "close", but let's get the permissions side settled before we look at that. Pick something your colleague can do and you can not, go to the project and look at the permission to do that one thing. What is the rule, and do you match it?
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.