- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
02-26-2024 02:40 PM - edited 02-26-2024 02:42 PM
So its been a while since I did anything with workspace and now we are adding onto an old app and I'm going back to it. There are going to be lots of attachments so we setup the attachment viewer so people could look at them without the whole save local and open part. The users can add attachments and can download them and save them locally, but when they click to view them the overlay opens and they get the close button, but the attachment never loads. If someone with the admin role does this it opens fine. So it feels like a permissions issue but I have run out of things to check. This is for a scoped app.
Any help is appreciated.
Solved! Go to Solution.
- Labels:
-
Scoped App Development
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
02-26-2024 08:47 PM
I understand you're facing an issue with the attachment viewer in a scoped ServiceNow application, where users with non-admin roles can't view attachments while admins can. Here are some troubleshooting steps you can follow:
1. Verify Attachment Viewer Configuration:
- Ensure the attachment viewer is activated in your scoped application. Navigate to System Definition > Scoped App > [Your Scoped App] > UI Page. Find the attachment viewer page (e.g., cmdb_ci.do) and check the "Activate Attachment Viewer" checkbox if it's unchecked.
- Review the access control (ACL) settings for the attachment viewer page. Go to System Definition > Scoped App > [Your Scoped App] > Access Control. Ensure the desired roles (excluding admin) have at least "Read" access to the attachment viewer page.
2. Troubleshoot User Permissions:
- Double-check the user roles and permissions associated with the users unable to view attachments. They need read access to:
- The tables containing the records with attachments (e.g., cmdb_ci for configuration items).
- The specific fields storing the attachment information (e.g., sys_attachment).
- Any custom fields used for attachment storage.
- Consider data scoping rules: If data scoping is enabled, ensure users have the necessary read access to the specific records they're trying to view attachments for.
3. Address Table ACLs:
- If you've implemented table ACLs (Advanced Control List) on the tables containing attachments, verify they don't restrict access to the relevant fields or records.
4. Check for JavaScript Errors:
- Use browser developer tools to inspect the browser console while a user attempts to view an attachment. Look for any JavaScript errors that might be preventing the attachment from loading.
5. Consider GlideRecord Scoping:
- If you're using GlideRecord scripts to access attachments, ensure the script is running with the correct scoping. This might require using the getDisplayBusinessObject() method to obtain the attachment within the scoped app's context.
6. Test in a Non-Scoped Instance:
- If possible, temporarily deploy your scoped application to a non-scoped instance and see if the attachment viewer works correctly for non-admin users. This can help isolate if the issue is specific to scoped app behavior.
Additional Tips:
- Consult ServiceNow documentation for detailed information on attachment viewers, scoped apps, and permissions: https://docs.servicenow.com/
- If you're still encountering issues, consider raising a support ticket with ServiceNow for further assistance.
Remember that granting access needs to be balanced with security concerns. By following these steps and carefully evaluating permissions for users, tables, and the attachment viewer itself, you should be able to identify the root cause and resolve the issue for non-admin users to view attachments within your ServiceNow scoped app.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
yesterday
Old thread however just found this one to provide the answer:
Use Browser's developer tools and under Network Tab search Attachment in the Filter.
You will notice the 403 for attachment query, with request method as GET and request URL contains /api/now/attachment.
This is where you will understand that the Service Operations Workspace (SOW) Attachment viewer works differently than let's say Incident classic Native UI Attachment viewer.
Now, the next step is to find the culprit ACL (Table: sys_security_acl) Name = "Attachment API" or sys_id = "2901dd518733320025fbd1a936cb0be9" and the role associated with it under Requires role > Sys user role.
If you can grant this role to end users who are facing this issue, then it will be resolved however if you have SOW audience (a custom role created) than you can add that or any other role in this ACL as ACL will evaluate whether the end user has either of the roles.
Hope that helps!
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
yesterday
Interesting, thank you for the information. But we decided the Workspace attachment viewer was worthless until we could get an attachment to open in another window/tab. We have several teams that have to open the attached letter and enter information that is there into the record. So having an attachment open over the form you are trying to fill out is worthless.
We got around the issue by building a new one that opens the attachment automatically in a new tab/window using the platform attachment viewer.