- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
‎05-03-2016 06:36 AM
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?
Solved! Go to Solution.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
‎05-03-2016 12:45 PM
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
‎09-25-2017 12:30 AM
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);
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
‎09-25-2017 08:16 AM
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
‎05-03-2016 09:25 AM
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.