Re: Renaming some ant tasks to improve consistency
On 3 April 2012 00:59, Jacopo Cappellato jacopo.cappell...@hotwaxmedia.comwrote: ... For now I didn't change the name of the ant.sh/ant.bat scripts to ofbiz.sh/ofbiz.bat but I would like to consider it soon. +1 Will reduce the number of people having problems because they are using the wrong version of ant (e.g. ant instead of ./ant) Thanks, Jacopo On Mar 30, 2012, at 11:49 AM, Jacques Le Roux wrote: +1 Jacques From: Pierre Smits pierre.sm...@gmail.com +1 Op 30 maart 2012 09:02 schreef Jacopo Cappellato jacopo.cappell...@hotwaxmedia.com het volgende: another nice thing we could do, merely esthetic, is to rename ant.sh/ant.bat to ofbiz.sh/ofbiz.bat. Then the commands will be like: ofbiz load-demo ofbiz run-tests ofbiz start ofbiz stop etc... Jacopo On Mar 29, 2012, at 5:34 PM, Jacopo Cappellato wrote: Ok, I have completed my work on this; however instead of running the new tasks from the old task I have preferred to print a message to inform the user about the new syntax; it seems to me that this is an easier transition because at some point we will remove. I also renamed a couple more tasks and refactored one to replace 2 more; I have also cleaned and improved the style of the descriptions. Since these changes ended up being more than what I initially proposed in this thread, I will wait before committing my work to the trunk and I have instead created a Jira ticket where I have described all the changes I did and attached the patch: https://issues.apache.org/jira/browse/OFBIZ-4771 Please review my work and let me know if you see issues in it; I would like to commit it in a few days. Regards, Jacopo PS: for your reference, here is the new output of the ant -p command: build-website For committers : Update dtds from OFBiz instance to site clean-all Clean all DB, Catalina and caches data, logs, and runtime subdirectories and all specific files like .rej, .orig clean-cache Clean the UtilCache file if errors found with old objects in the cache (Java runtime error something like 'local class incompatible') clean-catalinaClean Catalina data in runtime/catalina/work clean-dataClean all DB data (Derby) under runtime/data clean-downloads Clean all downloaded files clean-logsClean all logs in runtime/logs clean-lucene-indexRemove lucene indexes created in applications/content/index clean-output Clean runtime/output directory clean-tempfiles Remove files located in runtime/tempfiles (captcha, etc...) clean-xtraClean all other files like .rej, .orig, etc. cobertura-report Generate a HTML code coverage report with cobertura, can be found in runtime/logs/cobertura-report cobertura-report-xml Generate a XML file from the cobertura report, this will be use by sonar copy-dtds For committers : Copy all dtds from OFBiz instance to website create-admin-user-login Prompt for a user name, then create a user login with admin privileges and a temporary password equal to 'ofbiz'. After a successful login the user will be prompted for a new password. create-component Create the layout of an OFBiz component in the hot-deploy folder. create-tenant Create a new tenant in your environment, create the delegator, load initial data with admin-user and password (needs multitenant=Y in general.properties) docs-all For committers : Build all javadoc into one tree for easier viewing by the community download-PG-JDBC Download postgres jdbc driver download-selenium Download the selenium server v1.0.3 20.8 MB download load-admin-user-login Create a user login with admin privileges and a temporary password equal to 'ofbiz'; after a successful login the user will be prompted for a new password.[...] load-all-tenants Load data for all tenants, syntax eg: ant load-all-tenants (needs multitenant=Y in general.properties) load-demo Load all data; meant for generic OFBiz development, testing, demonstration, etc purposes load-demo-multitenant Load all data needed for the multi-tenancy demonstration. Caution: this creates three databases, with each one loaded with all demo data. load-extseed Load seed, seed-initial and ext data; meant for manual/generic testing, development, or going into production with a derived system based on stock OFBiz where the ext data basically replaces the demo data load-exttest
Re: Building OFBiz with Jenkins
Pierre I think this sort of question should be on the users list, so I'm copying it there. You might get more suggestions that way. Maybe you don't have paths set properly somewhere. Perhaps looking at OFBiz's ant script (ant.bat under windows) will give you some ideas. As an example, our Jenkins uses execute shell, with bash -ex ./ant auto-run-tests The auto-run-tests target is one I created. It applies our custom patches and does a few other housekeeping tasks before running the unit tests with cobertura. HTH Cheers, Anne. On 2 April 2012 21:42, Pierre Smits pierre.sm...@gmail.com wrote: Thanks Anne, For the heads up. Hadn't realized that the default ant wasn't the good one. I reconfigured my Jenkins job to point to the ant with OFBiz in the project directory of the Jenkins workspace, as shown below var/lib/tomcat6/webapps/jenkins/workspace/OFBIZ-Trunk/trunk/ant (pointing the ant script in OFBiz) but when running it after the re-configuration I got the message that the build file couldn't be found. Regards, Pierre Op 2 april 2012 01:56 schreef Anne a...@cohsoft.com.au het volgende: Are you sure Jenkins is running the right ant? That is, the one that comes with OFBiz, and not one installed separately? Cheers, Anne. On 31 March 2012 22:08, Pierre Smits pierre.sm...@gmail.com wrote: Hi all, I am trying to build OFBiz through Jenkings, but get following message: Started by user Pierre Smits http://sandbox.somonar.prd:8080/jenkins/user/Pierre%20Smits Updating http://svn.apache.org/repos/asf/ofbiz/trunk U framework/base/src/org/ofbiz/base/util/test/ObjectTypeTests.java U framework/base/src/org/ofbiz/base/util/ObjectType.java At revision 1307764 [trunk] $ ant build Buildfile: build.xml BUILD FAILED/var/lib/tomcat6/webapps/jenkins/workspace/OFBIZ-Trunk/trunk/build.xml:25: The following error occurred while executing this line: /var/lib/tomcat6/webapps/jenkins/workspace/OFBIZ-Trunk/trunk/macros.xml:26: No supported regular expression matcher found: java.lang.ClassNotFoundException: org.apache.tools.ant.util.regexp.Jdk14RegexpRegexp Total time: 0 seconds Build step 'Invoke Ant' marked build as failure Does the error sound familiar? And how can I resolve this? Regards, Pierre -- Coherent Software Australia Pty Ltd PO Box 2773 Cheltenham Vic 3192 Phone: (03) 9585 6788 Fax: (03) 9585 1086 Web: http://www.cohsoft.com.au/ Email: sa...@cohsoft.com.au Bonsai ERP, the all-inclusive ERP system http://www.bonsaierp.com.au/ -- Coherent Software Australia Pty Ltd PO Box 2773 Cheltenham Vic 3192 Phone: (03) 9585 6788 Fax: (03) 9585 1086 Web: http://www.cohsoft.com.au/ Email: sa...@cohsoft.com.au Bonsai ERP, the all-inclusive ERP system http://www.bonsaierp.com.au/
Re: Building OFBiz with Jenkins
Are you sure Jenkins is running the right ant? That is, the one that comes with OFBiz, and not one installed separately? Cheers, Anne. On 31 March 2012 22:08, Pierre Smits pierre.sm...@gmail.com wrote: Hi all, I am trying to build OFBiz through Jenkings, but get following message: Started by user Pierre Smits http://sandbox.somonar.prd:8080/jenkins/user/Pierre%20Smits Updating http://svn.apache.org/repos/asf/ofbiz/trunk U framework/base/src/org/ofbiz/base/util/test/ObjectTypeTests.java U framework/base/src/org/ofbiz/base/util/ObjectType.java At revision 1307764 [trunk] $ ant build Buildfile: build.xml BUILD FAILED/var/lib/tomcat6/webapps/jenkins/workspace/OFBIZ-Trunk/trunk/build.xml:25: The following error occurred while executing this line: /var/lib/tomcat6/webapps/jenkins/workspace/OFBIZ-Trunk/trunk/macros.xml:26: No supported regular expression matcher found: java.lang.ClassNotFoundException: org.apache.tools.ant.util.regexp.Jdk14RegexpRegexp Total time: 0 seconds Build step 'Invoke Ant' marked build as failure Does the error sound familiar? And how can I resolve this? Regards, Pierre -- Coherent Software Australia Pty Ltd PO Box 2773 Cheltenham Vic 3192 Phone: (03) 9585 6788 Fax: (03) 9585 1086 Web: http://www.cohsoft.com.au/ Email: sa...@cohsoft.com.au Bonsai ERP, the all-inclusive ERP system http://www.bonsaierp.com.au/
[jira] [Commented] (OFBIZ-4723) Support validation of resource xml files
[
https://issues.apache.org/jira/browse/OFBIZ-4723?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13238257#comment-13238257
]
Anne Jessel commented on OFBIZ-4723:
According to viewvc, UtilProperties.java has not been changed in 13 months.
Which means this patch has not been applied successfully. Can anyone see why
this part of the patch is not ending up in svn? Is the file locked or read-only
or something?
Index: framework/base/src/org/ofbiz/base/util/UtilProperties.java
===
--- framework/base/src/org/ofbiz/base/util/UtilProperties.java (revision
1304746)
+++ framework/base/src/org/ofbiz/base/util/UtilProperties.java (working copy)
@@ -964,8 +964,14 @@
throw new IllegalArgumentException(locale cannot be null);
}
String localeString = locale.toString();
+String correctedLocaleString = localeString.replace('_','-');
for (Element property : propertyList) {
-Element value = UtilXml.firstChildElement(property, value,
xml:lang, localeString);
+// Support old way of specifying xml:lang value.
+// Old way: en_AU, new way: en-AU
+Element value = UtilXml.firstChildElement(property, value,
xml:lang, correctedLocaleString);
+if( value == null ) {
+value = UtilXml.firstChildElement(property, value,
xml:lang, localeString);
+}
if (value != null) {
if (properties == null) {
properties = new Properties();
@@ -1053,7 +1059,9 @@
bundle = new UtilResourceBundle(bundle.properties,
locale, parentBundle);
}
double totalTime = System.currentTimeMillis() - startTime;
-Debug.logInfo(ResourceBundle + resource + ( + locale
+ ) created in + totalTime/1000.0 + s with + numProperties +
properties, module);
+if (Debug.infoOn()) {
+Debug.logInfo(ResourceBundle + resource + ( +
locale + ) created in + totalTime/1000.0 + s with + numProperties +
properties, module);
+}
bundleCache.put(resourceName, bundle);
}
}
Support validation of resource xml files
Key: OFBIZ-4723
URL: https://issues.apache.org/jira/browse/OFBIZ-4723
Project: OFBiz
Issue Type: Improvement
Components: framework
Affects Versions: SVN trunk
Environment: REV 1297286
Reporter: Anne Jessel
Assignee: Jacques Le Roux
Priority: Minor
Fix For: SVN trunk
Attachments: OFBIZ-4723_both.patch, OFBIZ-4723_code_cleanups.patch,
OFBIZ-4723_combined.patch, OFBIZ-4723_support-validation-resource-xml.patch
The xsd for the resource xml files is invalid. In addition, the format of the
value of the xml:lang attribute in resource xml files is invalid, according
to the xml standard.
The attached patch:
* provides a valid xsd
* updates UtilProperties and the Label Manager to deal with the correct
formatting of the xml:lang value, while still working with the old format,
following Adrian Crum's recommendation on the mailing list
* includes simple unit tests for UtilProperties to ensure it does work with
both formats
* changes the Label Manager to include a reference to the new xsd, and to use
the correct format of the xml:lang value, when writing a resource xml file.
This problem exists in released versions, but I doubt it is important enough
to back port.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (OFBIZ-4723) Support validation of resource xml files
[ https://issues.apache.org/jira/browse/OFBIZ-4723?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anne Jessel updated OFBIZ-4723: --- Attachment: OFBIZ-4723_UtilProperties_only.patch This patch has ONLY the changes to UtilProperties.java. Perhaps a patch that changes only this file will reveal why the other patches silently failed. Support validation of resource xml files Key: OFBIZ-4723 URL: https://issues.apache.org/jira/browse/OFBIZ-4723 Project: OFBiz Issue Type: Improvement Components: framework Affects Versions: SVN trunk Environment: REV 1297286 Reporter: Anne Jessel Assignee: Jacques Le Roux Priority: Minor Fix For: SVN trunk Attachments: OFBIZ-4723_UtilProperties_only.patch, OFBIZ-4723_both.patch, OFBIZ-4723_code_cleanups.patch, OFBIZ-4723_combined.patch, OFBIZ-4723_support-validation-resource-xml.patch The xsd for the resource xml files is invalid. In addition, the format of the value of the xml:lang attribute in resource xml files is invalid, according to the xml standard. The attached patch: * provides a valid xsd * updates UtilProperties and the Label Manager to deal with the correct formatting of the xml:lang value, while still working with the old format, following Adrian Crum's recommendation on the mailing list * includes simple unit tests for UtilProperties to ensure it does work with both formats * changes the Label Manager to include a reference to the new xsd, and to use the correct format of the xml:lang value, when writing a resource xml file. This problem exists in released versions, but I doubt it is important enough to back port. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (OFBIZ-4723) Support validation of resource xml files
[ https://issues.apache.org/jira/browse/OFBIZ-4723?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13238943#comment-13238943 ] Anne Jessel commented on OFBIZ-4723: Thank you Jacques. Support validation of resource xml files Key: OFBIZ-4723 URL: https://issues.apache.org/jira/browse/OFBIZ-4723 Project: OFBiz Issue Type: Improvement Components: framework Affects Versions: SVN trunk Environment: REV 1297286 Reporter: Anne Jessel Assignee: Jacques Le Roux Priority: Minor Fix For: SVN trunk Attachments: OFBIZ-4723_UtilProperties_only.patch, OFBIZ-4723_both.patch, OFBIZ-4723_code_cleanups.patch, OFBIZ-4723_combined.patch, OFBIZ-4723_support-validation-resource-xml.patch The xsd for the resource xml files is invalid. In addition, the format of the value of the xml:lang attribute in resource xml files is invalid, according to the xml standard. The attached patch: * provides a valid xsd * updates UtilProperties and the Label Manager to deal with the correct formatting of the xml:lang value, while still working with the old format, following Adrian Crum's recommendation on the mailing list * includes simple unit tests for UtilProperties to ensure it does work with both formats * changes the Label Manager to include a reference to the new xsd, and to use the correct format of the xml:lang value, when writing a resource xml file. This problem exists in released versions, but I doubt it is important enough to back port. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: Lose Weight Program for OFBiz - Birt and BI
Just for the record, we disable the birt container. I don't like loading things I know aren't being used. Cheers, Anne. On 23 March 2012 22:33, Mansour Al Akeel mansour.alak...@gmail.com wrote: in the config for base: base/config/ofbiz-containers.xml:!-- load the BIRT container -- base/config/ofbiz-containers.xml:container name=birt-container class=org.ofbiz.birt.container.BirtContainer/ This is what loads Birt. Not sure if there's something else needed to load it. Can this be temporary used until OSGI is introduced. OSGI makes it easy to load and unload any component. So (if done properly), no integration in the framework should be done. In this case Birt component should contain the logic to load its self when deployed into OSGI container. So those who needs it can just install it with one command. In the mean while, cleaning the code base will make it easier to look into the messy code in framework, and remove what is not needed. Which will help bringing new things like OSGI to the table. On Thu, Mar 22, 2012 at 7:58 PM, Anne a...@cohsoft.com.au wrote: +1 to Mansour's comments. I don't use Birt. I use JasperReports (GPL/LGPL). With JasperReports and Groovy I currently 2. can use ofbiz fieldnames and entity names. (not databasenames) 3. can use OFBiz views. 4. can fully integrate in the ERP application. 5. has many inbuilt output formats. (points are from Hans earlier email, though maybe my idea of fully integrate isn't the same as Hans). I presume I can also incorporate the warehouse entities, and use minilang (Hans' other two points), though I haven't yet tried either. Maybe it is easier to do these things with Birt, but I don't have any difficulty with JasperReports. More importantly to me, if I decide to drop JasperReports and move to something else later, it won't be very difficult. I am sure Hans integration of Birt would be very useful for those who use Birt, and I expect they appreciate his effort. If Birt was in Extras, perhaps some of those people would be more likely to contribute to its maintenance. Cheers, Anne. On 23 March 2012 01:37, Mansour Al Akeel mansour.alak...@gmail.com wrote: I don't know why birt is integrated with Ofbiz. A reporting tools, is an add-on to any database driven system, and not essential for the over all functionality. Yes all of us need reports, and most of the time we use a reporting engine, but why can't it be separated from the code base, and used as a separate application ? From my perspective, the core should contain only components needed to bring it up to a functional state. Entity Engine, Service Engine, fall under this category. Some may argue that UI should be considered as well, and this is valid argument. But when it comes to reporting engine, I don't think so. On Thu, Mar 22, 2012 at 7:43 AM, Erwan de FERRIERES erwan.de-ferrie...@nereide.fr wrote: Le 22/03/2012 02:38, Hans Bakker a écrit : Jacopo, you are making here a very negative review of the Birt integrationas any component sure there is room for improvement however Some positives you did not even notice? 1. can use minilanguage for the retrieval 2. can use ofbiz fieldnames and entity names. (not databasenames) 3. can use OFBiz views. 4. can fully integrate in the ERP application. 5. has many inbuilt output formats. 6. Incorporates the warehouse entities. Created/extended the datawarehouse which is essential for ordereporting. We have very big customers where using order reports directly on the OFBiz database was not possible. This warehouse function is essential for large customers I very strongly think about keeping this in the framework. BI component I agree, can go Regards, Hans I'm in two minds about BIRT. It's a fine tool to make reports, but underused in OFBiz. If the concerns Jacopo has about it were resolved, will it be kept in framework ? Also, creating more of those reports (with not available features in FOP), will this go in the right way to keep it there ? -- Erwan de FERRIERES www.nereide.biz -- Coherent Software Australia Pty Ltd PO Box 2773 Cheltenham Vic 3192 Phone: (03) 9585 6788 Fax: (03) 9585 1086 Web: http://www.cohsoft.com.au/ Email: sa...@cohsoft.com.au Bonsai ERP, the all-inclusive ERP system http://www.bonsaierp.com.au/ -- Coherent Software Australia Pty Ltd PO Box 2773 Cheltenham Vic 3192 Phone: (03) 9585 6788 Fax: (03) 9585 1086 Web: http://www.cohsoft.com.au/ Email: sa...@cohsoft.com.au Bonsai ERP, the all-inclusive ERP system http://www.bonsaierp.com.au/
Re: junit test still failing.
Hi Hans
Just tried locally with rev 1305182, and all tests passed. Perhaps you have
an older rev, where the patch hadn't applied properly?
Cheers,
Anne.
On 26 March 2012 10:56, Hans Bakker mailingl...@antwebsystems.com wrote:
javascript:showStackTrace('**test-org.ofbiz.base.util.test.**
UtilPropertiesTests.**testReadXmlLangNewStyle','org.**
ofbiz.base.util.test/**UtilPropertiesTests/**testReadXmlLangNewStyle//**summary')
org.ofbiz.base.util.test.**UtilPropertiesTests.**testReadXmlLangNewStyle
http://jenkins.antwebsystems.**com/job/OFBizTrunk/75/**
testReport/org.ofbiz.base.**util.test/UtilPropertiesTests/**
testReadXmlLangNewStyle/http://jenkins.antwebsystems.com/job/OFBizTrunk/75/testReport/org.ofbiz.base.util.test/UtilPropertiesTests/testReadXmlLangNewStyle/
Regards,
Hans
--
Coherent Software Australia Pty Ltd
PO Box 2773
Cheltenham Vic 3192
Phone: (03) 9585 6788
Fax: (03) 9585 1086
Web: http://www.cohsoft.com.au/
Email: sa...@cohsoft.com.au
Bonsai ERP, the all-inclusive ERP system
http://www.bonsaierp.com.au/
[jira] [Commented] (OFBIZ-4723) Support validation of resource xml files
[ https://issues.apache.org/jira/browse/OFBIZ-4723?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13238067#comment-13238067 ] Anne Jessel commented on OFBIZ-4723: Thank you Jacques. I would just like to confirm so I know for next time: the problem was not actually caused by my patches. It was just bad luck a problem elsewhere made it look as if my patches were the cause. So I should prepare future patches the same way. Is that correct? Support validation of resource xml files Key: OFBIZ-4723 URL: https://issues.apache.org/jira/browse/OFBIZ-4723 Project: OFBiz Issue Type: Improvement Components: framework Affects Versions: SVN trunk Environment: REV 1297286 Reporter: Anne Jessel Assignee: Jacques Le Roux Priority: Minor Fix For: SVN trunk Attachments: OFBIZ-4723_both.patch, OFBIZ-4723_code_cleanups.patch, OFBIZ-4723_combined.patch, OFBIZ-4723_support-validation-resource-xml.patch The xsd for the resource xml files is invalid. In addition, the format of the value of the xml:lang attribute in resource xml files is invalid, according to the xml standard. The attached patch: * provides a valid xsd * updates UtilProperties and the Label Manager to deal with the correct formatting of the xml:lang value, while still working with the old format, following Adrian Crum's recommendation on the mailing list * includes simple unit tests for UtilProperties to ensure it does work with both formats * changes the Label Manager to include a reference to the new xsd, and to use the correct format of the xml:lang value, when writing a resource xml file. This problem exists in released versions, but I doubt it is important enough to back port. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: Junit tests are failing: org.ofbiz.base.util.test.UtilPropertiesTests.testReadXmlLangNewStyle
Paul mentioned this to me, so I have just had a look. Something has gone wrong with the application of my patch. The commit log lists these files: Changed paths: M /ofbiz/trunk/framework/base/dtd/ofbiz-properties.xsd A /ofbiz/trunk/framework/base/src/org/ofbiz/base/util/test/UtilPropertiesTests.java M /ofbiz/trunk/framework/base/testdef/basetests.xml M /ofbiz/trunk/framework/webtools/src/org/ofbiz/webtools/labelmanager/LabelInfo.java M /ofbiz/trunk/framework/webtools/src/org/ofbiz/webtools/labelmanager/LabelManagerFactory.java M /ofbiz/trunk/framework/webtools/src/org/ofbiz/webtools/labelmanager/SaveLabelsToXmlFile.java but my patches for OFBIZ-4723 affect these files: framework/base/src/org/ofbiz/base/util/UtilProperties.java framework/base/src/org/ofbiz/base/util/test/UtilPropertiesTests.java framework/base/dtd/ofbiz-properties.xsd framework/base/testdef/basetests.xml framework/webtools/src/org/ofbiz/webtools/labelmanager/LabelManagerFactory.java framework/webtools/src/org/ofbiz/webtools/labelmanager/SaveLabelsToXmlFile.java framework/webtools/src/org/ofbiz/webtools/labelmanager/LabelInfo.java Notice the commit doesn't include UtilProperties.java, which is the change that the unit test is actually testing. Perhaps the patch needs to be re-applied? Cheers, Anne. On 24 March 2012 19:49, Jacopo Cappellato jacopo.cappell...@hotwaxmedia.com wrote: I suspect that in Anne's local box the tests will be successful (the test that is failing is using en-AU as a Locale and it may be related...) Jacopo On Mar 24, 2012, at 9:43 AM, Jacques Le Roux wrote: About http://svn.apache.org/viewvc?rev=1304193view=rev I did not run the tests locally. It's a pity Buildbot is still not working. Hopefully this should be soon fixed https://issues.apache.org/jira/browse/INFRA-4562 There are indeed chances that it's related, Anne introduced LangNewStyle changes. I guess it's not blocking anybody at the moment If Anne does not get a chance to look at her changes ( https://issues.apache.org/jira/browse/OFBIZ-4723) I will do Jacques From: Jacopo Cappellato jacopo.cappell...@hotwaxmedia.com I have noticed the same... it seems to be related to 1304193 Jacopo On Mar 24, 2012, at 12:58 AM, Hans Bakker wrote: Since today the following test is failing: org.ofbiz.base.util.test.UtilPropertiesTests.testReadXmlLangNewStyle Regards, Hans -- Coherent Software Australia Pty Ltd PO Box 2773 Cheltenham Vic 3192 Phone: (03) 9585 6788 Fax: (03) 9585 1086 Web: http://www.cohsoft.com.au/ Email: sa...@cohsoft.com.au Bonsai ERP, the all-inclusive ERP system http://www.bonsaierp.com.au/
Re: Junit tests are failing: org.ofbiz.base.util.test.UtilPropertiesTests.testReadXmlLangNewStyle
Thanks Jacques. Could you please also check that the patch hunk for
UtilProperties.java, starting at line 964, applies successfully? It applies
cleanly on my local copy.
Cheers,
Anne.
On 24 March 2012 20:25, Jacques Le Roux jacques.le.r...@les7arts.comwrote:
Indeed, it seems I did not notice this part is rejected, I will apply by
hand
--- framework/webtools/src/org/**ofbiz/webtools/labelmanager/**
LabelManagerFactory.java
+++ framework/webtools/src/org/**ofbiz/webtools/labelmanager/**
LabelManagerFactory.java
@@ -132,7 +132,12 @@
for (Node valueNode :
UtilXml.childNodeList(**propertyElem.getFirstChild()))
{
if (valueNode instanceof Element) {
Element valueElem = (Element) valueNode;
+// Support old way of specifying xml:lang
value.
+// Old way: en_AU, new way: en-AU
String localeName = valueElem.getAttribute(xml:
**lang);
+if( localeName.contains(_)) {
+localeName = localeName.replace('_', '-');
+}
String labelValue =
StringUtil.defaultWebEncoder.**canonicalize(UtilXml.**nodeValue(valueElem.
**getFirstChild()));
LabelInfo label = labels.get(labelKey +
keySeparator + fileInfo.getFileName());
Jacques
From: Anne a...@cohsoft.com.au
Paul mentioned this to me, so I have just had a look.
Something has gone wrong with the application of my patch. The commit log
lists these files:
Changed paths:
M /ofbiz/trunk/framework/base/**dtd/ofbiz-properties.xsd
A
/ofbiz/trunk/framework/base/**src/org/ofbiz/base/util/test/**
UtilPropertiesTests.java
M /ofbiz/trunk/framework/base/**testdef/basetests.xml
M
/ofbiz/trunk/framework/**webtools/src/org/ofbiz/**webtools/labelmanager/*
*LabelInfo.java
M
/ofbiz/trunk/framework/**webtools/src/org/ofbiz/**webtools/labelmanager/*
*LabelManagerFactory.java
M
/ofbiz/trunk/framework/**webtools/src/org/ofbiz/**webtools/labelmanager/*
*SaveLabelsToXmlFile.java
but my patches for OFBIZ-4723 affect these files:
framework/base/src/org/ofbiz/**base/util/UtilProperties.java
framework/base/src/org/ofbiz/**base/util/test/**UtilPropertiesTests.java
framework/base/dtd/ofbiz-**properties.xsd
framework/base/testdef/**basetests.xml
framework/webtools/src/org/**ofbiz/webtools/labelmanager/**
LabelManagerFactory.java
framework/webtools/src/org/**ofbiz/webtools/labelmanager/**
SaveLabelsToXmlFile.java
framework/webtools/src/org/**ofbiz/webtools/labelmanager/**LabelInfo.java
Notice the commit doesn't include UtilProperties.java, which is the change
that the unit test is actually testing. Perhaps the patch needs to be
re-applied?
Cheers,
Anne.
On 24 March 2012 19:49, Jacopo Cappellato jacopo.cappellato@**
hotwaxmedia.com jacopo.cappell...@hotwaxmedia.com
wrote:
I suspect that in Anne's local box the tests will be successful (the test
that is failing is using en-AU as a Locale and it may be related...)
Jacopo
On Mar 24, 2012, at 9:43 AM, Jacques Le Roux wrote:
About
http://svn.apache.org/viewvc?**rev=1304193view=revhttp://svn.apache.org/viewvc?rev=1304193view=rev
I did not run the tests locally. It's a pity Buildbot is still not
working. Hopefully this should be soon fixed
https://issues.apache.org/**jira/browse/INFRA-4562https://issues.apache.org/jira/browse/INFRA-4562
There are indeed chances that it's related, Anne introduced
LangNewStyle
changes.
I guess it's not blocking anybody at the moment
If Anne does not get a chance to look at her changes (
https://issues.apache.org/**jira/browse/OFBIZ-4723https://issues.apache.org/jira/browse/OFBIZ-4723)
I will do
Jacques
From: Jacopo Cappellato
jacopo.cappellato@**hotwaxmedia.comjacopo.cappell...@hotwaxmedia.com
I have noticed the same... it seems to be related to 1304193
Jacopo
On Mar 24, 2012, at 12:58 AM, Hans Bakker wrote:
Since today the following test is failing:
org.ofbiz.base.util.test.**UtilPropertiesTests.**testReadXmlLangNewStyle
Regards,
Hans
--
Coherent Software Australia Pty Ltd
PO Box 2773
Cheltenham Vic 3192
Phone: (03) 9585 6788
Fax: (03) 9585 1086
Web: http://www.cohsoft.com.au/
Email: sa...@cohsoft.com.au
Bonsai ERP, the all-inclusive ERP system
http://www.bonsaierp.com.au/
--
Coherent Software Australia Pty Ltd
PO Box 2773
Cheltenham Vic 3192
Phone: (03) 9585 6788
Fax: (03) 9585 1086
Web: http://www.cohsoft.com.au/
Email: sa...@cohsoft.com.au
Bonsai ERP, the all-inclusive ERP system
http://www.bonsaierp.com.au/
Re: Junit tests are failing: org.ofbiz.base.util.test.UtilPropertiesTests.testReadXmlLangNewStyle
Jacques,
The patch you added to jira does not include the changes to
UtilProperties.java. When I apply my original patch to my local copy of
trunk, it all applies cleanly. I can't see what is going wrong.
I will create a new combined patch and add it to the jira. Maybe it will be
simpler to see what is wrong then.
Cheers,
Anne.
On 24 March 2012 20:46, Jacques Le Roux jacques.le.r...@les7arts.comwrote:
I reapplied both patches in the right order (I did care about this point
last time I think, anyway did not get any rejects)
And I have applied the resulting patch to the issue, please check
Thanks
Jacques
From: Anne a...@cohsoft.com.au
Thanks Jacques. Could you please also check that the patch hunk for
UtilProperties.java, starting at line 964, applies successfully? It
applies
cleanly on my local copy.
Cheers,
Anne.
On 24 March 2012 20:25, Jacques Le Roux jacques.le.r...@les7arts.com**
wrote:
Indeed, it seems I did not notice this part is rejected, I will apply by
hand
--- framework/webtools/src/org/ofbiz/webtools/labelmanager/**
LabelManagerFactory.java
+++ framework/webtools/src/org/ofbiz/webtools/labelmanager/**
LabelManagerFactory.java
@@ -132,7 +132,12 @@
for (Node valueNode : UtilXml.childNodeList(
propertyElem.getFirstChild()))
{
if (valueNode instanceof Element) {
Element valueElem = (Element) valueNode;
+// Support old way of specifying xml:lang
value.
+// Old way: en_AU, new way: en-AU
String localeName =
valueElem.getAttribute(xml:
**lang);
+if( localeName.contains(_)) {
+localeName = localeName.replace('_',
'-');
+}
String labelValue =
StringUtil.defaultWebEncoder.canonicalize(UtilXml.
nodeValue(valueElem.
**getFirstChild()));
LabelInfo label = labels.get(labelKey +
keySeparator + fileInfo.getFileName());
Jacques
From: Anne a...@cohsoft.com.au
Paul mentioned this to me, so I have just had a look.
Something has gone wrong with the application of my patch. The commit
log
lists these files:
Changed paths:
M /ofbiz/trunk/framework/base/dtd/ofbiz-properties.xsd
A
/ofbiz/trunk/framework/base/src/org/ofbiz/base/util/test/
UtilPropertiesTests.java
M /ofbiz/trunk/framework/base/testdef/basetests.xml
M
/ofbiz/trunk/framework/webtools/src/org/ofbiz/
webtools/labelmanager/*
*LabelInfo.java
M
/ofbiz/trunk/framework/webtools/src/org/ofbiz/
webtools/labelmanager/*
*LabelManagerFactory.java
M
/ofbiz/trunk/framework/webtools/src/org/ofbiz/
webtools/labelmanager/*
*SaveLabelsToXmlFile.java
but my patches for OFBIZ-4723 affect these files:
framework/base/src/org/ofbiz/base/util/UtilProperties.java
framework/base/src/org/ofbiz/base/util/test/
UtilPropertiesTests.java
framework/base/dtd/ofbiz-properties.xsd
framework/base/testdef/basetests.xml
framework/webtools/src/org/ofbiz/webtools/labelmanager/**
LabelManagerFactory.java
framework/webtools/src/org/ofbiz/webtools/labelmanager/**
SaveLabelsToXmlFile.java
framework/webtools/src/org/ofbiz/webtools/labelmanager/
LabelInfo.java
Notice the commit doesn't include UtilProperties.java, which is the
change
that the unit test is actually testing. Perhaps the patch needs to be
re-applied?
Cheers,
Anne.
On 24 March 2012 19:49, Jacopo Cappellato jacopo.cappellato@**
hotwaxmedia.com
jacopo.cappellato@**hotwaxmedia.comjacopo.cappell...@hotwaxmedia.com
wrote:
I suspect that in Anne's local box the tests will be successful (the
test
that is failing is using en-AU as a Locale and it may be related...)
Jacopo
On Mar 24, 2012, at 9:43 AM, Jacques Le Roux wrote:
About
http://svn.apache.org/viewvc?rev=1304193view=revhttp://svn.apache.org/viewvc?**rev=1304193view=rev
http://**svn.apache.org/viewvc?rev=**1304193view=revhttp://svn.apache.org/viewvc?rev=1304193view=rev
I did not run the tests locally. It's a pity Buildbot is still not
working. Hopefully this should be soon fixed
https://issues.apache.org/jira/browse/INFRA-4562https://issues.apache.org/**jira/browse/INFRA-4562
https:/**/issues.apache.org/jira/**browse/INFRA-4562https://issues.apache.org/jira/browse/INFRA-4562
There are indeed chances that it's related, Anne introduced
LangNewStyle
changes.
I guess it's not blocking anybody at the moment
If Anne does not get a chance to look at her changes (
https://issues.apache.org/jira/browse/OFBIZ-4723https://issues.apache.org/**jira/browse/OFBIZ-4723
https:/**/issues.apache.org/jira/**browse/OFBIZ-4723https://issues.apache.org/jira/browse/OFBIZ-4723
)
I will do
Jacques
From: Jacopo Cappellato
jacopo.cappellato
[jira] [Updated] (OFBIZ-4723) Support validation of resource xml files
[ https://issues.apache.org/jira/browse/OFBIZ-4723?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anne Jessel updated OFBIZ-4723: --- Attachment: OFBIZ-4723_combined.patch New combined patch. Support validation of resource xml files Key: OFBIZ-4723 URL: https://issues.apache.org/jira/browse/OFBIZ-4723 Project: OFBiz Issue Type: Improvement Components: framework Affects Versions: SVN trunk Environment: REV 1297286 Reporter: Anne Jessel Assignee: Jacques Le Roux Priority: Minor Fix For: SVN trunk Attachments: OFBIZ-4723_both.patch, OFBIZ-4723_code_cleanups.patch, OFBIZ-4723_combined.patch, OFBIZ-4723_support-validation-resource-xml.patch The xsd for the resource xml files is invalid. In addition, the format of the value of the xml:lang attribute in resource xml files is invalid, according to the xml standard. The attached patch: * provides a valid xsd * updates UtilProperties and the Label Manager to deal with the correct formatting of the xml:lang value, while still working with the old format, following Adrian Crum's recommendation on the mailing list * includes simple unit tests for UtilProperties to ensure it does work with both formats * changes the Label Manager to include a reference to the new xsd, and to use the correct format of the xml:lang value, when writing a resource xml file. This problem exists in released versions, but I doubt it is important enough to back port. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (OFBIZ-4723) Support validation of resource xml files
[ https://issues.apache.org/jira/browse/OFBIZ-4723?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13236163#comment-13236163 ] Anne Jessel commented on OFBIZ-4723: Jacques The purpose of the Debug.infoOn() call is to avoid unnecessary string concatenations and unnecessary object creation, which are slow operations. It also reduces the need for garbage collection. There is lots of advice around the web to follow this pattern, unless the log message does not include any concatenation or conversions. For example: http://logging.apache.org/log4j/1.2/faq.html#a2.3 and http://blog.progs.be/91/isdebugenabled Support validation of resource xml files Key: OFBIZ-4723 URL: https://issues.apache.org/jira/browse/OFBIZ-4723 Project: OFBiz Issue Type: Improvement Components: framework Affects Versions: SVN trunk Environment: REV 1297286 Reporter: Anne Jessel Priority: Minor Attachments: OFBIZ-4723_code_cleanups.patch, OFBIZ-4723_support-validation-resource-xml.patch The xsd for the resource xml files is invalid. In addition, the format of the value of the xml:lang attribute in resource xml files is invalid, according to the xml standard. The attached patch: * provides a valid xsd * updates UtilProperties and the Label Manager to deal with the correct formatting of the xml:lang value, while still working with the old format, following Adrian Crum's recommendation on the mailing list * includes simple unit tests for UtilProperties to ensure it does work with both formats * changes the Label Manager to include a reference to the new xsd, and to use the correct format of the xml:lang value, when writing a resource xml file. This problem exists in released versions, but I doubt it is important enough to back port. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: Lose Weight Program for OFBiz - Birt and BI
+1 to Mansour's comments. I don't use Birt. I use JasperReports (GPL/LGPL). With JasperReports and Groovy I currently 2. can use ofbiz fieldnames and entity names. (not databasenames) 3. can use OFBiz views. 4. can fully integrate in the ERP application. 5. has many inbuilt output formats. (points are from Hans earlier email, though maybe my idea of fully integrate isn't the same as Hans). I presume I can also incorporate the warehouse entities, and use minilang (Hans' other two points), though I haven't yet tried either. Maybe it is easier to do these things with Birt, but I don't have any difficulty with JasperReports. More importantly to me, if I decide to drop JasperReports and move to something else later, it won't be very difficult. I am sure Hans integration of Birt would be very useful for those who use Birt, and I expect they appreciate his effort. If Birt was in Extras, perhaps some of those people would be more likely to contribute to its maintenance. Cheers, Anne. On 23 March 2012 01:37, Mansour Al Akeel mansour.alak...@gmail.com wrote: I don't know why birt is integrated with Ofbiz. A reporting tools, is an add-on to any database driven system, and not essential for the over all functionality. Yes all of us need reports, and most of the time we use a reporting engine, but why can't it be separated from the code base, and used as a separate application ? From my perspective, the core should contain only components needed to bring it up to a functional state. Entity Engine, Service Engine, fall under this category. Some may argue that UI should be considered as well, and this is valid argument. But when it comes to reporting engine, I don't think so. On Thu, Mar 22, 2012 at 7:43 AM, Erwan de FERRIERES erwan.de-ferrie...@nereide.fr wrote: Le 22/03/2012 02:38, Hans Bakker a écrit : Jacopo, you are making here a very negative review of the Birt integrationas any component sure there is room for improvement however Some positives you did not even notice? 1. can use minilanguage for the retrieval 2. can use ofbiz fieldnames and entity names. (not databasenames) 3. can use OFBiz views. 4. can fully integrate in the ERP application. 5. has many inbuilt output formats. 6. Incorporates the warehouse entities. Created/extended the datawarehouse which is essential for ordereporting. We have very big customers where using order reports directly on the OFBiz database was not possible. This warehouse function is essential for large customers I very strongly think about keeping this in the framework. BI component I agree, can go Regards, Hans I'm in two minds about BIRT. It's a fine tool to make reports, but underused in OFBiz. If the concerns Jacopo has about it were resolved, will it be kept in framework ? Also, creating more of those reports (with not available features in FOP), will this go in the right way to keep it there ? -- Erwan de FERRIERES www.nereide.biz -- Coherent Software Australia Pty Ltd PO Box 2773 Cheltenham Vic 3192 Phone: (03) 9585 6788 Fax: (03) 9585 1086 Web: http://www.cohsoft.com.au/ Email: sa...@cohsoft.com.au Bonsai ERP, the all-inclusive ERP system http://www.bonsaierp.com.au/
Re: Lose Weight Program for OFBiz - Birt and BI
+1 for Birt to extras.
Most of the useful reports OOTB are currently fo.
+1 to JasperReports in extras. I'm happy to volunteer for that one.
Cheers,
Anne.
On 22 March 2012 04:59, Jacques Le Roux jacques.le.r...@les7arts.comwrote:
From: Olivier Heintz holivier.lis...@nereide.biz
Le 20/03/2012 15:31,
adrian.crum@sandglass-**software.comadrian.c...@sandglass-software.coma
écrit :
I like the idea of keeping reporting tools separate from OFBiz. In my
experience, IT departments are already using a reporting tool for other
applications and they would prefer to integrate that tool with OFBiz,
instead of learning/using a new tool that comes bundled with it.
It will be nice if there is a default solution in OFBiz kernel to
maximize ready-to-use report and for small company which have not yet a
real reporting tool.
Then we have fo.ftl files and PDF rendering. Minimalistic but working.
Jacques
-Adrian
Quoting Jacopo Cappellato
jacopo.cappellato@**hotwaxmedia.comjacopo.cappell...@hotwaxmedia.com
:
L) framework/birt (and related dependencies/reports spread around):
move to Extras
M) framework/bi (and related dependencies - ecas/business rules and
data - spread around): move to Extras
This is an area where Hans and I are in disagreement and we didn't get
much feedback from others.
So I would like to explain here why I think we should move the Birt
component and the Birt reports out of the framework and consider them as
optional tools.
There are currently 18 reports in the applications implemented with
Birt; but they really seem experiments rather than something really usable;
to give you some examples:
* in most of them there is this code like this:
userLogin = null;
try {
userLogin = delegator.findByPrimaryKey(**
UserLogin,UtilMisc.toMap(**userLoginId,admin));
} catch(e) {
Debug.logError(e,);
}
* all the retrieval logic (scripts) is inlined with layout definition
and this is something we try to avoid in all the existing screens
* entity list iterators are not properly closed
* some of the widget based financial reports have been converted to
Birt: their layout is still very simple and comparable to the widget based
versions available before Birt; so the conversion to Birt added a
dependencies on this component without adding real value (the rptdesign
files mix together data preparation scripts and ui definitions and in order
to maintain them you have to use the Birt designer); also some of them are
now broken: Income Stetements, Balance Sheet etc... This is probably caused
by the recent refactoring of JSR-223 but the original widget based PDF are
still there and are working fine...
* building a report with this Birt integration still requires a lot of
development work (similar to the one required to create a screen); but then
the code in the rptdesign is very difficult to maintain without the editor
My questions are:
* do you really think that this way of integrating rptdesign reports is
the answer to fill the gap of a good reporting tool in OFBiz? Are you
actually using this integration for your reports?
* do we all agree to make this Birt integration the best practice
mechanism for all OFBiz reports?
* do you really think that we should replace all the existing widget
generated reports and FOP reports with rptdesign reports built using the
existing Birt integration under the framework?
If any of your answers will be no then in my opinion it would be much
better to:
1) make Birt integration an optional component, downloaded separately
2) move the existing rptdesign reports out of the applications and keep
them in the external Birt component
3) at this point users will have the option to use the Birt component
or not, but the ootb code will be clean and without dependencies on it;
most of all, we will not deliver reports that looks similar (ugly) but they
are implemented randomly with Birt or Widgets
4) start evaluating, as a community, what should be the best practices
for ootb reports: what is the tool we want, what are the minimal
requirements etc... and then work together to get it in place and then
migrate all existing reports to it in order to have a consistent system; if
the community will not be able to reach a consensus on this, then we should
leave the decision about the reporting tool to use to the end user
I think that the Birt integration is a nice optional component, and I
see that there may be interested parties, but in its current status it is
not something ready for becoming the primary reporting tool for the ootb
applications.
Jacopo
--
Coherent Software Australia Pty Ltd
PO Box 2773
Cheltenham Vic 3192
Phone: (03) 9585 6788
Fax: (03) 9585 1086
Web: http://www.cohsoft.com.au/
Email: sa...@cohsoft.com.au
Bonsai ERP, the all-inclusive ERP system
http://www.bonsaierp.com.au/
Re: Lose Weight Program for OFBiz JCR function
Keep in framework +1 Remove from upcoming release +1 Part of core eventually +1 I think it is (should be) central to content handling, and OFBiz core needs to handle content. Therefore it should be in core. Cheers, Anne. On 22 March 2012 05:04, Jacques Le Roux jacques.le.r...@les7arts.comwrote: From: Olivier Heintz holivier.lis...@nereide.biz Le 21/03/2012 11:45, Pierre Smits a écrit : Re 1: keep in framework +1 Re 2: remove from upcoming release 12.04 +1, remove from all upcoming future releases until 3 is finished plugin could really be the solution, because most of contribution coming from customer project, and it's easier for a project leader on a customer project to decide to use (or not) a addon versus to use a part of branch. I don't think JCR should be handled by a plugin. It should be part of core framework. And, while at it, I don't think it should replace all Content component (notably all its data model, and more anyway). It's just a better way to handle content repositories (JCR = Java Content Repository ;o): content should not go in DB We already discussed about reasons for that (versionning, webdav access, external HTML editors, etc.) Jacques If necessary I would help in making the addon to help contributors which want to help to do the roadmap define in point 3. Re 3: draft up requirements for content framework replacement +1 +1 Excellent roadmapping ;-) Regards, Pierre Op 20 maart 2012 11:48 schreef Jacopo Cappellato jacopo.cappellato@hotwaxmedia.**com jacopo.cappell...@hotwaxmedia.com het volgende: Or alternatively we could: 1) keep it in framework 2) but remove it from the upcoming new release branch 12.04 3) and then, as a community, we could start the effort (i.e. top priority for upcoming contributions/commits) of defining the set of requirements needed by the applications to replace the existing Content framework, finalizing the architecture and start working all on the implementation and migration of existing applications: this would mean that the community will focus on this refactoring effort for a while (postponing any other new development to focus the energy) At least in this way we could experiment if the concept of a roadmap is a viable options and we will not keep and distribute a component under development waiting to see if and when something good will come out of it. Jacopo On Mar 20, 2012, at 11:32 AM, Jacopo Cappellato wrote: On Mar 20, 2012, at 10:15 AM, Olivier Heintz wrote: New thread for only JCR funstion Summary of initial discussion: Jacoppo: N) framework/jcr: move back into the Jackrabbit branch until the work is completed and can replace the existing content framework Hans: Also moving the JCR function out is not a good idea however when not improved in the next few months using the content manager, i would agree to a removal. Jacoppo Keep it mind we are preparing for the creation of the new release branch (12.04): this would mean that all the future releases for 12.04 will be bundled with an incomplete JCR/Jackrabbit integration that duplicates (but not replaces) the existing Component framework. This is alone a good reason for moving this work back to the development branch and will save a lot of future work in backporting features if security issues or bugs will be discovered. IMO, jcr will be a good enhancement in ofbiz, but currently we(the company I'm working for) are using content component in a lot of place, product, workeffort, project, party, custRequest, to manage files, so we area waiting the next step of the jcr OFBiz (content) integration. Meanwhile this second step, if jcr was a plugin, we will use it for some new customer project (and maybe contribute on ;-) but not use it for older customer which currently works with OFBiz solution to avoid using not completely implement feature. So IMO, jcr should move, branch or extra, but I prefer as a plugin to be able to used it easily. I didn't follow the details of the plans for JCR/Jackrabbit integration but as far as I understand it it is intended to be highly integrated with OFBiz (to replace Content Framework features): I am not sure how this is inline with Olivier's idea of a plugin, but it is an idea that can be explored. However, since we are still in this design phase I think it is a good idea to keep the component in the development branch in the meantime. Jacopo -- Coherent Software Australia Pty Ltd PO Box 2773 Cheltenham Vic 3192 Phone: (03) 9585 6788 Fax: (03) 9585 1086 Web: http://www.cohsoft.com.au/ Email: sa...@cohsoft.com.au Bonsai ERP, the all-inclusive ERP system http://www.bonsaierp.com.au/
Re: Lose Weight Program for OFBiz - what should go to specialpurpose
If we can agree on exactly what specialpurpose will be for in future, we might find it easy to decide what to move. My original thought was that specialpurpose is for the extras that most people won't want. But in future Apache Extras will be doing that. So should we remove specialpurpose totally? Everything in it goes either to Extras or to Applications? I have not decided whether I like that idea. Only thing I am sure of is that ecommerce should stay somewhere in core, but it looks like everyone else agrees on that. Cheers, Anne. On 22 March 2012 07:06, Mansour Al Akeel mansour.alak...@gmail.com wrote: Thank you Jacques. XUL is the mozilla UI thing. I didn't use any of the framework mentioned her :) On Wed, Mar 21, 2012 at 2:24 PM, Jacques Le Roux jacques.le.r...@les7arts.com wrote: From: Mansour Al Akeel mansour.alak...@gmail.com Anil, I did not mean that putting a component under specialpurposes will make it used more by developers. I meant because it will be used more than other component, let's not move it. From Jacopo's first email about the Lose Weight : Legenda for what I propose for each piece of code: * Attic: remove from code base and document the removal for future reference in this page * Extras: identify a person interested in maintaining the code as a separate project hosted as an Apache Extra project (not officially under the ASF); add a link to it from the page that will contain OFBiz Extras He didn't mention anything about what type of applications should go/remain under specialpurposes. Since (I think), pos is used more than what went into Exta or Attic, I suggested keeping it where it's. The question is, will POS be maintained by ofbiz community or another party ? If it's will be separated from ofbiz, what about XUL integration code? It's not XUL but XUI (which is a dead project, replaced by Aria which now smells* almost as much) http://xui.sourceforge.net/index.html http://www.formaria.org/ This does not prevent the POS to work well... Jacques PS: *smells like Frank Zappa said about Jazz: Jazz isn't dead. It just smells funny. http://www.goodreads.com/quotes/show/3092 Jazz has much evolved since...Not Aria... should it remain part of the core ofbiz (framework), or moved to the component that needs it, and becomes the responsibility of the POS maintainer ? With regard to changing the License, I think it's possible on any part of Ofbiz and not only components under Extra. In all cases, users who uses POS more than I do, can give better suggestion. On Wed, Mar 21, 2012 at 11:16 AM, Anil Patel anil.pa...@hotwaxmedia.com wrote: Jacques, I don't use pos, but I think it's good idea to keep it where it's. I think it's more likely, it will be used more than what goes in Extra. It fits specialpurpose. Why do you think a component will be used more if its in specialpurpose section, instead of Extras. Personally think it opposite, If a business is interested in using POS, they will find be able to find it from Extras as well. Like any other Ofbiz application, The Users of POS application will will respond by saying UX sucks :). At that point Company who deployed the POS will be motivated to improve it. If POS is in Extras its will be much easy for new developer to become active committer. In some cases, contributor may want to change License on a components. Doing such thing will be possible for Ofbiz Extras. One of the reasons (I am sure there were many) why OpenTaps was started is License. I will personally like to have more freedom around UI toolset. Ofbiz Extras will make it possible. And if application is well accepted by users then it will get popular and community will grow. Regards Anil Patel On Wed, Mar 21, 2012 at 10:48 AM, Anil Patel anil.pa...@hotwaxmedia.com wrote: People are really worried on the idea of moving certain components from Ofbiz trunk to Ofbiz Extras. Why is it so? Moving a component from Ofbiz trunk to Ofbiz Extras does not mean that the component is not good and so we are throwing it out. Instead idea is to allow components to grow by giving them little more freedom. Like Jacopo mentioned in one of his responses, Projects from Ofbiz Extras can still post updates on Ofbiz lists. Finally if a Project in Extras is useful for business, people will keep improving it and community will grow. Thanks and Regards Anil Patel HotWax Media Inc On Mar 21, 2012, at 8:34 AM, Jacques Le Roux wrote: They are more generic sure, I wonder for the pos... Jacques From: Mansour Al Akeel mansour.alak...@gmail.com Jacques, Yes. You are right. I meant projectmgr. :) I believe assetmaint and projectmgr are used more than others and good to keep them where they are. Thank you. On Wed, Mar 21, 2012 at 10:02 AM, Jacques Le Roux
Re: Lose Weight Program for OFBiz - example, exampleext
Just wanted to mention an idea I had: add a new group Examples alongside applications and specialpurpose and hot-deploy (maybe replacing specialpurpose?). It should be easy to enable/disable the entire group in one go. So new developers have it easily available, it is easy to enable for demos, and easy to disable for production. It could have multiple components, rather than just example and exampleext. Each component could showcase best practice for a particular function. For example, there could be one component for Ajax widgets, and one for Jackrabbit, and so on. I think individual example components would be easier to maintain than one or two large ones. Projects in Extras could include a sample component that gets installed in Examples, showing example code using that Extra. Having support for Extras examples in core might encourage Extras developers to provide good sample code. Cheers, Anne. On 22 March 2012 04:36, Olivier Heintz holivier.lis...@nereide.biz wrote: Le 20/03/2012 23:44, Jacques Le Roux a écrit : From: Mansour Al Akeel mansour.alak...@gmail.com Everyone has different preference about how would the basic component skeleton looks like (ie, with ajax, without, exta functionality ). Even if a basic example included with ofbiz distribution, in the future it will grow again with extra unneeded functionality, or it will be an on going discussion about what should go there. It's much easier to provide a very basic skeleton as a separate download, to serve as an example and a reference. There could be more than one example provided, each showing different capabilities and different techniques. This is better than creating one huge example to show everything, and better than showing only the basics without any additional tips (ie, ajax). +1 for additional download for a example (or exempleext) showing all the current development best practice. This component could be update by a other plug-in which install a extra functionality to showing how to use it. Those who are not satisfied with the examples as a skeleton, can maintain their own copy that will make him/her start a component quickly. Examples are not needed to run ofbiz. So they (examples and examplesext) could be in specialpurpose (+1) of even Extras (0) Jacques On Tue, Mar 20, 2012 at 4:33 PM, Erwan de FERRIERES erwan.de-ferrie...@nereide.fr** wrote: Le 20/03/2012 12:47, Jacopo Cappellato a écrit : Q) framework/example and framework/exampleext: move to specialpurpose Adrian would like to keep Example in the framework but slim it down a lot to the essential (no form widgets examples, no Ajax examples, no content examples etc...). Adrian would you please confirm if in your vision the example application should document the layout of a typical OFBiz component only? If yes, we could use the output of the ant create-component task to document the best practice layout. Jacques, Olivier would like to keep also the examples for the various higher level features available to OFBiz applications. I think that from the discussion it could emerge the following solution to please everyone: * keep the example component in the framework but slim it down to the bare essential * move the exampleext component to specialpurpose and migrate to it all the extra features: this could also be used as a best practice guide on how to extend a component from hot-deploy/specialpurpose I still think that it would be nicer to not bundle the example component ootb to keep the framework cleaner: the example should be downloaded separately (when we will have clear separation between framework and the rest); this approach is similar to tomcat and its example applications. But I don't have a strong opinion on this. Jacopo create 2 components, one basic with simple CRUD and no ajax or whatever, and another one with more eye candy stuff (ajax, modal forms, etc...). Both components should be in specialpurpose/ I'm not in favor of moving them to extras, as when delivering an official release there should be a showcase included. And as Adrian said, when teaching people how to create apps with OFBiz, this could be really useful. And with JSR-223, there's a lot to add ! -- Erwan de FERRIERES www.nereide.biz -- Coherent Software Australia Pty Ltd PO Box 2773 Cheltenham Vic 3192 Phone: (03) 9585 6788 Fax: (03) 9585 1086 Web: http://www.cohsoft.com.au/ Email: sa...@cohsoft.com.au Bonsai ERP, the all-inclusive ERP system http://www.bonsaierp.com.au/
Re: Lose Weight Program for OFBiz - Birt and BI
I thought Birt was a report generation/layout tool, like JasperReports and
many others. I don't understand why it would have anything to do with
datawarehousing.
I agree with Hans that datawarehousing is important. But I think that
should be part of BI, or other (possibly framework) functionality not tied
to presentation.
With the single exception of point 5, aren't the listed positives all
related to non-Birt functionality? Birt just manages the presentation? And
point 5 could be handled by competitors to Birt?
Cheers,
Anne.
On 22 March 2012 12:38, Hans Bakker mailingl...@antwebsystems.com wrote:
Jacopo,
you are making here a very negative review of the Birt integrationas
any component sure there is room for improvement however
Some positives you did not even notice?
1. can use minilanguage for the retrieval
2. can use ofbiz fieldnames and entity names. (not databasenames)
3. can use OFBiz views.
4. can fully integrate in the ERP application.
5. has many inbuilt output formats.
6. Incorporates the warehouse entities.
Created/extended the datawarehouse which is essential for ordereporting.
We have very big customers where using order reports directly on the OFBiz
database was not possible.
This warehouse function is essential for large customers
I very strongly think about keeping this in the framework.
BI component I agree, can go
Regards,
Hans
On 03/20/2012 06:47 PM, Jacopo Cappellato wrote:
L) framework/birt (and related dependencies/reports spread around): move
to Extras
M) framework/bi (and related dependencies - ecas/business rules and data
- spread around): move to Extras
This is an area where Hans and I are in disagreement and we didn't get
much feedback from others.
So I would like to explain here why I think we should move the Birt
component and the Birt reports out of the framework and consider them as
optional tools.
There are currently 18 reports in the applications implemented with Birt;
but they really seem experiments rather than something really usable; to
give you some examples:
* in most of them there is this code like this:
userLogin = null;
try {
userLogin = delegator.findByPrimaryKey(**UserLogin,UtilMisc.toMap(
**userLoginId,admin));
} catch(e) {
Debug.logError(e,);
}
* all the retrieval logic (scripts) is inlined with layout definition and
this is something we try to avoid in all the existing screens
* entity list iterators are not properly closed
* some of the widget based financial reports have been converted to Birt:
their layout is still very simple and comparable to the widget based
versions available before Birt; so the conversion to Birt added a
dependencies on this component without adding real value (the rptdesign
files mix together data preparation scripts and ui definitions and in order
to maintain them you have to use the Birt designer); also some of them are
now broken: Income Stetements, Balance Sheet etc... This is probably caused
by the recent refactoring of JSR-223 but the original widget based PDF are
still there and are working fine...
* building a report with this Birt integration still requires a lot of
development work (similar to the one required to create a screen); but then
the code in the rptdesign is very difficult to maintain without the editor
My questions are:
* do you really think that this way of integrating rptdesign reports is
the answer to fill the gap of a good reporting tool in OFBiz? Are you
actually using this integration for your reports?
* do we all agree to make this Birt integration the best practice
mechanism for all OFBiz reports?
* do you really think that we should replace all the existing widget
generated reports and FOP reports with rptdesign reports built using the
existing Birt integration under the framework?
If any of your answers will be no then in my opinion it would be much
better to:
1) make Birt integration an optional component, downloaded separately
2) move the existing rptdesign reports out of the applications and keep
them in the external Birt component
3) at this point users will have the option to use the Birt component or
not, but the ootb code will be clean and without dependencies on it; most
of all, we will not deliver reports that looks similar (ugly) but they are
implemented randomly with Birt or Widgets
4) start evaluating, as a community, what should be the best practices
for ootb reports: what is the tool we want, what are the minimal
requirements etc... and then work together to get it in place and then
migrate all existing reports to it in order to have a consistent system; if
the community will not be able to reach a consensus on this, then we should
leave the decision about the reporting tool to use to the end user
I think that the Birt integration is a nice optional component, and I see
that there may be interested parties, but in its current status it is not
something
Re: Lose Weight Program for OFBiz
On 19 March 2012 07:15, Scott Gray scott.g...@hotwaxmedia.com wrote: Or perhaps even just tackle each of these consecutively after an agreement on the course of action is reached and a volunteer to do the work is found then we could move on to the next suggestion? +1 Basic ideas all look very good to me. IMO anything that is incomplete or not maintained should be moved to Attic or Extras, unless there is a very good reason for keeping it. The reason for moving it should be well documented. That way it is obvious which code needs work. If someone wants it, they can fix it and offer to maintain it, and then the community can consider whether it is important enough to return. Hopefully if non-committers can easily see what areas need work, they'll be more likely to adopt some code. Cheers, Anne. -- Coherent Software Australia Pty Ltd PO Box 2773 Cheltenham Vic 3192 Phone: (03) 9585 6788 Fax: (03) 9585 1086 Web: http://www.cohsoft.com.au/ Email: sa...@cohsoft.com.au Bonsai ERP, the all-inclusive ERP system http://www.bonsaierp.com.au/
Re: Groovy services and a DSL for OFBiz - a POC
On 15 March 2012 16:37, Jacopo Cappellato jacopo.cappell...@hotwaxmedia.com wrote: On Mar 15, 2012, at 1:40 AM, Anne wrote: I go away for a few days, and you drop the DSL idea and replace it with an old-fashioned language-agnostic helper class. :-) Anne, I must admit that I had the same reaction at the beginning, but in a community you have to blend your plans/ideas with the ones from others if they have strong opinions on them. Yes, Jacopo, I agree. Way I see it, if the community decides to do something I don't want (which isn't the case here!) I have two choices. I can silently live with it, or silently leave. I am happy with the helper class, just not as happy as I was when I thought a DSL was being developed. The helper class is a big improvement over the current system, and I am pleased it exists. I also accepted to see my work being re-routed when I realized we could still implement Groovy services and events in a very nice way: if you review the new version of my services/events, apart from the ugly ofbiz. prefix, all the important things are exactly the same. That is good to hear, though it is the possible directions the DSL could have gone in the future that I was looking forward to, rather than what had already been achieved. I have the following short term plans: * we will expand the DSL (i.e. the helper class) a little bit in order to provide a couple more frequently used operations * I will keep a close eye at the way the helper class evolves in order to avoid the risk of seeing it become another ugly complex api * at some point we may decide to wrap it into a Groovy friendly class to enable full DSL * we have also some plans to implement a Groovy builder for complex dynamic view entities or entity queries: this would complete the DSL for Groovy (if possible we will implement it in a Java friendly way, but if not it will be a Groovy only thing) +1 to all of this. Cheers, Anne. -- Coherent Software Australia Pty Ltd PO Box 2773 Cheltenham Vic 3192 Phone: (03) 9585 6788 Fax: (03) 9585 1086 Web: http://www.cohsoft.com.au/ Email: sa...@cohsoft.com.au Bonsai ERP, the all-inclusive ERP system http://www.bonsaierp.com.au/
Re: OFBiz and Apache Extras
I would be in favour of dropping the licence requirements, for two reasons: 1. The Apache Extras FAQ states that a possible reason for using Apache Extras instead of the Incubator is the project has a license or depends on a license that is not compatible with the Apache License 2.0 2. I seem to remember several suggestions in the ML for enhancements to OFBiz that had to be refused due to incompatible third party library licences. So not requiring the Apache licence might attract more projects. Either way, looks like a great idea to me. Cheers, Anne. On 14 March 2012 20:47, Jacopo Cappellato jacopo.cappell...@hotwaxmedia.com wrote: Hi all, this is a draft of a proposal for a new strategy to setup an ecosystem of extranal projects related with OFBiz (OFBiz Extras). THE GOAL * In the past from time to time we had contributors interested in working on a specific enhancement for OFBiz: because of the nature of their participation and because of the way the community works they could not become OFBiz committers and this made the collaboration more difficult * Recently a committer suggested the use of Apache Extras as a way to implement an OFBiz custom component that could not find its way in the framework * we have also a lot of code in the OFBiz trunk (framework, themes, specialpurpose and applications) that may find a better location outside of the trunk: this could slim down the codebase and in the same time help the grow of an OFBiz ecosystem. While some of the code we have is probably old and could be removed (of course it will always live in the svn history and we will also document the event somewhere) some other code may still be of some interest to a smaller audience: Apache Extras could be a good fit. THE DRAFT OF THE PROPOSAL (inspired by the references at the bottom of this page) Apache Extras is a community of open source projects related to Apache Software Foundation projects or based on their technology. It provides the infrastructure services typically required by open source projects, such as code repositories, bug tracking, project web sites/wiki. Apache Extras is hosted by Google Code Project Hosting, so it will be very familiar to developers already using Google Code Project Hosting. The projects in Apache Extras that accept to follow the rules stated below and are related to Apache OFBiz are grouped under the name OFBiz Extras. The following rules apply to projects in the OFBiz Extras group: * do not include the word Apache in their name but use the name OFBiz Extras - name of the project * do not use the org.apache and the org.ofbiz namespace for their bundles or package names; exceptions to this guideline must be approved and documented through official discussion by the Apache OFBiz PMC on its public mailing lists and will be dealt with on a case by case basis (in these cases the projects could use org.ofbiz.extras) * use the Apache License 2.0 * do not include or link to any code that is not compatible with Apache License 2.0 * keep track of all contributions and ensure they are contributed under an Apache License 2.0 compatible license * discussions about the projects will happen in the project's community * an official web page in the OFBiz site will be dedicated to projects in OFBiz Extras * the OFBiz PMC may ask for additional requirements/constraints on a case by case basis Note: we could even drop the 3 requirements about the license: I have added them because they will be required if the project will ever want to initiate the Incubator process to become an official ASF subproject (part of OFBiz) Kind regards, Jacopo Some references: http://community.apache.org/apache-extras/faq.html http://code.google.com/a/apache-extras.org/hosting/ -- Coherent Software Australia Pty Ltd PO Box 2773 Cheltenham Vic 3192 Phone: (03) 9585 6788 Fax: (03) 9585 1086 Web: http://www.cohsoft.com.au/ Email: sa...@cohsoft.com.au Bonsai ERP, the all-inclusive ERP system http://www.bonsaierp.com.au/
Re: Rethinking the structure of the OFBiz Applications Components
Perhaps user interface project(s) would be a good fit for the proposed Apache Extras? Our experience is that one interface does not fit all. Having different ones to choose from might be helpful for many people. Cheers, Anne. On 15 March 2012 20:20, Nicolas Malin malin.nico...@librenberry.net wrote: Hi, At this time, applications components embedded functional framework and business oriented (massively B2C) and aren't user friendly. I possible solution will be have a dedicate application components for only Consultant or high level user that contains only the functional framework (with business process cleaned) and for end user an oriented business components Exemple : application / content humanres manufacturing marketing order party product workeffort specialpurpose : cms edm ecommerce order-b2b crm-b2b ... The business components contains (in a beautiful world) only business service process and simplified screen. We work with Apache OFBiz on hight parameter ERP with dynamic (by jquery through screen engine) reusable screen based on portlet and portal page. Own idea is, the application components give a portlets list that business components use to configure their portal page. I'm not a modularity fan. For the technical framework, is great but I'm much more mixed to use on functional framework. Integration problem will not resolve easily. Nicolas Le 14/03/2012 23:04, Tom Burns a écrit : Adrian / Jacopo While thinking about a refactoring the OFBiz Architecture you may want to look at http://www.aosabook.org/en/intro.html. The book is all about Open Source architecture. In particular see the chapter on Eclipse, the ultimate open source component framework, Eclipse is the perfect environment to implement Adrian's ambitious vision. However the most pressing problem in OFBiz, given the available resources, is not the architecture, rearranging the components or refactoring of what in Moque would be the Core / Mantel (i.e. a scripting framework etc.). Rather the problem, as your most recent post to this thread suggest, is the short comings in the OFBiz Crust. OOB the user facing applications are difficult to understand, quirky and do not support needed business requirements. Just ask yourself would you go into a meeting with Steve Jobs ghost with these applications? On the OFBiz home page What is Apache OFBiz the focus is clearly ERP. The bullet points advertise OOB application functionality. The business applications should be easy to use, robust, and well documented. This will require more attention to business requirements, providing a consistent set of defined services, adherence to documented UI best practices and well written and better presented user help. All of this is possible without doing more additional work on the Core / Mantel. I would be happy to contribute to an effort to improve the user facing applications if there is support from the committers. I see these applications as falling into two categories. Applications that are common to most businesses and domain specific applications. This follows the pattern laid out in the two DMR Books. The former, more general, category should get the most attention. Those applications include: Common Business - Requirements common to most businesses Accounting Human Resources Marketing Work Effort Reporting Document Management E-Commerce Others to be identified I would like to start with Human Resources. Is anyone interested? Tom From: Pierre Smitspierre.sm...@gmail.com To: dev@ofbiz.apache.org Sent: Wednesday, March 14, 2012 5:53 PM Subject: Re: Rethinking the structure of the OFBiz Applications Components Hi Adrian, Could you list the applications you comment out in your production implementations? I think that would help creating insight. Regards, Pierre Op 14 maart 2012 18:33 schreef Adrian Crum adrian.c...@sandglass-software.com het volgende: Understood. As a service provider, I regularly comment out unused applications and build hot-deploy components to replace OOTB OFBiz components. I override service definitions, redefine entity definitions, etc - all in an effort to take what's good in OFBiz, and replace what's not-so-good. I seem to be doing a lot more of it lately - mostly due to components being added that break every other component. At least with a component approach, that sort of thing can be isolated and dealt with. -Adrian On 3/14/2012 5:22 PM, Jacopo Cappellato wrote: Thank you Adrian. Just to clarify that I was not talking about the architecture of the framework (topic for another day) but only for the layout of the applications and it is not based on what I think it is best in general but instead about what I think it is best to represent what we have
Re: Groovy services and a DSL for OFBiz - a POC
I go away for a few days, and you drop the DSL idea and replace it with an old-fashioned language-agnostic helper class. I don't have a problem with that. It gives up the ability to develop a nice DSL which would necessarily be groovy based, but replaces it with the advantage of being able to use almost any scripting language (but without direct DSL support). Maybe once the helper class is mature, there won't be much point creating a DSL. If there is still a point, a DSL probably would be easier to create using the helper class. Unfortunately I don't have time to help much with this effort at the moment, although I would really like to. I'll try to at least grab the changes soon and play with them, so I can give feedback. I do think it critical that the debugger works. The editing aids my editor gives me for groovy must also work. These are the two biggest issues with minilang, and why I no longer use minilang except for the simplest services. +1 to Jacopo's suggestion to concentrate on implementing what is actually used, and not what one thinks might be useful. Good work, everyone (especially Jacopo and Adrian). Cheers, Anne. -- Coherent Software Australia Pty Ltd PO Box 2773 Cheltenham Vic 3192 Phone: (03) 9585 6788 Fax: (03) 9585 1086 Web: http://www.cohsoft.com.au/ Email: sa...@cohsoft.com.au Bonsai ERP, the all-inclusive ERP system http://www.bonsaierp.com.au/
[jira] [Commented] (OFBIZ-4725) Currently the system ecommerce is B2C add functions to enable B2B
[ https://issues.apache.org/jira/browse/OFBIZ-4725?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13225708#comment-13225708 ] Anne Jessel commented on OFBIZ-4725: I don't think points 4 through 8 are right. One person in a company shouldn't be able to see everything ever ordered by anyone else in the company. An employee working in the Australian branch shouldn't be able to see what the French branch have been ordering. I think the order/quote/request related functions should only display the items relevant to the employee. The company details should be used for shipping and invoicing contacts, but not for display of historical items. Does that make sense? Currently the system ecommerce is B2C add functions to enable B2B - Key: OFBIZ-4725 URL: https://issues.apache.org/jira/browse/OFBIZ-4725 Project: OFBiz Issue Type: Improvement Components: order, specialpurpose/ecommerce Affects Versions: SVN trunk Reporter: Hans Bakker Currently the ecommerce and order component is facilitating B2C (business to consumer) We suggest to add functions to allow also B2B Business to Business where a contact person uses the ecommerce on behalf of the company he works for, i.e. not entering quotes/orders for himself but entering orders for the company he works for. This relationship is already establsihed on the party component in the profile contact/related-account box. These are functions which need change: 1. Registration : add the related company field and create a relationship between person and company. 2. Profile page: display an information of the related company: already shown 3. Checkout: if person who login has the related company, an order what person created will be an order of the related company. 4. Order History: adjust to be an order list for the related company. 5. Request entry : adjust to be the request list for the related company. 6. Quote entry: adjust to be the quote list for the related company. 7. Message : adjust to be the message list for the related company. 8. Shopping Lists : adjust to be the shopping list for the related company and adjust create a shopping list for the related company. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: Groovy services and a DSL for OFBiz - a POC
Hi Jacopo That is an excellent start! I used to prefer minilang to java because it was so easy to do common tasks, but 2 things about it were so annoying that I now only use it for the simplest tasks. But with java I have to put up with all that extra code to get simple things done. Your groovy approach takes the best of minilang and the best of java, and combines them. My only concern with it is speed, but I suppose we could use ant to compile the groovy if there is a problem? A couple of thoughts (probably you have already thought of these): Change runService to runServiceSync, so there can also be a runServiceAsync. The design effort on this could combine with the current design effort on improving minilang. Adrian's new wiki page ( https://cwiki.apache.org/confluence/display/OFBADMIN/Mini-language+Reference) could be used to guide what functionality the new groovy DSL needs. So there could (almost) be a one-to-one mapping between a minilang tag and a DSL function. Do you intend for the DSL to work with events, as well as services? Cheers, Anne. On 9 March 2012 05:02, Jacopo Cappellato jacopo.cappell...@hotwaxmedia.comwrote: Hi all, I have just completed my first pass in the implementation of a DSL (Domain Specific Language) for OFBiz that can be used by Groovy services to act like a modern version of Minilang. Please review my notes here: https://cwiki.apache.org/confluence/display/OFBIZ/Groovy+Services+and+DSL+for+OFBiz I look forward to your comments and feedback but please consider that 1) it is a work in progress, 2) I spent a lot of time and mental energy in the effort (reaching simplicity is really complex task!)... so please don't be too picky :-) Regards, Jacopo PS: if you find it useful, I can commit the Groovy service mentioned in the page in Confluence -- Coherent Software Australia Pty Ltd PO Box 2773 Cheltenham Vic 3192 Phone: (03) 9585 6788 Fax: (03) 9585 1086 Web: http://www.cohsoft.com.au/ Email: sa...@cohsoft.com.au Bonsai ERP, the all-inclusive ERP system http://www.bonsaierp.com.au/
[jira] [Created] (OFBIZ-4723) Support validation of resource xml files
Support validation of resource xml files Key: OFBIZ-4723 URL: https://issues.apache.org/jira/browse/OFBIZ-4723 Project: OFBiz Issue Type: Improvement Components: framework Affects Versions: SVN trunk Environment: REV 1297286 Reporter: Anne Jessel Priority: Minor The xsd for the resource xml files is invalid. In addition, the format of the value of the xml:lang attribute in resource xml files is invalid, according to the xml standard. The attached patch: * provides a valid xsd * updates UtilProperties and the Label Manager to deal with the correct formatting of the xml:lang value, while still working with the old format, following Adrian Crum's recommendation on the mailing list * includes simple unit tests for UtilProperties to ensure it does work with both formats * changes the Label Manager to include a reference to the new xsd, and to use the correct format of the xml:lang value, when writing a resource xml file. This problem exists in released versions, but I doubt it is important enough to back port. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (OFBIZ-4723) Support validation of resource xml files
[ https://issues.apache.org/jira/browse/OFBIZ-4723?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anne Jessel updated OFBIZ-4723: --- Attachment: OFBIZ-4723_support-validation-resource-xml.patch Support validation of resource xml files Key: OFBIZ-4723 URL: https://issues.apache.org/jira/browse/OFBIZ-4723 Project: OFBiz Issue Type: Improvement Components: framework Affects Versions: SVN trunk Environment: REV 1297286 Reporter: Anne Jessel Priority: Minor Attachments: OFBIZ-4723_support-validation-resource-xml.patch The xsd for the resource xml files is invalid. In addition, the format of the value of the xml:lang attribute in resource xml files is invalid, according to the xml standard. The attached patch: * provides a valid xsd * updates UtilProperties and the Label Manager to deal with the correct formatting of the xml:lang value, while still working with the old format, following Adrian Crum's recommendation on the mailing list * includes simple unit tests for UtilProperties to ensure it does work with both formats * changes the Label Manager to include a reference to the new xsd, and to use the correct format of the xml:lang value, when writing a resource xml file. This problem exists in released versions, but I doubt it is important enough to back port. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: Preferred solution to non-validating xml:lang?
Thanks Adrian. Have provided a patch for this as https://issues.apache.org/jira/browse/OFBIZ-4723 While working on this, I noticed org.ofbiz.webtools.labelmanager.LabelManagerFactory.java and org.ofbiz.webtools.labelmanager.LabelReferences.java have hard-coded references to the shark component. This doesn't seem appropriate, especially for an optional component. Cheers, Anne. On 29 February 2012 19:54, Adrian Crum adrian.c...@sandglass-software.comwrote: I would recommend that we support both versions of the xml:lang attribute. The UtilProperties class and the Label Manager application can be updated to read either version and write the correct version. That way we will have an upgrade path without breaking backward compatibility. -Adrian On 2/29/2012 4:17 AM, Anne wrote: The schema at framework/base/dtd/ofbiz-**properties.xsd is intended for the labels xml files. Currently those files do not to refer to a schema. So I tried to change that. However the ofbiz-properties.xsd itself wouldn't validate, so I fixed that, and then added it as the schema to a sample labels.xml file for testing. Now I have a different problem relating to the xml:lang attribute. I need a solution or there is no point me submitting a patch. The existing code in UtilProperties compares the string generated by Locale's toString() with the value of the xml:lang attribute. An example string generated by Locale's toString() is pt_BR. Therefore that is the format of the string currently used with xml:lang in the labels.xml files. The xml:lang attribute definition (according to both the xml standard and the relevant xsd) states the value must be of the form pt-BR. That is, a - and not a _. This is incompatible with current usage in OFBiz. If I apply a schema to an existing labels.xml file, the xml will not validate. If I fix the xml so it validates, it of course won't work in OFBiz unless I also change UtilProperties. One solution would be to change UtilProperties: stop using Locale's toString(), and instead create a string with a '-' using Locale's getCountry() and getLanguage() methods (is the Locale variant used anywhere?). Then all the labels.xml files would need to have their value of xml:lang updated to use '-' instead of '_'. What is the community's preferred solution? Cheers, Anne. -- Coherent Software Australia Pty Ltd PO Box 2773 Cheltenham Vic 3192 Phone: (03) 9585 6788 Fax: (03) 9585 1086 Web: http://www.cohsoft.com.au/ Email: sa...@cohsoft.com.au Bonsai ERP, the all-inclusive ERP system http://www.bonsaierp.com.au/
[jira] [Updated] (OFBIZ-4723) Support validation of resource xml files
[ https://issues.apache.org/jira/browse/OFBIZ-4723?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anne Jessel updated OFBIZ-4723: --- Attachment: OFBIZ-4723_code_cleanups.patch While creating the main patch, I made some minor code cleanups to these files. Including as a separate patch to aid review. Patch should be applied after main one. Support validation of resource xml files Key: OFBIZ-4723 URL: https://issues.apache.org/jira/browse/OFBIZ-4723 Project: OFBiz Issue Type: Improvement Components: framework Affects Versions: SVN trunk Environment: REV 1297286 Reporter: Anne Jessel Priority: Minor Attachments: OFBIZ-4723_code_cleanups.patch, OFBIZ-4723_support-validation-resource-xml.patch The xsd for the resource xml files is invalid. In addition, the format of the value of the xml:lang attribute in resource xml files is invalid, according to the xml standard. The attached patch: * provides a valid xsd * updates UtilProperties and the Label Manager to deal with the correct formatting of the xml:lang value, while still working with the old format, following Adrian Crum's recommendation on the mailing list * includes simple unit tests for UtilProperties to ensure it does work with both formats * changes the Label Manager to include a reference to the new xsd, and to use the correct format of the xml:lang value, when writing a resource xml file. This problem exists in released versions, but I doubt it is important enough to back port. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: Please review the text in the OFBiz download page
Ah yes, thanks Jacques. And Jacopo even said his message was aimed at committers, which I missed. Sorry. Cheers, Anne. On 1 March 2012 03:47, Jacques Le Roux jacques.le.r...@les7arts.com wrote: From: Anne a...@cohsoft.com.au I can't find a way to log in and change it myself, but my suggested edits are trivial: FYI: you have to be committer Jacques -- Coherent Software Australia Pty Ltd PO Box 2773 Cheltenham Vic 3192 Phone: (03) 9585 6788 Fax: (03) 9585 1086 Web: http://www.cohsoft.com.au/ Email: sa...@cohsoft.com.au Bonsai ERP, the all-inclusive ERP system http://www.bonsaierp.com.au/
[jira] [Commented] (OFBIZ-4638) OFBiz does not build when using OpenJDK 7
[ https://issues.apache.org/jira/browse/OFBIZ-4638?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13219836#comment-13219836 ] Anne Jessel commented on OFBIZ-4638: I don't have the right compilers to test this, but my editor says both the original and the patched versions of CommonServices and WorldPayEvents are incorrect. It says the fix is the same as for OFBizSecurity, namely to change UtilMisc.toMap(...) to be similar to UtilMisc.String,StringtoMap(...). OFBiz does not build when using OpenJDK 7 - Key: OFBIZ-4638 URL: https://issues.apache.org/jira/browse/OFBIZ-4638 Project: OFBiz Issue Type: Bug Components: ALL APPLICATIONS Affects Versions: SVN trunk Environment: Ubuntu 11.10 $ java -version java version 1.7.0_147-icedtea OpenJDK Runtime Environment (IcedTea7 2.0) (7~b147-2.0-0ubuntu0.11.10.1) OpenJDK 64-Bit Server VM (build 21.0-b17, mixed mode) Reporter: Sam Hamilton Priority: Critical Attachments: OpenJDK 7 Error.txt, java7.patch OFBiz does not build when using OpenJDK 7. The log with the error is attached. Thanks Sam -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
Preferred solution to non-validating xml:lang?
The schema at framework/base/dtd/ofbiz-properties.xsd is intended for the labels xml files. Currently those files do not to refer to a schema. So I tried to change that. However the ofbiz-properties.xsd itself wouldn't validate, so I fixed that, and then added it as the schema to a sample labels.xml file for testing. Now I have a different problem relating to the xml:lang attribute. I need a solution or there is no point me submitting a patch. The existing code in UtilProperties compares the string generated by Locale's toString() with the value of the xml:lang attribute. An example string generated by Locale's toString() is pt_BR. Therefore that is the format of the string currently used with xml:lang in the labels.xml files. The xml:lang attribute definition (according to both the xml standard and the relevant xsd) states the value must be of the form pt-BR. That is, a - and not a _. This is incompatible with current usage in OFBiz. If I apply a schema to an existing labels.xml file, the xml will not validate. If I fix the xml so it validates, it of course won't work in OFBiz unless I also change UtilProperties. One solution would be to change UtilProperties: stop using Locale's toString(), and instead create a string with a '-' using Locale's getCountry() and getLanguage() methods (is the Locale variant used anywhere?). Then all the labels.xml files would need to have their value of xml:lang updated to use '-' instead of '_'. What is the community's preferred solution? Cheers, Anne. -- Coherent Software Australia Pty Ltd PO Box 2773 Cheltenham Vic 3192 Phone: (03) 9585 6788 Fax: (03) 9585 1086 Web: http://www.cohsoft.com.au/ Email: sa...@cohsoft.com.au Bonsai ERP, the all-inclusive ERP system http://www.bonsaierp.com.au/
[jira] [Commented] (OFBIZ-4709) Support jcr-stored file content within Applications
[ https://issues.apache.org/jira/browse/OFBIZ-4709?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13218929#comment-13218929 ] Anne Jessel commented on OFBIZ-4709: Thanks for restructuring the wiki page, Sascha. It will be easier to expand on now. I planned to add some draft design ideas today, but instead I have come up with lots of questions. I realised I don't understand well enough how you intended the existing JCR classes to be used. I am adding here some of my thoughts: hopefully that will help make it all clearer to me and maybe others. I can think of two general use cases (ignoring standard CRUD-type operations): * I have already information that specifies which content I want. For example, I have a PartyContent or ProductContent entity, and want the associated content. * I need to choose specific content based on certain criteria. For example, I want to display a list of available and current Data Sheets to the user. When the user chooses one, I will link it to a Product by creating a ProductContent. Initially I had in mind a general workflow as follows: # use current entity support to find desired Content entity (or maybe just contentId) # pass chosen Content entity (or contentId) to a ContentFactory class method # ContentFactory returns an object of an Interface type, with specific implementation determined by (at least) storageTypeId. # code that invoked ContentFactory uses methods of Interface to access actual content and its metadata, and does not need to know whether the content and metadata is from other Entities, or from JCR If we do this, the design of the Interface returned by the ContentFactory will be very important. If the orm classes and Jackrabbit annotations are used, I'm not sure how best to make use of Content entity in a generic way. Maybe there needs to be a different orm.jackrabbit class, and corresponding api.*Helper, for each ContentType? And the ContentFactory uses the contentTypeId field to work out what class to instantiate (but only when storageTypeId is JCR). If we store searchable metadata such as from/thruDate and contentType in JCR, then maybe we can't always do workflow step 1 the way I was thinking. Maybe we need also a ContentWorker that will do searches for us, and automatically knows how to search both Entities and JCR repository? Support jcr-stored file content within Applications --- Key: OFBIZ-4709 URL: https://issues.apache.org/jira/browse/OFBIZ-4709 Project: OFBiz Issue Type: Sub-task Components: ALL APPLICATIONS Affects Versions: SVN trunk Reporter: Anne Jessel Assignee: Sascha Rodekamp My current requirements: * store uploaded documents (pdf and scans), mainly for legal compliance reasons * old document versions should be accessible * documents should be associated with existing entities. So far I've identified a need to associate with Product, Party, OrderHeader, ShipmentItem, probably InventoryItemDetail and maybe WorkEffort. I would not be surprised if we discover more as this project proceeds. * documents may have a type and a purpose, though sometimes I'm not sure of the difference. For example, type: drivers_licence might be purpose: identification, and/or purpose: permission_to_drive, while type: shipping_label would be purpose: shipping_label * many documents have an expiry date (e.g. drivers licence) * a document may become invalid before its expiry date (e.g. because the law changed) * a specific version of a document may need to be associated with an entity. For example, a licence agreement document accessed via a Product should always be the latest version. However the version of that document actually shipped with the product should be associated with the ShipmentItem. * a single document might be associated with more than one entity type: see the example in the previous point Not all documents require all of the above. For example, there are some documents where we don't need to track which version was used when, and some without expiry dates. I'm thinking of using the from/thruDate pattern to handle expiry related needs. I'd like to put as much information into the jcr path as possible, so less needs to go into entities, as per Sascha's suggestion on the dev ML. However (at least) from/thruDate and which version of a document was actually used where will presumably need to be stored in an entity. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: Please review the text in the OFBiz download page
I can't find a way to log in and change it myself, but my suggested edits are trivial: where YY and MM are the year and month of when the release branch was created should be where YY and MM are the year and month the release branch was created (drop of when) Major Release Number is created every year on April should be Major Release Number is created every year in April (on becomes in) Minor Release Number is a two digits sequential number should be Minor Release Number is a two digit sequential number (singular, not plural, for digit) Cheers, Anne. On 27 February 2012 00:46, Jacopo Cappellato jacopo.cappell...@hotwaxmedia.com wrote: This is mainly a request for committers that are native English speaker: today I have edited/cleaned a lot of information in the download page: http://ofbiz.apache.org/download.html could you please review what I wrote and improve the English? Thank you, Jacopo -- Coherent Software Australia Pty Ltd PO Box 2773 Cheltenham Vic 3192 Phone: (03) 9585 6788 Fax: (03) 9585 1086 Web: http://www.cohsoft.com.au/ Email: sa...@cohsoft.com.au Bonsai ERP, the all-inclusive ERP system http://www.bonsaierp.com.au/
[jira] [Commented] (OFBIZ-4709) Support jcr-stored file content within Applications
[ https://issues.apache.org/jira/browse/OFBIZ-4709?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13217004#comment-13217004 ] Anne Jessel commented on OFBIZ-4709: Thanks all for the excellent feedback. Like many of you, I also like to have little data in the entities, and most in Jackrabbit. I would prefer to ignore the existing DataResource for this. I don't like storing a document's expiry date as from/thruDate in ProductContent, because one document could be associated with multiple Product, Party, ShipmentItem etc entity values. The same from/thruDate would have to be copied to all of these. To me, the from/thru in something like a ProductContent entity states when the association between the content and the product is valid, not when the content itself is valid. The difference doesn't really matter if a specific content is always related to only one product. If Jackrabbit can efficiently and easily support searches such as all documents of a certain type that have not expired then I'd prefer to put the expiry date in Jackrabbit. But if the OOTB entity system does a better job (as I suspect), then I'd rather expiry be in an entity. Anyone know which is more efficient? I think Jacopo misunderstood what I said about contentTypeId having values such as ANNOTATION. I don't wish to add those. That is what is there now. I was trying to say that I think the existing use of contentTypeId is not compatible with indicating whether content is stored in JCR or Entity, therefore I suggest we add a new field for that purpose, namely storageTypeId. Adrian asked whether there is a design document somewhere. No there isn't (except my scratches on paper). Do you think I should add a page on the wiki or something? I don't mind where we discuss this: I started on the ML, and was advised to move it to Jira, but maybe it has evolved such that Jira is no longer appropriate. It is time I did a summary of my understanding of the current consensus anyway, so let me know where you all would prefer me to put it. Support jcr-stored file content within Applications --- Key: OFBIZ-4709 URL: https://issues.apache.org/jira/browse/OFBIZ-4709 Project: OFBiz Issue Type: Sub-task Components: ALL APPLICATIONS Affects Versions: SVN trunk Reporter: Anne Jessel Assignee: Sascha Rodekamp My current requirements: * store uploaded documents (pdf and scans), mainly for legal compliance reasons * old document versions should be accessible * documents should be associated with existing entities. So far I've identified a need to associate with Product, Party, OrderHeader, ShipmentItem, probably InventoryItemDetail and maybe WorkEffort. I would not be surprised if we discover more as this project proceeds. * documents may have a type and a purpose, though sometimes I'm not sure of the difference. For example, type: drivers_licence might be purpose: identification, and/or purpose: permission_to_drive, while type: shipping_label would be purpose: shipping_label * many documents have an expiry date (e.g. drivers licence) * a document may become invalid before its expiry date (e.g. because the law changed) * a specific version of a document may need to be associated with an entity. For example, a licence agreement document accessed via a Product should always be the latest version. However the version of that document actually shipped with the product should be associated with the ShipmentItem. * a single document might be associated with more than one entity type: see the example in the previous point Not all documents require all of the above. For example, there are some documents where we don't need to track which version was used when, and some without expiry dates. I'm thinking of using the from/thruDate pattern to handle expiry related needs. I'd like to put as much information into the jcr path as possible, so less needs to go into entities, as per Sascha's suggestion on the dev ML. However (at least) from/thruDate and which version of a document was actually used where will presumably need to be stored in an entity. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (OFBIZ-4709) Support jcr-stored file content within Applications
[ https://issues.apache.org/jira/browse/OFBIZ-4709?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13215192#comment-13215192 ] Anne Jessel commented on OFBIZ-4709: Thanks everyone for the comments. I like the direction this is heading. I think the treatment of contentTypeId needs more work. Currently this has values such as ANNOTATION, DECORATOR, TOPIC. Adding JCR_CONTENT_ANNOTATION and similar would make it difficult to find all the ANNOTATION content. Perhaps we should add an extra field to Content, called storageTypeId? It could have two possible values (at this stage) ENTITY or JCR, with default being ENTITY for backwards compatability. Also, Content entity doesn't currently have from/thruDate fields. I'll need to add those. Support jcr-stored file content within Applications --- Key: OFBIZ-4709 URL: https://issues.apache.org/jira/browse/OFBIZ-4709 Project: OFBiz Issue Type: Sub-task Components: ALL APPLICATIONS Affects Versions: SVN trunk Reporter: Anne Jessel Assignee: Sascha Rodekamp My current requirements: * store uploaded documents (pdf and scans), mainly for legal compliance reasons * old document versions should be accessible * documents should be associated with existing entities. So far I've identified a need to associate with Product, Party, OrderHeader, ShipmentItem, probably InventoryItemDetail and maybe WorkEffort. I would not be surprised if we discover more as this project proceeds. * documents may have a type and a purpose, though sometimes I'm not sure of the difference. For example, type: drivers_licence might be purpose: identification, and/or purpose: permission_to_drive, while type: shipping_label would be purpose: shipping_label * many documents have an expiry date (e.g. drivers licence) * a document may become invalid before its expiry date (e.g. because the law changed) * a specific version of a document may need to be associated with an entity. For example, a licence agreement document accessed via a Product should always be the latest version. However the version of that document actually shipped with the product should be associated with the ShipmentItem. * a single document might be associated with more than one entity type: see the example in the previous point Not all documents require all of the above. For example, there are some documents where we don't need to track which version was used when, and some without expiry dates. I'm thinking of using the from/thruDate pattern to handle expiry related needs. I'd like to put as much information into the jcr path as possible, so less needs to go into entities, as per Sascha's suggestion on the dev ML. However (at least) from/thruDate and which version of a document was actually used where will presumably need to be stored in an entity. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (OFBIZ-4709) Support jcr-stored file content within Applications
[ https://issues.apache.org/jira/browse/OFBIZ-4709?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13214373#comment-13214373 ] Anne Jessel commented on OFBIZ-4709: Hi Sascha I agree with you. There will need to be entities to track the connections, so the key thing is what goes in an entity and what in a node. I'm thinking we will need several new entities such as PartyContentJcr and ProductContentJcr (suggestions for names welcome). Should these link directly to jcr nodes, or should there be a ContentJcr entity which represents the jcr node? I think a ContentJcr, so we can store (at least) from/thruDate there. But the reason I think that is because I am familiar with OOTB support for from/thruDate queries. I do not know jcr well enough: would these queries be just as efficient with the Jackrabbit SQL2 queries? Rights management is not an issue for me. But I am sure it will need to be added sometime. Support jcr-stored file content within Applications --- Key: OFBIZ-4709 URL: https://issues.apache.org/jira/browse/OFBIZ-4709 Project: OFBiz Issue Type: Sub-task Components: ALL APPLICATIONS Affects Versions: SVN trunk Reporter: Anne Jessel Assignee: Sascha Rodekamp My current requirements: * store uploaded documents (pdf and scans), mainly for legal compliance reasons * old document versions should be accessible * documents should be associated with existing entities. So far I've identified a need to associate with Product, Party, OrderHeader, ShipmentItem, probably InventoryItemDetail and maybe WorkEffort. I would not be surprised if we discover more as this project proceeds. * documents may have a type and a purpose, though sometimes I'm not sure of the difference. For example, type: drivers_licence might be purpose: identification, and/or purpose: permission_to_drive, while type: shipping_label would be purpose: shipping_label * many documents have an expiry date (e.g. drivers licence) * a document may become invalid before its expiry date (e.g. because the law changed) * a specific version of a document may need to be associated with an entity. For example, a licence agreement document accessed via a Product should always be the latest version. However the version of that document actually shipped with the product should be associated with the ShipmentItem. * a single document might be associated with more than one entity type: see the example in the previous point Not all documents require all of the above. For example, there are some documents where we don't need to track which version was used when, and some without expiry dates. I'm thinking of using the from/thruDate pattern to handle expiry related needs. I'd like to put as much information into the jcr path as possible, so less needs to go into entities, as per Sascha's suggestion on the dev ML. However (at least) from/thruDate and which version of a document was actually used where will presumably need to be stored in an entity. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: Extending Jackrabbit/JCR support
Thanks for the feedback, Sascha. I was thinking that following the existing Content pattern might be easier for others to understand and hence migrate to. It might also be a way to support usage patterns I have not though of. However if we can use this as an opportunity to both improve and simplify things with a new improved design, that would be great. I over-simplified my requirements in my last email. I'll create a sub-task under OFBIZ-4659 https://issues.apache.org/jira/browse/OFBIZ-4659 as you suggested, and add some relevant detail there for further discussion. Cheers, Anne. On 21 February 2012 20:38, Sascha Rodekamp sascha.rodekamp.lynx...@googlemail.com wrote: Hi Anne, that is a great idea. The Association between products and content in the JCR repository is one of the next steps which i plan to implement so every help and ideas are welcome. For all Jackrabbit related Tickets i created an Umbrella task, which could be found under: https://issues.apache.org/jira/browse/OFBIZ-4659 This is the best starting point for any further discussion. I haven't thought about an solution in detail yet. But i was wondering if an entity that represent the connection between product and content is really necessary. What if we assign a unique node path to each product content? I.e. /categoryOne/SubCategory/product-1701/long-description/en If we define a node name pattern for these kind of content a database entry is superfluous, isn't it? Cheers Sascha 2012/2/20 Anne a...@cohsoft.com.au: Hi We have a requirement to allow the user to upload files associated with products. These files may need to be updated, and versioning would be useful. I would like to use the new JCR support for this, but of course the OOTB support is currently basic (but welcome!) and doesn't support association of the uploaded files with a product. I therefore plan on implementing very simple support, based on the current Content and ProductContent entity model. I'm thinking of new ContentJcr and ProductContentJcr entities, with relevant CRUD services. Also a helper that fetches the file referred to by a ContentJcr. As our needs are simple, I don't plan on implementing all the features currently found in the Content and ProductContent ecosystem, but I thought our implementation might be a useful starting point for others to build on. Would it be useful for me to create a Jira with this proposal, to which I could attach patches once we've implemented it? And more importantly, does anyone have comments or suggestions that might make our implementation more useful to others? Cheers, Anne. -- Coherent Software Australia Pty Ltd PO Box 2773 Cheltenham Vic 3192 Phone: (03) 9585 6788 Fax: (03) 9585 1086 Web: http://www.cohsoft.com.au/ Email: sa...@cohsoft.com.au Bonsai ERP, the all-inclusive ERP system http://www.bonsaierp.com.au/ -- Sascha Rodekamp Visit the new german OFBiz Blog: http://www.ofbiz.biz Lynx-Consulting GmbH Johanniskirchplatz 6 D-33615 Bielefeld http://www.lynx.de -- Coherent Software Australia Pty Ltd PO Box 2773 Cheltenham Vic 3192 Phone: (03) 9585 6788 Fax: (03) 9585 1086 Web: http://www.cohsoft.com.au/ Email: sa...@cohsoft.com.au Bonsai ERP, the all-inclusive ERP system http://www.bonsaierp.com.au/
[jira] [Commented] (OFBIZ-4678) widget image tag to use css for resizing
[ https://issues.apache.org/jira/browse/OFBIZ-4678?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13213231#comment-13213231 ] Anne Jessel commented on OFBIZ-4678: I would be sorry to see the width and height go, but do not object as I understand the reasons. The ideal solution would indeed be for the server to insert the real width and height. However as I said before, I couldn't see a practical way to do that. widget image tag to use css for resizing -- Key: OFBIZ-4678 URL: https://issues.apache.org/jira/browse/OFBIZ-4678 Project: OFBiz Issue Type: Improvement Components: ALL COMPONENTS Affects Versions: SVN trunk Reporter: Wai Priority: Minor Attachments: ofbiz-4678.patch, ofbiz-4678.patch, ofbiz-4678.patch, ofbiz-4678.patch -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (OFBIZ-4709) Support jcr-stored file content within Applications
Support jcr-stored file content within Applications --- Key: OFBIZ-4709 URL: https://issues.apache.org/jira/browse/OFBIZ-4709 Project: OFBiz Issue Type: Sub-task Components: ALL APPLICATIONS Affects Versions: SVN trunk Reporter: Anne Jessel My current requirements: * store uploaded documents (pdf and scans), mainly for legal compliance reasons * old document versions should be accessible * documents should be associated with existing entities. So far I've identified a need to associate with Product, Party, OrderHeader, ShipmentItem, probably InventoryItemDetail and maybe WorkEffort. I would not be surprised if we discover more as this project proceeds. * documents may have a type and a purpose, though sometimes I'm not sure of the difference. For example, type: drivers_licence might be purpose: identification, and/or purpose: permission_to_drive, while type: shipping_label would be purpose: shipping_label * many documents have an expiry date (e.g. drivers licence) * a document may become invalid before its expiry date (e.g. because the law changed) * a specific version of a document may need to be associated with an entity. For example, a licence agreement document accessed via a Product should always be the latest version. However the version of that document actually shipped with the product should be associated with the ShipmentItem. * a single document might be associated with more than one entity type: see the example in the previous point Not all documents require all of the above. For example, there are some documents where we don't need to track which version was used when, and some without expiry dates. I'm thinking of using the from/thruDate pattern to handle expiry related needs. I'd like to put as much information into the jcr path as possible, so less needs to go into entities, as per Sascha's suggestion on the dev ML. However (at least) from/thruDate and which version of a document was actually used where will presumably need to be stored in an entity. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: Extending Jackrabbit/JCR support
Created https://issues.apache.org/jira/browse/OFBIZ-4709 We will rethink and discuss the design in-house, ignoring the current Content pattern, and I'll update Jira with our thoughts tomorrow. More advice from others is very welcome. Cheers, Anne. On 22 February 2012 14:07, Anne a...@cohsoft.com.au wrote: Thanks for the feedback, Sascha. I was thinking that following the existing Content pattern might be easier for others to understand and hence migrate to. It might also be a way to support usage patterns I have not though of. However if we can use this as an opportunity to both improve and simplify things with a new improved design, that would be great. I over-simplified my requirements in my last email. I'll create a sub-task under OFBIZ-4659 https://issues.apache.org/jira/browse/OFBIZ-4659 as you suggested, and add some relevant detail there for further discussion. Cheers, Anne. On 21 February 2012 20:38, Sascha Rodekamp sascha.rodekamp.lynx...@googlemail.com wrote: Hi Anne, that is a great idea. The Association between products and content in the JCR repository is one of the next steps which i plan to implement so every help and ideas are welcome. For all Jackrabbit related Tickets i created an Umbrella task, which could be found under: https://issues.apache.org/jira/browse/OFBIZ-4659 This is the best starting point for any further discussion. I haven't thought about an solution in detail yet. But i was wondering if an entity that represent the connection between product and content is really necessary. What if we assign a unique node path to each product content? I.e. /categoryOne/SubCategory/product-1701/long-description/en If we define a node name pattern for these kind of content a database entry is superfluous, isn't it? Cheers Sascha 2012/2/20 Anne a...@cohsoft.com.au: Hi We have a requirement to allow the user to upload files associated with products. These files may need to be updated, and versioning would be useful. I would like to use the new JCR support for this, but of course the OOTB support is currently basic (but welcome!) and doesn't support association of the uploaded files with a product. I therefore plan on implementing very simple support, based on the current Content and ProductContent entity model. I'm thinking of new ContentJcr and ProductContentJcr entities, with relevant CRUD services. Also a helper that fetches the file referred to by a ContentJcr. As our needs are simple, I don't plan on implementing all the features currently found in the Content and ProductContent ecosystem, but I thought our implementation might be a useful starting point for others to build on. Would it be useful for me to create a Jira with this proposal, to which I could attach patches once we've implemented it? And more importantly, does anyone have comments or suggestions that might make our implementation more useful to others? Cheers, Anne. -- Coherent Software Australia Pty Ltd PO Box 2773 Cheltenham Vic 3192 Phone: (03) 9585 6788 Fax: (03) 9585 1086 Web: http://www.cohsoft.com.au/ Email: sa...@cohsoft.com.au Bonsai ERP, the all-inclusive ERP system http://www.bonsaierp.com.au/ -- Sascha Rodekamp Visit the new german OFBiz Blog: http://www.ofbiz.biz Lynx-Consulting GmbH Johanniskirchplatz 6 D-33615 Bielefeld http://www.lynx.de -- Coherent Software Australia Pty Ltd PO Box 2773 Cheltenham Vic 3192 Phone: (03) 9585 6788 Fax: (03) 9585 1086 Web: http://www.cohsoft.com.au/ Email: sa...@cohsoft.com.au Bonsai ERP, the all-inclusive ERP system http://www.bonsaierp.com.au/ -- Coherent Software Australia Pty Ltd PO Box 2773 Cheltenham Vic 3192 Phone: (03) 9585 6788 Fax: (03) 9585 1086 Web: http://www.cohsoft.com.au/ Email: sa...@cohsoft.com.au Bonsai ERP, the all-inclusive ERP system http://www.bonsaierp.com.au/
[jira] [Commented] (OFBIZ-4678) widget image tag to use css for resizing
[ https://issues.apache.org/jira/browse/OFBIZ-4678?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13211688#comment-13211688 ] Anne Jessel commented on OFBIZ-4678: In the old days, one always included width and height in an img tag so that the browser could layout the page before the image had been downloaded. If width and height were not present, then as each image arrived the page would be completely reformatted and redrawn. This flashing of the page was disconcerting for users with slow connections. I see this patch removes the width and height from the img tags. Is that because browser technology has moved on, and the major reason for including those attributes no longer applies? BTW I looked a while ago at including the real image size in the img tag, but couldn't see a practical way to do it. widget image tag to use css for resizing -- Key: OFBIZ-4678 URL: https://issues.apache.org/jira/browse/OFBIZ-4678 Project: OFBiz Issue Type: Improvement Components: ALL COMPONENTS Affects Versions: SVN trunk Reporter: Wai Priority: Minor Attachments: ofbiz-4678.patch, ofbiz-4678.patch, ofbiz-4678.patch, ofbiz-4678.patch -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
Extending Jackrabbit/JCR support
Hi We have a requirement to allow the user to upload files associated with products. These files may need to be updated, and versioning would be useful. I would like to use the new JCR support for this, but of course the OOTB support is currently basic (but welcome!) and doesn't support association of the uploaded files with a product. I therefore plan on implementing very simple support, based on the current Content and ProductContent entity model. I'm thinking of new ContentJcr and ProductContentJcr entities, with relevant CRUD services. Also a helper that fetches the file referred to by a ContentJcr. As our needs are simple, I don't plan on implementing all the features currently found in the Content and ProductContent ecosystem, but I thought our implementation might be a useful starting point for others to build on. Would it be useful for me to create a Jira with this proposal, to which I could attach patches once we've implemented it? And more importantly, does anyone have comments or suggestions that might make our implementation more useful to others? Cheers, Anne. -- Coherent Software Australia Pty Ltd PO Box 2773 Cheltenham Vic 3192 Phone: (03) 9585 6788 Fax: (03) 9585 1086 Web: http://www.cohsoft.com.au/ Email: sa...@cohsoft.com.au Bonsai ERP, the all-inclusive ERP system http://www.bonsaierp.com.au/
[jira] [Created] (OFBIZ-4675) Incorrect fix applied in OFBIZ-4381
Incorrect fix applied in OFBIZ-4381 --- Key: OFBIZ-4675 URL: https://issues.apache.org/jira/browse/OFBIZ-4675 Project: OFBiz Issue Type: Bug Components: commonext/setup Affects Versions: Release 10.04, Release Branch 11.04, SVN trunk Reporter: Anne Jessel The fix applied in OFBIZ-4381 was to copy DemoShipping.xml from the ecommerce component (where it is loaded as DEMO data), and add it to commonext component as SEED data. IMO this data should not be part of SEED data, as not all users will use this data. Also, the file should not be duplicated. I suggest reverting trunk r1167510, R11.04 r1167513, R10.04 r1167514. I suspect the correct fix for OFBIZ-4381 is either for the user to load the demo data, or to configure the carriers before trying to create a ProductStore. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: Why not overcome minlang's weakness.....attract new developers instead of letting something so easily fixed scare them off
Last week I attended the Open Source Developers Conference in Australia. I went to a few talks that discussed using Groovy to create a DSL. At the time, I thought it would be a great replacement for minilang. Properly designed, it could have all the benefits of minilang, combined with the benefits of Groovy, and the possibility of compiling to a jar for production. An added advantage is that groovy is already fully supported OOTB in OFBiz, so no new third-party jars need be added. One such talk was Groovy DSLs from beginner to expert by Paul King, the slides of which are available on slideshare.net. One of his examples was a Medical Prescription DSL, where the resultant groovy script was: take 2.pills of chloroquinine after 6.hours Unfortunately I don't currently have the time to work on the design and implementation of a groovy-based DSL for OFBiz. :-( Cheers, Anne. On 22 November 2011 04:32, BJ Freeman bjf...@free-man.net wrote: I am not sure how you first paragraph relates to minilang and jumping. Minilang is defines as events (not ECA) or Service in other places. This is the same for Java and would require the same tracing. ECA are keyed off of ENtities changes and Service, whether Minilang or Java. Simple has nothing to do with the length of code but making a line of code that takes multiple java code lines to accomplish. I do agree that all mini code should be reviewed and take repetitive code and break it out as a re-factor. That is a major effort and based on the way people code and add to the SVN without reviewing what code is available, I doubt it would stay clean. ki...@objectedge.com sent the following on 11/20/2011 8:21 AM: I agree that minilang is easy understand as long as the methods are truly simple. i.e: you don't have to jump between other methods/services, eca rules, etc. Take an example of createCustomermethod in ecommerce. This simple-method is over 400 lines. How is that simple :-) Now whether you write it java or minilang it will be difficult for the reader to understand. But I feel it is better to write such methods in Java. Of course, even in Java it should be made more modular (using refactoring tools). Then you can use find references or implementation. Selecting variable highlights it across entire method/class. You can use debugging tools: set breakpoint, view variables, step in/over, drop to frame, etc. Ideally the simple-method shouldn't grow beyond scrollable window in Eclipse say 40 lines. Regards, Kiran Gawde Senior Software Architect Object Edge Inc (925) 943 5558 x108 There are two kind of people: Those who do the work and those who take the credit. Try to be in the first group because there is less competition there. Never give up on what you really want to do. The person with big dreams is more powerful than one with all the facts. From: BJ Freeman bjf...@free-man.net To: dev@ofbiz.apache.org Date: 11/19/2011 06:07 PM Subject:Re: Why not overcome minlang's weakness.attract new developers instead of letting something so easily fixed scare them off short answer is to add to webtools artifacts. Have you investigated that section of ofbiz? The basics is Java increases bloat by creating classes. I find the concept the ofbiz is java based is what throws a lot of people. The frame of mind that Ofbiz was made to work in a java environment is more accurate in my opinion. It takes more lines of code in Java to accomplish the same n minilang. However a happy medium is to use Grovvy. I shy away from Opentaps because they broke the design rules that brought me to ofbiz. Justin Robinson sent the following on 11/19/2011 4:57 AM: But Minilang would be the better option because with Minilang, the developers time is much reduced as it is used to implement simple and repetitive tasks - from the article OFBiz Framework: An Innovative Approach to E-commerce http://www.dotcominfoway.com/blog/ofbiz-framework-an-innovative-approach-to-e-commerce Why not overcome minlang's weakness. Minilang seems to be one of the reasons for the branch in projects (well that's entirely speculation on my part)it seems a bone of contention and I've seen posts where people complain about how difficult it is to debug, how they've had to get rid of developers who refused to learn it. On the wiki of one of the main down stream projects Opentaps it says: don't ever write one in minilang!http://www.opentaps.org/docs/index.php/Danc_-_temp#Services I personally don't enjoy working in minilang, scanning hundreds of lines of minilang then using 'simple method' names together with search find to move between files to trace a path of execution looking for a bug or that one small operation somewhere in the service chain I need to disable, gives me a headache. However a couple of months ago I decided
[jira] [Updated] (OFBIZ-4393) View entity condition-expr doesn't handle null
[ https://issues.apache.org/jira/browse/OFBIZ-4393?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anne Jessel updated OFBIZ-4393: --- Attachment: OFBIZ-4393-view-entity_condition-expr_null.patch Updated patch based on Adrian's, that adds changes suggested by Leon based on OFBIZ-4523 View entity condition-expr doesn't handle null -- Key: OFBIZ-4393 URL: https://issues.apache.org/jira/browse/OFBIZ-4393 Project: OFBiz Issue Type: Bug Components: framework Affects Versions: SVN trunk Environment: Rev 1165137 Reporter: Anne Jessel Assignee: Adrian Crum Attachments: OFBIZ-4393-view-entity_condition-expr_null.patch, OFBIZ-4393-view-entity_condition-expr_null.patch, OFBIZ-4393-view-entity_condition-expr_null.patch Original Estimate: 2h Remaining Estimate: 2h condition-expr tag in view-entity can't be used to compare a field with null. An absent value attribute is read as an empty string, and the code currently checks for value being null to know when to compare against null. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (OFBIZ-4393) View entity condition-expr doesn't handle null
[ https://issues.apache.org/jira/browse/OFBIZ-4393?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13148107#comment-13148107 ] Anne Jessel commented on OFBIZ-4393: I've tested a combination of Adrian's approach and Leon's comments regarding relFieldName, and uploaded a new patch. I can confirm it works for my use case. A condition-expr in a view-entity that has no value or rel-field-name will now correctly compare with null. In reviewing the relevant code, I did notice a potential change in behaviour with this approach. Because an absent value and value= are treated the same way, a NOT_EQUAL comparison with the empty string will be treated as a NOT_EQUAL test with null instead. View entity condition-expr doesn't handle null -- Key: OFBIZ-4393 URL: https://issues.apache.org/jira/browse/OFBIZ-4393 Project: OFBiz Issue Type: Bug Components: framework Affects Versions: SVN trunk Environment: Rev 1165137 Reporter: Anne Jessel Assignee: Adrian Crum Attachments: OFBIZ-4393-view-entity_condition-expr_null.patch, OFBIZ-4393-view-entity_condition-expr_null.patch, OFBIZ-4393-view-entity_condition-expr_null.patch Original Estimate: 2h Remaining Estimate: 2h condition-expr tag in view-entity can't be used to compare a field with null. An absent value attribute is read as an empty string, and the code currently checks for value being null to know when to compare against null. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (OFBIZ-4393) View entity condition-expr doesn't handle null
[ https://issues.apache.org/jira/browse/OFBIZ-4393?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13148121#comment-13148121 ] Anne Jessel commented on OFBIZ-4393: On consideration, I don't think the change in behaviour is a major problem. This patch supports EQUALS with null, which the previous code did not support. IMO comparisons with null are very useful. However we lose the specific NOT_EQUAL with empty string, IMO an uncommon test, especially in a view-entity. Overall a big gain, but perhaps not yet a perfect solution. View entity condition-expr doesn't handle null -- Key: OFBIZ-4393 URL: https://issues.apache.org/jira/browse/OFBIZ-4393 Project: OFBiz Issue Type: Bug Components: framework Affects Versions: SVN trunk Environment: Rev 1165137 Reporter: Anne Jessel Assignee: Adrian Crum Attachments: OFBIZ-4393-view-entity_condition-expr_null.patch, OFBIZ-4393-view-entity_condition-expr_null.patch, OFBIZ-4393-view-entity_condition-expr_null.patch Original Estimate: 2h Remaining Estimate: 2h condition-expr tag in view-entity can't be used to compare a field with null. An absent value attribute is read as an empty string, and the code currently checks for value being null to know when to compare against null. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (OFBIZ-4393) View entity condition-expr doesn't handle null
[ https://issues.apache.org/jira/browse/OFBIZ-4393?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13146659#comment-13146659 ] Anne Jessel commented on OFBIZ-4393: I would expect it to work, but will try it out to be sure. Won't be able to do so for a day or two, though. View entity condition-expr doesn't handle null -- Key: OFBIZ-4393 URL: https://issues.apache.org/jira/browse/OFBIZ-4393 Project: OFBiz Issue Type: Bug Components: framework Affects Versions: SVN trunk Environment: Rev 1165137 Reporter: Anne Jessel Assignee: Adrian Crum Attachments: OFBIZ-4393-view-entity_condition-expr_null.patch, OFBIZ-4393-view-entity_condition-expr_null.patch Original Estimate: 2h Remaining Estimate: 2h condition-expr tag in view-entity can't be used to compare a field with null. An absent value attribute is read as an empty string, and the code currently checks for value being null to know when to compare against null. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (OFBIZ-4393) View entity condition-expr doesn't handle null
[ https://issues.apache.org/jira/browse/OFBIZ-4393?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13145185#comment-13145185 ] Anne Jessel commented on OFBIZ-4393: FWIW I prefer Adrian's way. My patch aimed for the minimum change needed to fix the identified and testable problem. I would have done it Adrian's way if I was confident there were no side effects. View entity condition-expr doesn't handle null -- Key: OFBIZ-4393 URL: https://issues.apache.org/jira/browse/OFBIZ-4393 Project: OFBiz Issue Type: Bug Components: framework Affects Versions: SVN trunk Environment: Rev 1165137 Reporter: Anne Jessel Assignee: Adrian Crum Attachments: OFBIZ-4393-view-entity_condition-expr_null.patch, OFBIZ-4393-view-entity_condition-expr_null.patch Original Estimate: 2h Remaining Estimate: 2h condition-expr tag in view-entity can't be used to compare a field with null. An absent value attribute is read as an empty string, and the code currently checks for value being null to know when to compare against null. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: Incorrect use of eca for create/updateShipment
Basically I agree with Jacques. I am in favour of keeping ECAs, as I believe them (seca, eeca and meca) to be a useful and powerful extension mechanism. However I think they are misused and overused in OOTB code. It is a while since I looked closely at them, so I can't give examples, but I have seen places where I couldn't understand why they were being used in preference to changing the triggering service. Which means either I didn't understand that part of the system properly, or they shouldn't have been implemented as ecas. It looks like Kiran has found and fixed one of the eca mis-uses. An update of an entity being triggered by a create of the same entity does not sound sensible. Surely the entity should be created correctly the first time, and not rely on triggered updates to reach a desired state. The risk of timing and similar bugs is high, for what advantage? An example of where I think a seca often makes sense: when a status change in one entity should trigger an async change elsewhere (not in the same entity). Cheers, Anne. On 5 November 2011 08:59, Jacques Le Roux jacques.le.r...@les7arts.com wrote: I think that if we want to discuss this seriously we need to have 1st a clear and complete workflow of ECA use in OFBiz. IMO, the Event Driven Architecture (EDA) http://en.wikipedia.org/wiki/Event-driven_architecture, is well adapted to complete SOA (Service Oriented Architecture). But one Criticism of Event Driven Programming (http://en.wikipedia.org/wiki/Event-driven_programming#Criticism_and_best_practice) apply: it can lead programmers to create difficult to extend and, especially, excessively complex application code. So it's rather a matter of use and abuse. In other words, I'd be ok to remove abuse but not use. In some cases it's very convenient... Jacques J. Eckard wrote: I spend a great deal of time reading through existing OFBiz codebases to get a handle on process implementations, an experience that feels much more tedious and frustrating than it should. One of the things that contributes to the difficulty is the practice of using EECAs and / or SECAs to orchestrate a basic process with smaller, specialized services. I was hesitant to bring this up because I don't have any concrete suggestions or guidelines for improvements - its more of a nagging feeling I get when I see ECAs that are not very generic or used outside of the orchestration, or ECAs that perform crucial tasks that you would never want to disable or remove. Joe On Nov 3, 2011, at 2:12 PM, Adrian Crum wrote: Actually, what I recommended was a discussion on using/removing ECAs in general - not this specific case. -Adrian On 11/3/2011 5:15 PM, ki...@objectedge.com wrote: Hello Friends, In case of createShipment, during commit, eca rules are fired. These invoke updateShipment(i.e: even before commit on createShipment is complete). Update Shipment is called multiple times (You can view the log during quickShipOrder/quickDropShipOrder). Also, these rules are fired in incorrect order. These rules are updating the same shipment that is being committed by the original method. I believe this is incorrect. I have verified the functionality of quickShipOrder/quickDropShipOrder after the changes. Let me know if there are any testcases that I need to run. Please take a look at email thread for more details. Let me know if you have questions and concerns. If we integrate the change sooner, we can avoid merge conflicts. PS: Thanks Adrian and Anil for your vote of confidence. As per your recommendation, I am posting this to dev mailing list. Regards, Kiran Gawde Senior Software Architect Object Edge Inc (925) 943 5558 x108 There are two kind of people: Those who do the work and those who take the credit. Try to be in the first group because there is less competition there. Never give up on what you really want to do. The person with big dreams is more powerful than one with all the facts. From: Adrian Crum (Commented) (JIRA)j...@apache.org To: ki...@objectedge.com Date: 11/03/2011 02:04 AM Subject: [jira] [Commented] (OFBIZ-4501) Incorrect use of eca for create/updateShipment [ https://issues.apache.org/jira/browse/OFBIZ-4501?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13142972#comment-13142972 ] Adrian Crum commented on OFBIZ-4501: Kiran, Thank you for working on this. I agree that the overuse of ECAs causes problems and makes the services difficult to troubleshoot. But removing them is going to be a tough sell because many in the community see it as a feature - they see it as a crude form of a workflow implementation. I have added my vote to this issue because I believe a lot of the ECAs should go away. It might help your cause to start a discussion on the dev mailing list and see if you can rally some more support for ECA
[jira] [Commented] (OFBIZ-4393) View entity condition-expr doesn't handle null
[ https://issues.apache.org/jira/browse/OFBIZ-4393?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13137709#comment-13137709 ] Anne Jessel commented on OFBIZ-4393: The point is that the code quoted by Leon will never be executed, because 'value' will never be null. If value is absent in the xml, then it is read as an empty string. value is intialised using org.w3c.dom.Element.getAttribute() which never returns null, according to the documentation. View entity condition-expr doesn't handle null -- Key: OFBIZ-4393 URL: https://issues.apache.org/jira/browse/OFBIZ-4393 Project: OFBiz Issue Type: Bug Components: framework Affects Versions: SVN trunk Environment: Rev 1165137 Reporter: Anne Jessel Attachments: OFBIZ-4393-view-entity_condition-expr_null.patch Original Estimate: 2h Remaining Estimate: 2h condition-expr tag in view-entity can't be used to compare a field with null. An absent value attribute is read as an empty string, and the code currently checks for value being null to know when to compare against null. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (OFBIZ-3847) Entity ECAs not triggered correctly when using Delegator.storeAll() method
[
https://issues.apache.org/jira/browse/OFBIZ-3847?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Anne Jessel updated OFBIZ-3847:
---
Attachment: OFBIZ-3847_Entity-ECAs-not-triggered-correctly.patch
Entity ECAs not triggered correctly when using Delegator.storeAll() method
--
Key: OFBIZ-3847
URL: https://issues.apache.org/jira/browse/OFBIZ-3847
Project: OFBiz
Issue Type: Bug
Components: framework
Affects Versions: Release Branch 10.04
Reporter: Martin Kreidenweis
Attachments: GenericDelegator.java.diff,
OFBIZ-3847_Entity-ECAs-not-triggered-correctly.patch
The conditions don't work when updating (not creating) entities using the
Delegator.storeAll() method. E.g. the following condition does not work:
{code}
eca entity=Product operation=create-store event=return
condition field-name=autoCreateKeywords operator=not-equals
value=N/
action service=indexProductKeywords mode=sync
value-attr=productInstance/
/eca
{code}
The indexProductKeywords service is called anyway when the product is updated
and the autoCreateKeywords was N and stays N. It works correctly for
newly created products.
The problem is in the method GenericDelegator.storeAll(), where unchanged
field values are not passed down to the store() method. The store method
calls the ECA engine, which does not receive the unchanged values at all and
thus cannot evaluate the EECA conditions correctly.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (OFBIZ-3847) Entity ECAs not triggered correctly when using Delegator.storeAll() method
[
https://issues.apache.org/jira/browse/OFBIZ-3847?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13134730#comment-13134730
]
Anne Jessel commented on OFBIZ-3847:
I've created a patch modeled after Scott's suggestion. I'd appreciate someone
reviewing it. It does work for me, however I am concerned that it might fail
when the value of a field that is part of the EECA condition is being changed
from non-null to null using GenericDelegator.storeAll, because of the way
storeAll works. There may be a simple solution I've missed.
Entity ECAs not triggered correctly when using Delegator.storeAll() method
--
Key: OFBIZ-3847
URL: https://issues.apache.org/jira/browse/OFBIZ-3847
Project: OFBiz
Issue Type: Bug
Components: framework
Affects Versions: Release Branch 10.04
Reporter: Martin Kreidenweis
Attachments: GenericDelegator.java.diff,
OFBIZ-3847_Entity-ECAs-not-triggered-correctly.patch
The conditions don't work when updating (not creating) entities using the
Delegator.storeAll() method. E.g. the following condition does not work:
{code}
eca entity=Product operation=create-store event=return
condition field-name=autoCreateKeywords operator=not-equals
value=N/
action service=indexProductKeywords mode=sync
value-attr=productInstance/
/eca
{code}
The indexProductKeywords service is called anyway when the product is updated
and the autoCreateKeywords was N and stays N. It works correctly for
newly created products.
The problem is in the method GenericDelegator.storeAll(), where unchanged
field values are not passed down to the store() method. The store method
calls the ECA engine, which does not receive the unchanged values at all and
thus cannot evaluate the EECA conditions correctly.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (OFBIZ-4510) List css before js in ecommerce header
List css before js in ecommerce header -- Key: OFBIZ-4510 URL: https://issues.apache.org/jira/browse/OFBIZ-4510 Project: OFBiz Issue Type: Improvement Components: specialpurpose/ecommerce Affects Versions: SVN trunk Reporter: Anne Jessel Priority: Trivial Attachments: OFBIZ-4510_List-css-before-js-in-ecommerce.patch Trivial patch to list css before js in ecommerce pages. This helps some browsers display pages faster. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (OFBIZ-4510) List css before js in ecommerce header
[ https://issues.apache.org/jira/browse/OFBIZ-4510?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anne Jessel updated OFBIZ-4510: --- Attachment: OFBIZ-4510_List-css-before-js-in-ecommerce.patch List css before js in ecommerce header -- Key: OFBIZ-4510 URL: https://issues.apache.org/jira/browse/OFBIZ-4510 Project: OFBiz Issue Type: Improvement Components: specialpurpose/ecommerce Affects Versions: SVN trunk Reporter: Anne Jessel Priority: Trivial Attachments: OFBIZ-4510_List-css-before-js-in-ecommerce.patch Original Estimate: 10m Remaining Estimate: 10m Trivial patch to list css before js in ecommerce pages. This helps some browsers display pages faster. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (OFBIZ-4511) Non-standard markup for categories screenlet
Non-standard markup for categories screenlet Key: OFBIZ-4511 URL: https://issues.apache.org/jira/browse/OFBIZ-4511 Project: OFBiz Issue Type: Bug Components: specialpurpose/ecommerce Affects Versions: SVN trunk Reporter: Anne Jessel Priority: Trivial ProductCategories.ftl uses markup for the screenlet title area that is different to that commonly used for screenlets within ecommerce. This patch makes the markup more like other screenlets. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (OFBIZ-4511) Non-standard markup for categories screenlet
[ https://issues.apache.org/jira/browse/OFBIZ-4511?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anne Jessel updated OFBIZ-4511: --- Attachment: OFBIZ-4511_non-standard-markup-categories-screenlet.patch Non-standard markup for categories screenlet Key: OFBIZ-4511 URL: https://issues.apache.org/jira/browse/OFBIZ-4511 Project: OFBiz Issue Type: Bug Components: specialpurpose/ecommerce Affects Versions: SVN trunk Reporter: Anne Jessel Priority: Trivial Attachments: OFBIZ-4511_non-standard-markup-categories-screenlet.patch Original Estimate: 10m Remaining Estimate: 10m ProductCategories.ftl uses markup for the screenlet title area that is different to that commonly used for screenlets within ecommerce. This patch makes the markup more like other screenlets. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (OFBIZ-3847) Entity ECAs not triggered correctly when using Delegator.storeAll() method
[
https://issues.apache.org/jira/browse/OFBIZ-3847?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13114427#comment-13114427
]
Anne Jessel commented on OFBIZ-3847:
This bug is one I'd like to fix. Scott's suggestion looks good to me. Anyone
have any comments or better ideas before I go ahead and implement it?
Entity ECAs not triggered correctly when using Delegator.storeAll() method
--
Key: OFBIZ-3847
URL: https://issues.apache.org/jira/browse/OFBIZ-3847
Project: OFBiz
Issue Type: Bug
Components: framework
Affects Versions: Release Branch 10.04
Reporter: Martin Kreidenweis
Attachments: GenericDelegator.java.diff
The conditions don't work when updating (not creating) entities using the
Delegator.storeAll() method. E.g. the following condition does not work:
{code}
eca entity=Product operation=create-store event=return
condition field-name=autoCreateKeywords operator=not-equals
value=N/
action service=indexProductKeywords mode=sync
value-attr=productInstance/
/eca
{code}
The indexProductKeywords service is called anyway when the product is updated
and the autoCreateKeywords was N and stays N. It works correctly for
newly created products.
The problem is in the method GenericDelegator.storeAll(), where unchanged
field values are not passed down to the store() method. The store method
calls the ECA engine, which does not receive the unchanged values at all and
thus cannot evaluate the EECA conditions correctly.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: widgetVerbose
If the main problem is not wanting to go through all the code to find where the comments are on/off, perhaps a solution would be log messages at startup saying which comments are turned on where? Then when anyone sees/doesn't see comments they do/don't want, they can look at the startup logs to see exactly what is on and off. And then no one will care as strongly about the details. I'm not familiar with this code, but I'd guess adding a logging statement where each relevant property is loaded wouldn't be difficult? Of course, if they are loaded lots of times all over the place, then it isn't that simple. In which case maybe something in webtools that reports what is on and off and where? Cheers, Anne. On 20 September 2011 02:02, BJ Freeman bjf...@free-man.net wrote: yes I understand. but a simple turn off all comments lets you work with that. but if you want to see what is generating that, then turn them all on. Like Hans said, I really don't want to have to go through code to find where it is turned off or on. Adrian Crum sent the following on 9/19/2011 8:56 AM: BJ, The original message of this thread points out why that approach does not work. If comments are defaulted to on, then there MUST be a way to turn them off for things like CSV output. -Adrian On 9/19/2011 4:39 PM, BJ Freeman wrote: +1 KISS one place to turn off and on. common sense says you use for development then you turn it off so there are no comments in the ouput. So there is not need to have the comments turned off at component level. Hans Bakker sent the following on 9/19/2011 2:14 AM: If i use the widget comments option i want it to be generally applied and taken away depending on the properties setting. I do not want to find out that somewhere it is not following the setting, then have to dig in the code and find out that is, because somebody put an undocumented override somewhere by default as happened the first time. Bird and google checkout is fine. I think how it is implemented now is fine. I hope i commented now enough? Regards, Hans On Mon, 2011-09-19 at 10:03 +0100, Adrian Crum wrote: Hans, Jacques gave some examples of where an override is currently used and why it is needed. Could you give us another reason besides i think an override is an overkill - like a reason based on a design issue or a real-world problem? -Adrian On 9/19/2011 7:55 AM, Hans Bakker wrote: I as sorry i do not see the problem here. as long as the properties setting in the trunk will show or hide all widget comments (so in the trunk NO override) then it is fine. why? because i think an override is an overkill anyway Regards, Hans On Mon, 2011-09-19 at 08:43 +0200, Jacques Le Roux wrote: Yes, but I guess we will set widget.verbose in the properties file to true (as we do for all defaults to be dev friendly). Will that suit Hans? Else why do you Hans ask for now overriding in web.xml? For instance what for Birt by defaut? Why not keeping the example in example component commented out? Waht for testtools? Not sure why it's false in googlecheckout but I guess there is a reason.. In other word I guess Hans expect widget.verbose in the properties file to be false... Jacques From: Adrian Crumadrian.c...@sandglass-software.com Let's see if we can bring this to a happy ending. If the widget.verbose setting in the properties file is false, then it overrides any other setting and all boundary comments are shut off. If the widget.verbose setting in the properties file is true, then it follows the previous pattern, where true is the default, but it can be overridden in web.xml and in the context Map. Will that work for everyone? -Adrian On 9/15/2011 5:01 PM, Jacopo Cappellato wrote: I am going to feel bad if I don't add my 2 cents to this thread :-) I agree with Jacques that the formatting of boundary comments should be output specific (i.e no output for CSV etc...) instead of always rendering as html comments. As regards the logic to determine if comments should be enabled or not, I don't have a strong opinion because I have always used this feature in a very rough way (enable all or disable all); however I can understand the we may want to avoid that (when widget.properties.enableBoundaryComments == false) the comments are enabled by passing a URL parameter to the screen. Kind regards, Jacopo On Sep 15, 2011, at 4:18 PM, Jacques Le Roux wrote: Someone I work with suggested: I have to point out though that I kind of agree with the way David put it in that the false setting could have a priority, i.e. it's like in security permissions where deny has precedence over allow, so if you set it in widget.properties to false then you're sure comments will never be enabled anywhere... security-wise it makes sense despite the comment about qc... Maybe something like this? (compromise between the two) if (widget.properties.enableBoundaryComments
Re: widgetVerbose
Thanks Adrian. I was just trying to work out a way everyone would get what they really wanted. Your precedence makes sense to me, and I'm not sure I understand others' concerns. But that doesn't mean I think they are unimportant, just that I haven't managed to understand yet. I was thinking their concern was that it was difficult to determine what's on/off and where, and hence thought I'd suggest a possible solution to that problem. Maybe I'm wrong. Cheers, Anne. On 20 September 2011 10:06, Adrian Crum adrian.c...@sandglass-software.com wrote: Anne, Logging the settings is not necessary because the design is not that complicated. A setting in the widget.properties file is the default. That setting can be overridden in web.xml, and the setting in web.xml can be overridden in an individual screen widget by setting a value in the rendering context. So: properties file - web.xml - rendering context There is no need to go through code. If you enabled the widget comments in the properties file and the comments are not appearing in a particular web application, then check the web.xml file. If the comments are appearing in a web application but not in a particular screen, then check the screen widget xml file. It's very simple. We just have a couple of people who are trying to make it seem hard. -Adrian On 9/20/2011 12:56 AM, Anne wrote: If the main problem is not wanting to go through all the code to find where the comments are on/off, perhaps a solution would be log messages at startup saying which comments are turned on where? Then when anyone sees/doesn't see comments they do/don't want, they can look at the startup logs to see exactly what is on and off. And then no one will care as strongly about the details. I'm not familiar with this code, but I'd guess adding a logging statement where each relevant property is loaded wouldn't be difficult? Of course, if they are loaded lots of times all over the place, then it isn't that simple. In which case maybe something in webtools that reports what is on and off and where? Cheers, Anne. On 20 September 2011 02:02, BJ Freemanbjf...@free-man.net wrote: yes I understand. but a simple turn off all comments lets you work with that. but if you want to see what is generating that, then turn them all on. Like Hans said, I really don't want to have to go through code to find where it is turned off or on. Adrian Crum sent the following on 9/19/2011 8:56 AM: BJ, The original message of this thread points out why that approach does not work. If comments are defaulted to on, then there MUST be a way to turn them off for things like CSV output. -Adrian On 9/19/2011 4:39 PM, BJ Freeman wrote: +1 KISS one place to turn off and on. common sense says you use for development then you turn it off so there are no comments in the ouput. So there is not need to have the comments turned off at component level. Hans Bakker sent the following on 9/19/2011 2:14 AM: If i use the widget comments option i want it to be generally applied and taken away depending on the properties setting. I do not want to find out that somewhere it is not following the setting, then have to dig in the code and find out that is, because somebody put an undocumented override somewhere by default as happened the first time. Bird and google checkout is fine. I think how it is implemented now is fine. I hope i commented now enough? Regards, Hans On Mon, 2011-09-19 at 10:03 +0100, Adrian Crum wrote: Hans, Jacques gave some examples of where an override is currently used and why it is needed. Could you give us another reason besides i think an override is an overkill - like a reason based on a design issue or a real-world problem? -Adrian On 9/19/2011 7:55 AM, Hans Bakker wrote: I as sorry i do not see the problem here. as long as the properties setting in the trunk will show or hide all widget comments (so in the trunk NO override) then it is fine. why? because i think an override is an overkill anyway Regards, Hans On Mon, 2011-09-19 at 08:43 +0200, Jacques Le Roux wrote: Yes, but I guess we will set widget.verbose in the properties file to true (as we do for all defaults to be dev friendly). Will that suit Hans? Else why do you Hans ask for now overriding in web.xml? For instance what for Birt by defaut? Why not keeping the example in example component commented out? Waht for testtools? Not sure why it's false in googlecheckout but I guess there is a reason.. In other word I guess Hans expect widget.verbose in the properties file to be false... Jacques From: Adrian Crumadrian.c...@sandglass-software.com Let's see if we can bring this to a happy ending. If the widget.verbose setting in the properties file is false, then it overrides any other setting and all boundary comments are shut off. If the widget.verbose setting in the properties file is true, then it follows
Re: New link between communication event and sales opportunity
I wonder if this business case is analogous to Marketing Tasks on page 293 of Volume 2 of the Data Model book? Cheers, Anne. On 15 September 2011 18:12, Hans Bakker mailingl...@antwebsystems.com wrote: Ok sounds fair, let wait for other comments. On Thu, 2011-09-15 at 19:37 +1200, Scott Gray wrote: Ask for comments and then ignore them, well done Hans. If you don't have time to wait for opinions and have proper discussions then keep your changes local until you do. Regards Scott On 15/09/2011, at 7:33 PM, Hans Bakker wrote: then we have to agree to disagree? Ok my last question, you are going to block this?' cannot spend too much time on this... Regards, Hans On Thu, 2011-09-15 at 19:08 +1200, Scott Gray wrote: It really doesn't seem very difficult to me and coupling SalesOpportunity and WorkEffort will give you much more flexibility in the future. Regards Scott On 15/09/2011, at 7:00 PM, Hans Bakker wrote: I do not agree, i want to list all commevents on an opportunity which gets now too difficul Hans On Thu, 2011-09-15 at 18:19 +1200, Scott Gray wrote: Not necessarily every communication event, but if it requires action then a WorkEffort seems like the logic choice to track the work done. If you were to send more emails in connection with the opportunity then they would be linked to the existing WorkEffort. Ask yourself this, why is there a SalesOpportunityWorkEffort entity? What purpose does it fulfill if not the type of problem that you are describing here? Regards Scott On 15/09/2011, at 6:10 PM, Hans Bakker wrote: Sure I am all in favor to use the existing datamodel, this means however that every communication event will have a workeffort connected to it because somebody has to handle it? sounds a it bureaucratic?, then as a result of the creation of the opportunity more emails are sent from the opportunity, we need a workeffort to create another communication event? What kind of information the workeffort adds? Regards, Hans On Thu, 2011-09-15 at 17:37 +1200, Scott Gray wrote: It is possible to have a link between CommunicationEvent and SalesOpportunity via SalesOpportunityWorkEffort - WorkEffort - CommunicationEventWorkEffort. The business case could be redescribed as: - Email Received (CommunicationEvent) - WorkEffort created to handle the communication - Communication deemed to be a sales opportunity and record is created Regards Scott On 15/09/2011, at 4:13 PM, Hans Bakker wrote: Business case: An email is received requesting more information about certain services where the originator could be interested in. The support person receives the email and creates an opportunity in SFA for the sales people. Problem: currently it is not possible to have a link between CommunicationEvent and SalesOpportunity entity. Proposal: create a new entity: SalesOpportCommEvent: key: salesOpportunityId, communicationEventId comments please? Regards, Hans -- Ofbiz on twitter: http://twitter.com/apache_ofbiz Alternative ofbiz website: http://www.ofbiz.info http://www.antwebsystems.com : Quality services for competitive rates. -- Ofbiz on twitter: http://twitter.com/apache_ofbiz Alternative ofbiz website: http://www.ofbiz.info http://www.antwebsystems.com : Quality services for competitive rates. -- Ofbiz on twitter: http://twitter.com/apache_ofbiz Alternative ofbiz website: http://www.ofbiz.info http://www.antwebsystems.com : Quality services for competitive rates. -- Ofbiz on twitter: http://twitter.com/apache_ofbiz Alternative ofbiz website: http://www.ofbiz.info http://www.antwebsystems.com : Quality services for competitive rates. -- Ofbiz on twitter: http://twitter.com/apache_ofbiz Alternative ofbiz website: http://www.ofbiz.info http://www.antwebsystems.com : Quality services for competitive rates. -- Coherent Software Australia Pty Ltd PO Box 2773 Cheltenham Vic 3192 Phone: (03) 9585 6788 Fax: (03) 9585 1086 Web: http://www.cohsoft.com.au/ Email: sa...@cohsoft.com.au Bonsai ERP, the all-inclusive ERP system http://www.bonsaierp.com.au/
[jira] [Commented] (OFBIZ-4412) Set initial ecommerce Locale/Currency based on mount point specified in specialpurpose/ecommerce/ofbiz-component.xm
[ https://issues.apache.org/jira/browse/OFBIZ-4412?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13105003#comment-13105003 ] Anne Jessel commented on OFBIZ-4412: I presume this would also work with mount-point /au having locale en-AU, mount-point /us having locale en-US, and mount-point /gb having locale en-GB (and corresponding currencies)? Set initial ecommerce Locale/Currency based on mount point specified in specialpurpose/ecommerce/ofbiz-component.xm --- Key: OFBIZ-4412 URL: https://issues.apache.org/jira/browse/OFBIZ-4412 Project: OFBiz Issue Type: Improvement Components: specialpurpose/ecommerce Affects Versions: Release Branch 10.04, Release Branch 11.04, SVN trunk Environment: Not specific Reporter: mz4wheeler Priority: Trivial Labels: patch Fix For: Release Branch 10.04, Release Branch 11.04, SVN trunk Attachments: OFBIZ-4412.patch Original Estimate: 2h Remaining Estimate: 2h Using the specified patch, it is now possible to set a users initial Locale (and even currency) based on the webapp mount point. This works with a single store, and does not require the use virtual hosts. This is especially useful when setting up sitemap.xml, which allows crawlers (like google) to correctly locate and traverse products and services in multiple languages. Here is an example where ecomclone has been modified to Locale=fr with a mount point of /fr. specialpurpose/ecommerce/ofbiz-component.xml: !-- init-param name=Currency value=EUR/ -- webapp name=ecommerce title=eCommerce server=default-server location=webapp/ecommerce mount-point=/ecommerce app-bar-display=false /webapp webapp name=ecomclone title=eCommerce Clone server=default-server location=webapp/ecomclone mount-point=/fr--- SPECIFY MOUNT app-bar-display=false init-param name=Locale value=fr/ --- SPECIFY LOCALE /webapp The below sitemap.xml would allow products with the /fr path to be indexed in french. ?xml version=1.0 encoding=UTF-8? urlset xmlns=http://www.sitemaps.org/schemas/sitemap/0.9; urllochttp://ofbizsite.com/ecommerce/products/10002/p_1001TANGRAMPUZ/loc/url urllochttp://ofbizsite.com/fr/products/10002/p_1001TANGRAMPUZ/loc/url /urlset The patch: The attached patch modifies setDefaultStoreSettings in ProductEvents.java, which is called once during the initial session creation. After a user enters the URL, they are still free to modify the language, as long as the page supports it (like the default demo store). The patch also allows the Currency to be forced as well, and it does appear to work, but should be more throughly tested. Although this patch bypasses the requirement for multiple stores, there may be issues with other aspects of the store, like emails. However, it is no different than a user who enters your English-based ecommerce store, selects french, and attempts a checkout. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: svn commit: r1169790 - in /ofbiz/trunk/framework/common/data: GeoData_CA.xml GeoData_US.xml
I don't understand why it matters what the geoId is. Surely they could be 1, 10001 etc and it wouldn't matter, *as long as they never change* (because they are PK). In the UI it *should* be the geoCode or the abbreviation or the geoName that is displayed, depending on context. I know in some places in the UI the geoId is currently displayed, but I consider this a strange choice by the coder of the UI code, and nothing to do with the data in the Geo. In our local UI, we've changed that to display either the abbreviation or geoName or geoCode instead. So -1 for this change. Cheers, Anne. On 13 September 2011 08:30, David E Jones d...@me.com wrote: Yes, there is no conflict currently because countries are using the 3-letter ISO code, and the USA states (the first states we had data for, way back in 2001, had just the 2-letter state abbreviation; later states had a country prefix and then a state abbreviation as the US states really should have originally). So anyway yes, Canada is geoId=CAN and California is geoId=CA. So yes, I'm even more for reverting this change. -David On Sep 12, 2011, at 2:03 PM, Jacques Le Roux wrote: I'm still waiting before reverting, I'd like to have other opinions on this Thanks Jacques From: Jacques Le Roux jacques.le.r...@les7arts.com Oops, an assumption was wrong in my previous emaim, there are no conflicts with California and Canada geoId (how could it be since it's the PK, idiot I'm) So yes maybe it's simpler to revert all and forget about that forever? Jacques From: Jacques Le Roux jacques.le.r...@les7arts.com I could provide a SQL script which removes the wrong entities, but it's the users responsability to update or not their own data. It seems impossible to envision all possible cases Jacques From: Jacques Le Roux jacques.le.r...@les7arts.com So we are forever stuck with wrong data? Consider Canada and California geoId, it's CA for both. Actually this was more an effort for future systems to be consistent with ISO 3166-2 and sound (CA case). This said I'm ready to revert r1169822 + r1169790, but I wonder then if we will never find a window to fix this data... Should not better concerned systems update and fix data? Then maybe we could provide a mean for that? Jacques From: David E Jones d...@me.com Did you consider that changing this seed data will make ALL current production data that depends on this data suddenly break? In fact for existing systems, by this change alone, you'll be adding new records and not modifying the existing records because the PK (geoId) is being changed. That's gonna screw up a lot of stuff. Please revert this and any commits done based on these changes. -David On Sep 12, 2011, at 8:50 AM, Jacques Le Roux wrote: I have to take care about data for test and demo also... Jacques From: jler...@apache.org Author: jleroux Date: Mon Sep 12 15:11:00 2011 New Revision: 1169790 URL: http://svn.apache.org/viewvc?rev=1169790view=rev Log: Normalizes * Canada GeoId for Province prefixed with CA- as it should be (following ISO 3166-2:CA, http://en.wikipedia.org/wiki/ISO_3166-2:CA) * USA GeoId for Province prefixed with US- as it should be (following ISO 3166-2:US, http://en.wikipedia.org/wiki/ISO_3166-2:US). I did not see any reasons to no use the same scheme for US Armed Forces provinces No other countries had the same problem Modified: ofbiz/trunk/framework/common/data/GeoData_CA.xml ofbiz/trunk/framework/common/data/GeoData_US.xml Modified: ofbiz/trunk/framework/common/data/GeoData_CA.xml URL: http://svn.apache.org/viewvc/ofbiz/trunk/framework/common/data/GeoData_CA.xml?rev=1169790r1=1169789r2=1169790view=diff == --- ofbiz/trunk/framework/common/data/GeoData_CA.xml (original) +++ ofbiz/trunk/framework/common/data/GeoData_CA.xml Mon Sep 12 15:11:00 2011 @@ -19,33 +19,33 @@ under the License. -- entity-engine-xml - Geo abbreviation=AB geoCode=AB geoId=AB geoName=Alberta geoTypeId=PROVINCE/ - Geo abbreviation=BC geoCode=BC geoId=BC geoName=British Columbia geoTypeId=PROVINCE/ - Geo abbreviation=MB geoCode=MB geoId=MB geoName=Manitoba geoTypeId=PROVINCE/ - Geo abbreviation=NB geoCode=NB geoId=NB geoName=New Brunswick geoTypeId=PROVINCE/ - Geo abbreviation=NL geoCode=NL geoId=NL geoName=Newfoundland and Labrador geoTypeId=PROVINCE/ - Geo abbreviation=NS geoCode=NS geoId=NS geoName=Nova Scotia geoTypeId=PROVINCE/ - Geo abbreviation=NT geoCode=NT geoId=NT geoName=Northwest Territories geoTypeId=PROVINCE/ - Geo abbreviation=NU geoCode=NU geoId=NU geoName=Nunavut geoTypeId=PROVINCE/ - Geo abbreviation=ON geoCode=ON geoId=ON geoName=Ontario geoTypeId=PROVINCE/ - Geo abbreviation=PE geoCode=PE geoId=PE geoName=Prince Edward Island geoTypeId=PROVINCE/ - Geo abbreviation=QC geoCode=QC geoId=QC geoName
[jira] [Commented] (OFBIZ-4394) Replace newnote.ftl with form widget
[ https://issues.apache.org/jira/browse/OFBIZ-4394?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13097048#comment-13097048 ] Anne Jessel commented on OFBIZ-4394: I don't know either way. The permission test was in the ftl, so I copied it into the screen. If it shouldn't be there, then that's also a bug in newnote.ftl. Replace newnote.ftl with form widget Key: OFBIZ-4394 URL: https://issues.apache.org/jira/browse/OFBIZ-4394 Project: OFBiz Issue Type: Improvement Components: order Affects Versions: SVN trunk Environment: REV 1165137 Reporter: Anne Jessel Priority: Trivial Attachments: OFBIZ-4394-replace-newnoteftl-with-formwidget.patch Original Estimate: 0.5h Remaining Estimate: 0.5h This patch replaces ordermgr newnote.ftl with a form widget. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (OFBIZ-4393) View entity condition-expr doesn't handle null
View entity condition-expr doesn't handle null -- Key: OFBIZ-4393 URL: https://issues.apache.org/jira/browse/OFBIZ-4393 Project: OFBiz Issue Type: Bug Components: framework Affects Versions: SVN trunk Environment: Rev 1165137 Reporter: Anne Jessel condition-expr tag in view-entity can't be used to compare a field with null. An absent value attribute is read as an empty string, and the code currently checks for value being null to know when to compare against null. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (OFBIZ-4393) View entity condition-expr doesn't handle null
[ https://issues.apache.org/jira/browse/OFBIZ-4393?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anne Jessel updated OFBIZ-4393: --- Attachment: OFBIZ-4393-view-entity_condition-expr_null.patch This patch replaces relevant tests for null with UtilValidate.is(Not)Empty. IMPORTANT: if any code relies on a missing value attribute being converted to an empty string that is then used, then this patch will break that. I did look, and couldn't find any such code OOTB. View entity condition-expr doesn't handle null -- Key: OFBIZ-4393 URL: https://issues.apache.org/jira/browse/OFBIZ-4393 Project: OFBiz Issue Type: Bug Components: framework Affects Versions: SVN trunk Environment: Rev 1165137 Reporter: Anne Jessel Attachments: OFBIZ-4393-view-entity_condition-expr_null.patch Original Estimate: 2h Remaining Estimate: 2h condition-expr tag in view-entity can't be used to compare a field with null. An absent value attribute is read as an empty string, and the code currently checks for value being null to know when to compare against null. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (OFBIZ-4393) View entity condition-expr doesn't handle null
[ https://issues.apache.org/jira/browse/OFBIZ-4393?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13096984#comment-13096984 ] Anne Jessel commented on OFBIZ-4393: value=null definitely doesn't work. It's what I tried first before looking at the code. Is that what should work? The current code compares value variable with null, but I can't see how value can ever be null, as it has the value returned by org.w3c.dom.Element.getAttribute, which doesn't return null. I can change patch so it looks for String null instead of using isEmpty. View entity condition-expr doesn't handle null -- Key: OFBIZ-4393 URL: https://issues.apache.org/jira/browse/OFBIZ-4393 Project: OFBiz Issue Type: Bug Components: framework Affects Versions: SVN trunk Environment: Rev 1165137 Reporter: Anne Jessel Attachments: OFBIZ-4393-view-entity_condition-expr_null.patch Original Estimate: 2h Remaining Estimate: 2h condition-expr tag in view-entity can't be used to compare a field with null. An absent value attribute is read as an empty string, and the code currently checks for value being null to know when to compare against null. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (OFBIZ-4394) Replace newnote.ftl with form widget
Replace newnote.ftl with form widget Key: OFBIZ-4394 URL: https://issues.apache.org/jira/browse/OFBIZ-4394 Project: OFBiz Issue Type: Improvement Components: order Affects Versions: SVN trunk Environment: REV 1165137 Reporter: Anne Jessel Priority: Trivial This patch replaces ordermgr newnote.ftl with a form widget. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (OFBIZ-4394) Replace newnote.ftl with form widget
[ https://issues.apache.org/jira/browse/OFBIZ-4394?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anne Jessel updated OFBIZ-4394: --- Attachment: OFBIZ-4394-replace-newnoteftl-with-formwidget.patch Replace newnote.ftl with form widget Key: OFBIZ-4394 URL: https://issues.apache.org/jira/browse/OFBIZ-4394 Project: OFBiz Issue Type: Improvement Components: order Affects Versions: SVN trunk Environment: REV 1165137 Reporter: Anne Jessel Priority: Trivial Attachments: OFBIZ-4394-replace-newnoteftl-with-formwidget.patch Original Estimate: 0.5h Remaining Estimate: 0.5h This patch replaces ordermgr newnote.ftl with a form widget. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: assets and inventory
Hi Hans We looked at something similar to this a long time ago, but the client decided not to go ahead. If they had, we would have discussed this in detail on the mailing list before proceeding. Seeing the client didn't go ahead, we never went past a rough idea of how we might do it. From memory, here's some of the conclusions and ideas we had. The items to be rented would be FixedAssets, but associated with products. No inventory. The productTypeId was ASSET_USAGE. The FixedAsset entity has an instanceOfProductId field which we would have used. There's code there currently that is not general, but specifically for accommodation reservations. As some of our rental items could be booked ahead of time for 30 minute increments, we were wondering about generalising that code. My own opinion was that the existing code was so specific to accommodation that it would be simpler starting again, but more research was needed before we would know whether I was right. When a customer rented an asset, they would be assigned to that asset using a role via PartyFixedAssetAssignment. So an asset without a current PartyFixedAssetAssignment of the right roleType would be free for renting. If we did replace the existing reservation code, we were thinking of using Requirements, as they seemed ideal for managing the relevant important details. Namely, that a customer requires a specific fixed asset for a specified span of time. Once confirmed/approved this could become a PartyFixedAssetAssignment. This could of course work for accommodation as well as lots of other things. We weren't intending to use the existing Order system, as rental of the non-booked items was to be on-going, invoiced monthly. And any bookable items rented during a month were added to the monthly invoice. Using Orders would have been unneccessarily complicated. The clients wanted one invoice per customer per month. They didn't want to know about orders or anything like that. So we were thinking of a service that ran monthly, looking at all current PartyFixedAssetAssignments plus those that ended during the month, and generating an invoice based on that information. We didn't look closely at shipments, but did notice that the ShipmentItem refers to an ItemIssuance entity that includes a fixedAssetId, so we assumed the data structures would support it, even if the code didn't yet exist for it. I am guessing this was originally meant for shipping assets somewhere for maintenance, but I didn't see much difference at the shipment level between shipping an asset for maintenance or for temporary use by a customer. Because we weren't intending to use the Order system, we wouldn't be handling returns via it either. When a rental item was returned, the PartyFixedAssetAssignment would be expired. The invoice generation service would include it at the end of the month, or the user could trigger an invoice run immediately for a specific customer. I don't know how much of the above we would have actually done that way had the project proceeded. But I hope it's given you some ideas. Cheers, Anne. On 1 September 2011 14:20, Hans Bakker h.bak...@antwebsystems.com wrote: if we have assets, shouldn't there be a relationship to inventory item, to be able to know what is in inventory? This is in relation to to the rental of assets, which need to be shipped and returned. some background: A new product type in ofbiz: rental of items which need to be shipped. Currently we have the function in the system to be able to rent hotel rooms which obviously stay in house and do not need to be shipped. If however you would like to rent video's or cars or motorcycles the system should support its delivery with a shipment and return process. So when a shippable rental product is ordered, there will be created automatically a return when the order is completed. The order and shipment slip will list the product and the asset number, so the warehouse knows where to find the item. (if there would be a link between asset and inventory item) This shipment and return process however should not affect accounting what it currently does. Further it is required to ship 'assets' and not 'products' because they are an asset of the company which is rented. -- http://www.antwebsystems.com : Quality OFBiz support for competitive rates -- Coherent Software Australia Pty Ltd PO Box 2773 Cheltenham Vic 3192 Phone: (03) 9585 6788 Fax: (03) 9585 1086 Web: http://www.cohsoft.com.au/ Email: sa...@cohsoft.com.au Bonsai ERP, the all-inclusive ERP system http://www.bonsaierp.com.au/
[jira] [Commented] (OFBIZ-4373) Duplicate quote leads to editing original instead of copy
[ https://issues.apache.org/jira/browse/OFBIZ-4373?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13088500#comment-13088500 ] Anne Jessel commented on OFBIZ-4373: Just discovered this problem was actually fixed as a side-effect of OFBIZ-4357, committed in Rev 1152729. Duplicate quote leads to editing original instead of copy - Key: OFBIZ-4373 URL: https://issues.apache.org/jira/browse/OFBIZ-4373 Project: OFBiz Issue Type: Improvement Components: order Affects Versions: SVN trunk Environment: REV 1152668 Reporter: Anne Jessel Priority: Minor Attachments: OFBIZ-4373_DuplicateQuoteEditCopy.patch Currently if you duplicate a quote, you are then prompted to edit the original quote. This patch instead displays the newly-created quote for editing. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (OFBIZ-4372) Order terms not displayed correctly
[ https://issues.apache.org/jira/browse/OFBIZ-4372?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anne Jessel updated OFBIZ-4372: --- Attachment: OFBIZ-4372_OrderTermsDisplay.patch Replaced git-format patch with svn patch. New patch is against REV 1160087. Order terms not displayed correctly --- Key: OFBIZ-4372 URL: https://issues.apache.org/jira/browse/OFBIZ-4372 Project: OFBiz Issue Type: Bug Components: order Affects Versions: SVN trunk Environment: REV 1152668 Reporter: Anne Jessel Priority: Minor Attachments: OFBIZ-4372_OrderTermsDisplay.patch, OFBIZ-4372_OrderTermsDisplay.patch If an order is created from a quote with terms, the terms copied to the order do not display correctly. This is because the ordermgr displays the textValue field against the Description label, and does not display the description field at all. The patch alters the display of terms within the ordermgr so that the textValue field is labelled as the Text Value, and the description field is displayed for the Description label. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (OFBIZ-4374) Support filtering on non-std date field names in performFind and prepareFind
[ https://issues.apache.org/jira/browse/OFBIZ-4374?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anne Jessel updated OFBIZ-4374: --- Attachment: OFBIZ-4374_FilterNonStdDateFieldNames.patch Replaced git-format patch with svn-format patch, against REV 1160087. Support filtering on non-std date field names in performFind and prepareFind Key: OFBIZ-4374 URL: https://issues.apache.org/jira/browse/OFBIZ-4374 Project: OFBiz Issue Type: Improvement Components: framework Affects Versions: SVN trunk Environment: REV 1152668 Reporter: Anne Jessel Priority: Trivial Attachments: OFBIZ-4374_FilterNonStdDateFieldNames.patch, OFBIZ-4374_FilterNonStdDateFieldNames.patch I had a need to filter by date ranges for entities that didn't follow the standard fromDate and thruDate field-naming pattern. I therefore enhanced prepareFind and performFind services so they could be passed the names of the fields to use in place of fromDate and thruDate when the filterByDate option was chosen. Thought this might be useful to others, even though it isn't currently used in OOTB code. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Closed] (OFBIZ-4373) Duplicate quote leads to editing original instead of copy
[ https://issues.apache.org/jira/browse/OFBIZ-4373?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anne Jessel closed OFBIZ-4373. -- Resolution: Fixed Fix Version/s: SVN trunk Fixed as a side-effect of OFBIZ-4357 in REV 1152729 Duplicate quote leads to editing original instead of copy - Key: OFBIZ-4373 URL: https://issues.apache.org/jira/browse/OFBIZ-4373 Project: OFBiz Issue Type: Improvement Components: order Affects Versions: SVN trunk Environment: REV 1152668 Reporter: Anne Jessel Priority: Minor Fix For: SVN trunk Attachments: OFBIZ-4373_DuplicateQuoteEditCopy.patch Currently if you duplicate a quote, you are then prompted to edit the original quote. This patch instead displays the newly-created quote for editing. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (OFBIZ-4370) Support Notes on Quotes
[ https://issues.apache.org/jira/browse/OFBIZ-4370?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anne Jessel updated OFBIZ-4370: --- Attachment: OFBIZ-4370_QuoteNotes.patch Updated patch, svn format. Support Notes on Quotes --- Key: OFBIZ-4370 URL: https://issues.apache.org/jira/browse/OFBIZ-4370 Project: OFBiz Issue Type: New Feature Components: order Affects Versions: SVN trunk Environment: REV 1152668 Reporter: Anne Jessel Assignee: Adrian Crum Priority: Minor Attachments: OFBIZ-4370_QuoteNotes.patch, OFBIZ-4370_QuoteNotes.patch, OFBIZ-4370_QuoteNotes.patch Original Estimate: 1h Remaining Estimate: 1h Attaching a patch which allows the user to add notes to Quotes. It is based on the similar feature already implemented for notes on Orders and Parties. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (OFBIZ-4373) Duplicate quote leads to editing original instead of copy
[ https://issues.apache.org/jira/browse/OFBIZ-4373?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anne Jessel updated OFBIZ-4373: --- Attachment: OFBIZ-4373_DuplicateQuoteEditCopy.patch Duplicate quote leads to editing original instead of copy - Key: OFBIZ-4373 URL: https://issues.apache.org/jira/browse/OFBIZ-4373 Project: OFBiz Issue Type: Improvement Components: order Affects Versions: SVN trunk Environment: REV 1152668 Reporter: Anne Jessel Priority: Minor Attachments: OFBIZ-4373_DuplicateQuoteEditCopy.patch Currently if you duplicate a quote, you are then prompted to edit the original quote. This patch instead displays the newly-created quote for editing. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (OFBIZ-4373) Duplicate quote leads to editing original instead of copy
Duplicate quote leads to editing original instead of copy - Key: OFBIZ-4373 URL: https://issues.apache.org/jira/browse/OFBIZ-4373 Project: OFBiz Issue Type: Improvement Components: order Affects Versions: SVN trunk Environment: REV 1152668 Reporter: Anne Jessel Priority: Minor Attachments: OFBIZ-4373_DuplicateQuoteEditCopy.patch Currently if you duplicate a quote, you are then prompted to edit the original quote. This patch instead displays the newly-created quote for editing. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (OFBIZ-4374) Support filtering on non-std date field names in performFind and prepareFind
Support filtering on non-std date field names in performFind and prepareFind Key: OFBIZ-4374 URL: https://issues.apache.org/jira/browse/OFBIZ-4374 Project: OFBiz Issue Type: Improvement Components: framework Affects Versions: SVN trunk Environment: REV 1152668 Reporter: Anne Jessel Priority: Trivial I had a need to filter by date ranges for entities that didn't follow the standard fromDate and thruDate field-naming pattern. I therefore enhanced prepareFind and performFind services so they could be passed the names of the fields to use in place of fromDate and thruDate when the filterByDate option was chosen. Thought this might be useful to others, even though it isn't currently used in OOTB code. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (OFBIZ-4374) Support filtering on non-std date field names in performFind and prepareFind
[ https://issues.apache.org/jira/browse/OFBIZ-4374?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anne Jessel updated OFBIZ-4374: --- Attachment: OFBIZ-4374_FilterNonStdDateFieldNames.patch Support filtering on non-std date field names in performFind and prepareFind Key: OFBIZ-4374 URL: https://issues.apache.org/jira/browse/OFBIZ-4374 Project: OFBiz Issue Type: Improvement Components: framework Affects Versions: SVN trunk Environment: REV 1152668 Reporter: Anne Jessel Priority: Trivial Attachments: OFBIZ-4374_FilterNonStdDateFieldNames.patch I had a need to filter by date ranges for entities that didn't follow the standard fromDate and thruDate field-naming pattern. I therefore enhanced prepareFind and performFind services so they could be passed the names of the fields to use in place of fromDate and thruDate when the filterByDate option was chosen. Thought this might be useful to others, even though it isn't currently used in OOTB code. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (OFBIZ-4370) Support Notes on Quotes
[ https://issues.apache.org/jira/browse/OFBIZ-4370?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13086904#comment-13086904 ] Anne Jessel commented on OFBIZ-4370: Thanks for the feedback, Adrian. I would normally have used screen widgets instead of freemarker, but in this case much of the code was copied from Orders and Order replaced with Quote. I'll update as you suggest. Would it be worthwhile me updating some of the existing Orders code as well while I'm at it? I'm thinking in particular of replacing webapp/ordermgr/order/newnote.ftl with a screen widget. Support Notes on Quotes --- Key: OFBIZ-4370 URL: https://issues.apache.org/jira/browse/OFBIZ-4370 Project: OFBiz Issue Type: New Feature Components: order Affects Versions: SVN trunk Environment: REV 1152668 Reporter: Anne Jessel Priority: Minor Attachments: OFBIZ-4370_QuoteNotes.patch Original Estimate: 1h Remaining Estimate: 1h Attaching a patch which allows the user to add notes to Quotes. It is based on the similar feature already implemented for notes on Orders and Parties. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (OFBIZ-4370) Support Notes on Quotes
[ https://issues.apache.org/jira/browse/OFBIZ-4370?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anne Jessel updated OFBIZ-4370: --- Attachment: OFBIZ-4370_QuoteNotes.patch Updated patch. It no longer copies style used with notes for orders. Main changes: - no freemarker - new service createQuoteNote is now minilang - less new labels My limited understanding of entity-auto services suggests it can't be used for createQuoteNote, which creates two entities. Support Notes on Quotes --- Key: OFBIZ-4370 URL: https://issues.apache.org/jira/browse/OFBIZ-4370 Project: OFBiz Issue Type: New Feature Components: order Affects Versions: SVN trunk Environment: REV 1152668 Reporter: Anne Jessel Priority: Minor Attachments: OFBIZ-4370_QuoteNotes.patch, OFBIZ-4370_QuoteNotes.patch Original Estimate: 1h Remaining Estimate: 1h Attaching a patch which allows the user to add notes to Quotes. It is based on the similar feature already implemented for notes on Orders and Parties. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (OFBIZ-4370) Support Notes on Quotes
Support Notes on Quotes --- Key: OFBIZ-4370 URL: https://issues.apache.org/jira/browse/OFBIZ-4370 Project: OFBiz Issue Type: New Feature Components: order Affects Versions: SVN trunk Environment: REV 1152668 Reporter: Anne Jessel Priority: Minor Attaching a patch which allows the user to add notes to Quotes. It is based on the similar feature already implemented for notes on Orders and Parties. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (OFBIZ-4370) Support Notes on Quotes
[ https://issues.apache.org/jira/browse/OFBIZ-4370?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anne Jessel updated OFBIZ-4370: --- Attachment: OFBIZ-4370_QuoteNotes.patch Patch is in git format. Hope this is okay. If not, let me know and I'll redo it. Support Notes on Quotes --- Key: OFBIZ-4370 URL: https://issues.apache.org/jira/browse/OFBIZ-4370 Project: OFBiz Issue Type: New Feature Components: order Affects Versions: SVN trunk Environment: REV 1152668 Reporter: Anne Jessel Priority: Minor Attachments: OFBIZ-4370_QuoteNotes.patch Original Estimate: 1h Remaining Estimate: 1h Attaching a patch which allows the user to add notes to Quotes. It is based on the similar feature already implemented for notes on Orders and Parties. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (OFBIZ-4372) Order terms not displayed correctly
Order terms not displayed correctly --- Key: OFBIZ-4372 URL: https://issues.apache.org/jira/browse/OFBIZ-4372 Project: OFBiz Issue Type: Bug Components: order Affects Versions: SVN trunk Environment: REV 1152668 Reporter: Anne Jessel Priority: Minor Attachments: OFBIZ-4372_OrderTermsDisplay.patch If an order is created from a quote with terms, the terms copied to the order do not display correctly. This is because the ordermgr displays the textValue field against the Description label, and does not display the description field at all. The patch alters the display of terms within the ordermgr so that the textValue field is labelled as the Text Value, and the description field is displayed for the Description label. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (OFBIZ-4372) Order terms not displayed correctly
[ https://issues.apache.org/jira/browse/OFBIZ-4372?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anne Jessel updated OFBIZ-4372: --- Attachment: OFBIZ-4372_OrderTermsDisplay.patch Order terms not displayed correctly --- Key: OFBIZ-4372 URL: https://issues.apache.org/jira/browse/OFBIZ-4372 Project: OFBiz Issue Type: Bug Components: order Affects Versions: SVN trunk Environment: REV 1152668 Reporter: Anne Jessel Priority: Minor Attachments: OFBIZ-4372_OrderTermsDisplay.patch If an order is created from a quote with terms, the terms copied to the order do not display correctly. This is because the ordermgr displays the textValue field against the Description label, and does not display the description field at all. The patch alters the display of terms within the ordermgr so that the textValue field is labelled as the Text Value, and the description field is displayed for the Description label. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (OFBIZ-4022) Collapse all broken if hyperlink in pane
Collapse all broken if hyperlink in pane Key: OFBIZ-4022 URL: https://issues.apache.org/jira/browse/OFBIZ-4022 Project: OFBiz Issue Type: Bug Components: framework Affects Versions: SVN trunk Environment: Rev 1035845 Reporter: Anne Jessel Priority: Minor To reproduce the bug: - edit the EditProduct form in applications/product/widget/catalog/ProductForms.xml - add a new field with a hyperlink sub-element. - refer to this new field in the first, non-collapsible field-group in the sort-order - go to this page in the UI (edit a product in the catalog) - the Expand All and Collapse All buttons do not work properly The problem is caused by the javascript finding the added hyperlink field in the first field-group, and incorrectly assuming it is the expand/collapse link for the field-group. This causes the javascript to crash when it gets a null reference to an enclosing li element. It is not specific to the EditProduct form, but applies to any group of collapsible panes where one contains a hyperlink. The attached patch simply checks that the li element actually exists. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (OFBIZ-4022) Collapse all broken if hyperlink in pane
[ https://issues.apache.org/jira/browse/OFBIZ-4022?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anne Jessel updated OFBIZ-4022: --- Attachment: OFBIZ-4022_collapse-all-broken.patch Collapse all broken if hyperlink in pane Key: OFBIZ-4022 URL: https://issues.apache.org/jira/browse/OFBIZ-4022 Project: OFBiz Issue Type: Bug Components: framework Affects Versions: SVN trunk Environment: Rev 1035845 Reporter: Anne Jessel Priority: Minor Attachments: OFBIZ-4022_collapse-all-broken.patch Original Estimate: 0.33h Remaining Estimate: 0.33h To reproduce the bug: - edit the EditProduct form in applications/product/widget/catalog/ProductForms.xml - add a new field with a hyperlink sub-element. - refer to this new field in the first, non-collapsible field-group in the sort-order - go to this page in the UI (edit a product in the catalog) - the Expand All and Collapse All buttons do not work properly The problem is caused by the javascript finding the added hyperlink field in the first field-group, and incorrectly assuming it is the expand/collapse link for the field-group. This causes the javascript to crash when it gets a null reference to an enclosing li element. It is not specific to the EditProduct form, but applies to any group of collapsible panes where one contains a hyperlink. The attached patch simply checks that the li element actually exists. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (OFBIZ-4023) Wrong product displayed as associated product
Wrong product displayed as associated product - Key: OFBIZ-4023 URL: https://issues.apache.org/jira/browse/OFBIZ-4023 Project: OFBiz Issue Type: Bug Components: specialpurpose/ecommerce Affects Versions: SVN trunk Environment: Rev 1035845 Reporter: Anne Jessel Priority: Minor To reproduce: - add two associated products to a main product, both with Complementary or Cross-Sell association type - view the main product in ecommerce Expected behaviour: the two associated products are listed near the bottom of the page Actual behaviour: two products are listed at the bottom of the page, but only one of them is an associated product. The other is the main product. The problem is caused by the value of a freemarker variable changing at a point where other freemarker code assumes the variable does not change. The execution path is complicated. I will attach a patch which does fix the problem, by saving the value of the key variable into another variable, and restoring it later. However I do wonder if there is a better solution. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (OFBIZ-4023) Wrong product displayed as associated product
[ https://issues.apache.org/jira/browse/OFBIZ-4023?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anne Jessel updated OFBIZ-4023: --- Attachment: OFBIZ-4023_Wrong-product-displayed-as-assoc-product.patch Wrong product displayed as associated product - Key: OFBIZ-4023 URL: https://issues.apache.org/jira/browse/OFBIZ-4023 Project: OFBiz Issue Type: Bug Components: specialpurpose/ecommerce Affects Versions: SVN trunk Environment: Rev 1035845 Reporter: Anne Jessel Priority: Minor Attachments: OFBIZ-4023_Wrong-product-displayed-as-assoc-product.patch To reproduce: - add two associated products to a main product, both with Complementary or Cross-Sell association type - view the main product in ecommerce Expected behaviour: the two associated products are listed near the bottom of the page Actual behaviour: two products are listed at the bottom of the page, but only one of them is an associated product. The other is the main product. The problem is caused by the value of a freemarker variable changing at a point where other freemarker code assumes the variable does not change. The execution path is complicated. I will attach a patch which does fix the problem, by saving the value of the key variable into another variable, and restoring it later. However I do wonder if there is a better solution. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (OFBIZ-4024) Improve handling and display of additional product images
Improve handling and display of additional product images - Key: OFBIZ-4024 URL: https://issues.apache.org/jira/browse/OFBIZ-4024 Project: OFBiz Issue Type: Improvement Components: product, specialpurpose/ecommerce Affects Versions: SVN trunk Environment: Rev 1035845 Reporter: Anne Jessel Priority: Minor This patch adds several closely-related features, intended to improve the display of products and their images in the ecommerce webapp. When additional images for a product are uploaded via the Catalog, the scaled versions that were already being created in service addAdditionalViewForProduct are now recorded as ProductContent. This makes them easily available for use elsewhere. New ProductContentType values were added to identify these content types. The obviously consistent string to use for these was too long, and so I had to choose something less consistent, but shorter and hopefully still clear. I used XTRA instead of ADDITIONAL. The sizes to which additional images are rescaled has been changed, so they better fit in the ecommerce display. Relevant sizes in productdetail.ftl have been updated to match these sizes. The ecommerce product display now uses the scaled additional images if available, rather than relying on the web browser to scale the images. When displaying a single product in ecommerce, the main image is larger than the additional images. Hovering over an additional image displays a larger version in place of the main image. Clicking on an additional image displays a popup with a detailed version of the image. To use the new features, one or more large images (suggest at least 600x600) should be attached as additional images to a product, using the form on the bottom of the content tab for a product in Catalog. Viewing the product in ecommerce should then exhibit the above behaviour. I have tried to maintain backwards compatibility, so that products with the old-style use of additional images will continue to display as they did previously. This means some of the code is not as streamlined as it might be. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (OFBIZ-4024) Improve handling and display of additional product images
[ https://issues.apache.org/jira/browse/OFBIZ-4024?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anne Jessel updated OFBIZ-4024: --- Attachment: OFBIZ-4024_additional-images-enhancements.patch Improve handling and display of additional product images - Key: OFBIZ-4024 URL: https://issues.apache.org/jira/browse/OFBIZ-4024 Project: OFBiz Issue Type: Improvement Components: product, specialpurpose/ecommerce Affects Versions: SVN trunk Environment: Rev 1035845 Reporter: Anne Jessel Priority: Minor Attachments: OFBIZ-4024_additional-images-enhancements.patch This patch adds several closely-related features, intended to improve the display of products and their images in the ecommerce webapp. When additional images for a product are uploaded via the Catalog, the scaled versions that were already being created in service addAdditionalViewForProduct are now recorded as ProductContent. This makes them easily available for use elsewhere. New ProductContentType values were added to identify these content types. The obviously consistent string to use for these was too long, and so I had to choose something less consistent, but shorter and hopefully still clear. I used XTRA instead of ADDITIONAL. The sizes to which additional images are rescaled has been changed, so they better fit in the ecommerce display. Relevant sizes in productdetail.ftl have been updated to match these sizes. The ecommerce product display now uses the scaled additional images if available, rather than relying on the web browser to scale the images. When displaying a single product in ecommerce, the main image is larger than the additional images. Hovering over an additional image displays a larger version in place of the main image. Clicking on an additional image displays a popup with a detailed version of the image. To use the new features, one or more large images (suggest at least 600x600) should be attached as additional images to a product, using the form on the bottom of the content tab for a product in Catalog. Viewing the product in ecommerce should then exhibit the above behaviour. I have tried to maintain backwards compatibility, so that products with the old-style use of additional images will continue to display as they did previously. This means some of the code is not as streamlined as it might be. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (OFBIZ-4025) Is Empty for text-find widget broken
Is Empty for text-find widget broken Key: OFBIZ-4025 URL: https://issues.apache.org/jira/browse/OFBIZ-4025 Project: OFBiz Issue Type: Bug Components: framework Affects Versions: SVN trunk Environment: Rev 1036293 Reporter: Anne Jessel Priority: Minor To reproduce: - go to Facility, Inventory Items tab (or any form that uses text-find widget) - choose Is Empty from drop-down next to Product Id - click Find button Expected behaviour: no matching items listed, as all items have a Product Id. Observed behaviour: all items match. Problem is caused by find code assuming that there is no entity condition to be created if the text field is empty, but of course Is Empty is different to the other operators in that the text field is expected to be empty. The attached patch adds a special check for the Is Empty operator. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (OFBIZ-4025) Is Empty for text-find widget broken
[ https://issues.apache.org/jira/browse/OFBIZ-4025?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anne Jessel updated OFBIZ-4025: --- Attachment: OFBIZ-4025_Is-Empty-for-text-find-broken.patch Is Empty for text-find widget broken Key: OFBIZ-4025 URL: https://issues.apache.org/jira/browse/OFBIZ-4025 Project: OFBiz Issue Type: Bug Components: framework Affects Versions: SVN trunk Environment: Rev 1036293 Reporter: Anne Jessel Priority: Minor Attachments: OFBIZ-4025_Is-Empty-for-text-find-broken.patch To reproduce: - go to Facility, Inventory Items tab (or any form that uses text-find widget) - choose Is Empty from drop-down next to Product Id - click Find button Expected behaviour: no matching items listed, as all items have a Product Id. Observed behaviour: all items match. Problem is caused by find code assuming that there is no entity condition to be created if the text field is empty, but of course Is Empty is different to the other operators in that the text field is expected to be empty. The attached patch adds a special check for the Is Empty operator. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (OFBIZ-4018) title-property should be titleProperty
title-property should be titleProperty -- Key: OFBIZ-4018 URL: https://issues.apache.org/jira/browse/OFBIZ-4018 Project: OFBiz Issue Type: Bug Components: order Affects Versions: SVN trunk Environment: Rev 1035845 Reporter: Anne Jessel Priority: Minor Some screen widgets set the field title-property instead of titleProperty. This causes errors in the logs, and means that the page title is not being set. Patch attached. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (OFBIZ-2888) Reserved words used for field names in PaymentGatewayOrbital
Reserved words used for field names in PaymentGatewayOrbital Key: OFBIZ-2888 URL: https://issues.apache.org/jira/browse/OFBIZ-2888 Project: OFBiz Issue Type: Bug Affects Versions: SVN trunk Environment: Linux, Java 1.6, Postgresql 8.3 with driver postgresql-8.3-604.jdbc4.jar Reporter: Anne Jessel Priority: Minor On starting Rev 809782 of trunk, I see the following warnings: 2009-09-02 09:05:03,747 (main) [ DelegatorImpl.java:176:WARN ] =-=-=-=-= Found 2 warnings when checking the entity definitions: 2009-09-02 09:05:03,748 (main) [ DelegatorImpl.java:178:WARN ] [FieldNameRW] Column name PASSWORD of entity PaymentGatewayOrbital is a reserved word. 2009-09-02 09:05:03,748 (main) [ DelegatorImpl.java:178:WARN ] [FieldNameRW] Column name CLASS of entity PaymentGatewayOrbital is a reserved word. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Query re: (OFBIZ-2748) Wrong calculation in UtilDateTime getIntervalInDays
Thank you. Wish I'd known a week ago. :-) Could someone please clarify - the methods in UtilDateTime destined for deprecation are those not using TimeZone or Locale? So those using TimeZone and Locale are okay to use? Cheers, Anne. 2009/7/23 Adrian Crum (JIRA) lt;j...@apache.orggt; nbsp; nbsp; [ https://issues.apache.org/jira/browse/OFBIZ-2748?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Adrian Crum closed OFBIZ-2748. -- nbsp; nbsp;Resolution: Won't Fix Anne, It would be preferable to use the TimeDuration class instead of these UtilDateTime methods. The UtilDateTime methods are flawed because they don't take locale and time zone into consideration, and they use millisecond arithmetic (a definite no-no). Those methods are about to be deprecated and eventually they will be removed. gt; Wrong calculation in UtilDateTime getIntervalInDays gt; --- gt; gt; nbsp; nbsp; nbsp; nbsp; nbsp; nbsp; nbsp; nbsp; Key: OFBIZ-2748 gt; nbsp; nbsp; nbsp; nbsp; nbsp; nbsp; nbsp; nbsp; URL: https://issues.apache.org/jira/browse/OFBIZ-2748 gt; nbsp; nbsp; nbsp; nbsp; nbsp; nbsp; Project: OFBiz gt; nbsp; nbsp; nbsp; nbsp; nbsp;Issue Type: Bug gt; nbsp; nbsp; nbsp; nbsp; nbsp;Components: framework gt; nbsp; nbsp;Affects Versions: Release Branch 9.04 gt; nbsp; nbsp; nbsp; nbsp; Environment: Sun Java 6, Linux, Postgres gt; nbsp; nbsp; nbsp; nbsp; nbsp; nbsp;Reporter: Anne Jessel gt; nbsp; nbsp; nbsp; nbsp; Attachments: castbug.patch gt; gt; gt; If the two timestamps passed to getIntervalInDays are more than Integer.MAX_VALUE nanoseconds apart, the returned value is incorrect. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. -- Coherent Software Australia Pty Ltd PO Box 2773 Cheltenham Vic 3192 Phone: (03) 9585 6788 Fax: (03) 9585 1086 Web: http://www.cohsoft.com.au/ Email: sa...@cohsoft.com.au Bonsai ERP, the all-inclusive ERP system http://www.bonsaierp.com.au/ signature.asc Description: OpenPGP digital signature
[jira] Created: (OFBIZ-2748) Wrong calculation in UtilDateTime getIntervalInDays
Wrong calculation in UtilDateTime getIntervalInDays --- Key: OFBIZ-2748 URL: https://issues.apache.org/jira/browse/OFBIZ-2748 Project: OFBiz Issue Type: Bug Components: framework Affects Versions: Release Branch 9.04 Environment: Sun Java 6, Linux, Postgres Reporter: Anne Jessel If the two timestamps passed to getIntervalInDays are more than Integer.MAX_VALUE nanoseconds apart, the returned value is incorrect. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
