User tests: Successful: Unsuccessful:
This change adds the behavior of being able to use a return URL on the Cancel button. This feature already exists on the Save & Close button and makes sense to me to add it to the other functions as well.
This is not something users will use manually but programmers can use it to make sure users go back to where they came from. It adds consistency to the workflow.
We are going to assume you reached the article via Banners
&return=aW5kZXgucGhwP29wdGlvbj1jb21fYmFubmVycw==
behind the URLRepeat step 1 & 2
3. Click Cancel
4. You are now on the Article listing instead of the Banner listing despite providing a return URL
Apply Patch
&return=aW5kZXgucGhwP29wdGlvbj1jb21fYmFubmVycw==
behind the URLRepeat step 1 & 2
3. Click Cancel
4. You are now on the Banner listing as expected due to the provided return URL
After Cancel you end up where you started
You end up at the Article listing
None
Status | New | ⇒ | Pending |
Category | ⇒ | Libraries |
Labels |
Added:
?
?
|
Title |
|
@ggppdk Thank you for reviewing the code. You are correct, for Save & Close the change is not needed because the code is already in place there. I have updated the code and test instructions to reflect this.
also a little irrelevant but you would not verify it when just passing it, usually we would check it for being "internal" only before final usage ?
I am not sure what you are asking here. Are you talking about the isInternal check? That is just taken from how it is used in the Save action.
I am not sure what you are asking here. Are you talking about the isInternal check? That is just taken from how it is used in the Save action.
I meant (for the code that you have now removed) when appending the '&return' variable
'&return=' . $someurl
, no need to check that someurl is internal
$return_url = $this->getInput(...);
// No need check return_url is internal, just append it
// it will be checked when it is time to be used (redirecting to it)
$this->setRedirect($someurl . '&return = ' . $url);
Like you correctly check it in cancel,
because we have reached the point that it will be used (redirecting to it)
I have tested this item
Also i see that custom article controller for frontend
(and also some controllers of 3rd party components)
already support using return url for the cancel task
so this is change is consistent, all core and 3rd party components using the default controller should benefit for this
I have tested this item
Status | Pending | ⇒ | Ready to Commit |
RTC
Status | Ready to Commit | ⇒ | Fixed in Code Base |
Closed_Date | 0000-00-00 00:00:00 | ⇒ | 2018-05-12 18:40:35 |
Closed_By | ⇒ | mbabker | |
Labels |
Added:
?
|
Without testing
also a little irrelevant but you would not verify it when just passing it, usually we would check it for being "internal" only before final usage ?