Portal Request Permissions

[Alex Mihailoff]

I am building out a new user hire form. HR was testing it today and went the form was sent to the approver via an automation rule. They select or type out an email within the organization on the form. That person gets sent an email with a link to the request which, ideally, they would be able to see in order to complete the form and submit it for us to process. This is where the issue lies.

When that person clicks the link, they receive a message that they do not have permissions to view the request. This is extra strange because I had tested this and had not seen this issue before.

I have set a security scheme that I thought would allow all "Service Desk Customers" to view and edit the New User Onboarding request. That didn't work. It falls under a "Service Request" request type.

Where do I specifically go to address the permissions I need to make this work? Or is it not possible?

[Mathew Lederman]

@Alex Mihailoff typically tickets on the service desk portal are only visible by those who are involved in the request itself. The reporter, anybody who the request was shared with, approvers, and agents working the request. 

If you want all users to be able to see every request, it sounds like you want to utilize JSM Organizations and simply share every request with the organization. This would allow every user in the organization to see every request raised.

[Alex Mihailoff]

The field that the email is put into is linked to the Approvers group. Does that not make them an approver? Is there a permission I can check to ensure that's what is happening? Perhaps it isn't properly associating that person as an approver.

Opening up every request to be visible to everyone in the organization sounds like a blanket option that could create issues. It certainly is easier but it's significantly less secure. That being said, am I interpreting that incorrectly? What settings would I need to enable to make that possible but also not alert everyone in the organization that a request came in?

[Mathew Lederman]

Apologies, I misread your original question incorrectly. You're right, giving everyone access to everything is significantly less secure and it doesn't sound like that's your goal.

I believe the piece you're missing is in the workflow. JSM workflows have an Approver selection on each status where you can define a user/group custom field that should be given approval permissions. Putting your 'Approver' field in the workflow at the appropriate status should solve your issue.

To answer your first question, no adding a user to the 'Approver' field doesn't do anything by itself. You have to also define the Approver field in the workflow as the appropriate approver selection for that specific status.

[Alex Mihailoff]

Ok, all of that makes sense. Now let me throw the curveball.

This started as a workflow with an approval step. The way we're trying to make it work is one person fills out part of the form and creates the request. The hiring manager would then fill out the rest of the form and do the final submission which would then tell us in IT that everything was ready for us to begin configuration.

With the approval step enabled, what would happen is the hiring manager, who would be considered an Approver based on linked fields, would get the form and be able to submit just fine but then they would have to refresh the page and click Approve to progress the status. I removed the approval step by unchecking the box in the workflow which now has caused this issue.

Using the logic that a completed and submitted form means it is also approved, I'm trying to remove the need to both submit and approve.

Perhaps I could configure an automation rule that when the form is submitted, the request becomes "Approved" automatically and then moves to the next step. Could that be the way to go?

[Mathew Lederman]

Totally understand why you don't want the approval step.

It sounds like HR fills out the form and defines the hiring manager, request is created in a DRAFT status. Automation could add the hiring manager as a request participant and send them the form. Once the hiring manager completes the second form or remaining fields on the first, the request moves into an OPEN status. This would avoid the need for an 'Approved' step, and the only people with access would be HR and the hiring manager. 

The 'Keep this form open for edits' option on the form only allows 1 additional submission, so that should meet your goals if you want the hiring manager to complete/correct the data.

The 'Lock this form' option would allow the hiring manger to see the original, but only to make changes to their own secondary form.

[Alex Mihailoff]

Ok, how would I do that? I can link the Hiring Manager dropdown to the Request Participants field and then send an email to that group but wouldn't that include the originator?

I found the automation that would automatically approve the request. Could I just enable the approval step again which then would give the Hiring Manager permissions to see the request and submit the form but use the automation to approve it and move past the approval step automatically? That seems simpler.

[Mathew Lederman]

I haven't tested this exactly, but we do something similar and this should work:

Automation 1:

• Trigger on issue creation
  • Update Issue
    • Request Participants = Hiring Manager user picker field
  • Send Email to Hiring Manager user picker field

Automation 2:

• Trigger on form submitted (this is different than left in open for edits)
• Transition request to Open

[Alex Mihailoff]

Ah, I see what you did.

I do not have "Lock for edits" enabled so the ticket is created and the form is considered "Open" so this seems to work.

Here's what I did:

Automation 1:

• When issue is created
  • If "New Hire Form" attached
  • Status = Open
• Then send email to Approvers (linked field to the Hiring Manager dropdown)

Automation 2:

• When "New hire form" is submitted
  • If summary = default text
  • Change summary to specifics pulled from smart values
  • Then put request to "In Review"
  • Then Approve request
  • Then put request to "Work in Progress" - this might be redundant because I believe approving the request moves it to "Work in Progress" via the workflow but I'll figure that out later.

I won't be able to test the automatic approval part until next week but I think that should solve my problem. If it doesn't, I'll change the rules to what you suggested because I think that will work too.

Thanks for your help. I'll update next week with the results.

[Mathew Lederman]

Only thing you may be missing from Automation 1 is to add the Hiring Manager is added as a Request Participant; unless you're doing that on creation.

[Alex Mihailoff]

I believe you are correct. How do I do that? I can't seem to find the automation option to add that.

[Mathew Lederman]

This should give you a few options for how to add the appropriate participants:

https://confluence.atlassian.com/jirakb/how-to-add-update-remove-request-participants-using-automation-for-jira-1157468434.html