SPRedirectWithID not working
rob-windsor opened this issue · comments
I'm trying to redirect a user to the edit form after they submit an item in a new form. Here's the code I'm embedding into the new form:
<script src="https://cdnjs.cloudflare.com/ajax/libs/jquery/1.12.1/jquery.min.js"></script>
<script src="https://cdnjs.cloudflare.com/ajax/libs/jquery.SPServices/2014.02/jquery.SPServices.js"></script>
<script type="text/javascript">
(function () {
jQuery(function () {
$().SPServices.SPRedirectWithID({
redirectUrl: "EditForm.aspx",
qsParamName: "ID"
});
});
window.PreSaveAction = function () {
var aspnetForm = jQuery("#aspnetForm");
alert(aspnetForm.attr("action"));
return true;
}
})();
</script>
In SharePoint Online the alert in the PreSaveAction function shows that the action attribute in the form has been updated but I still get redirected to the list view after the save.
In SharePoint 2013 (with MDS disabled) the alert in the PreSaveAction function shows that the action attribute in the form has not been updated so, as expected, I get redirected to the list view after the save.
I think I'm using SPRedirectWithID as directed in the documentation.
This function was always a bit of a hack. Basically, the page refreshes until the script sees that the item has been created (there's a new item since the Save button was pushed), and then the aspnewForm action is changed to redirect to the the target with the newly discovered ID.
What you're seeing in your first screenshot is that interim state: the Source is set to the current page and RealSource holds the Source value SharePoint had set originally.
I haven't ever tested this on SharePoint Online, to be honest. In theory it should work in a "classic" list's NewForm, but it's possible something has changed to make it not work. Let me see if I can replicate.
OK, thanks. I just wanted to confirm that I wasn't using the API incorrectly.
I've reproduced, and it looks to me like the action attribute is ignored for some reason. It may be that they saw this as a vulnerability and plugged that hole. I'll do a little more debugging...
Yeah, from what I can see, action is now ignored, unless I'm missing something. The script to do the postback is more byzantine than ever, but I traced it pretty deep. All the right set up occurs when the NewForm loads, but the redirect I put into the action never happens.
Thanks for investigating this.
Sorry I don't have a better answer.
I want to help on this project.
is there any progress on this bug? I got the same problem that the redirection is not working at all
with this script i could change the redirection behaving but i don't have the ID of the record which is much more important
`$(document).ready(function () {
// for Save button
var button = $('input[accesskey="O"]');
button.removeAttr("onclick");
button.click(function() {
var elementName = $(this).attr("name");
var aspForm = $("form[id=aspnetForm]");
var oldPostbackUrl = aspForm.get(0).action;
var currentSourceValue = GetUrlKeyValue("Source", true, oldPostbackUrl);
var newPostbackUrl = oldPostbackUrl.replace(currentSourceValue, "https://departments.brueckner.com/shared/pro/NBD_BOPE/Lists/BOPE_interested_parties_contact/NewForm.aspx");
if (!PreSaveItem()) return false;
WebForm_DoPostBackWithOptions(new WebForm_PostBackOptions(elementName, "", true, "", newPostbackUrl, false, true));
});
});`
This function was always a bit of a hack, and I haven't tried to maintain it over the years. Obviously, the version of SharePoint matters, but patches to the versions may have rendered this unusable.
I get XHRPOSThttps://sharepoint.womicklawfirm.com/test3/_vti_bin/Lists.asmx
[HTTP/1.1 500 Internal Server Error 236ms] when I try to use SPRedirectWithID