kevinclark-7EL
Tera Contributor

Hi Team, 

I've posted this in a few threads talking about Service Portal redirects - I just wanted to share a custom app that I've built to solve a requirement that I had in my instance around Service Portal Redirection for multiple user groups/roles/whatever. 

The reason I developed this is because I had a requirement to introduce a number of different default portals with not only different branding depending on which Company the user worked for, but also to allow different user types to see different content based on Role or Group.

It will not only allow me to build Service Portal versions for different groups, but also allows me to do "dark launches" of new Service Portals for different user groups.

Here's the Service Portal Redirector App on Github:  https://github.com/milligna/sn-portal-redirector.git

And here the quick and dirty Wiki for how to use it: https://github.com/milligna/sn-portal-redirector/wiki/Welcome-to-my-ServiceNow-Portal-Redirector 

It basically replaces the SPEntryPage script and lets you create a series of redirect rules for different user attributes: Groups, Roles, Field values, and tells the Redirect Script whether or not to send the user to the Platform UI or to direct them to a specific Service Portal:

find_real_file.png

It's in testing in my environment now, but it seems to do the trick.  I thought I'd do it as a scoped app and see if it works for others. 

The only limitation is that Scoped Apps can't access some of the functions required by the SPEntryPage Script include, so you have to create your own version of SPEntryPage in the Global Scope to use it.  The sample Script Include in the Scoped app won't work while it's scoped, but if the content is copied out, then it will.

If anyone wants to try it out and provide feedback, that'd be awesome 🙂  Obviously be careful using it in your own company instances - I can't be held responsible for anything going wrong.

Cheers,

Kevin

Comments
kevinclark-7EL
Tera Contributor

Hi All, 

 

The app is currently in Production Verification Testing phase at the moment - I'm hunting some bugs with the RPPSPEntryPage script - in its current form it will fail to redirect to Portal every second attempt (when a user follows a link to ServiceNow from another page it will work the first time, then the next attempt will drop the user to the Nav_to page).

This appears to happen if the attempt has a nav_to value of welcome.do in the session - I'm not sure how it's getting there, but it's affecting the processing of the custom SPEntryPage.

 

I've got a temporary fix running by inserting an extra condition if the Matched Rule is a Portal, and by adding an additional if statement in the appropriate area as below:

 

		 // PRB726860: if page is still welcome.do, go to glide.login.home preserving frameset
			if (nt == "welcome.do" && returnedPortal.getRedirectType() == "platform_ui") {   // PRR: Inserted a condition to skip if the Redirect Rule is for Portal
				session.putProperty("nav_to", ep);
				gs.log('PRR USER: '+gs.getUserName()+' INJECTED GLIDE.LOGIN.HOME: '+ep);
				return;
			}
			// PRR Condition for Portal redirects
			if (nt == "welcome.do" && returnedPortal.getRedirectType() == "portal") {   // inserted to clear the nt value to allow redirect.
				nt = null;
				gs.log('PRR USER: '+gs.getUserName()+' Portal user Redirect - wipe nav_to for redirect cycle');
			}
			

 

I'll roll my enhancements back into the GIT version of the script eventually, but would welcome feedback if anyone wanted to have a look at it.

Cheers,

Kevin

 

 

kevinclark-7EL
Tera Contributor

Hi All,

I've committed some enhancements to the SPEntryPageSample script in the Git repository.  

First one makes  the Sample Script Include a little more explicit in how it should be used, and the second resolves a bug where a Portal redirect would only fire every second attempt due to users having a "welcome.do" nav_to value in their session data every second login attempt.  This should fire far more consistently now.

Kevin

 

Brian S5
Kilo Sage

Hey Kevin,

 

Trying to implement this in my DEV instance of Madrid to overcome the unsupported "more than 1 portal" limitations of SPEntry

 

When cloning my SPEntry (I called it the same thing you called yours) and turning off the default SPEntry SI, and changing the default login property to our portal landing page, changing the glide.entry properties and clearing the cache and logging out, it does not bring up the default landing portal. It brings up the out of box login widget. 

 

find_real_file.png

kevclark
Tera Contributor

Hi there!  I've moved organisations, so I didn't see this response at my old email address... Sorry about that!  Didn't mean to leave you hanging!

From memory I built a system property called "x_17973_conditiona.default_login_portal" which contains the URL suffix of the default portal (which is used to redirect for the first login attempt by the user).  It's set to /sp/ by default, so you can set it to whichever portal suffix URL you want, which should redirect the initial unauthenticated user login attempt to the login page for the relevant service portal.

Try that and let me know if you have any further issues.  I can't remember if I documented that properly or not - by the sounds of it my doco wasn't clear enough! 😞

 

Brian S5
Kilo Sage

Thanks for responding, very much appreciated. 

That guide was labeled pretty well in the documentation, and everything seems configured correctly as per the instructions. The glide.entry values correlate with what the global cloned SPentry page is named.

find_real_file.png

 

Seems like im getting a bunch of script errors when logging in though. Not sure where getDisplayValue in Object false is

 

org.mozilla.javascript.EcmaError: Cannot find function getDisplayValue in object false.
Caused by error in <refname> at line 1

==> 1: new PRRSPEntryPage().getLoginURL();

 

_____________________________________________________________________________

org.mozilla.javascript.EcmaError: Cannot find function getDisplayValue in object false.
Caused by error in sys_script_include.dadc976d4ffe130069b8c3818110c769.script at line 78

________________________________________________________________________________

org.mozilla.javascript.EcmaError: Cannot find function getDisplayValue in object false.
Caused by error in sys_script_include.c3729855db0fb3403e37d2e3ca9619b3.script at line 31

kevclark
Tera Contributor

Try dropping the ";" from the sysprops...  I feel like that breaks whatever calls spentrypage.

kevclark
Tera Contributor

@bshaw did this help?

AllanH
Kilo Contributor

Hello kevClark

Really nice solution here, i like the flexibility the rules give you. 

One question i have is i'm not sure if this will resolve one of my use cases. 

1. When a user logs into the fulfillment view redirect to the correct portal based on roles - achieved 120%

2. When a user attempts to navigate directly to a portal, redirect them to the portal they are assigned. - having troubles with this one. 

As far as I can tell, if a user navigates directly to a portal the pageEntry script isn't called thus this solution may not work for that. 

Do you have any experience or ideas on the second use case? could this be modified to support that use case?

 

Thanks,

Allan

Version history
Last update:
‎06-20-2018 09:47 PM
Updated by: