How to interrupt / override the ongoing routing?

OpenUI5 version: 1.98.0

Under some circumstance, I would like to forward a user from the view «A» to the view «C» instead of the view «B». I’ve tried so far:

1. attachRoutePatternMatched
2. attachBeforeRouteMatched
3. router.stop()
4. changing a hash via the HashChanger
5. sap.m.library.URLHelper.redirect(…)

attachRoutePatternMatched and attachBeforeRouteMatched work but I observe the undesired view «B» for a second and then I’m redirected to the view «C». router.stop() stops the navigation but then if I re-initialize it again within the same method, then I’m redirected the undesired view «B». Changing a hash via the HashChanger doesn’t help either. The only workaround that works for me is to use a hard redirect sap.m.library.URLHelper.redirect(…), that works correctly but I assume it leads to extra performance costs.

Is there any reliable and «friendly» approach to override /interrupt the ongoing routing, so user will not see the initially planned view but another one? I’m talking purely from the UX perspective, not the security-one.

Related topics:

• https://github.com/SAP/openui5/issues/3094
• How to override the routing and redirect to another view in UI5?

[flovogt]

Hi @pubmikeb , @jversignify points to a valid point. Overriding the HashChanger artefact would enable you to hook into the navigation process. But as @jversignify already points out, it is bad practice because the HashChanger artefact should not be changed by applications. We have discussed this requirement and thought about following future concept: You can attach your check function in the attachBeforeRouteMatched handler:

this.getOwnerComponent().getRouter().attachBeforeRouteMatched(this.checkAccess.bind(this));

checkAccess: function(oEvent) {
    if(!this.hasAccess()) {
       oEvent.preventDefault();
    }
   }

When the event is marked with preventDefault we would omit loading the target and the history would not contain the hash for this route. IMHO the downside of this solution is that the hasAccess method has to return synchronously the result. So, you can not perform any async backend calls here because the response of the backend call would come later than the navigation process. Whats your opinion on that?

[pubmikeb]

What’s your opinion on that?

I also thought about this scenario and assumed that there should be 2 checks:

• before the navigation, if a user tries to open a view from the side bar menu, here this approach can work out.
• a user tries to open a view, which he has no permissions to, directly, via URL in address bar, then a permission check should be implemented somewhere in onBeforeRendering.