Business Rule not triggering on sys_attachment table when new cat item is submitted
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
‎02-09-2024 04:11 AM
Hi All
I am trying get a Business rule to execute when a new catalog item is submitted with an attachment, but it does work. The problem I am trying to solve is to restrict the viewing of any attachments on a RITM, if the catalog item has an attribute set to "true". The business rule is configured to look up the catalog item details associated to the RITM and then update a field on the sys_attachment table. If the checkbox on the catalog item is set to true, then the checkbox on the sys_attachment table should be true also.
When a new RITM with an attachment is submitted the attachment flag is not getting updated, however if you add any further attachments to the same RITM, the business rule executes as expected, so the problem isonly on the intial ticket creation.
Here is my Before INSERT & UPDATE BR on the sys_attachment table
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
‎02-09-2024 06:29 AM - edited ‎02-09-2024 06:31 AM
Hi @jonathangilbert ,
Reason for initial RITM creation with attachment not updating the field in sys_attachment
When the end user first add some attachment to the catalog item( before clicking on catalog submit button) ,your BR in sys_attachment will be triggering but the query will return 0 records as the the requested item is not submitted by the end user and it is not created in sc_req_item table..so the addQuery('sys_id',current.table_sys_id); will retrun 0 records.
And when the catalog item is submitted by the user, the BR in sys_attachment is not triggering since at that time no attachment is inserting in to sys_attachment table..already it got inserted when user add attachment using attachment icon.
In order to update the field in sys_attachment table when catalog item is submitted, you need to write a before insert BR in sc_req_item which will query the sys_attachment table and get all attachments for the current record and update the field.
You can refer below script:
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
‎02-09-2024 07:00 AM
Hi Jonathan,
If you look at the sys_attachment table right after you attach a file to a request form, before you submit the request, you'll see that the attachment is associated with the cart, not the RITM which doesn't yet exist
Then after the request is submitted, the same record is updated to the sc_req_item table and sys_id of the newly-created RITM
That's what appears in the sys_attachment table, but logging the BR shows that the attachment record is created with the sc_cart_item table, then it is updated to a different sc_cart_item sys_id for some reason. The BR logging is not detecting the next change to the sc_req_item table_name and table_sys_id which means that somewhere in the entire process of when an order is submitted - the REQ then RITM creation, workflow/flow trigger,... there's a scripted command to update any sys_attachment records, but that - wherever it's buried - also includes the command to not run other Business Rules when that happens. Because this is not exposed or buried, an alternate approach is needed. Keep this rule for the use case of adding attachments to an existing RITM, but you'll want to add a Filter Condition table name is sc_req_item and remove the user.update() line as you are not changing/updating the sc_req_item record in this case. Then create another BR after Insert on the sc_req_item table with a script to see if there is an attachment, then update it based on the RITM field:
(function executeRule(current, previous /*null when async*/) {
var attach = new GlideRecord('sys_attachment');
attach.addQuery('table_sys_id', current.sys_id);
attach.query();
while (attach.next()) {
attach.u_only_visible_to_people_services = current.cat_item.u_restrict_attachments_to_people_services;
attach.update();
}
})(current, previous);