Not able to export reports/lists.

sg28
Tera Contributor

A particular ITIL user is not able to export reports/lists. He is able to build, run and get the report until the dialog box that says Download.

Once clicked on download, the page turns white and redirecting to https://xxx.service-now.com/sys_attachment.do?sys_id=xxxxxxx6193a

Same is happening when trying to export any list. This is only happening with one particular user, user has ITIL role.

Any lead would be helpful

1 ACCEPTED SOLUTION

Eric Nichols
Kilo Guru

I have a single user with the same problem.  I believe the root cause is:

One of the Read ACLs on the sys_attachment table calls the "canRead" function in the "AttachmentSecurity" global script include ("global.AttachmentSecurity().canRead(current)" ).
The function says the user has read rights to download attachments if the created_by field matches the current user's User ID.

The max length of the sys_attachment.created_by field is 40.
My affected user's user ID is 42 characters long due to a hyphenated long last name, so the created_by field gets truncated.

Since the truncated created_by field doesn't match the user ID, she is denied the attachment download, and gets a blank white screen with no error message.

I will open a HI ticket and report back with their findings.

View solution in original post

9 REPLIES 9

sg28
Tera Contributor

I have impersonated with the user, and I'm not able to export anything from his profile. Tried to export from other alike profiles, end users, and its working as expected. Tried on both chrome and IE. But it doesnt seem like browser/cookie issue. ACLs, Roles are same in all cases. Export setting is set to default. And even I am not getting any error/warning logs. Its just redirecting to sys_attachment table (https://xxx.service-now.com/sys_attachment.do?sys_id=xxxxxxx6193a). From admin I could see the attachment is getting stored from the sys id.


Anything?



or just that report/list?



If you've tried it as well (as impersonating) then it's not the browser or packet sniffing or anything like that. All fine suggestions, but this is definitely isolated to SN and unfortunately, without screenshots, we can only speculate.



Unless there is some BR/ACL isolating this one specific user, there is really no way that this person can have the same roles and everything and everyone else can export, except them. Just doesn't make sense.



For testing purposes I'd almost say, make them an admin, temporarily, then do this again and see if it allows them....at that point you can isolate that it's a permission issue.



Please consider marking my reply as Helpful and/or Accept Solution, if applicable. Thanks!

It looks like you should focus on the ideas that Chuck has presented.  



Try this:


Turn on Debug of Business Rules


Impersonate the user


Try to export a list


Note which business rules run.


See if any of them have code to redirect the user.


If you're lucky, you'll find the culprit.



Finally, can you reproduce this in a "sub prod" instance?   If so,   you can work there and try a couple of things:


1. Change things about the user's profile to see if anything fixes it.


2. Change another user's profile to match the user with the problem and see if you can recreate the issue.


Eric Nichols
Kilo Guru

I have a single user with the same problem.  I believe the root cause is:

One of the Read ACLs on the sys_attachment table calls the "canRead" function in the "AttachmentSecurity" global script include ("global.AttachmentSecurity().canRead(current)" ).
The function says the user has read rights to download attachments if the created_by field matches the current user's User ID.

The max length of the sys_attachment.created_by field is 40.
My affected user's user ID is 42 characters long due to a hyphenated long last name, so the created_by field gets truncated.

Since the truncated created_by field doesn't match the user ID, she is denied the attachment download, and gets a blank white screen with no error message.

I will open a HI ticket and report back with their findings.

Eric Nichols
Kilo Guru

ServiceNow support provided a workaround in article KB0756802.  The ACL script is changed from an exact match to an indexOf function which checks the first 40 characters.