🐛 Fix: 'cancel' button redirects to console instead of portal

[jbostoen]

Before:

1. Sign in to the portal, navigate to https://demo.combodo.com/simple/pages/exec.php/object/create/UserRequest?exec_module=itop-portal-base&exec_page=index.php&portal_id=itop-portal , press Cancel.
2. User with console permissions is redirected to the back end instead of staying in the portal.

After PR: user with console permissions should stay in the portal. Either a simple 'go back 1 page' is executed, or the user is redirected to the portal's home page.

[Molkobain]

window.history.length greater than 1 means no history? Seems counter intuitive. Isn't it equals 0?

[jbostoen]

Absolutely right, should have been == 1 (it's always at least 1 = current location)

[Molkobain]

I'm not sure hacking the URL through the regex is the best approach here. To me it's more like the this.options.base_url isn't set properly in the first place. It should be set with app['combodo.portal.base.absolute_url'] in datamodels/2.x/itop-portal-base/portal/templates/bricks/object/mode_create.html.twig

[Hipska]

True, also some customers might have different path e.g. set up.

For example they use another portal base or portal_id is not the third argument or the portal url is rewritten..

[jbostoen]

True, but I think it will be a minority? (Perhaps you guys have a better view on that).

It addresses the most common implementation. About the order of arguments: I could rewrite it like that, but I'm not sure if there's a different order somewhere in the native implementation?

[Hipska]

Anyway, is the RegEx needed? The filename (portal_form_handler.js) kind of suggests we are always in the portal?

[Molkobain]

I explained the fix as we would accept it in the first message :)

[jbostoen]

It definitely needs the portal ID parameter. The other parts I added to be more certain of where it was used and to re-use in the final URL

[jbostoen]

@Molkobain so I should just change this line to use app['combodo.portal.base.absolute_url'] instead in the create object Twig template?

base_url: "{{ app['combodo.absolute_url'] }}",

[Molkobain]

Yep :)

[jbostoen]

Alright, I updated the PR to be a mix of @Molkobain's suggestion and also just some basic 'go back' logic.

[Molkobain]

Thanks, that new behavior will need to be tested / validated. We'll see that during next functional review

[Hipska]

I'm wondering if this now also messes up when the form was created by going to the services browser. As if I do that, clicking cancel on the modal, the modal is closed. If I make the form open as a new page by right clicking on the link, It just closes the window by clicking on cancel (Safari & FF 102) So in this scenario, everything works as expected.

[Molkobain]

Accepted during technical review.

[Molkobain]

Discussed during functional review:

• Fix of the URL passed to the widget is accepted.
• Change on the JS to go back to the previous page if any history is available is rejected. I missed it during the technical review, but this is done in the "apply close rule" function which is meant to close the page/form. Any redirection "back" to the previous page should be handle by the "back" redirection rule and is out of scope of this PR.

So long story short, revert the changes on the JS file and the PR will be good to merge :)

[jbostoen]

Thanks for the feedback!

Well, it doesn't make sense the page would be "closed" at some point.

Image this scenario:

1. User opens the portal. ( https://demo.combodo.com/simple/pages/exec.php/?exec_module=itop-portal-base&exec_page=index.php&portal_id=itop-portal )
2. User gets redirected by an extension to the actual URL: https://demo.combodo.com/simple/pages/exec.php/object/create/UserRequest?exec_module=itop-portal-base&exec_page=index.php&portal_id=itop-portal (non-modal).
3. Window should not be closed, IMHO?

Isn't the current logic only based on the assumption that the above URL is shown in a modal dialog (while this could be much more versatile, I'm using it outside a modal)?