Business rule on sys_attachment table not fully working when creating new incident in ESS

[kc99]

Hello,

I wonder if anyone can help with a problem I have.

We were asked to add details of any inserted or deleted attachments in to the activity log of the related incident.

So I found the business rule code below on the Community site - this will write an entry into the activity log on an insert into the 'sys_attachment' table - this is 'after insert' code - there is also a matching deletion business rule that runs separately.

NOTE: These business rules work fine in console when inserting/deleting attachments on an existing incident as an analyst using the paperclip icon in console.

However, if we test this for a customer using the ESS Portal (I should point out we have added functionality to enable attachments onto a record producer), then the code below isn't fully working and the second 'gs.log' display isn't reached - the if(gr.get(current.table_sys_id)){   statement does not return true - the first 'gs.log' is displayed ok.

I tried adding the 'gs.sleep' function into the code to see if it is a timing issue but this still doesn't work.

On checking the 'sys_attachment' table, the fields 'table_name' and 'table_sys_id' are populated with the correct table and incident sys id.

Can anyone suggest why this would fail at this point when run from the Portal?

Any help would be greatly appreciated.

Business Rule: Insert Attachment - Update Record

Table: sys_attachment

Condition: current.table_name == "incident"

When to run: After Insert

function onAfter(current, previous) {  

updateRecordForAttachment();  

function updateRecordForAttachment(){  

gs.sleep(10000);

var gr = new GlideRecord(current.table_name);  

gs.log('xxxxxxxxxxxxxxx Here');

    if(gr.get(current.table_sys_id)){  

    gs.log('zzzzzzzzzzzz Here');

          gr.work_notes = "Attachment: " + current.file_name + " has been attached.";  

          gr.update();  

    }  

}

}

[Brian Dailey1]

Hi Keiron,

The most likely cause is that ESS users do not have write access (nor read either) to the work_notes field that you are attempting to use.   The work_notes field is intended for internal (read as analyst/staff) use and is not supposed to be visible to the client.

I would suggest instead using the comments field to append your attachment details:

                  e.g.,         gr.comments = "Attachment: " + current.file_name + " has been attached.";  

The comments field works just like work_notes (is a Journal Entry field, can be tracked in the Activity for a task), but is usually accessible to the client who has no role (ESS users).

I would give that a try instead, rather than your other option of granting ESS users access to the work_notes field, which could cause you headaches down the road a bit.

Thanks,

-Brian

[kc99]

Hi Brian,

thanks very much for the quick reply.

I tried this but no luck I'm afraid - it doesn't appear to like if(gr.get(current.table_sys_id)){   as the second 'gs.log' is still not being displayed in the logs.

Once the record producer is submitted the ESS user can then access the created incident and successfully make attachments which display in the activity log so the ACL works from that point onwards.

So it appears that the above statement isn't being successful for some reason - do you think this may be an access issue?

Thanks again,

Keiron.

[Brian Dailey1]

Hi Keiron,

Look here at using the GlideRecord get() method:   GlideRecord - ServiceNow Wiki

If you are not using it on the actual 'sys_id' field, you'd have to call it like this:

        if(gr.get('table_sys_id', current.table_sys_id)){

Give that a try and see how it goes.

-Brian

[kc99]

Hi Brian,

thanks for getting back again - I'll take a better look at the GET statement and it's variations.

I'm probably going to have to step back and have a rethink about this one.

Part of the problem appears to be that we've recently implemented the functionality to add an attachment to an RP.

This means that, when they add an attachment to the RP then a (temporary?) incident is created in the background and the sys_id of this is written to the sys_attachment record (I may ask the customer if we can remove this functionality and only let them attach from the created incident).

Strangely, if we remove the 'if' statement from the above test and simply use gr.get(current.table_sys_id), then the business rule works and the work notes (or comments) display the relevant information BUT we receive a 'Duplicate key Violation' message when the created incident is displayed - I appreciate that these duplicate key errors are hard to debug when business rules are involved.

On top of this I've just been informed that we need to also log (in the activity log) any attachments added to emailed incidents - this is another kettle of fish and it could be that we need to also look at doing something like suggested here...

Attachment changes in Audit Log — ServiceNow ELITE.com

Either way this is turning out to be more work than I anticipated so I may need to look at this in between other jobs.

Many thanks again for taking the time out to reply,

thanks,

Keiron.