Hi there - I'm the owner of my company's long-standing Atlassian environment. There is an SM project within this environment that has a user portal set up, but has historically had users fill their tickets on the back-end of Jira. This has worked for a long time and no real changes have been made to their fields or permission schemes.
However recently users attempting to fill the form on the back end have been getting a permissions error in regards to the Due Date field:
Field 'duedate' cannot be set. It is not on the appropriate screen, or unknown.
After some looking, I figured that this must be an issue with the Schedule Issues permission and have attempted to amend it in a few ways to no avail. Attempting to grant this permission to the role Service Desk Customers yields an error stating that the permission cannot be granted to that group. Attempting to grant this permission to our Users role results in an error that JSM overrides the permission. I even tried "any logged in user", but again, overridden. Users have zero issues logging through the portal, as the "Service Project Customer - Portal Access" permission group works.
As a workaround, I can use another date field that users fill that then clones into the duedate field via automation afterward, but would rather know if there is some way to address this for the team using the project first.
Did something change regarding scheduling issues in JSM recently? Am I overlooking something?
According to this article (and this one and this one), the schedule permission is the culprit.. Customers seemed to have previously been able to use this field just fine in Jira, but due to the strange way this project was set up in the past, there were a few erroneously licensed agents that may have been the ones logging the tickets, and thus the issue with the permissions was hidden until a license clean-up recently.
We will re-educate our customers on using the portal for this project.
Hi @Sara Innes
Welcome to the community.
No changes are made on this topic in Jira SM to my knowledge.
Is the field due date still on the create screen of the issue the users want to create?
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.
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.
Hi @Sara Innes
To use the Due Date on the Request Type, when filling the from from the backend the field needs to be on the request form.
This has no relation with the Schedule issue permission. this is due to the fact the users in the role Service Desk Customer never had the option to schedule issues, this is only for agents in a JSM project.
Also the screenshot you are showing on the Due Date is a behaviour action defined in a Scriptrunner behaviour.
This is probably the culprit in your instance.
Also what create screen is used on the jsm project, related to the form, request type this form is in and the issue type related to this request type.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Thanks - There are no Scriptrunner behaviours tied to this project.
According to this article (and this one and this one), the schedule permission is the culprit.. Customers seemed to have previously been able to use this field just fine in Jira, but due to the strange way this project was set up in the past, there were a few erroneously licensed agents that may have been the ones logging the tickets, and thus the issue with the permissions was hidden until a license clean-up recently.
We will re-educate our customers on using the portal for this project.
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.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.