I am testing a new application and users are getting a 403 Access Denied Error when interacting with task links from email, but are otherwise able to access the task via tempo or the application's site. The users are already logged in.
Any idea what is causing this?
Discussion posts and replies are publicly visible
What is the source of the emailed task links? Is it a link that's being manually constructed, or one of the ones that Appian sends automatically? Can you post the plaintext URL that the email is sending, alongside the plaintext URL that a user gets if they successfully open the same task from within the Appian site? My strongest guess here is that something in the URL is malformed, though that's relying on a few assumptions.
They are the ones sent out by Appian automatically. The linked URL path in the email is /suite/sites/page/task/536880381?source=notif while the one from Tempo is /suite/tempo/tasks/task/536880381 and from sites is /suite/sites/shipment-tracking/task/536880381.
Whenever I've had "403 - Access Denied" it's always been down to security or user permission issues. Have you tried testing this with a system administrator account and seeing if the issue still persists?
That is what I suspected at first as well, but users being able to access the task via Tempo/sites, but not task emails is not something that I've seen before.
I tested it with a system admin account and do not have any issues.
Based on the URL, it looks like the specific site "shipment-tracking" is not being included in the link. If you added that portion to your sample URL (ex: ../suite/sites/shipment-trackin/...?source=notif" does the 403 go away?
Are user start pages set up correctly in the Admin Console for this new application? I'm wondering if the default start page isn't accessible to these users so the link generation isn't working correctly. My best guess anyways.
Ref: https://docs.appian.com/suite/help/19.4/Sites.html#task-notifications
The fact it works with a system admin account but not with basic users reinforces to me it might be down to security, but like you said it seems odd that they can access it via other methods. Justin's suggestion below seems plausible, based on the documentation they linked.
Edit: Have you checked the tomcat-stdOut logs (inside System Logs) around the time when the user got the error? It might shed some light on the issue.
Hi Kyle,
Was this resolved?