Upgrading from opentaps 1.0 to opentaps 1.4

Data Changes

• Run the service opentaps.setSupplementalDataForAllParties to populate primary contact data for all parties.
• Configuration of GL accounts for invoice writeoffs have been changed. Instead of using GlAccountTypeDefault, they are now configured with InvoiceAdjustmentGlAccount with the adjustment type "WRITEOFF"
• If you have custom UI labels, they may be loaded by adding them to LabelConfiguration.properties in opentaps-common/config/
  • If previously you were using UtilMessage.registerLabelMap() to load custom labels, you may now remove all calls to this function as it is no longer needed.
• Run the upgrade SQL script in hot-deploy/opentaps-common/scripts/sql for the following:
  • ProductAverageCost has been re-factored to use a single productAverageCostId as its primary key. The script will alter the table and automatically fill in its values and update SequenceValueItem so that opentaps will generate correct future keys.
• Add the following to your custom component's build.xml:

  <fileset dir="${ofbiz.dir}/hot-deploy/opentaps-common/lib" includes="*.jar"/>
  <fileset dir="${ofbiz.dir}/hot-deploy/opentaps-common/lib/hibernate" includes="*.jar"/>

• Set SupplierProduct.supplierPrefOrderId to 10_MAIN_SUPPL where it is null.
• Run the following services to set summary fields:
  • recalcAllEmptyAmountsPayments
  • recalcAllEmptyAmountsInvoices
  • updatePostedAmountAcctgTrans

Coding Changes

Changes in the ofbiz framework would require the following changes to your code:

URL Parameter Security

You can no longer pass parameters to a service request directly in the URL. These requests must be part of a POST form. To make buttons work as before, you need to change them to forms and then activate them with javascript. For example, in earlier versions, you could have a button to delete a lead like this:

 <#assign update_options = update_options + "<a class='subMenuButtonDangerous' 
          href='deleteLead?leadPartyId=" + partySummary.partyId + "'>" + uiLabelMap.CommonDelete + "</a>"  />

In opentaps 1.4, you must do it this way:

  <form name="deleteLeadForm" method="post" action="<@ofbizUrl>deleteLead</@ofbizUrl>"/>
     <@inputHidden name="leadPartyId" value="${partySummary.partyId}"/>
  </form>
  <#assign update_options = update_options + "<a class='subMenuButtonDangerous' 
           href='javascript:document.deleteLeadForm.submit()'>" + uiLabelMap.CommonDelete + "</a>"  />

For your convenience, there is also a new macro to do this (see form and submitFormLink in opentapsFormMacro.ftl):

  <@form name="deleteLeadForm" url="deleteLead" leadPartyId=partySummary.partyId />
  <#assign update_options>${update_options}<@submitFormLink form="deleteLeadForm" text=uiLabelMap.CommonDelete class="subMenuButtonDangerous" /></#assign>

The form macro makes hidden inputs for all parameters (except name, url and method that are used to define the form element itself), and also accept nested elements for more complex cases.

For the cases where a form has to be used for multiple items, for example when you have an Update form block which must include multiple remove links, instead of writing a JavaScript handler which passes the item Ids to the form before submitting, you can do:

  <@form name="removeReturnItemAction" url="removeReturnItem" returnId=returnId returnItemSeqId="" />
  <@form name="updateReturnItemsAction" url="updateReturnItems" returnId=returnId>
    <#list returnItems as item>
     <@submitFormLinkConfirm form="removeReturnItemAction" text=uiLabelMap.CommonRemove returnItemSeqId=item.returnItemSeqId />
    </#list>
  </@form>

Also the new selectActionForm and actionForm can be used with form to define a drop-down menu where when an item (actionForm) is selected it submits the corresponding form:

  <@form name="deleteLeadForm" url="deleteLead" leadPartyId=partySummary.partyId />
  <@form ... />
  <@selectActionForm name="leadActions" prompt="${uiLabelMap.CommonSelectOne}">
    <@actionForm form="deleteLeadForm" text="${uiLabelMap.CommonDelete}"/>
    <@actionForm .../>
  <@selectAction/>

Service and HTML inputs

As a security feature, the services will filter any input with HTML by default. Some services still require HTML (like emails or templates services) and to allow that there is a new allow-html parameter. For example:

    <attribute name="content" type="String" mode="IN" optional="false" allow-html="safe"/>
    <override name="mergeFormText" allow-html="safe"/>

Form Widget Changes

Form widget URL parameters should be specified with parameter tag now, instead of in the URL:

-            <hyperlink description="${contactListName} (${contactListId})" target="viewContactList?contactListId=${contactListId}">
+            <hyperlink description="${contactListName} (${contactListId})" target="viewContactList">
+                <parameter param-name="contactListId" from-field="contactListId"/>
             </hyperlink>

Do not have it both in the URL and as a parameter, or the parameter will be on the form twice and be passed incorrectly.

Controller redirects

Redirects have been changed, now request-redirect will only copy the parameters that were in the URL string by default. To forward posted or service output parameter, use the redirect-parameter elements (one per parameter).

  <response name="success" type="request-redirect" value="viewAccount">
      <redirect-parameter name="partyId"/>
  </response>

Also request-redirect-filter-param is now considered deprecated.

Js dateTime format

Js dataTime format in ftl have been changed, now the format will return html encode string which will cause the parse exception, you should use StringUtil.wrapString to avoid this issue. For example, in earlier versions, you could have define a js dataTime format variable like this:

 <#assign dateFormat = Static["org.opentaps.common.util.UtilDate"].getJsDateTimeFormat(Static["org.opentaps.common.util.UtilDate"].getDateFormat(locale))/>

In opentaps 1.4, you must do it this way:

 <#assign dateFormat = StringUtil.wrapString(Static["org.opentaps.common.util.UtilDate"].getJsDateTimeFormat(Static["org.opentaps.common.util.UtilDate"].getDateFormat(locale)))/>

BSH embedded in Forms

In Forms widgets you could embed bsh code in order to have more flexibility over the formatting. Those embedded scripts need to be changed to groovy to avoid classpath issues. Fortunately this is as simple as changing the ${bsh: to ${groovy:

For example, in earlier versions, you could transform a party Id into the whole party name:

  <field name="partyId" title="${uiLabelMap.ProductSupplier}"> 
    <display description="${bsh:org.ofbiz.party.party.PartyHelper.getPartyName(delegator, partyId, false)} (${partyId})"/>
  </field>

In opentaps 1.4, you must change it to:

  <field name="partyId" title="${uiLabelMap.ProductSupplier}"> 
    <display description="${groovy:org.ofbiz.party.party.PartyHelper.getPartyName(delegator, partyId, false)} (${partyId})"/>
  </field>

UEL in Minilang

The ofbiz framework now supports unified express language (UEL) in the screen widgets and minilang simple methods. (See ofbiz wiki)

One side effect is that code in simple methods, for example:

 someHash.${someVariableAsKey}

In opentaps 1.4, you must change it to:

 someHash[someVariableAsKey]

HTML escaping

The ofbiz framework now automatically encodes most of the data displayed on the page. In some cases this is not wanted, and to avoid escaping in form widget use encode-output="false" in the field element:

   <field name="transactionDate" encode-output="false"><date-time/></field>

In the FTL templates use the StringUtil class:

   ${StringUtil.wrapString(someData)}

Some previous helper methods that constructed HTML code will not work anymore. For example PartyHelper.createViewPageLink has been replaced with the macro:

   <@displayPartyLink partyId=partyId />

Internationalization and Translations

In ofbiz09.04, translations are now in XML format instead of .properties. However, the old .properties translations are supported still as well.

Furthermore, it is possible to define a component with all your translations, instead of putting them into the various existing components. As an example, hot-deploy/translations in opentaps contains a full set of translations for opentaps to Bulgarian.

Other Changes

In some cases the screenlet-title-bar used in some ofbiz forms and screens is not wanted, in that case simply wrap the form or screen section in a noTitleBar div.

For example ViewShipmentRouteInfo.ftl defines such a title, to hide it we added to the screen definition:

     <container style="noTitleBar">
         <platform-specific>
             <html><html-template location="component://product/webapp/facility/shipment/ViewShipmentRouteInfo.ftl"/></html>
         </platform-specific>
     </container>