This can be removed, the same is done in renderLookupField macro in htmlFormMacroLibrary.ftl which is included above and called just below

git-svn-id: https://svn.apache.org/repos/asf/ofbiz/trunk@1562401 13f79535-47bb-0310-9956-ffa450edef68
Closes https://issues.apache.org/jira/browse/OFBIZ-5521 as not a problem
It was my bad, I was simply stupid on this, reverts r1519245


git-svn-id: https://svn.apache.org/repos/asf/ofbiz/trunk@1562767 13f79535-47bb-0310-9956-ffa450edef68
Workaround for "Lookups (layered mode) and dropdown menus overlap" (in BizznessTime Theme) https://issues.apache.org/jira/browse/OFBIZ-5519

A good example is in order creation page, open the customer lookup and then try to close it.

I think we should not fiddle with the theme, there is a faster and easier solution: center all lookups in the screen by default. It will not fix but hide the issue for now. Anyway the awful dropdown menu behaviour must be fixed and i will open another Jira for that.

You may ask why I'm concerned with a theme which is no longer bundled in future releases? It's because some custom projects still use it...


git-svn-id: https://svn.apache.org/repos/asf/ofbiz/trunk@1563238 13f79535-47bb-0310-9956-ffa450edef68
Put a warning about the version automatically downloaded by Ivy for activemq, postgres and mySQL jdbc drivers

git-svn-id: https://svn.apache.org/repos/asf/ofbiz/trunk@1563406 13f79535-47bb-0310-9956-ffa450edef68
A patch from Christian Carlow  for "Mandatory and dependent production run links don't navigate to corresponding production run page when clicked" https://issues.apache.org/jira/browse/OFBIZ-5502

When clicking the links associated with madatory or dependent production runs, the corresponding production run page is not loaded. This means its required to go back to the production run search page and lookup the productionRunId manually. I think the links should load the corresponding production run page when clicked.

This simple patch resolves the problem. The <hyperlink> elements in the form widget needed the "link-type" attribute set to "anchor" otherwise it defaults to creating a link that submits a form that automatically sets the productionRunId to the current production run workEffortId which causes this issue.

git-svn-id: https://svn.apache.org/repos/asf/ofbiz/trunk@1563683 13f79535-47bb-0310-9956-ffa450edef68
Updates jQuery to 1.11.0

git-svn-id: https://svn.apache.org/repos/asf/ofbiz/trunk@1563799 13f79535-47bb-0310-9956-ffa450edef68
When last updating jQuery I forgot to commit the calling points changes

git-svn-id: https://svn.apache.org/repos/asf/ofbiz/trunk@1563806 13f79535-47bb-0310-9956-ffa450edef68
I neglected to commit the patch from "Missing helptext regarding manufacturing rules" https://issues.apache.org/jira/browse/OFBIZ-5309


git-svn-id: https://svn.apache.org/repos/asf/ofbiz/trunk@1563807 13f79535-47bb-0310-9956-ffa450edef68
makes explicit required fields

git-svn-id: https://svn.apache.org/repos/asf/ofbiz/trunk@1563832 13f79535-47bb-0310-9956-ffa450edef68
Fixes a typo

git-svn-id: https://svn.apache.org/repos/asf/ofbiz/trunk@1563949 13f79535-47bb-0310-9956-ffa450edef68
No functional changes, just makes things easier to compare

git-svn-id: https://svn.apache.org/repos/asf/ofbiz/trunk@1563953 13f79535-47bb-0310-9956-ffa450edef68
Closes "Help screens in Manufacturing" https://issues.apache.org/jira/browse/OFBIZ-4802

This simply follows "HELP_OFBizDocumentationSystem.xml" i18n directives which have been overlooked so far. Of course having all i18n files in the same folder is not very convenient, but at least it works. This files organisation could be reconsidered, I'd need more work...

git-svn-id: https://svn.apache.org/repos/asf/ofbiz/trunk@1563958 13f79535-47bb-0310-9956-ffa450edef68
A (slightly modified) patch from  Ritu Raj Lakhera for "Order return is not refunding the money" https://issues.apache.org/jira/browse/OFBIZ-5528

When we placed an order with two items and generate a return towards one item then code is refunding the money correctly.
But if we again do return for second item then code is not refunding the money because first return-refund process has changed the status of OrderPaymentPreference from 'PAYMENT_SETTLED' to ‘PAYMENT_REFUNDED’.
I think We should create the new OrderPaymentPreference with PAYMENT_REFUNDED status against old OrderPaymentPreference of 'PAYMENT_SETTLED' status at the time of return-refund process. So second return can also refund the money.

In other words we should create the new OrderPaymentPreference for each refund amount as we are doing with Payment entity(processRefundResult PaymentGatewayServices.java).

jleroux: I 
* replaced the deprecated findByPrimaryKey by a finByOne
* replaced Exception GenericServiceException in catch (as it was before)
* reformatted some parts 

git-svn-id: https://svn.apache.org/repos/asf/ofbiz/trunk@1564111 13f79535-47bb-0310-9956-ffa450edef68
When I replaced the deprecated findByPrimaryKey by a finByOne I forgot to put a catch around, this fixes it.
Also removed an useless logError, ServiceUtil.returnError will take care of it

git-svn-id: https://svn.apache.org/repos/asf/ofbiz/trunk@1564113 13f79535-47bb-0310-9956-ffa450edef68
Merges trunk HEAD

git-svn-id: https://svn.apache.org/repos/asf/ofbiz/branches/webhelp-2012-12-07@1564402 13f79535-47bb-0310-9956-ffa450edef68