Hi, I often hear from clients that they do not like the OOTB Info Messages getting shown on the CSM portal as soon as Customer Admin approves a registration request. This is definitely annoying and can be a cause for numerous Service Desk contacts.
There might be other situations where those messages are shown on the CSM portal.
I would like to show one of the possible solutions to this below. Not saying this is the best/only approach. But it does not modify any of the OOTB scripts so should be upgrade safe.
1. Note that the Messages are being generated by the OOTB "RoleManager" script include. We don't want to mess with that.
2. Note the above SI is being triggered based on Business Rules running on the sys_user_has_role and sys_group_has_role tables. Example:
You might want to repeat step 3 for multiple cases, depending on your requirements.
3. Note that when approving via CSM portal, we are only worried about roles being Inserted (not updated or deleted) since this is what happens for a newly registered user. In this case, we can create our own Business Rule:
- Scope: global (unfortunately the below method does not work for scope, but this should not be a big deal here).
- When: After
- Insert: checked
- Order: 900 (or whatever above the order of the OOTB Business Rule. The idea is that this one has to trigger after the OOTB one).
- Filter Conditions: User.Sys class name | is | Contact (we only want this to kick in for new Contacts being created)
- Role conditions: sn_customerservice.customer_admin (we only want this to kick in for the external Customer Admin)*
*you might want to include more roles, depending on your setup. - Conditions (scripted): !gs.hasRole('admin')
this is to ensure the regular Admin is not affected by our condition - Script: gs.flushMessages();
That's it! 🙂 As you can see, this is super simple. You don't have to modify OOTB SI or BRs.
Q: what to do if I only want this to work on Service Portal, not on the Back End?
A: Normally Customer Admins would not have access to back end anyway. Still, you can play around with the conditions, e.g. try and use the "gs.action.getGlideURI()" method to check for parts of URL to figure out if this is portal or back end. Not tested and not sure if this method still works.
Q: this hides ALL the messages! what if I want to still show a particular message?
A: Yeah that's a bummer. But you could add another after BR with a yet higher order including the info message(s) to be shown. Specify the conditiosn for that etc.
Note: As of Quebec release, I have not been able to find any OOTB handling for this issue. But if I have missed something or anyting new was added to control this behaviour, let me know in the comments 😉 It would definitely be nice to control this from e.g. portal widget options if possible. If you used a different approach, it would also be great to hear it 🙂
