I am new on JIRA and I've trying to create the dashboard for the operators to report their assembly line issues through it.
Is there anyway to set up the board for reporting system that required no log in? To prevent operators hit into log in issues I'd like to let them just open the link and type. That's it.
Any guideline on how to achieve that is greatly appreciated.
Thank you all.
Hi Joe Sun,
Welcome to the Atlassian Community!
To recap my understanding of your question, you are looking to allow users to view, create and potentially edit issues without having to login to Jira to do so.
If my understanding is correct, I believe what you would like to do is set up Anonymous Access for the projects the operators would need access to. This will provide non-authenticated users the equivalent access of a Jira Core user (as outlined within Jira Applications and Project Types Overview ).
Does anonymous access look like what you are looking to implement? If this isn't what you are looking for and I have misunderstood your question or if you have additional questions related to this please let me know and I would be more than happy to discuss further.
That sound right, the only thing I'd like will be restrict the anonymous user to only access to the particular Jira issue/board which he/she has the access link to.
i.e. no access to any other board/issues within organization.
If creating anonymous user can limit the access to such, can you please point me the direction on how to create such?
The access is set at the project level not at the issue level. So there isn't a way to grant anonymous access on a specific issue. It is only available for the permissions at the project level.
Anonymous access also doesn't include Agile Boards, as that requires the user to be authenticated within the software.
In terms of limiting the users access, since this is at the project level, anonymous users would only have access to projects that employ the permission scheme granting anonymous access. So they wouldn't have access to other projects that may restrict that permission.
I would recommend if you are going to be implementing any of these changes you try these in a test environment first to confirm the functionality is going to do what you are looking for prior to rolling out in a production environment.
There are a few key parts you will need:
1. The project itself for which you want to provide anonymous access.
2. The permission scheme to apply to the project that grants the anonymous access.
The permission scheme is where you would set the permissions you wish the anonymous users to have. This is done via Settings > Issues > Permission Schemes.
Then you would need to apply this permission scheme to the project itself via Settings > Projects > select the project > Project Settings > Permissions > Actions > Use a Different Scheme. Then apply the scheme you created.
You could also choose the Edit Permissions from the Actions menu and edit the current scheme. However I would suggest creating a new Permissions Scheme to ensure that there is no cross over with any other projects and this also creates a reusable scheme that you could apply to other projects in the event you needed to.
More detailed steps can be found within the Allowing Anonymous Access to Your Project knowledge base article.
My team is posting everything under same project as each sub-project being an issue.
Hence each "issue" = "project" in real world.
You already said posting anonymously cannot be under issue, but is there other level between "issue" and "Project"
Thank you so much for the help
Thanks for the clarification Joe! There isn't another level between an issue and project. Projects are made up of issues, and issues can have sub tasks. You do also have Epics you could potentially which can include issues which can in turn include sub tasks.
But from a permission perspective in terms of granting anonymous access, this is all done at the project level, not at the issue or Epic level. So if your organization is using issues and then sub tasks for the concept of a project and then just having one big project, it would be recommended to split out the projects. That way you could restrict which projects would have anonymous access and which ones would not.
Splitting out the projects could also enhance the user experience as it would allow grouping of specific issues more easily.
Connect with like-minded Atlassian users at free events near you!Find an event
Connect with like-minded Atlassian users at free events near you!
Unfortunately there are no Community Events near you at the moment.Host an event