Restrict attachment deletion

kunal16
Tera Expert

I want to restrict the removal of attachment from a change request record. If the current logged in user is not Assigned to, OR not Requester, OR not a member of assignment group, THEN the same user should not be able to remove the attachments (using Manage attachment link on the change request form). How this can be achieved?

1 ACCEPTED SOLUTION

I haven't had a chance to debug but does something like this work:


// Check if change_request table


if (current.table_name == "change_request") {



  // Look up the particular change request so we can see the assigned to


var gr = new GlideRecord("change_request");



// current.table_sys_id gives us the sys_id of the change request record


gr.addQuery("sys_id",current.table_sys_id);


gr.query();


if (gr.next()) {


    // If the person assigned to the change is the user checking the permissions, return true


    if (gr.assigned_to == gs.getUserID()) {


        return true;


    }


    else {


        return false;


    }


  else {


      return false;


    }


}



You can toss in some gs.log's or something in there too to see where it is getting in the logic. But without testing it, I think the concept like above will work.


View solution in original post

12 REPLIES 12

Hello Trevor,



I have written the code suggested by you in business rule but current.table_name is giving sc_cat_item when i am clicking on 'manage attachments' under incident table



(function executeRule(current, previous /*null when async*/) {




gs.log("inside function");


gs.log("tablenameq" + current.table_name);


// Check if change_request table




  // Look up the particular change request so we can see the assigned to


var gr = new GlideRecord("u_business_support_desk");



// current.table_sys_id gives us the sys_id of the change request record


gr.addQuery("sys_id",current.table_sys_id);


gr.query();



if (gr.next()) {


gs.log("inside second if");


    // If the person assigned to the change is the user checking the permissions, return true


    if (gr.assigned_to.hasRole('bsd_funct_specialist')) {


  gs.log("inside third if");


        return false;


 


    }




    else {


        return true;


    }




}




})(current, previous);


What does current.table_sys_id give you?



current.table_name should be the name of the table and current.table_sys_id should be the record within that table. If you are receiving the wrong table_name and wrong table_sys_id it seems there is a bigger issue at play because both those are populated by out-of-box code from ServiceNow. Perhaps if you look at the record in question you will see what is going on that is unexpected.


The ACL works - but it's not the most user friendly solution. The "Remove" button will still be present/visable, and when the user goes to remove the attachment it will look like it works but not actually work. You could modify the attachment UI page to hide the remove button I guess for times when the user does not have the permissions if you wanted a more user-friendly solution.



We didn't go this route - sometimes we find that level of customization just does not have a great payoff. In the end people generally know if they should or should not be doing something, and if someone thinks they should be able to delete attachments they are prohibited from doing then I would rather they talk to us about it when it doesn't work than coding some workaround that tampers with the functionality of the out-of-box page and might break on future upgrades.