- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
02-03-2016 01:12 PM
Within our offboarding workflow there is a task related to a specific account type. I would like to restrict who can close this specifc task (by role or group membership)
Task short description always follows same pattern: date+XYZ account offboarding for+user i.e. 2015-11-25 XYZ account offboarding for Bouland, Andrew
There are two teams who need to participate in this task. The task auto-assigns to the first team who is supposed to do some work and then they are supposed to assign to the second team (XYZadmins) who will verify the first team did their job then will complete the work and mark the task closed.
I would like to create a restriction that will only allow members of the 2nd team to be able to mark the task closed_skipped, closed_incomplete, closed_complete
I have currently created an ACL that prohibits the first team from being able to change the state of the task AT ALL when task short description contains "XYZ account offboarding" but I'm curious if there isn't a way to do this in the workflow (haven't worked with approval or rollback activity yet) or with a business rule that would allow them to change state to anything other than one of our "closed" choices.
My current attempt via a Business Rule is as follows but doesn't seem to be working as intended:
Table: sc_task
Before Update/insert
Condition: current.state.changesTo(3) || current.state.changesTo(4) || current.state.changesTo(7)
script:
function userHasRole(userID, role) {
var uhrRec = new GlideRecord('sys_user_has_role');
uhrRec.addQuery('user', userID);
uhrRec.addQuery('role.name', role);
uhrRec.query();
return uhrRec.hasNext();
}
var shortdesc = current.short_description ;
if ((shortdesc.indexOf('XYZ account offboarding for') != -1))
{
var closedBy = current.closed_by;
if (!userHasRole(closedBy, 'GFRadmin'))
{
current.state.setError('Only ESops can close this task - please re-assign.');
current.setAbortAction(true);
}
}
Solved! Go to Solution.

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
02-03-2016 01:28 PM
Hi Andrew,
Two suggestions I can make:
1) this sounds more like a job for a client script (onChange, onSubmit) than for ACLs and Business Rules.
2) I'm not a fan of making an important distinction (i.e., the type of Task) by matching text in the subject... This could too easily get changed and break your code. I would suggest giving this type of task an exclusive category all to itself, and key off that.
Thanks,
-Brian
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
02-03-2016 10:48 PM
Hi Andrew,
You can make the "state" read-only all together(which will restrict everybody from closing the task). There is a UI action called "Close Task". Make this UI Action visible to only people belonging to the specific group or having a specific role. So the state will change to "Closed" only through the UI action. Ideally the state should be read-only (More like automating the process through action and not using manual changes).
Thanks,
Sneha.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
02-04-2016 12:08 PM
So, final solution is an onChange client script against the Catalog Task (sc_task) table, field name: State
function onChange(control, oldValue, newValue, isLoading, isTemplate) {
if (isLoading)
return;
// prohibit "Closed" states from everyone but XYZadmin
if (g_user.hasRole('XYZadmin'))
return;
//custom field on sc_task form Tag is populated in the workflow
if (g_form.getValue('u_tag') != 'XYZdisable')
return;
if (newValue == '3' || newValue == '4' || newValue == '7') {
alert('Only XYZ admins may close this task. No soup for you!');
g_form.setValue('state', oldValue);
}
}

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
02-04-2016 12:18 PM
The other benefit to using something client-side in this case is that if you used a BR and set it to abort the action, the user would loose any other changes they'd made to the record just because the change of state was being rejected.
-Brian