Images appear "broken" on Service Portal Homepage for certain users. How can I correct this?

jordanmatlovsky
Kilo Contributor

When I am logged in as myself (many roles) and I go to the Service Portal, I am able to see some images that I have inserted into the widgets of the Service Portal home page. See belowfind_real_file.png

However, when I impersonate a user and go to the home page the images have a broken image icon. See blow:

find_real_file.png

This happens on multiple browsers, and has been noticed by users who directly sign in and also do not have any roles. How can I correct this so that everyone has access to the images? 

It should also be noted that we recently switched instances from a Development instance to a Production instance, but when I log in to the Development instance I see the same results. Please advise! Thank you!

5 REPLIES 5

Brian Lancaster
Tera Sage

I would check the ACLs on the sys_attachment table.  Seems like there blocking non-rolled users from access the images.

jordanmatlovsky
Kilo Contributor

Thanks for your help! Would you be able to briefly explain to me how I could access this? I went to System Definition Tables and then typed in sys_attachment and looked at the different read, write, delete, create records. I figured it would be in the read record, but I do not see any roles set here (even though I do see the space where the roles would be assigned). Thanks again for your help, I really appreciate it!

My instance which is using the OOB ACLs has two for read and neither of them has roles but they do have scripts.

 

answer = getAttachmentReadAnswer();

	function getAttachmentReadAnswer() {
		if (current.table_name.nil())
			return true;

		// If the attachment is from live feed,
		// grant it the read access
		if (current.table_name.indexOf("live_profile") > -1 || current.table_name.indexOf("live_group_profile") > -1)
			return true;

		// Remove Prefix
		var tableName = current.table_name;
		if (tableName.startsWith("invisible."))
			tableName = tableName.substring(10);
		else if (tableName.startsWith("ZZ_YY"))
			tableName = tableName.substring(5);

		var parentRecord = new GlideRecord(tableName);

		parentRecord.setWorkflow(false);
		if (!parentRecord.isValid() || !parentRecord.get(current.table_sys_id)) {
			if (current.sys_created_by.equals(gs.getUserName()))
				return true;
			return false;
		}

		return parentRecord.canRead();
	}

 

and the there has

answer = getSCAttachmentReadAnswer();

function getSCAttachmentReadAnswer() {
	if (current.table_name == 'sc_cart_item')
		return true;
	return false;
}

jordanmatlovsky
Kilo Contributor

Thanks for all your help. As it turns out, the issue was being caused by the extension bring placed on it via the IMG picker. I think the workaround is saving the image into ServiceNow and editing the html to reflect that extension. However I also did notice that when I went to attachments, these images were bring put into a table that wasn't quite right - it was a KB table that must have had some quirky permissions. When I changed them to a different image table they seemed to work, so your answer totally put me on the right path. Thanks again for all your help!