Great Skip, could you please provide a patch rather (against trunk would be better)?
https://cwiki.apache.org/confluence/display/OFBADMIN/OFBiz+Contributors+Best+Practices Thanks Jacques From: "Skip" <s...@thedevers.org> > Created a Jira at OFBIZ-5220 that includes a fix for the problem. > > -----Original Message----- > From: Jacques Le Roux [mailto:jacques.le.r...@les7arts.com] > Sent: Monday, June 10, 2013 3:01 PM > To: Jacques Le Roux; user@ofbiz.apache.org > Subject: Re: Upgrading to 12.04 send-redirect seems broken > > > Jacques Le Roux wrote: >> redirect-parameter was introduced by >> http://svn.apache.org/viewvc?view=revision&revision=741374 >> The comment about it there seems a bit distorded, I guess a wrong C/P. >> Anyway it basically does not say that all should not be used if none is > specified >> >> I'd also prefer to follow the xsd documentation: if none is specified then > "pick them all", make more sense than "any is used" >> But we should check this commit before changing it back if it's this > commit which changed it purposedly (could be also a side >> effect of another commit...) because it could be a diff between GET and > POST for security reasons (should not clearly specified >> in commit comment, but "sensitive information") > > (though not clearly specified in commit comment, but "sensitive > information") > > Jacques > >> HTH (and hope I'm clear, it's late here ;o) >> >> Jacques >> >> From: "Skip" <s...@thedevers.org> >>> After some further research into the code, it seems as if > request-redirect >>> now requires an optional redirect-parameter with the name of a field that >>> was in a form. >>> >>> In the past, you were not required to explicitly declare which parameters >>> from the form you wanted to pass on, it just passed them all on. >>> >>> I have something like 700 of these request-redirects to deal with. To > get >>> the required parameters, I need to find each of te 700 screens, open the > ftl >>> and make a redirect-parameter for each of them. That will take me a long >>> time. >>> >>> It will be much easier for me to put the code back the way it was, maybe > 15 >>> minutes vs 48 hours. Before I make that decision, I am wondering what > the >>> value is of not just including all the parameters like we use to? >>> >>> Thanks >>> Skip >>> >>> -----Original Message----- >>> From: Jacques Le Roux [mailto:jacques.le.r...@les7arts.com] >>> Sent: Saturday, June 08, 2013 5:35 AM >>> To: user@ofbiz.apache.org >>> Subject: Re: Upgrading to 12.04 send-redirect seems broken >>> >>> >>> From the XSD documentation it should continue to work the same, I did not >>> check code... >>> >>> <xs:enumeration value="request-redirect"> >>> <xs:annotation> >>> <xs:documentation> >>> Send a redirect down to the browser telling it to go to the > new >>> request. >>> Automatically redirect all current request parameters to the > new >>> request or only redirected parameters if specified. >>> </xs:documentation> >>> </xs:annotation> >>> </xs:enumeration> >>> <xs:enumeration value="request-redirect-noparam"> >>> <xs:annotation> >>> <xs:documentation> >>> Send a redirect down to the browser telling it to go to the > new >>> request. >>> No current request parameters are sent to the new request, nor >>> redirected parameters if specified. >>> </xs:documentation> >>> </xs:annotation> >>> </xs:enumeration> >>> >>> Jacques >>> >>> From: "Skip" <s...@thedevers.org> >>>> I have lots of send-redirect calls in my controllers to prevent users > from >>>> using the back button when that would cause problems. >>>> >>>> However, now, send-redirect does not pass the original parameters to the >>>> redirected call. No parameters are passed (or so it seems). Is there >>> some >>>> other method I can use to redirect with all the parameters from the >>> original >>>> call? >>>> >>>> For example, I have a screen which takes an billingAccountId as a >>> parameter. >>>> This screen accepts an amount to add to the billingAccount available >>>> balance. If the user can click back and submit again, double the amount >>> is >>>> added. To prevent this, I use request-redirect, but I need the >>>> billingAccountId for the subsequent screen. >>>> >>>> Skip >
