Workspace Attachment Viewer only works for Admins???

DrewW
Mega Sage
Mega Sage

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.

 

 

1 ACCEPTED SOLUTION

Umesh Dubal
Giga Expert

 

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.

View solution in original post

3 REPLIES 3

Umesh Dubal
Giga Expert

 

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.

DrewW
Mega Sage
Mega Sage

Thanks for the post.

Your first one I do not have that module and when I go to the Scoped App record via a different way I do not have anything you mention.  I also think for Workspace the attachment viewer is a component which I could not find so it does not seam to have an obvious name.

Most of the other stuff I already checked but you did give me a few things I had not thought of yet.  Thank you.

 

DrewW
Mega Sage
Mega Sage

Ok, so anyone who finds this later this is what I discovered.

The ServiceNow UI's, (Platform, Workspace) apparently do not check ACL's in the same way that other tables are checked.  I made the mistake of thinking it was not a security issue on the attachment table because the users could see the attachments and download them but could not open them in the attachment viewer.  What I eventually found was that one of our contractors/partners added a field level ACL to the sys_attachment table, so only CSM users could read the fields in the table.  But everyone could still see attachments and there names.  There where no other field level ACL's on the attachment table.  After disablaling this one ACL the attchment view started to work for everyone. 

 

So how ever ACL's are evaluated for the sys_attachment table the system appears to not care about the field level ACL's until you try and use the attachment viewer to look at it.  So if you have access to the table/row you can see the attachment on the record and can download it even when you do not have access to the fields.  I would be interested to know if anyone else has seen this same behavior of if we have something else making this work oddly.