Re: svn commit: r931594 - /ofbiz/trunk/applications/product/src/org/ofbiz/shipment/shipment/ShipmentServices.java
I'm fairly sure this fix is correct. We need to look at what the demo store is doing. Matching with an OR doesn't make sense to me. If you've specified an exact productStoreShipMethId, why should you receive anything other than the corresponding entity? - Scott Gray wrote: This commit broke the demo system, no cost estimates are returned during checkout any more.
Re: Release 4 on the download page
would 4.0 be an archive or put some other site like 3.0 is = BJ Freeman http://bjfreeman.elance.com Strategic Power Office with Supplier Automation http://www.businessesnetwork.com/automation/viewforum.php?f=93 Specialtymarket.com http://www.specialtymarket.com/ Systems Integrator-- Glad to Assist Chat Y! messenger: bjfr33man Linkedin http://www.linkedin.com/profile?viewProfile=key=1237480locale=en_UStrk=tab_pro Jacopo Cappellato sent the following on 4/16/2010 10:28 PM: On Apr 17, 2010, at 3:00 AM, Adrian Crum wrote: Now that we have an official 9.04 release, and since interest in Release 4.0 has waned, should we remove Release 4.0 from the downloads page? I agree, especially because Release 4.0 is not an official ASF release BTW have a look at the new download page, it is much cleaner now. Also, now that we have an official 9.04 release, do we still need all of those 9.04 snapshots? In my opinion we don't need all those snapshots (there are too many also for the trunk, imo). But at least a couple of snapshots for the 9.04 release branch are useful because the release branch is receiving new bug fix commits (that could induce us to release a bug fix release 9.04.1 in the future). Jacopo -Adrian
Re: Release 4 on the download page
If we want to distribute it thru the ASF mirrors (and have it in the ASF release archive) we will have to officially release it (i.e. prepare the package, sign it, vote on it and publish) as we did a few days ago for the 09.04 release. I don't think it is worth of the effort but I am wide open to suggestions. Jacopo On Apr 17, 2010, at 8:48 AM, BJ Freeman wrote: would 4.0 be an archive or put some other site like 3.0 is = BJ Freeman http://bjfreeman.elance.com Strategic Power Office with Supplier Automation http://www.businessesnetwork.com/automation/viewforum.php?f=93 Specialtymarket.com http://www.specialtymarket.com/ Systems Integrator-- Glad to Assist Chat Y! messenger: bjfr33man Linkedin http://www.linkedin.com/profile?viewProfile=key=1237480locale=en_UStrk=tab_pro Jacopo Cappellato sent the following on 4/16/2010 10:28 PM: On Apr 17, 2010, at 3:00 AM, Adrian Crum wrote: Now that we have an official 9.04 release, and since interest in Release 4.0 has waned, should we remove Release 4.0 from the downloads page? I agree, especially because Release 4.0 is not an official ASF release BTW have a look at the new download page, it is much cleaner now. Also, now that we have an official 9.04 release, do we still need all of those 9.04 snapshots? In my opinion we don't need all those snapshots (there are too many also for the trunk, imo). But at least a couple of snapshots for the 9.04 release branch are useful because the release branch is receiving new bug fix commits (that could induce us to release a bug fix release 9.04.1 in the future). Jacopo -Adrian
[jira] Commented: (OFBIZ-3636) Order Manager: the Add Gift Certificate button in 3rd screen of order creation does not work
[ https://issues.apache.org/jira/browse/OFBIZ-3636?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12858106#action_12858106 ] Scott Gray commented on OFBIZ-3636: --- Yeah those extra (and unnecessary IMO) ProductStores are a real PITA Order Manager: the Add Gift Certificate button in 3rd screen of order creation does not work - Key: OFBIZ-3636 URL: https://issues.apache.org/jira/browse/OFBIZ-3636 Project: OFBiz Issue Type: Bug Components: order Affects Versions: SVN trunk Reporter: Jacques Le Roux Fix For: SVN trunk https://demo-trunk.ofbiz.apache.org/ordermgr/control/AddGiftCertificate It does not work or I don't know how it works. Anyway if something special is needed it should no be available in any cases as it's now. This feature does not exist in R9.04 -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (OFBIZ-3576) Error in Creating new Content - CMS.
[ https://issues.apache.org/jira/browse/OFBIZ-3576?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Scott Gray closed OFBIZ-3576. - Resolution: Fixed Somebody fixed it because it works now Error in Creating new Content - CMS. - Key: OFBIZ-3576 URL: https://issues.apache.org/jira/browse/OFBIZ-3576 Project: OFBiz Issue Type: Bug Components: content Affects Versions: SVN trunk Reporter: Sumit Pandit Fix For: SVN trunk At https://demo-trunk.ofbiz.apache.org:8443/content/control/CMSContentFind when click on 'Create new' getting error at next page. org.ofbiz.widget.screen.ScreenRenderException: Error rendering screen [component://content/widget/cms/CMSScreens.xml#EditAddContent]: org.ofbiz.base.util.GeneralException: Error running Groovy script at location [component://content/webapp/content/WEB-INF/actions/cms/CmsEditAddPrep.groovy] (Could not find SimpleMapProcessor XML document in resource: org/ofbiz/content/ContentManagementMapProcessors.xml) (Error running Groovy script at location [component://content/webapp/content/WEB-INF/actions/cms/CmsEditAddPrep.groovy] (Could not find SimpleMapProcessor XML document in resource: org/ofbiz/content/ContentManagementMapProcessors.xml)) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: svn commit: r935141 - in /ofbiz/site: documentation.html download.html
Should be screenshots not screenshoots. Regards Scott On 17/04/2010, at 7:46 PM, jler...@apache.org wrote: Author: jleroux Date: Sat Apr 17 07:46:27 2010 New Revision: 935141 URL: http://svn.apache.org/viewvc?rev=935141view=rev Log: I forgot to update these 2 pages for screenshots link Modified: ofbiz/site/documentation.html ofbiz/site/download.html Modified: ofbiz/site/documentation.html URL: http://svn.apache.org/viewvc/ofbiz/site/documentation.html?rev=935141r1=935140r2=935141view=diff == --- ofbiz/site/documentation.html (original) +++ ofbiz/site/documentation.html Sat Apr 17 07:46:27 2010 @@ -41,6 +41,7 @@ li id=currenta href=documentation.htmlDocumentation/a/li lia href=download.htmlDownload/a/li lia href=http://cwiki.apache.org/confluence/x/L4B2;Community/a/li +lia href=http://cwiki.apache.org/confluence/x/f4AHAQ;Screenshoots/a/li /ul /div div id=search Modified: ofbiz/site/download.html URL: http://svn.apache.org/viewvc/ofbiz/site/download.html?rev=935141r1=935140r2=935141view=diff == --- ofbiz/site/download.html (original) +++ ofbiz/site/download.html Sat Apr 17 07:46:27 2010 @@ -41,6 +41,7 @@ lia href=documentation.htmlDocumentation/a/li li id=currenta href=download.htmlDownload/a/li lia href=http://cwiki.apache.org/confluence/x/L4B2;Community/a/li +lia href=http://cwiki.apache.org/confluence/x/f4AHAQ;Screenshoots/a/li /ul /div div id=search smime.p7s Description: S/MIME cryptographic signature
Re: svn commit: r935141 - in /ofbiz/site: documentation.html download.html
And also: do we really need them in the top nav bar? I would prefer to see them as a link in the right bar (and maybe also in the content of the main page). There are too many top links right now (and screenshots is not properly rendered) and imo one of our next steps should be to discuss what should stay there (for example I would also remove about and maybe features). Jacopo On Apr 17, 2010, at 9:47 AM, Scott Gray wrote: Should be screenshots not screenshoots. Regards Scott On 17/04/2010, at 7:46 PM, jler...@apache.org wrote: Author: jleroux Date: Sat Apr 17 07:46:27 2010 New Revision: 935141 URL: http://svn.apache.org/viewvc?rev=935141view=rev Log: I forgot to update these 2 pages for screenshots link Modified: ofbiz/site/documentation.html ofbiz/site/download.html Modified: ofbiz/site/documentation.html URL: http://svn.apache.org/viewvc/ofbiz/site/documentation.html?rev=935141r1=935140r2=935141view=diff == --- ofbiz/site/documentation.html (original) +++ ofbiz/site/documentation.html Sat Apr 17 07:46:27 2010 @@ -41,6 +41,7 @@ li id=currenta href=documentation.htmlDocumentation/a/li lia href=download.htmlDownload/a/li lia href=http://cwiki.apache.org/confluence/x/L4B2;Community/a/li +lia href=http://cwiki.apache.org/confluence/x/f4AHAQ;Screenshoots/a/li /ul /div div id=search Modified: ofbiz/site/download.html URL: http://svn.apache.org/viewvc/ofbiz/site/download.html?rev=935141r1=935140r2=935141view=diff == --- ofbiz/site/download.html (original) +++ ofbiz/site/download.html Sat Apr 17 07:46:27 2010 @@ -41,6 +41,7 @@ lia href=documentation.htmlDocumentation/a/li li id=currenta href=download.htmlDownload/a/li lia href=http://cwiki.apache.org/confluence/x/L4B2;Community/a/li +lia href=http://cwiki.apache.org/confluence/x/f4AHAQ;Screenshoots/a/li /ul /div div id=search
Re: svn commit: r935141 - in /ofbiz/site: documentation.html download.html
Oops, I did not see the typo :/. Bruno suggested to put it in the top bar. But I see no problems to have it in the right bar (just under documentation and before the Resources Tools section) I don't see a place for it in content of main page. Do we agree? Jacques From: Jacopo Cappellato jacopo.cappell...@hotwaxmedia.com And also: do we really need them in the top nav bar? I would prefer to see them as a link in the right bar (and maybe also in the content of the main page). There are too many top links right now (and screenshots is not properly rendered) and imo one of our next steps should be to discuss what should stay there (for example I would also remove about and maybe features). Jacopo On Apr 17, 2010, at 9:47 AM, Scott Gray wrote: Should be screenshots not screenshoots. Regards Scott On 17/04/2010, at 7:46 PM, jler...@apache.org wrote: Author: jleroux Date: Sat Apr 17 07:46:27 2010 New Revision: 935141 URL: http://svn.apache.org/viewvc?rev=935141view=rev Log: I forgot to update these 2 pages for screenshots link Modified: ofbiz/site/documentation.html ofbiz/site/download.html Modified: ofbiz/site/documentation.html URL: http://svn.apache.org/viewvc/ofbiz/site/documentation.html?rev=935141r1=935140r2=935141view=diff == --- ofbiz/site/documentation.html (original) +++ ofbiz/site/documentation.html Sat Apr 17 07:46:27 2010 @@ -41,6 +41,7 @@ li id=currenta href=documentation.htmlDocumentation/a/li lia href=download.htmlDownload/a/li lia href=http://cwiki.apache.org/confluence/x/L4B2;Community/a/li +lia href=http://cwiki.apache.org/confluence/x/f4AHAQ;Screenshoots/a/li /ul /div div id=search Modified: ofbiz/site/download.html URL: http://svn.apache.org/viewvc/ofbiz/site/download.html?rev=935141r1=935140r2=935141view=diff == --- ofbiz/site/download.html (original) +++ ofbiz/site/download.html Sat Apr 17 07:46:27 2010 @@ -41,6 +41,7 @@ lia href=documentation.htmlDocumentation/a/li li id=currenta href=download.htmlDownload/a/li lia href=http://cwiki.apache.org/confluence/x/L4B2;Community/a/li +lia href=http://cwiki.apache.org/confluence/x/f4AHAQ;Screenshoots/a/li /ul /div div id=search
[jira] Commented: (OFBIZ-3636) Order Manager: the Add Gift Certificate button in 3rd screen of order creation does not work
[ https://issues.apache.org/jira/browse/OFBIZ-3636?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12858110#action_12858110 ] Jacques Le Roux commented on OFBIZ-3636: Should we not do something about that. Because it's clearly leading to bad experience with order entry :( And this is a very important point IMO... Order Manager: the Add Gift Certificate button in 3rd screen of order creation does not work - Key: OFBIZ-3636 URL: https://issues.apache.org/jira/browse/OFBIZ-3636 Project: OFBiz Issue Type: Bug Components: order Affects Versions: SVN trunk Reporter: Jacques Le Roux Fix For: SVN trunk https://demo-trunk.ofbiz.apache.org/ordermgr/control/AddGiftCertificate It does not work or I don't know how it works. Anyway if something special is needed it should no be available in any cases as it's now. This feature does not exist in R9.04 -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Reopened: (OFBIZ-3636) Order Manager: the Add Gift Certificate button in 3rd screen of order creation does not work
[ https://issues.apache.org/jira/browse/OFBIZ-3636?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jacques Le Roux reopened OFBIZ-3636: Order Manager: the Add Gift Certificate button in 3rd screen of order creation does not work - Key: OFBIZ-3636 URL: https://issues.apache.org/jira/browse/OFBIZ-3636 Project: OFBiz Issue Type: Bug Components: order Affects Versions: SVN trunk Reporter: Jacques Le Roux Fix For: SVN trunk https://demo-trunk.ofbiz.apache.org/ordermgr/control/AddGiftCertificate It does not work or I don't know how it works. Anyway if something special is needed it should no be available in any cases as it's now. This feature does not exist in R9.04 -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (OFBIZ-3636) Order Manager: the Add Gift Certificate button in 3rd screen of order creation does not work
[ https://issues.apache.org/jira/browse/OFBIZ-3636?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12858111#action_12858111 ] Scott Gray commented on OFBIZ-3636: --- Talk to Hans, I'm pretty sure I complained at the time. Order Manager: the Add Gift Certificate button in 3rd screen of order creation does not work - Key: OFBIZ-3636 URL: https://issues.apache.org/jira/browse/OFBIZ-3636 Project: OFBiz Issue Type: Bug Components: order Affects Versions: SVN trunk Reporter: Jacques Le Roux Fix For: SVN trunk https://demo-trunk.ofbiz.apache.org/ordermgr/control/AddGiftCertificate It does not work or I don't know how it works. Anyway if something special is needed it should no be available in any cases as it's now. This feature does not exist in R9.04 -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (OFBIZ-3523) Send a Confirmation email content doesn't generate correct URL
[ https://issues.apache.org/jira/browse/OFBIZ-3523?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Scott Gray closed OFBIZ-3523. - Assignee: Scott Gray (was: Ashish Vijaywargiya) Resolution: Fixed Sorry Ashish, I didn't realize this was assigned to you until just now :-) Anyways fixed in r935146 Send a Confirmation email content doesn't generate correct URL --- Key: OFBIZ-3523 URL: https://issues.apache.org/jira/browse/OFBIZ-3523 Project: OFBiz Issue Type: Bug Components: order Affects Versions: SVN trunk Reporter: Ashish Vijaywargiya Assignee: Scott Gray Fix For: SVN trunk Attachments: Order_Confirmation.png Steps to reproduce: 1) Place a sales order. 2) Edit that Order. 3) There is a link next to the email address Send Confirmation Email. 4) Clink on the Send button. 5) The generated email doesn't contain correct URL. 6) Image attached for ready reference (Refer status bar in the attached image). -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (OFBIZ-3653) CSS Style for select wrong in tomahawk theme
[
https://issues.apache.org/jira/browse/OFBIZ-3653?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12858113#action_12858113
]
Bruno Busco commented on OFBIZ-3653:
Thank you Blas,
your patch is in trunk at revision: 935149
BTW I noted another wrong alignment that I will show you with a screenshot.
Thank you for all your work on these topics.
Bruno
CSS Style for select wrong in tomahawk theme
Key: OFBIZ-3653
URL: https://issues.apache.org/jira/browse/OFBIZ-3653
Project: OFBiz
Issue Type: Bug
Components: themes
Affects Versions: SVN trunk
Reporter: Blas Rodriguez Somoza
Assignee: Bruno Busco
Priority: Minor
Fix For: SVN trunk
Attachments: OFBIZ-3653_after2_halign.jpg,
OFBIZ-3653_after2_listform.jpg, OFBIZ-3653_before2_halign.jpg,
OFBIZ-3653_before2_listform.jpg, OFBIZ-3653_css.diff, pagination_select.JPG,
tomahawk_chrome_after.jpg, tomahawk_chrome_before.jpg, tomahawk_ff_after.jpg,
tomahawk_ff_before.jpg, tomahawk_ie_after.jpg, tomahawk_ie_before.jpg
The css style of select tag in style.css
uses an height which is 1.6em when the height of text input is (1.1em + 0.4em
* 2 + 0.1em * 2) = 2.1 em
this gives a ugly look and in IE could cut the lower part of the text.
existing style.css:
select {
background-color: #fffcea;
border: #99 solid 0.1em;
font-size: 1.1em;
height: 1.6em; /* force ctrl to scale with text */
margin: 0.1em;
}
input[type=text],input[type=password] {
background-color: #fffcea;
border:0.1em solid #99;
font-size: 1.1em;
margin: 0.2em;
padding:0.4em 0;
}
The proposed css style for select is the following (height and margin
changed, padding added)
select {
background-color: #fffcea;
border: #99 solid 0.1em;
font-size: 1.1em;
height: 2.1em; /* force ctrl to scale with text */
margin: 0.2em;
padding: 0.1em;
}
The result in IE is not good because IE 7 don't support select styling
correctly, but it is better than previously.
Attached images of FF 3.5 , IE 7 and Chrome with the existing style and the
proposed one.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
https://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: svn commit: r935141 - in /ofbiz/site: documentation.html download.html
On Apr 17, 2010, at 10:12 AM, Jacques Le Roux wrote: Oops, I did not see the typo :/. Bruno suggested to put it in the top bar. But I see no problems to have it in the right bar (just under documentation and before the Resources Tools section) I don't see a place for it in content of main page. Do we agree? +1 for moving to right bar now we can always refine this later. Jacopo Jacques From: Jacopo Cappellato jacopo.cappell...@hotwaxmedia.com And also: do we really need them in the top nav bar? I would prefer to see them as a link in the right bar (and maybe also in the content of the main page). There are too many top links right now (and screenshots is not properly rendered) and imo one of our next steps should be to discuss what should stay there (for example I would also remove about and maybe features). Jacopo On Apr 17, 2010, at 9:47 AM, Scott Gray wrote: Should be screenshots not screenshoots. Regards Scott On 17/04/2010, at 7:46 PM, jler...@apache.org wrote: Author: jleroux Date: Sat Apr 17 07:46:27 2010 New Revision: 935141 URL: http://svn.apache.org/viewvc?rev=935141view=rev Log: I forgot to update these 2 pages for screenshots link Modified: ofbiz/site/documentation.html ofbiz/site/download.html Modified: ofbiz/site/documentation.html URL: http://svn.apache.org/viewvc/ofbiz/site/documentation.html?rev=935141r1=935140r2=935141view=diff == --- ofbiz/site/documentation.html (original) +++ ofbiz/site/documentation.html Sat Apr 17 07:46:27 2010 @@ -41,6 +41,7 @@ li id=currenta href=documentation.htmlDocumentation/a/li lia href=download.htmlDownload/a/li lia href=http://cwiki.apache.org/confluence/x/L4B2;Community/a/li +lia href=http://cwiki.apache.org/confluence/x/f4AHAQ;Screenshoots/a/li /ul /div div id=search Modified: ofbiz/site/download.html URL: http://svn.apache.org/viewvc/ofbiz/site/download.html?rev=935141r1=935140r2=935141view=diff == --- ofbiz/site/download.html (original) +++ ofbiz/site/download.html Sat Apr 17 07:46:27 2010 @@ -41,6 +41,7 @@ lia href=documentation.htmlDocumentation/a/li li id=currenta href=download.htmlDownload/a/li lia href=http://cwiki.apache.org/confluence/x/L4B2;Community/a/li +lia href=http://cwiki.apache.org/confluence/x/f4AHAQ;Screenshoots/a/li /ul /div div id=search
[jira] Updated: (OFBIZ-3653) CSS Style for select wrong in tomahawk theme
[
https://issues.apache.org/jira/browse/OFBIZ-3653?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Bruno Busco updated OFBIZ-3653:
---
Attachment: fieldname_alignment.jpg
There are several vertical alignment issues between field names and the
textbox, select etc.
This is not caused by the committed patch but related in subject.
CSS Style for select wrong in tomahawk theme
Key: OFBIZ-3653
URL: https://issues.apache.org/jira/browse/OFBIZ-3653
Project: OFBiz
Issue Type: Bug
Components: themes
Affects Versions: SVN trunk
Reporter: Blas Rodriguez Somoza
Assignee: Bruno Busco
Priority: Minor
Fix For: SVN trunk
Attachments: fieldname_alignment.jpg, OFBIZ-3653_after2_halign.jpg,
OFBIZ-3653_after2_listform.jpg, OFBIZ-3653_before2_halign.jpg,
OFBIZ-3653_before2_listform.jpg, OFBIZ-3653_css.diff, pagination_select.JPG,
tomahawk_chrome_after.jpg, tomahawk_chrome_before.jpg, tomahawk_ff_after.jpg,
tomahawk_ff_before.jpg, tomahawk_ie_after.jpg, tomahawk_ie_before.jpg
The css style of select tag in style.css
uses an height which is 1.6em when the height of text input is (1.1em + 0.4em
* 2 + 0.1em * 2) = 2.1 em
this gives a ugly look and in IE could cut the lower part of the text.
existing style.css:
select {
background-color: #fffcea;
border: #99 solid 0.1em;
font-size: 1.1em;
height: 1.6em; /* force ctrl to scale with text */
margin: 0.1em;
}
input[type=text],input[type=password] {
background-color: #fffcea;
border:0.1em solid #99;
font-size: 1.1em;
margin: 0.2em;
padding:0.4em 0;
}
The proposed css style for select is the following (height and margin
changed, padding added)
select {
background-color: #fffcea;
border: #99 solid 0.1em;
font-size: 1.1em;
height: 2.1em; /* force ctrl to scale with text */
margin: 0.2em;
padding: 0.1em;
}
The result in IE is not good because IE 7 don't support select styling
correctly, but it is better than previously.
Attached images of FF 3.5 , IE 7 and Chrome with the existing style and the
proposed one.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
https://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (OFBIZ-3636) Order Manager: the Add Gift Certificate button in 3rd screen of order creation does not work
[ https://issues.apache.org/jira/browse/OFBIZ-3636?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jacques Le Roux closed OFBIZ-3636. -- Assignee: Jacques Le Roux Resolution: Fixed Fixed at r935150, I even updated the demo server Order Manager: the Add Gift Certificate button in 3rd screen of order creation does not work - Key: OFBIZ-3636 URL: https://issues.apache.org/jira/browse/OFBIZ-3636 Project: OFBiz Issue Type: Bug Components: order Affects Versions: SVN trunk Reporter: Jacques Le Roux Assignee: Jacques Le Roux Fix For: SVN trunk https://demo-trunk.ofbiz.apache.org/ordermgr/control/AddGiftCertificate It does not work or I don't know how it works. Anyway if something special is needed it should no be available in any cases as it's now. This feature does not exist in R9.04 -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (OFBIZ-3442) Replace popup lookups by layer lookups
[ https://issues.apache.org/jira/browse/OFBIZ-3442?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12858117#action_12858117 ] Jacques Le Roux commented on OFBIZ-3442: Hi Bilgin, Forget what I said, I saw the ajaxLookup working in an FTL field (Customer field in the 1st Order Entry screen in Order Manager). It's weird in Firefox 3.6.3 because some time it works some time not (but with my 58 plugins ;o). It's ok in Opera. I don't remember if I have not opened a Jira issue for that (I don't this so), maybe I simply wrote something about that in another place. Replace popup lookups by layer lookups -- Key: OFBIZ-3442 URL: https://issues.apache.org/jira/browse/OFBIZ-3442 Project: OFBiz Issue Type: Sub-task Components: ALL APPLICATIONS Reporter: Jacques Le Roux Assignee: Jacques Le Roux Priority: Minor Attachments: lookup.htm, OFBIZ-3442 replace popup lookups by layered lookups.patch Following Sascha Rodekamp's work on layer lookups OFBIZ-3374 and improvements OFBIZ-3430, I propose now to replace old the popup lookups by layered (Ajaxified) lookups. For that please find a patch attached. In this patch I followed a simple S/R tactic: * I replaced all occurences of LookupDecorator by LookupLayerPopupDecorator in screens * I replaced all occurences of lookup by lookup presentation=layer position=center It's as simple as this. For the moment I decided to use as default position=center because it's was the easiest (sure that any lookups will be out of the screen). I think we will refine this by removing position=center and use the default (position=normal) which does not move the layer from the point it's called and will be more aesthetic. I did not test anything in OFBIz OOTB for the moment, but I already use layered lookups in a custom application without any issues so far. The only drawback I found for the moment is when a lookup is called from a lookup. If you are aware of such cases please chime in. Of course everybody is encouraged to test this improvement as much as possible. I really think it's a very cool feature for users, and they will appreciate. There are still some ideas like that (see the link Sasca referred to in OFBIZ-3374), and we will try to implement them. There are issues to be fixed prior to a commit, see OFBIZ-3446. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: svn commit: r935141 - in /ofbiz/site: documentation.html download.html
From: Jacopo Cappellato jacopo.cappell...@hotwaxmedia.com On Apr 17, 2010, at 10:12 AM, Jacques Le Roux wrote: Oops, I did not see the typo :/. Bruno suggested to put it in the top bar. But I see no problems to have it in the right bar (just under documentation and before the Resources Tools section) I don't see a place for it in content of main page. Do we agree? +1 for moving to right bar now we can always refine this later. Jacopo I was ready to commit, but I wonder if we should keep the link in top bar of other pages (than home page)? Or do you plan to have something in the right bar of these other pages (for now documentation and download), Jacopo? As I said before, I wonder about that... Any opinions? Jacques Jacques From: Jacopo Cappellato jacopo.cappell...@hotwaxmedia.com And also: do we really need them in the top nav bar? I would prefer to see them as a link in the right bar (and maybe also in the content of the main page). There are too many top links right now (and screenshots is not properly rendered) and imo one of our next steps should be to discuss what should stay there (for example I would also remove about and maybe features). Jacopo On Apr 17, 2010, at 9:47 AM, Scott Gray wrote: Should be screenshots not screenshoots. Regards Scott On 17/04/2010, at 7:46 PM, jler...@apache.org wrote: Author: jleroux Date: Sat Apr 17 07:46:27 2010 New Revision: 935141 URL: http://svn.apache.org/viewvc?rev=935141view=rev Log: I forgot to update these 2 pages for screenshots link Modified: ofbiz/site/documentation.html ofbiz/site/download.html Modified: ofbiz/site/documentation.html URL: http://svn.apache.org/viewvc/ofbiz/site/documentation.html?rev=935141r1=935140r2=935141view=diff == --- ofbiz/site/documentation.html (original) +++ ofbiz/site/documentation.html Sat Apr 17 07:46:27 2010 @@ -41,6 +41,7 @@ li id=currenta href=documentation.htmlDocumentation/a/li lia href=download.htmlDownload/a/li lia href=http://cwiki.apache.org/confluence/x/L4B2;Community/a/li +lia href=http://cwiki.apache.org/confluence/x/f4AHAQ;Screenshoots/a/li /ul /div div id=search Modified: ofbiz/site/download.html URL: http://svn.apache.org/viewvc/ofbiz/site/download.html?rev=935141r1=935140r2=935141view=diff == --- ofbiz/site/download.html (original) +++ ofbiz/site/download.html Sat Apr 17 07:46:27 2010 @@ -41,6 +41,7 @@ lia href=documentation.htmlDocumentation/a/li li id=currenta href=download.htmlDownload/a/li lia href=http://cwiki.apache.org/confluence/x/L4B2;Community/a/li +lia href=http://cwiki.apache.org/confluence/x/f4AHAQ;Screenshoots/a/li /ul /div div id=search
[jira] Closed: (OFBIZ-3653) CSS Style for select wrong in tomahawk theme
[
https://issues.apache.org/jira/browse/OFBIZ-3653?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Blas Rodriguez Somoza closed OFBIZ-3653.
Resolution: Fixed
CSS Style for select wrong in tomahawk theme
Key: OFBIZ-3653
URL: https://issues.apache.org/jira/browse/OFBIZ-3653
Project: OFBiz
Issue Type: Bug
Components: themes
Affects Versions: SVN trunk
Reporter: Blas Rodriguez Somoza
Assignee: Bruno Busco
Priority: Minor
Fix For: SVN trunk
Attachments: fieldname_alignment.jpg, OFBIZ-3653_after2_halign.jpg,
OFBIZ-3653_after2_listform.jpg, OFBIZ-3653_before2_halign.jpg,
OFBIZ-3653_before2_listform.jpg, OFBIZ-3653_css.diff, pagination_select.JPG,
tomahawk_chrome_after.jpg, tomahawk_chrome_before.jpg, tomahawk_ff_after.jpg,
tomahawk_ff_before.jpg, tomahawk_ie_after.jpg, tomahawk_ie_before.jpg
The css style of select tag in style.css
uses an height which is 1.6em when the height of text input is (1.1em + 0.4em
* 2 + 0.1em * 2) = 2.1 em
this gives a ugly look and in IE could cut the lower part of the text.
existing style.css:
select {
background-color: #fffcea;
border: #99 solid 0.1em;
font-size: 1.1em;
height: 1.6em; /* force ctrl to scale with text */
margin: 0.1em;
}
input[type=text],input[type=password] {
background-color: #fffcea;
border:0.1em solid #99;
font-size: 1.1em;
margin: 0.2em;
padding:0.4em 0;
}
The proposed css style for select is the following (height and margin
changed, padding added)
select {
background-color: #fffcea;
border: #99 solid 0.1em;
font-size: 1.1em;
height: 2.1em; /* force ctrl to scale with text */
margin: 0.2em;
padding: 0.1em;
}
The result in IE is not good because IE 7 don't support select styling
correctly, but it is better than previously.
Attached images of FF 3.5 , IE 7 and Chrome with the existing style and the
proposed one.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
https://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (OFBIZ-3653) CSS Style for select wrong in tomahawk theme
[
https://issues.apache.org/jira/browse/OFBIZ-3653?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12858125#action_12858125
]
Blas Rodriguez Somoza commented on OFBIZ-3653:
--
Hi Bruno
This is exactly the problem that I refer to in my comment 11/Apr/10 10:50 PM
AR - Payments - Edit - Header (wrong layout)
I've a patch for this also, but I need OFBIZ-3671 committed before, because the
solution for those problems imply not only styles, but also
htmlFormMacroLibrary.flt
I'll close this issue.
I'll open a new JIRA issue with the patch for this problem as soon as
OFBIZ-3671 is closed.
CSS Style for select wrong in tomahawk theme
Key: OFBIZ-3653
URL: https://issues.apache.org/jira/browse/OFBIZ-3653
Project: OFBiz
Issue Type: Bug
Components: themes
Affects Versions: SVN trunk
Reporter: Blas Rodriguez Somoza
Assignee: Bruno Busco
Priority: Minor
Fix For: SVN trunk
Attachments: fieldname_alignment.jpg, OFBIZ-3653_after2_halign.jpg,
OFBIZ-3653_after2_listform.jpg, OFBIZ-3653_before2_halign.jpg,
OFBIZ-3653_before2_listform.jpg, OFBIZ-3653_css.diff, pagination_select.JPG,
tomahawk_chrome_after.jpg, tomahawk_chrome_before.jpg, tomahawk_ff_after.jpg,
tomahawk_ff_before.jpg, tomahawk_ie_after.jpg, tomahawk_ie_before.jpg
The css style of select tag in style.css
uses an height which is 1.6em when the height of text input is (1.1em + 0.4em
* 2 + 0.1em * 2) = 2.1 em
this gives a ugly look and in IE could cut the lower part of the text.
existing style.css:
select {
background-color: #fffcea;
border: #99 solid 0.1em;
font-size: 1.1em;
height: 1.6em; /* force ctrl to scale with text */
margin: 0.1em;
}
input[type=text],input[type=password] {
background-color: #fffcea;
border:0.1em solid #99;
font-size: 1.1em;
margin: 0.2em;
padding:0.4em 0;
}
The proposed css style for select is the following (height and margin
changed, padding added)
select {
background-color: #fffcea;
border: #99 solid 0.1em;
font-size: 1.1em;
height: 2.1em; /* force ctrl to scale with text */
margin: 0.2em;
padding: 0.1em;
}
The result in IE is not good because IE 7 don't support select styling
correctly, but it is better than previously.
Attached images of FF 3.5 , IE 7 and Chrome with the existing style and the
proposed one.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
https://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: svn commit: r935141 - in /ofbiz/site: documentation.html download.html
On Apr 17, 2010, at 11:18 AM, Jacques Le Roux wrote: From: Jacopo Cappellato jacopo.cappell...@hotwaxmedia.com On Apr 17, 2010, at 10:12 AM, Jacques Le Roux wrote: Oops, I did not see the typo :/. Bruno suggested to put it in the top bar. But I see no problems to have it in the right bar (just under documentation and before the Resources Tools section) I don't see a place for it in content of main page. Do we agree? +1 for moving to right bar now we can always refine this later. Jacopo I was ready to commit, but I wonder if we should keep the link in top bar of other pages (than home page)? Or do you plan to have something in the right bar of these other pages (for now documentation and download), Jacopo? As I said before, I wonder about that... Any opinions? My preference would be to have the same header for all the pages; as I said before we can then rethink the links in the header. Jacopo Jacques Jacques From: Jacopo Cappellato jacopo.cappell...@hotwaxmedia.com And also: do we really need them in the top nav bar? I would prefer to see them as a link in the right bar (and maybe also in the content of the main page). There are too many top links right now (and screenshots is not properly rendered) and imo one of our next steps should be to discuss what should stay there (for example I would also remove about and maybe features). Jacopo On Apr 17, 2010, at 9:47 AM, Scott Gray wrote: Should be screenshots not screenshoots. Regards Scott On 17/04/2010, at 7:46 PM, jler...@apache.org wrote: Author: jleroux Date: Sat Apr 17 07:46:27 2010 New Revision: 935141 URL: http://svn.apache.org/viewvc?rev=935141view=rev Log: I forgot to update these 2 pages for screenshots link Modified: ofbiz/site/documentation.html ofbiz/site/download.html Modified: ofbiz/site/documentation.html URL: http://svn.apache.org/viewvc/ofbiz/site/documentation.html?rev=935141r1=935140r2=935141view=diff == --- ofbiz/site/documentation.html (original) +++ ofbiz/site/documentation.html Sat Apr 17 07:46:27 2010 @@ -41,6 +41,7 @@ li id=currenta href=documentation.htmlDocumentation/a/li lia href=download.htmlDownload/a/li lia href=http://cwiki.apache.org/confluence/x/L4B2;Community/a/li +lia href=http://cwiki.apache.org/confluence/x/f4AHAQ;Screenshoots/a/li /ul /div div id=search Modified: ofbiz/site/download.html URL: http://svn.apache.org/viewvc/ofbiz/site/download.html?rev=935141r1=935140r2=935141view=diff == --- ofbiz/site/download.html (original) +++ ofbiz/site/download.html Sat Apr 17 07:46:27 2010 @@ -41,6 +41,7 @@ lia href=documentation.htmlDocumentation/a/li li id=currenta href=download.htmlDownload/a/li lia href=http://cwiki.apache.org/confluence/x/L4B2;Community/a/li +lia href=http://cwiki.apache.org/confluence/x/f4AHAQ;Screenshoots/a/li /ul /div div id=search
Re: svn commit: r935141 - in /ofbiz/site: documentation.html download.html
BTW: I like the idea of a screenshot page! Jacopo On Apr 17, 2010, at 12:25 PM, Jacopo Cappellato wrote: On Apr 17, 2010, at 11:18 AM, Jacques Le Roux wrote: From: Jacopo Cappellato jacopo.cappell...@hotwaxmedia.com On Apr 17, 2010, at 10:12 AM, Jacques Le Roux wrote: Oops, I did not see the typo :/. Bruno suggested to put it in the top bar. But I see no problems to have it in the right bar (just under documentation and before the Resources Tools section) I don't see a place for it in content of main page. Do we agree? +1 for moving to right bar now we can always refine this later. Jacopo I was ready to commit, but I wonder if we should keep the link in top bar of other pages (than home page)? Or do you plan to have something in the right bar of these other pages (for now documentation and download), Jacopo? As I said before, I wonder about that... Any opinions? My preference would be to have the same header for all the pages; as I said before we can then rethink the links in the header. Jacopo Jacques Jacques From: Jacopo Cappellato jacopo.cappell...@hotwaxmedia.com And also: do we really need them in the top nav bar? I would prefer to see them as a link in the right bar (and maybe also in the content of the main page). There are too many top links right now (and screenshots is not properly rendered) and imo one of our next steps should be to discuss what should stay there (for example I would also remove about and maybe features). Jacopo On Apr 17, 2010, at 9:47 AM, Scott Gray wrote: Should be screenshots not screenshoots. Regards Scott On 17/04/2010, at 7:46 PM, jler...@apache.org wrote: Author: jleroux Date: Sat Apr 17 07:46:27 2010 New Revision: 935141 URL: http://svn.apache.org/viewvc?rev=935141view=rev Log: I forgot to update these 2 pages for screenshots link Modified: ofbiz/site/documentation.html ofbiz/site/download.html Modified: ofbiz/site/documentation.html URL: http://svn.apache.org/viewvc/ofbiz/site/documentation.html?rev=935141r1=935140r2=935141view=diff == --- ofbiz/site/documentation.html (original) +++ ofbiz/site/documentation.html Sat Apr 17 07:46:27 2010 @@ -41,6 +41,7 @@ li id=currenta href=documentation.htmlDocumentation/a/li lia href=download.htmlDownload/a/li lia href=http://cwiki.apache.org/confluence/x/L4B2;Community/a/li +lia href=http://cwiki.apache.org/confluence/x/f4AHAQ;Screenshoots/a/li /ul /div div id=search Modified: ofbiz/site/download.html URL: http://svn.apache.org/viewvc/ofbiz/site/download.html?rev=935141r1=935140r2=935141view=diff == --- ofbiz/site/download.html (original) +++ ofbiz/site/download.html Sat Apr 17 07:46:27 2010 @@ -41,6 +41,7 @@ lia href=documentation.htmlDocumentation/a/li li id=currenta href=download.htmlDownload/a/li lia href=http://cwiki.apache.org/confluence/x/L4B2;Community/a/li +lia href=http://cwiki.apache.org/confluence/x/f4AHAQ;Screenshoots/a/li /ul /div div id=search
Re: svn commit: r935141 - in /ofbiz/site: documentation.html download.html
From: Jacopo Cappellato jacopo.cappell...@hotwaxmedia.com BTW: I like the idea of a screenshot page! It's Bruno's ideas (and work). BTW, same typo than Bruno: screenshoOt :D Jacques Jacopo On Apr 17, 2010, at 12:25 PM, Jacopo Cappellato wrote: On Apr 17, 2010, at 11:18 AM, Jacques Le Roux wrote: From: Jacopo Cappellato jacopo.cappell...@hotwaxmedia.com On Apr 17, 2010, at 10:12 AM, Jacques Le Roux wrote: Oops, I did not see the typo :/. Bruno suggested to put it in the top bar. But I see no problems to have it in the right bar (just under documentation and before the Resources Tools section) I don't see a place for it in content of main page. Do we agree? +1 for moving to right bar now we can always refine this later. Jacopo I was ready to commit, but I wonder if we should keep the link in top bar of other pages (than home page)? Or do you plan to have something in the right bar of these other pages (for now documentation and download), Jacopo? As I said before, I wonder about that... Any opinions? My preference would be to have the same header for all the pages; as I said before we can then rethink the links in the header. Jacopo Jacques Jacques From: Jacopo Cappellato jacopo.cappell...@hotwaxmedia.com And also: do we really need them in the top nav bar? I would prefer to see them as a link in the right bar (and maybe also in the content of the main page). There are too many top links right now (and screenshots is not properly rendered) and imo one of our next steps should be to discuss what should stay there (for example I would also remove about and maybe features). Jacopo On Apr 17, 2010, at 9:47 AM, Scott Gray wrote: Should be screenshots not screenshoots. Regards Scott On 17/04/2010, at 7:46 PM, jler...@apache.org wrote: Author: jleroux Date: Sat Apr 17 07:46:27 2010 New Revision: 935141 URL: http://svn.apache.org/viewvc?rev=935141view=rev Log: I forgot to update these 2 pages for screenshots link Modified: ofbiz/site/documentation.html ofbiz/site/download.html Modified: ofbiz/site/documentation.html URL: http://svn.apache.org/viewvc/ofbiz/site/documentation.html?rev=935141r1=935140r2=935141view=diff == --- ofbiz/site/documentation.html (original) +++ ofbiz/site/documentation.html Sat Apr 17 07:46:27 2010 @@ -41,6 +41,7 @@ li id=currenta href=documentation.htmlDocumentation/a/li lia href=download.htmlDownload/a/li lia href=http://cwiki.apache.org/confluence/x/L4B2;Community/a/li +lia href=http://cwiki.apache.org/confluence/x/f4AHAQ;Screenshoots/a/li /ul /div div id=search Modified: ofbiz/site/download.html URL: http://svn.apache.org/viewvc/ofbiz/site/download.html?rev=935141r1=935140r2=935141view=diff == --- ofbiz/site/download.html (original) +++ ofbiz/site/download.html Sat Apr 17 07:46:27 2010 @@ -41,6 +41,7 @@ lia href=documentation.htmlDocumentation/a/li li id=currenta href=download.htmlDownload/a/li lia href=http://cwiki.apache.org/confluence/x/L4B2;Community/a/li +lia href=http://cwiki.apache.org/confluence/x/f4AHAQ;Screenshoots/a/li /ul /div div id=search
[jira] Created: (OFBIZ-3707) Error in polling JobSandbox
Error in polling JobSandbox --- Key: OFBIZ-3707 URL: https://issues.apache.org/jira/browse/OFBIZ-3707 Project: OFBiz Issue Type: Bug Components: specialpurpose/ecommerce Affects Versions: Release Branch 9.04 Environment: Fedora 9 Linux,2GB RAM,Core2Duo Processor, deployed on JBOSS 5.0 Appserver Reporter: Rashmi R Hati Fix For: Release Branch 9.04 Hi, I am using the Ofbiz Release 9.04 stable version. I am getting this error on simultaneously creating New Customers for the ecommerce site - for 20 users == Error in polling JobSandbox: [org.ofbiz.entity.transaction.GenericTransactionException: Not Supported error, could not begin transaction (probably a nesting problem) (BaseTransaction.checkTransactionState - [com.arjuna.ats.internal.jta.transaction.arjunacore.alreadyassociated] [com.arjuna.ats.internal.jta.transaction.arjunacore.alreadyassociated] thread is already associated with a transaction!)]. Rolling back transaction. Exception: org.ofbiz.entity.transaction.GenericTransactionException Message: Not Supported error, could not begin transaction (probably a nesting problem) (BaseTransaction.checkTransactionState - [com.arjuna.ats.internal.jta.transaction.arjunacore.alreadyassociated] [com.arjuna.ats.internal.jta.transaction.arjunacore.alreadyassociated] thread is already associated with a transaction!) cause - Exception: javax.transaction.NotSupportedException Message: BaseTransaction.checkTransactionState - [com.arjuna.ats.internal.jta.transaction.arjunacore.alreadyassociated] [com.arjuna.ats.internal.jta.transaction.arjunacore.alreadyassociated] thread is already associated with a transaction! stack trace --- javax.transaction.NotSupportedException: BaseTransaction.checkTransactionState - [com.arjuna.ats.internal.jta.transaction.arjunacore.alreadyassociated] [com.arjuna.ats.internal.jta.transaction.arjunacore.alreadyassociated] thread is already associated with a transaction! com.arjuna.ats.internal.jta.transaction.arjunacore.BaseTransaction.begin(BaseTransaction.java:80) com.arjuna.ats.jbossatx.BaseTransactionManagerDelegate.begin(BaseTransactionManagerDelegate.java:65) org.jboss.tm.usertx.client.ServerVMClientUserTransaction.begin(ServerVMClientUserTransaction.java:137) org.ofbiz.entity.transaction.TransactionUtil.begin(TransactionUtil.java:125) org.ofbiz.entity.transaction.TransactionUtil.begin(TransactionUtil.java:81) org.ofbiz.service.job.JobManager.poll(JobManager.java:148) org.ofbiz.service.job.JobPoller.run(JobPoller.java:90) java.lang.Thread.run(Thread.java:619) 16:27:18,249 ERROR [TransactionUtil] exception report -- WARNING: In setSetRollbackOnlyCause a stack placeholder was already in place, here is the original rollbackOnly cause: Error in polling JobSandbox: [org.ofbiz.entity.transaction.GenericTransactionException: Not Supported error, could not begin transaction (probably a nesting problem) (BaseTransaction.checkTransactionState - [com.arjuna.ats.internal.jta.transaction.arjunacore.alreadyassociated] [com.arjuna.ats.internal.jta.transaction.arjunacore.alreadyassociated] thread is already associated with a transaction!)]. Rolling back transaction.org.ofbiz.entity.transaction.GenericTransactionException: Not Supported error, could not begin transaction (probably a nesting problem) (BaseTransaction.checkTransactionState - [com.arjuna.ats.internal.jta.transaction.arjunacore.alreadyassociated] [com.arjuna.ats.internal.jta.transaction.arjunacore.alreadyassociated] thread is already associated with a transaction!) Exception: org.ofbiz.entity.transaction.GenericTransactionException Message: Not Supported error, could not begin transaction (probably a nesting problem) (BaseTransaction.checkTransactionState - [com.arjuna.ats.internal.jta.transaction.arjunacore.alreadyassociated] [com.arjuna.ats.internal.jta.transaction.arjunacore.alreadyassociated] thread is already associated with a transaction!) cause - Exception: javax.transaction.NotSupportedException Message: BaseTransaction.checkTransactionState - [com.arjuna.ats.internal.jta.transaction.arjunacore.alreadyassociated] [com.arjuna.ats.internal.jta.transaction.arjunacore.alreadyassociated] thread is already associated with a transaction! stack trace --- javax.transaction.NotSupportedException: BaseTransaction.checkTransactionState -
Re: svn commit: r935141 - in /ofbiz/site: documentation.html download.html
From: Jacopo Cappellato jacopo.cappell...@hotwaxmedia.com On Apr 17, 2010, at 11:18 AM, Jacques Le Roux wrote: From: Jacopo Cappellato jacopo.cappell...@hotwaxmedia.com On Apr 17, 2010, at 10:12 AM, Jacques Le Roux wrote: Oops, I did not see the typo :/. Bruno suggested to put it in the top bar. But I see no problems to have it in the right bar (just under documentation and before the Resources Tools section) I don't see a place for it in content of main page. Do we agree? +1 for moving to right bar now we can always refine this later. Jacopo I was ready to commit, but I wonder if we should keep the link in top bar of other pages (than home page)? Or do you plan to have something in the right bar of these other pages (for now documentation and download), Jacopo? As I said before, I wonder about that... Any opinions? My preference would be to have the same header for all the pages; as I said before we can then rethink the links in the header. Jacopo Done at r... Arg I can't commit, something wrong happens here :( I will revert and redo... Jacques Jacques Jacques From: Jacopo Cappellato jacopo.cappell...@hotwaxmedia.com And also: do we really need them in the top nav bar? I would prefer to see them as a link in the right bar (and maybe also in the content of the main page). There are too many top links right now (and screenshots is not properly rendered) and imo one of our next steps should be to discuss what should stay there (for example I would also remove about and maybe features). Jacopo On Apr 17, 2010, at 9:47 AM, Scott Gray wrote: Should be screenshots not screenshoots. Regards Scott On 17/04/2010, at 7:46 PM, jler...@apache.org wrote: Author: jleroux Date: Sat Apr 17 07:46:27 2010 New Revision: 935141 URL: http://svn.apache.org/viewvc?rev=935141view=rev Log: I forgot to update these 2 pages for screenshots link Modified: ofbiz/site/documentation.html ofbiz/site/download.html Modified: ofbiz/site/documentation.html URL: http://svn.apache.org/viewvc/ofbiz/site/documentation.html?rev=935141r1=935140r2=935141view=diff == --- ofbiz/site/documentation.html (original) +++ ofbiz/site/documentation.html Sat Apr 17 07:46:27 2010 @@ -41,6 +41,7 @@ li id=currenta href=documentation.htmlDocumentation/a/li lia href=download.htmlDownload/a/li lia href=http://cwiki.apache.org/confluence/x/L4B2;Community/a/li +lia href=http://cwiki.apache.org/confluence/x/f4AHAQ;Screenshoots/a/li /ul /div div id=search Modified: ofbiz/site/download.html URL: http://svn.apache.org/viewvc/ofbiz/site/download.html?rev=935141r1=935140r2=935141view=diff == --- ofbiz/site/download.html (original) +++ ofbiz/site/download.html Sat Apr 17 07:46:27 2010 @@ -41,6 +41,7 @@ lia href=documentation.htmlDocumentation/a/li li id=currenta href=download.htmlDownload/a/li lia href=http://cwiki.apache.org/confluence/x/L4B2;Community/a/li +lia href=http://cwiki.apache.org/confluence/x/f4AHAQ;Screenshoots/a/li /ul /div div id=search
Re: Release 4 on the download page
maybe post on user ml to see how many respond. I agree a lot of work if not being used. I guess removing it give the same message as archive. = BJ Freeman http://bjfreeman.elance.com Strategic Power Office with Supplier Automation http://www.businessesnetwork.com/automation/viewforum.php?f=93 Specialtymarket.com http://www.specialtymarket.com/ Systems Integrator-- Glad to Assist Chat Y! messenger: bjfr33man Linkedin http://www.linkedin.com/profile?viewProfile=key=1237480locale=en_UStrk=tab_pro Jacopo Cappellato sent the following on 4/17/2010 12:25 AM: If we want to distribute it thru the ASF mirrors (and have it in the ASF release archive) we will have to officially release it (i.e. prepare the package, sign it, vote on it and publish) as we did a few days ago for the 09.04 release. I don't think it is worth of the effort but I am wide open to suggestions. Jacopo On Apr 17, 2010, at 8:48 AM, BJ Freeman wrote: would 4.0 be an archive or put some other site like 3.0 is = BJ Freeman http://bjfreeman.elance.com Strategic Power Office with Supplier Automation http://www.businessesnetwork.com/automation/viewforum.php?f=93 Specialtymarket.com http://www.specialtymarket.com/ Systems Integrator-- Glad to Assist Chat Y! messenger: bjfr33man Linkedin http://www.linkedin.com/profile?viewProfile=key=1237480locale=en_UStrk=tab_pro Jacopo Cappellato sent the following on 4/16/2010 10:28 PM: On Apr 17, 2010, at 3:00 AM, Adrian Crum wrote: Now that we have an official 9.04 release, and since interest in Release 4.0 has waned, should we remove Release 4.0 from the downloads page? I agree, especially because Release 4.0 is not an official ASF release BTW have a look at the new download page, it is much cleaner now. Also, now that we have an official 9.04 release, do we still need all of those 9.04 snapshots? In my opinion we don't need all those snapshots (there are too many also for the trunk, imo). But at least a couple of snapshots for the 9.04 release branch are useful because the release branch is receiving new bug fix commits (that could induce us to release a bug fix release 9.04.1 in the future). Jacopo -Adrian
[jira] Assigned: (OFBIZ-3700) Convert WorkEffort (and related entities) quantities from Double - BigDecimal
[ https://issues.apache.org/jira/browse/OFBIZ-3700?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Adrian Crum reassigned OFBIZ-3700: -- Assignee: Adrian Crum Convert WorkEffort (and related entities) quantities from Double - BigDecimal -- Key: OFBIZ-3700 URL: https://issues.apache.org/jira/browse/OFBIZ-3700 Project: OFBiz Issue Type: Bug Components: workeffort Affects Versions: SVN trunk Reporter: Bob Morley Assignee: Adrian Crum Priority: Minor Fix For: SVN trunk It appears that this entity was missed from the BigDecimal conversion. Ran into this when ProductionRunServices was attempting to create a WorkEffort (it is passing the quantity to produce as a BigDecimal). A different bug in OFBIZ-3699 was causing an auto-convert of the field from BigDecimal to Double (which was allowing ProductionRuns to be created). At any rate, we should convert this entity and any other quantity related entities in the WorkEffort component. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Excluding test classes from deployed Jars
Right now the test classes are included in each component's jar file. It seems to me it might save on memory or the target server's disk space if the test classes were left out of the component's final jar file. Maybe have a folder structure something like: component src main org ofbiz etc... test org ofbiz etc... The main branch is for the deployment jar and the test branch is only for test classes. The end result would be you could have a separate build for the test classes that wouldn't put them in the final jar. Another advantage is the test classes can be in the same package as the classes they test. (The current setup is a pain in that respect.) What do you think? -Adrian
[jira] Assigned: (OFBIZ-3671) XHTML validation errors (framework/widget) In xml (xhtml) ID must be unique
[ https://issues.apache.org/jira/browse/OFBIZ-3671?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bruno Busco reassigned OFBIZ-3671: -- Assignee: Bruno Busco XHTML validation errors (framework/widget) In xml (xhtml) ID must be unique --- Key: OFBIZ-3671 URL: https://issues.apache.org/jira/browse/OFBIZ-3671 Project: OFBiz Issue Type: Bug Components: framework Affects Versions: SVN trunk Reporter: Blas Rodriguez Somoza Assignee: Bruno Busco Priority: Trivial Fix For: SVN trunk Attachments: OFBIZ-3671_widget_xhtml_id_v3.diff In XML id is a special attribute which must be unique. - ModelFormField.java must have the method getCurrentContainerId which is already on ModelForm - MacroFormRendered and HtmlFormRenderer must be modified to use the getCurrentContainerID instead of getIdName - htmlFormMacroLibrary. span id must be different from the associated hidden field. Also: htmlFormMacroLibrary Line 73: readonly attribute without value. Lines 102.103: better formatted, more readable javascript call. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (OFBIZ-3671) XHTML validation errors (framework/widget) In xml (xhtml) ID must be unique
[ https://issues.apache.org/jira/browse/OFBIZ-3671?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bruno Busco closed OFBIZ-3671. -- Resolution: Fixed Thank you Blas, your slightly changed patch is in trunk at revision: 935197 I only changed some tabs with spaces XHTML validation errors (framework/widget) In xml (xhtml) ID must be unique --- Key: OFBIZ-3671 URL: https://issues.apache.org/jira/browse/OFBIZ-3671 Project: OFBiz Issue Type: Bug Components: framework Affects Versions: SVN trunk Reporter: Blas Rodriguez Somoza Assignee: Bruno Busco Priority: Trivial Fix For: SVN trunk Attachments: OFBIZ-3671_widget_xhtml_id_v3.diff In XML id is a special attribute which must be unique. - ModelFormField.java must have the method getCurrentContainerId which is already on ModelForm - MacroFormRendered and HtmlFormRenderer must be modified to use the getCurrentContainerID instead of getIdName - htmlFormMacroLibrary. span id must be different from the associated hidden field. Also: htmlFormMacroLibrary Line 73: readonly attribute without value. Lines 102.103: better formatted, more readable javascript call. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: Excluding test classes from deployed Jars
Yes, this vould be great ! we've already been speaking on doing this in this thread. But I don't think it's needed to create a main dir, just adding a test dir under src is enough. http://n4.nabble.com/Renaming-of-java-junit-tests-td1755800.html#a1774188 -- View this message in context: http://n4.nabble.com/Excluding-test-classes-from-deployed-Jars-tp2014236p2014256.html Sent from the OFBiz - Dev mailing list archive at Nabble.com.
Re: Release 4 on the download page
I'd say let's do the same with 4.0 release - it then shows that we have more than one release :) Cheers, Ruppert On Apr 17, 2010, at 8:50 AM, BJ Freeman wrote: maybe post on user ml to see how many respond. I agree a lot of work if not being used. I guess removing it give the same message as archive. = BJ Freeman http://bjfreeman.elance.com Strategic Power Office with Supplier Automation http://www.businessesnetwork.com/automation/viewforum.php?f=93 Specialtymarket.com http://www.specialtymarket.com/ Systems Integrator-- Glad to Assist Chat Y! messenger: bjfr33man Linkedin http://www.linkedin.com/profile?viewProfile=key=1237480locale=en_UStrk=tab_pro Jacopo Cappellato sent the following on 4/17/2010 12:25 AM: If we want to distribute it thru the ASF mirrors (and have it in the ASF release archive) we will have to officially release it (i.e. prepare the package, sign it, vote on it and publish) as we did a few days ago for the 09.04 release. I don't think it is worth of the effort but I am wide open to suggestions. Jacopo On Apr 17, 2010, at 8:48 AM, BJ Freeman wrote: would 4.0 be an archive or put some other site like 3.0 is = BJ Freeman http://bjfreeman.elance.com Strategic Power Office with Supplier Automation http://www.businessesnetwork.com/automation/viewforum.php?f=93 Specialtymarket.com http://www.specialtymarket.com/ Systems Integrator-- Glad to Assist Chat Y! messenger: bjfr33man Linkedin http://www.linkedin.com/profile?viewProfile=key=1237480locale=en_UStrk=tab_pro Jacopo Cappellato sent the following on 4/16/2010 10:28 PM: On Apr 17, 2010, at 3:00 AM, Adrian Crum wrote: Now that we have an official 9.04 release, and since interest in Release 4.0 has waned, should we remove Release 4.0 from the downloads page? I agree, especially because Release 4.0 is not an official ASF release BTW have a look at the new download page, it is much cleaner now. Also, now that we have an official 9.04 release, do we still need all of those 9.04 snapshots? In my opinion we don't need all those snapshots (there are too many also for the trunk, imo). But at least a couple of snapshots for the 9.04 release branch are useful because the release branch is receiving new bug fix commits (that could induce us to release a bug fix release 9.04.1 in the future). Jacopo -Adrian
Re: Excluding test classes from deployed Jars
As per that thread, I was planning on doing this in conjunction with renaming some of the tests. Shall I proceed? Bob On 2010-04-17, at 12:48 PM, Adrian Crum adrian.c...@yahoo.com wrote: Thanks for the link. I missed that thread. -Adrian --- On Sat, 4/17/10, Erwan de FERRIERES erwan.de- ferrie...@nereide.fr wrote: From: Erwan de FERRIERES erwan.de-ferrie...@nereide.fr Subject: Re: Excluding test classes from deployed Jars To: dev@ofbiz.apache.org Date: Saturday, April 17, 2010, 9:30 AM Yes, this vould be great ! we've already been speaking on doing this in this thread. But I don't think it's needed to create a main dir, just adding a test dir under src is enough. http://n4.nabble.com/Renaming-of-java-junit-tests-td1755800.html#a1774188 -- View this message in context: http://n4.nabble.com/Excluding-test-classes-from-deployed-Jars-tp2014236p2014256.html Sent from the OFBiz - Dev mailing list archive at Nabble.com.
Re: Release 4 on the download page
If support is important then the Phrase you need to upgrade to current trunk should be evaluated. one of the things I try to keep is what commits will work with what versions. I don't have a complete list, and have non for 4.0. = BJ Freeman http://bjfreeman.elance.com Strategic Power Office with Supplier Automation http://www.businessesnetwork.com/automation/viewforum.php?f=93 Specialtymarket.com http://www.specialtymarket.com/ Systems Integrator-- Glad to Assist Chat Y! messenger: bjfr33man Linkedin http://www.linkedin.com/profile?viewProfile=key=1237480locale=en_UStrk=tab_pro Ean Schuessler sent the following on 4/17/2010 11:25 AM: I hear Jacopo on it not being worth the trouble but I agree with Tim that showing more than one release is important. A related thing that releasing 4.0 signals is that we are concerned about providing long-term support for the product. Support is an important factor for decision makers evaluating OFBiz as a solution for their business. - Tim Ruppert wrote: I'd say let's do the same with 4.0 release - it then shows that we have more than one release :)
Re: Release 4 on the download page
On Apr 17, 2010, at 8:25 PM, Ean Schuessler wrote: I hear Jacopo on it not being worth the trouble but I agree with Tim that showing more than one release is important. If there is enough interest I will do the necessary steps to prepare the release package and start a vote, I am not against this, but I would like to get more positive feedback before I start the process. Even if it is a bit weird to release and older release a few days after a newer has been released; but of course we will not give much visibility to this one, and I understand it is more like a paperwork. A related thing that releasing 4.0 signals is that we are concerned about providing long-term support for the product. Support is an important factor for decision makers evaluating OFBiz as a solution for their business. The only signal we can give is that we do what we can to provide to the community (final users, service providers etc...) the resources (in this case the resource is the official release package available thru mirrors) to facilitate the work of supporting older releases; but the burden to support the releases is up to the community, if there are no contributions then the releases (in term of support, docs etc...) will not be much different from trunk snapshots. It is important that we all understand that there are no (implied) promises for support, backward compatibility etc. when the PMC issues a release. It is up to the community the burden of maintaining it. Kind regards, Jacopo - Tim Ruppert wrote: I'd say let's do the same with 4.0 release - it then shows that we have more than one release :)
Re: svn commit: r935141 - in /ofbiz/site: documentation.html download.html
Scott Gray wrote: Should be screenshots not screenshoots. I can offer some fiber if that helps. Regards Scott On 17/04/2010, at 7:46 PM, jler...@apache.org wrote: Author: jleroux Date: Sat Apr 17 07:46:27 2010 New Revision: 935141 URL: http://svn.apache.org/viewvc?rev=935141view=rev Log: I forgot to update these 2 pages for screenshots link Modified: ofbiz/site/documentation.html ofbiz/site/download.html Modified: ofbiz/site/documentation.html URL: http://svn.apache.org/viewvc/ofbiz/site/documentation.html?rev=935141r1=935140r2=935141view=diff == --- ofbiz/site/documentation.html (original) +++ ofbiz/site/documentation.html Sat Apr 17 07:46:27 2010 @@ -41,6 +41,7 @@ li id=currenta href=documentation.htmlDocumentation/a/li lia href=download.htmlDownload/a/li lia href=http://cwiki.apache.org/confluence/x/L4B2;Community/a/li +lia href=http://cwiki.apache.org/confluence/x/f4AHAQ;Screenshoots/a/li /ul /div div id=search Modified: ofbiz/site/download.html URL: http://svn.apache.org/viewvc/ofbiz/site/download.html?rev=935141r1=935140r2=935141view=diff == --- ofbiz/site/download.html (original) +++ ofbiz/site/download.html Sat Apr 17 07:46:27 2010 @@ -41,6 +41,7 @@ lia href=documentation.htmlDocumentation/a/li li id=currenta href=download.htmlDownload/a/li lia href=http://cwiki.apache.org/confluence/x/L4B2;Community/a/li +lia href=http://cwiki.apache.org/confluence/x/f4AHAQ;Screenshoots/a/li /ul /div div id=search
Re: Excluding test classes from deployed Jars
Adrian Crum wrote: Right now the test classes are included in each component's jar file. It seems to me it might save on memory or the target server's disk space if the test classes were left out of the component's final jar file. Maybe have a folder structure something like: component src main org ofbiz etc... test org ofbiz etc... The main branch is for the deployment jar and the test branch is only for test classes. The end result would be you could have a separate build for the test classes that wouldn't put them in the final jar. Another advantage is the test classes can be in the same package as the classes they test. (The current setup is a pain in that respect.) There is no reason to move the source for the tests. If fact, that is actually a bad thing to do. Just use an appropriate pattern to put them into a separate jar. However, then the startup code needs to handle loading the correct jars. I've thought about this myself.
Re: Excluding test classes from deployed Jars
Adam Heath wrote: Adrian Crum wrote: Right now the test classes are included in each component's jar file. It seems to me it might save on memory or the target server's disk space if the test classes were left out of the component's final jar file. Maybe have a folder structure something like: component src main org ofbiz etc... test org ofbiz etc... The main branch is for the deployment jar and the test branch is only for test classes. The end result would be you could have a separate build for the test classes that wouldn't put them in the final jar. Another advantage is the test classes can be in the same package as the classes they test. (The current setup is a pain in that respect.) There is no reason to move the source for the tests. If fact, that is actually a bad thing to do. Just use an appropriate pattern to put them into a separate jar. However, then the startup code needs to handle loading the correct jars. I've thought about this myself. This is complicated if any classes in foo-test.jar are registered in META-INF/services, while normal classes are also so registered. Also, if a test class is registed as some normal interface, the name of the file in META-INF/services will not match the *.test.* pattern. If we want to keep a single src directory(which is what I prefer), then src/META-INF/services has to go. In its place, jar's nested service element will have to be used.
[jira] Closed: (OFBIZ-3690) XHTML validation errors round 2 (accounting)
[ https://issues.apache.org/jira/browse/OFBIZ-3690?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bruno Busco closed OFBIZ-3690. -- Assignee: Bruno Busco Resolution: Fixed Thank you Blas, your patch is in trunk at revision: 935260 XHTML validation errors round 2 (accounting) Key: OFBIZ-3690 URL: https://issues.apache.org/jira/browse/OFBIZ-3690 Project: OFBiz Issue Type: Bug Components: accounting Affects Versions: SVN trunk Reporter: Blas Rodriguez Somoza Assignee: Bruno Busco Priority: Trivial Fix For: SVN trunk Attachments: OFBIZ-3690_accounting_xhtml_v2.diff XHTML validation errors * Unclosed tags * attributes without values (checked, selected, disabled, etc) * attribute values without * Uppercase tags or attributes. * Unencoded ampersands in urls. Other errors: CostCenters.ftl Lines 37,51: input must be inside td. Lines 45,47: duplicated id, and invalid character | EditCustomTimePeriods.ftl Form must be outside table CommisionReport.ftl Line 77: invalid td outside tr and there is no open table at this point -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: svn commit: r935141 - in /ofbiz/site: documentation.html download.html
From: Jacques Le Roux jacques.le.r...@les7arts.com To: dev@ofbiz.apache.org Sent: Saturday, April 17, 2010 1:06 PM Subject: Re: svn commit: r935141 - in /ofbiz/site: documentation.html download.html From: Jacopo Cappellato jacopo.cappell...@hotwaxmedia.com On Apr 17, 2010, at 11:18 AM, Jacques Le Roux wrote: From: Jacopo Cappellato jacopo.cappell...@hotwaxmedia.com On Apr 17, 2010, at 10:12 AM, Jacques Le Roux wrote: Oops, I did not see the typo :/. Bruno suggested to put it in the top bar. But I see no problems to have it in the right bar (just under documentation and before the Resources Tools section) I don't see a place for it in content of main page. Do we agree? +1 for moving to right bar now we can always refine this later. Jacopo I was ready to commit, but I wonder if we should keep the link in top bar of other pages (than home page)? Or do you plan to have something in the right bar of these other pages (for now documentation and download), Jacopo? As I said before, I wonder about that... Any opinions? My preference would be to have the same header for all the pages; as I said before we can then rethink the links in the header. Jacopo Done at r... Arg I can't commit, something wrong happens here :( I will revert and redo... Done at r935261 Sorry Bruno for confusion around screenshot spelling. Jacues Jacques Jacques Jacques From: Jacopo Cappellato jacopo.cappell...@hotwaxmedia.com And also: do we really need them in the top nav bar? I would prefer to see them as a link in the right bar (and maybe also in the content of the main page). There are too many top links right now (and screenshots is not properly rendered) and imo one of our next steps should be to discuss what should stay there (for example I would also remove about and maybe features). Jacopo On Apr 17, 2010, at 9:47 AM, Scott Gray wrote: Should be screenshots not screenshoots. Regards Scott On 17/04/2010, at 7:46 PM, jler...@apache.org wrote: Author: jleroux Date: Sat Apr 17 07:46:27 2010 New Revision: 935141 URL: http://svn.apache.org/viewvc?rev=935141view=rev Log: I forgot to update these 2 pages for screenshots link Modified: ofbiz/site/documentation.html ofbiz/site/download.html Modified: ofbiz/site/documentation.html URL: http://svn.apache.org/viewvc/ofbiz/site/documentation.html?rev=935141r1=935140r2=935141view=diff == --- ofbiz/site/documentation.html (original) +++ ofbiz/site/documentation.html Sat Apr 17 07:46:27 2010 @@ -41,6 +41,7 @@ li id=currenta href=documentation.htmlDocumentation/a/li lia href=download.htmlDownload/a/li lia href=http://cwiki.apache.org/confluence/x/L4B2;Community/a/li +lia href=http://cwiki.apache.org/confluence/x/f4AHAQ;Screenshoots/a/li /ul /div div id=search Modified: ofbiz/site/download.html URL: http://svn.apache.org/viewvc/ofbiz/site/download.html?rev=935141r1=935140r2=935141view=diff == --- ofbiz/site/download.html (original) +++ ofbiz/site/download.html Sat Apr 17 07:46:27 2010 @@ -41,6 +41,7 @@ lia href=documentation.htmlDocumentation/a/li li id=currenta href=download.htmlDownload/a/li lia href=http://cwiki.apache.org/confluence/x/L4B2;Community/a/li +lia href=http://cwiki.apache.org/confluence/x/f4AHAQ;Screenshoots/a/li /ul /div div id=search
[jira] Closed: (OFBIZ-3689) XHTML validation errors round 2 (commonext)
[ https://issues.apache.org/jira/browse/OFBIZ-3689?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bruno Busco closed OFBIZ-3689. -- Assignee: Bruno Busco Resolution: Fixed Thank you Blas, your patch is in trunk at revision: 935262 XHTML validation errors round 2 (commonext) --- Key: OFBIZ-3689 URL: https://issues.apache.org/jira/browse/OFBIZ-3689 Project: OFBiz Issue Type: Bug Components: commonext/setup Affects Versions: SVN trunk Reporter: Blas Rodriguez Somoza Assignee: Bruno Busco Priority: Trivial Fix For: SVN trunk Attachments: OFBIZ-3689_commonext_xhtml.diff XHTML validation errors * Unclosed tags * attributes without values (checked, selected, disabled, etc) * attribute values without * Uppercase tags or attributes. * Unencoded ampersands in urls. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (OFBIZ-3688) XHTML validation errors round 2 (content)
[ https://issues.apache.org/jira/browse/OFBIZ-3688?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bruno Busco closed OFBIZ-3688. -- Assignee: Bruno Busco Resolution: Fixed Thank you Blas, your patch is in trunk at revision: 935263 XHTML validation errors round 2 (content) - Key: OFBIZ-3688 URL: https://issues.apache.org/jira/browse/OFBIZ-3688 Project: OFBiz Issue Type: Bug Components: content Affects Versions: SVN trunk Reporter: Blas Rodriguez Somoza Assignee: Bruno Busco Priority: Trivial Fix For: SVN trunk Attachments: OFBIZ-3688_content_xhtml.diff XHTML validation errors * Unclosed tags * attributes without values (checked, selected, disabled, etc) * attribute values without * Uppercase tags or attributes. * Unencoded ampersands in urls. Other errors: ContentTreeLookupList.ftl Line 20: tr with attribute colspan -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (OFBIZ-3687) XHTML validation errors round 2 (manufacturing)
[ https://issues.apache.org/jira/browse/OFBIZ-3687?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bruno Busco closed OFBIZ-3687. -- Assignee: Bruno Busco Resolution: Fixed Thank you Blas, your patch is in trunk at revision: 935266 XHTML validation errors round 2 (manufacturing) --- Key: OFBIZ-3687 URL: https://issues.apache.org/jira/browse/OFBIZ-3687 Project: OFBiz Issue Type: Bug Components: manufacturing Affects Versions: SVN trunk Reporter: Blas Rodriguez Somoza Assignee: Bruno Busco Priority: Trivial Fix For: SVN trunk Attachments: OFBIZ-3687_manufacturing_xhtml.diff XHTML validation errors * Unclosed tags * attributes without values (checked, selected, disabled, etc) * attribute values without * Uppercase tags or attributes. * Unencoded ampersands in urls. Other errors: EditProductBom.ftl Line 110: duplicated id productId EditCalendar.ftl Lines 71, 74: unclosed td -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (OFBIZ-3591) application - securityext
[ https://issues.apache.org/jira/browse/OFBIZ-3591?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jacques Le Roux closed OFBIZ-3591. -- Assignee: Jacques Le Roux Resolution: Not A Problem I have only had to remove Debug application - securityext - Key: OFBIZ-3591 URL: https://issues.apache.org/jira/browse/OFBIZ-3591 Project: OFBiz Issue Type: Sub-task Reporter: Bob Morley Assignee: Jacques Le Roux Attachments: OFBIZ-3591_ResolveWarningsSecurityExt.patch -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: Excluding test classes from deployed Jars
Adrian Crum wrote: --- On Sat, 4/17/10, Adam Heath doo...@brainfood.com wrote: Adam Heath wrote: Adrian Crum wrote: Right now the test classes are included in each component's jar file. It seems to me it might save on memory or the target server's disk space if the test classes were left out of the component's final jar file. Maybe have a folder structure something like: component src main org ofbiz etc... test org ofbiz etc... The main branch is for the deployment jar and the test branch is only for test classes. The end result would be you could have a separate build for the test classes that wouldn't put them in the calfinal jar. Another advantage is the test classes can be in the same package as the classes they test. (The current setup is a pain in that respect.) There is no reason to move the source for the tests. If fact, that is actually a bad thing to do. Why? Separate calls to javac, which can make some classes of compile errors hide without explicitly doing a clean. Just use an appropriate pattern to put them into a separate jar. Like have the build target exclude the test classes by using a file name pattern match? However, then the startup code needs to handle loading the correct jars. I've thought about this myself. This is complicated if any classes in foo-test.jar are registered in META-INF/services, while normal classes are also so registered. Can't each src branch have its own META-INF folder? Sure. Also, if a test class is registed as some normal interface, the name of the file in META-INF/services will not match the *.test.* pattern. Huh? Could you gave an example please? org.ofbiz.base.converters.ConverterLoader contains org.ofbiz.base.converters.test.TestCase$ConverterThatDoesSomethingBrokenDuringLoadingSoThatItCanBeTested A filename pattern will not detect the line that resides in the above file. If we want to keep a single src directory(which is what I prefer), then src/META-INF/services has to go. In its place, jar's nested service element will have to be used. I know it works because that's how Commons is set up. I haven't run into any problems so far. I've got it working locally, for base. Will be applying it to the other components that have test classes. Currently, it'll only save about 145k of compressed bytecode data(based on the size of the jars). But that will probably increase as more source-level tests are added. We might always want to consider splitting ofbiz-component.xml, splitting screen/form/script resources, basically move out everything that is only used when tests are being run, and don't make it available at all during normal runs.
[jira] Closed: (OFBIZ-3685) XHTML validation errors round 2 (order)
[ https://issues.apache.org/jira/browse/OFBIZ-3685?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bruno Busco closed OFBIZ-3685. -- Assignee: Bruno Busco Resolution: Fixed Thank you Blas, your slightly changed patch (I only changed some tabs with spaces) is in trunk at revision: 935270 XHTML validation errors round 2 (order) --- Key: OFBIZ-3685 URL: https://issues.apache.org/jira/browse/OFBIZ-3685 Project: OFBiz Issue Type: Bug Components: order Affects Versions: SVN trunk Reporter: Blas Rodriguez Somoza Assignee: Bruno Busco Priority: Trivial Fix For: SVN trunk Attachments: OFBIZ-3685_order_xhtml_v4.diff XHTML validation errors * Unclosed tags * attributes without values (checked, selected, disabled, etc) * attribute values without * Uppercase tags or attributes. * Unencoded ampersands in urls. Other errors: checkinits.ftl Line 104, 171: duplicated id userLoginId appendorderitem.ftl Line 65: invalid a closing editorderitems.ftl Line 214: needed td close; orderagreements.ftl Line 35,55: hidden input must be inside td. Line 37,67: attribute valign not valid for tr orderinfo.ftl Lines 22-88: form must be inside li. Lines 232-248: form must be inside td. orderpaymentinfo.ftl LInes 122,123,124,155: wrong syntax - classlabel should be - class=label ordershippinginfo.ftl Line 62: form must be inside li. Line 296,297: label for attribute does not match input id Lines 308, 310: label for attribute does not match select id Line 318: duplicated unneeded id. Line 319. 321: label for attribute does not match select id Lines 499, 519: form must be inside td Line 527: duplicated span open Lines 521,546: form must be inside td Line 552: duplicated span open quoteInfo.ftl Line 40: invalid /div quoteRoles.ftl Lines 24-44: avoid empty table -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (OFBIZ-3708) Fields should be defined with span not div. (radio, date, lookup)
Fields should be defined with span not div. (radio, date, lookup) - Key: OFBIZ-3708 URL: https://issues.apache.org/jira/browse/OFBIZ-3708 Project: OFBiz Issue Type: Bug Components: framework Affects Versions: SVN trunk Reporter: Blas Rodriguez Somoza Priority: Minor Fix For: SVN trunk Attachments: CAL_after_bizznesstime.jpg, CAL_before_bizznesstime.jpg, CAL_before_bluelight.jpg Field markup should be a valid inline element. Defining fields with div (block) instead of span (inline) creates several problems: - Missalignments in screen. (See LOOKUP_CAL screenshots) - Implies a end-of-line after the div. (See CAL screenshots) - If used inside inline elements which should be OK, becames XHTML validation errors. (Manufacturing - MRP - MRP log) Because this is a markup problem, it spans to all the themes. This patch contains 2 files in the framework/widget area and 5 in the themes area. Because the source of the problem is in the framework/widget area, I opt to assign the bug to the framework area. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (OFBIZ-3708) Fields should be defined with span not div. (radio, date, lookup)
[ https://issues.apache.org/jira/browse/OFBIZ-3708?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Blas Rodriguez Somoza updated OFBIZ-3708: - Attachment: CAL_before_bizznesstime.jpg CAL_after_bizznesstime.jpg CAL_before_bluelight.jpg Fields should be defined with span not div. (radio, date, lookup) - Key: OFBIZ-3708 URL: https://issues.apache.org/jira/browse/OFBIZ-3708 Project: OFBiz Issue Type: Bug Components: framework Affects Versions: SVN trunk Reporter: Blas Rodriguez Somoza Priority: Minor Fix For: SVN trunk Attachments: CAL_after_bizznesstime.jpg, CAL_before_bizznesstime.jpg, CAL_before_bluelight.jpg Field markup should be a valid inline element. Defining fields with div (block) instead of span (inline) creates several problems: - Missalignments in screen. (See LOOKUP_CAL screenshots) - Implies a end-of-line after the div. (See CAL screenshots) - If used inside inline elements which should be OK, becames XHTML validation errors. (Manufacturing - MRP - MRP log) Because this is a markup problem, it spans to all the themes. This patch contains 2 files in the framework/widget area and 5 in the themes area. Because the source of the problem is in the framework/widget area, I opt to assign the bug to the framework area. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (OFBIZ-3708) Fields should be defined with span not div. (radio, date, lookup)
[ https://issues.apache.org/jira/browse/OFBIZ-3708?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Blas Rodriguez Somoza updated OFBIZ-3708: - Attachment: CAL_after_bluelight.jpg CAL_before_droppingcrumbs.jpg CAL_after_droppingcrumbs.jpg Fields should be defined with span not div. (radio, date, lookup) - Key: OFBIZ-3708 URL: https://issues.apache.org/jira/browse/OFBIZ-3708 Project: OFBiz Issue Type: Bug Components: framework Affects Versions: SVN trunk Reporter: Blas Rodriguez Somoza Priority: Minor Fix For: SVN trunk Attachments: CAL_after_bizznesstime.jpg, CAL_after_bluelight.jpg, CAL_after_droppingcrumbs.jpg, CAL_before_bizznesstime.jpg, CAL_before_bluelight.jpg, CAL_before_droppingcrumbs.jpg Field markup should be a valid inline element. Defining fields with div (block) instead of span (inline) creates several problems: - Missalignments in screen. (See LOOKUP_CAL screenshots) - Implies a end-of-line after the div. (See CAL screenshots) - If used inside inline elements which should be OK, becames XHTML validation errors. (Manufacturing - MRP - MRP log) Because this is a markup problem, it spans to all the themes. This patch contains 2 files in the framework/widget area and 5 in the themes area. Because the source of the problem is in the framework/widget area, I opt to assign the bug to the framework area. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (OFBIZ-3708) Fields should be defined with span not div. (radio, date, lookup)
[ https://issues.apache.org/jira/browse/OFBIZ-3708?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Blas Rodriguez Somoza updated OFBIZ-3708: - Attachment: CAL_before_flatgrey.jpg CAL_after_flatgrey.jpg CAL_before_tomahawk.jpg Fields should be defined with span not div. (radio, date, lookup) - Key: OFBIZ-3708 URL: https://issues.apache.org/jira/browse/OFBIZ-3708 Project: OFBiz Issue Type: Bug Components: framework Affects Versions: SVN trunk Reporter: Blas Rodriguez Somoza Priority: Minor Fix For: SVN trunk Attachments: CAL_after_bizznesstime.jpg, CAL_after_bluelight.jpg, CAL_after_droppingcrumbs.jpg, CAL_after_flatgrey.jpg, CAL_after_tomahawk.jpg, CAL_before_bizznesstime.jpg, CAL_before_bluelight.jpg, CAL_before_droppingcrumbs.jpg, CAL_before_flatgrey.jpg, CAL_before_tomahawk.jpg, LOOKUP_CAL_after_bizznesstime.jpg, LOOKUP_CAL_before_bizznesstime.jpg Field markup should be a valid inline element. Defining fields with div (block) instead of span (inline) creates several problems: - Missalignments in screen. (See LOOKUP_CAL screenshots) - Implies a end-of-line after the div. (See CAL screenshots) - If used inside inline elements which should be OK, becames XHTML validation errors. (Manufacturing - MRP - MRP log) Because this is a markup problem, it spans to all the themes. This patch contains 2 files in the framework/widget area and 5 in the themes area. Because the source of the problem is in the framework/widget area, I opt to assign the bug to the framework area. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (OFBIZ-3708) Fields should be defined with span not div. (radio, date, lookup)
[ https://issues.apache.org/jira/browse/OFBIZ-3708?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12858243#action_12858243 ] Adam Heath commented on OFBIZ-3708: --- div and span are the same, just with different css. display: inline solves most differents, maybe combined with a clear: both. So no, do not change the field definitions to span, just because you can't align the divs correctly. Fields should be defined with span not div. (radio, date, lookup) - Key: OFBIZ-3708 URL: https://issues.apache.org/jira/browse/OFBIZ-3708 Project: OFBiz Issue Type: Bug Components: framework Affects Versions: SVN trunk Reporter: Blas Rodriguez Somoza Priority: Minor Fix For: SVN trunk Attachments: CAL_after_bizznesstime.jpg, CAL_after_bluelight.jpg, CAL_after_droppingcrumbs.jpg, CAL_after_flatgrey.jpg, CAL_after_tomahawk.jpg, CAL_before_bizznesstime.jpg, CAL_before_bluelight.jpg, CAL_before_droppingcrumbs.jpg, CAL_before_flatgrey.jpg, CAL_before_tomahawk.jpg, LOOKUP_CAL_after_bizznesstime.jpg, LOOKUP_CAL_before_bizznesstime.jpg Field markup should be a valid inline element. Defining fields with div (block) instead of span (inline) creates several problems: - Missalignments in screen. (See LOOKUP_CAL screenshots) - Implies a end-of-line after the div. (See CAL screenshots) - If used inside inline elements which should be OK, becames XHTML validation errors. (Manufacturing - MRP - MRP log) Because this is a markup problem, it spans to all the themes. This patch contains 2 files in the framework/widget area and 5 in the themes area. Because the source of the problem is in the framework/widget area, I opt to assign the bug to the framework area. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (OFBIZ-3708) Fields should be defined with span not div. (radio, date, lookup)
[ https://issues.apache.org/jira/browse/OFBIZ-3708?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Blas Rodriguez Somoza updated OFBIZ-3708: - Attachment: CAL_after_tomahawk.jpg LOOKUP_CAL_before_bizznesstime.jpg LOOKUP_CAL_after_bizznesstime.jpg Fields should be defined with span not div. (radio, date, lookup) - Key: OFBIZ-3708 URL: https://issues.apache.org/jira/browse/OFBIZ-3708 Project: OFBiz Issue Type: Bug Components: framework Affects Versions: SVN trunk Reporter: Blas Rodriguez Somoza Priority: Minor Fix For: SVN trunk Attachments: CAL_after_bizznesstime.jpg, CAL_after_bluelight.jpg, CAL_after_droppingcrumbs.jpg, CAL_after_flatgrey.jpg, CAL_after_tomahawk.jpg, CAL_before_bizznesstime.jpg, CAL_before_bluelight.jpg, CAL_before_droppingcrumbs.jpg, CAL_before_flatgrey.jpg, CAL_before_tomahawk.jpg, LOOKUP_CAL_after_bizznesstime.jpg, LOOKUP_CAL_before_bizznesstime.jpg Field markup should be a valid inline element. Defining fields with div (block) instead of span (inline) creates several problems: - Missalignments in screen. (See LOOKUP_CAL screenshots) - Implies a end-of-line after the div. (See CAL screenshots) - If used inside inline elements which should be OK, becames XHTML validation errors. (Manufacturing - MRP - MRP log) Because this is a markup problem, it spans to all the themes. This patch contains 2 files in the framework/widget area and 5 in the themes area. Because the source of the problem is in the framework/widget area, I opt to assign the bug to the framework area. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (OFBIZ-3708) Fields should be defined with span not div. (radio, date, lookup)
[ https://issues.apache.org/jira/browse/OFBIZ-3708?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Blas Rodriguez Somoza updated OFBIZ-3708: - Attachment: LOOKUP_CAL_after_droppingcrumbs.jpg LOOKUP_CAL_before_flatgrey.jpg LOOKUP_CAL_after_flatgrey.jpg Fields should be defined with span not div. (radio, date, lookup) - Key: OFBIZ-3708 URL: https://issues.apache.org/jira/browse/OFBIZ-3708 Project: OFBiz Issue Type: Bug Components: framework Affects Versions: SVN trunk Reporter: Blas Rodriguez Somoza Priority: Minor Fix For: SVN trunk Attachments: CAL_after_bizznesstime.jpg, CAL_after_bluelight.jpg, CAL_after_droppingcrumbs.jpg, CAL_after_flatgrey.jpg, CAL_after_tomahawk.jpg, CAL_before_bizznesstime.jpg, CAL_before_bluelight.jpg, CAL_before_droppingcrumbs.jpg, CAL_before_flatgrey.jpg, CAL_before_tomahawk.jpg, LOOKUP_CAL_after_bizznesstime.jpg, LOOKUP_CAL_after_bluelight.jpg, LOOKUP_CAL_after_droppingcrumbs.jpg, LOOKUP_CAL_after_flatgrey.jpg, LOOKUP_CAL_before_bizznesstime.jpg, LOOKUP_CAL_before_bluelight.jpg, LOOKUP_CAL_before_droppingcrumbs.jpg, LOOKUP_CAL_before_flatgrey.jpg Field markup should be a valid inline element. Defining fields with div (block) instead of span (inline) creates several problems: - Missalignments in screen. (See LOOKUP_CAL screenshots) - Implies a end-of-line after the div. (See CAL screenshots) - If used inside inline elements which should be OK, becames XHTML validation errors. (Manufacturing - MRP - MRP log) Because this is a markup problem, it spans to all the themes. This patch contains 2 files in the framework/widget area and 5 in the themes area. Because the source of the problem is in the framework/widget area, I opt to assign the bug to the framework area. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (OFBIZ-3708) Fields should be defined with span not div. (radio, date, lookup)
[ https://issues.apache.org/jira/browse/OFBIZ-3708?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Blas Rodriguez Somoza updated OFBIZ-3708: - Attachment: LOOKUP_CAL_before_bluelight.jpg LOOKUP_CAL_after_bluelight.jpg LOOKUP_CAL_before_droppingcrumbs.jpg Fields should be defined with span not div. (radio, date, lookup) - Key: OFBIZ-3708 URL: https://issues.apache.org/jira/browse/OFBIZ-3708 Project: OFBiz Issue Type: Bug Components: framework Affects Versions: SVN trunk Reporter: Blas Rodriguez Somoza Priority: Minor Fix For: SVN trunk Attachments: CAL_after_bizznesstime.jpg, CAL_after_bluelight.jpg, CAL_after_droppingcrumbs.jpg, CAL_after_flatgrey.jpg, CAL_after_tomahawk.jpg, CAL_before_bizznesstime.jpg, CAL_before_bluelight.jpg, CAL_before_droppingcrumbs.jpg, CAL_before_flatgrey.jpg, CAL_before_tomahawk.jpg, LOOKUP_CAL_after_bizznesstime.jpg, LOOKUP_CAL_after_bluelight.jpg, LOOKUP_CAL_after_droppingcrumbs.jpg, LOOKUP_CAL_after_flatgrey.jpg, LOOKUP_CAL_before_bizznesstime.jpg, LOOKUP_CAL_before_bluelight.jpg, LOOKUP_CAL_before_droppingcrumbs.jpg, LOOKUP_CAL_before_flatgrey.jpg Field markup should be a valid inline element. Defining fields with div (block) instead of span (inline) creates several problems: - Missalignments in screen. (See LOOKUP_CAL screenshots) - Implies a end-of-line after the div. (See CAL screenshots) - If used inside inline elements which should be OK, becames XHTML validation errors. (Manufacturing - MRP - MRP log) Because this is a markup problem, it spans to all the themes. This patch contains 2 files in the framework/widget area and 5 in the themes area. Because the source of the problem is in the framework/widget area, I opt to assign the bug to the framework area. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: svn commit: r935278 - in /ofbiz/trunk/applications/accounting/webapp/accounting/WEB-INF/actions: invoice/ order/ payment/ reports/
lekt...@apache.org wrote:
Author: lektran
Date: Sun Apr 18 00:16:52 2010
New Revision: 935278
URL: http://svn.apache.org/viewvc?rev=935278view=rev
Log:
A few examples of using groovy's first() list method instead of
EntityUtil.getFirst(List)
Modified:
ofbiz/trunk/applications/accounting/webapp/accounting/WEB-INF/actions/invoice/EditInvoice.groovy
ofbiz/trunk/applications/accounting/webapp/accounting/WEB-INF/actions/invoice/OrderListInvoiceItem.groovy
ofbiz/trunk/applications/accounting/webapp/accounting/WEB-INF/actions/order/BillingAccountOrders.groovy
ofbiz/trunk/applications/accounting/webapp/accounting/WEB-INF/actions/payment/BillingAccounts.groovy
ofbiz/trunk/applications/accounting/webapp/accounting/WEB-INF/actions/reports/GlAccountTrialBalance.groovy
ofbiz/trunk/applications/accounting/webapp/accounting/WEB-INF/actions/reports/TransactionTotals.groovy
Modified:
ofbiz/trunk/applications/accounting/webapp/accounting/WEB-INF/actions/invoice/EditInvoice.groovy
URL:
http://svn.apache.org/viewvc/ofbiz/trunk/applications/accounting/webapp/accounting/WEB-INF/actions/invoice/EditInvoice.groovy?rev=935278r1=935277r2=935278view=diff
==
---
ofbiz/trunk/applications/accounting/webapp/accounting/WEB-INF/actions/invoice/EditInvoice.groovy
(original)
+++
ofbiz/trunk/applications/accounting/webapp/accounting/WEB-INF/actions/invoice/EditInvoice.groovy
Sun Apr 18 00:16:52 2010
@@ -77,7 +77,8 @@ if (invoice) {
// also create a map with tax grand total amount by VAT tax: it is
also required in invoices by UE
taxRate = invoiceItem.getRelatedOne(TaxAuthorityRateProduct);
if (taxRate VAT_TAX.equals(taxRate.taxAuthorityRateTypeId)) {
-taxInfo =
EntityUtil.getFirst(EntityUtil.filterByDate(delegator.findByAnd(PartyTaxAuthInfo,
UtilMisc.toMap(partyId, billingParty.partyId, taxAuthGeoId,
taxRate.taxAuthGeoId, taxAuthPartyId, taxRate.taxAuthPartyId)),
invoice.invoiceDate));
+taxInfos =
EntityUtil.filterByDate(delegator.findByAnd(PartyTaxAuthInfo, [partyId :
billingParty.partyId, taxAuthGeoId : taxRate.taxAuthGeoId, taxAuthPartyId :
taxRate.taxAuthPartyId]), invoice.invoiceDate);
+taxInfo = taxInfos.first();
if (taxInfo) {
context.billingPartyTaxId = taxInfo.partyTaxId;
}
Why the split into multiple lines? None of the other changes do this.
Modified:
ofbiz/trunk/applications/accounting/webapp/accounting/WEB-INF/actions/invoice/OrderListInvoiceItem.groovy
URL:
http://svn.apache.org/viewvc/ofbiz/trunk/applications/accounting/webapp/accounting/WEB-INF/actions/invoice/OrderListInvoiceItem.groovy?rev=935278r1=935277r2=935278view=diff
==
---
ofbiz/trunk/applications/accounting/webapp/accounting/WEB-INF/actions/invoice/OrderListInvoiceItem.groovy
(original)
+++
ofbiz/trunk/applications/accounting/webapp/accounting/WEB-INF/actions/invoice/OrderListInvoiceItem.groovy
Sun Apr 18 00:16:52 2010
@@ -32,7 +32,7 @@ if (invoiceItemList) {
invoiceItemList.each { invoiceItem -
invoiceItemSeqId = invoiceItem.invoiceItemSeqId;
invoiceId = invoiceItem.invoiceId;
-orderItemBilling =
EntityUtil.getFirst(delegator.findByAnd(OrderItemBilling, [invoiceId :
invoiceId, invoiceItemSeqId : invoiceItemSeqId]));
+orderItemBilling = delegator.findByAnd(OrderItemBilling,
[invoiceId : invoiceId, invoiceItemSeqId : invoiceItemSeqId]).first();
Map invoiceItemMap = FastMap.newInstance();
invoiceItemMap.putAll((Map) invoiceItem);
if (orderItemBilling) {
Modified:
ofbiz/trunk/applications/accounting/webapp/accounting/WEB-INF/actions/order/BillingAccountOrders.groovy
URL:
http://svn.apache.org/viewvc/ofbiz/trunk/applications/accounting/webapp/accounting/WEB-INF/actions/order/BillingAccountOrders.groovy?rev=935278r1=935277r2=935278view=diff
==
---
ofbiz/trunk/applications/accounting/webapp/accounting/WEB-INF/actions/order/BillingAccountOrders.groovy
(original)
+++
ofbiz/trunk/applications/accounting/webapp/accounting/WEB-INF/actions/order/BillingAccountOrders.groovy
Sun Apr 18 00:16:52 2010
@@ -27,7 +27,7 @@ if (billingAccountId) {
if (orderList) {
orderList.each { orderHeader -
orderId = orderHeader.orderId;
-orderBillingAcc =
EntityUtil.getFirst(delegator.findByAnd(OrderHeaderAndPaymentPref, [orderId
: orderId]));
+orderBillingAcc =
delegator.findByAnd(OrderHeaderAndPaymentPref, [orderId : orderId]).first();
orderBillingAccMap = FastMap.newInstance();
if (orderBillingAcc.paymentMethodTypeId.equals(EXT_BILLACT)
[jira] Updated: (OFBIZ-3708) Fields should be defined with span not div. (radio, date, lookup)
[ https://issues.apache.org/jira/browse/OFBIZ-3708?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Blas Rodriguez Somoza updated OFBIZ-3708: - Attachment: LOOKUP_CAL_before_tomahawk.jpg LOOKUP_CAL_after_tomahawk.jpg Fields should be defined with span not div. (radio, date, lookup) - Key: OFBIZ-3708 URL: https://issues.apache.org/jira/browse/OFBIZ-3708 Project: OFBiz Issue Type: Bug Components: framework Affects Versions: SVN trunk Reporter: Blas Rodriguez Somoza Priority: Minor Fix For: SVN trunk Attachments: CAL_after_bizznesstime.jpg, CAL_after_bluelight.jpg, CAL_after_droppingcrumbs.jpg, CAL_after_flatgrey.jpg, CAL_after_tomahawk.jpg, CAL_before_bizznesstime.jpg, CAL_before_bluelight.jpg, CAL_before_droppingcrumbs.jpg, CAL_before_flatgrey.jpg, CAL_before_tomahawk.jpg, LOOKUP_CAL_after_bizznesstime.jpg, LOOKUP_CAL_after_bluelight.jpg, LOOKUP_CAL_after_droppingcrumbs.jpg, LOOKUP_CAL_after_flatgrey.jpg, LOOKUP_CAL_after_tomahawk.jpg, LOOKUP_CAL_before_bizznesstime.jpg, LOOKUP_CAL_before_bluelight.jpg, LOOKUP_CAL_before_droppingcrumbs.jpg, LOOKUP_CAL_before_flatgrey.jpg, LOOKUP_CAL_before_tomahawk.jpg Field markup should be a valid inline element. Defining fields with div (block) instead of span (inline) creates several problems: - Missalignments in screen. (See LOOKUP_CAL screenshots) - Implies a end-of-line after the div. (See CAL screenshots) - If used inside inline elements which should be OK, becames XHTML validation errors. (Manufacturing - MRP - MRP log) Because this is a markup problem, it spans to all the themes. This patch contains 2 files in the framework/widget area and 5 in the themes area. Because the source of the problem is in the framework/widget area, I opt to assign the bug to the framework area. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (OFBIZ-3708) Fields should be defined with span not div. (radio, date, lookup)
[ https://issues.apache.org/jira/browse/OFBIZ-3708?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Blas Rodriguez Somoza updated OFBIZ-3708: - Attachment: (was: CAL_after_bizznesstime.jpg) Fields should be defined with span not div. (radio, date, lookup) - Key: OFBIZ-3708 URL: https://issues.apache.org/jira/browse/OFBIZ-3708 Project: OFBiz Issue Type: Bug Components: framework Affects Versions: SVN trunk Reporter: Blas Rodriguez Somoza Priority: Minor Fix For: SVN trunk Attachments: CAL_after_flatgrey.jpg, CAL_after_tomahawk.jpg, CAL_before_bizznesstime.jpg, CAL_before_bluelight.jpg, CAL_before_droppingcrumbs.jpg, CAL_before_flatgrey.jpg, CAL_before_tomahawk.jpg, CAL_bizznesstime_after.jpg, CAL_bizznesstime_before.jpg, CAL_bluelight_after.jpg, LOOKUP_CAL_after_bizznesstime.jpg, LOOKUP_CAL_after_bluelight.jpg, LOOKUP_CAL_after_droppingcrumbs.jpg, LOOKUP_CAL_after_flatgrey.jpg, LOOKUP_CAL_after_tomahawk.jpg, LOOKUP_CAL_before_bizznesstime.jpg, LOOKUP_CAL_before_bluelight.jpg, LOOKUP_CAL_before_droppingcrumbs.jpg, LOOKUP_CAL_before_flatgrey.jpg, LOOKUP_CAL_before_tomahawk.jpg Field markup should be a valid inline element. Defining fields with div (block) instead of span (inline) creates several problems: - Missalignments in screen. (See LOOKUP_CAL screenshots) - Implies a end-of-line after the div. (See CAL screenshots) - If used inside inline elements which should be OK, becames XHTML validation errors. (Manufacturing - MRP - MRP log) Because this is a markup problem, it spans to all the themes. This patch contains 2 files in the framework/widget area and 5 in the themes area. Because the source of the problem is in the framework/widget area, I opt to assign the bug to the framework area. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (OFBIZ-3708) Fields should be defined with span not div. (radio, date, lookup)
[ https://issues.apache.org/jira/browse/OFBIZ-3708?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Blas Rodriguez Somoza updated OFBIZ-3708: - Attachment: (was: CAL_after_bluelight.jpg) Fields should be defined with span not div. (radio, date, lookup) - Key: OFBIZ-3708 URL: https://issues.apache.org/jira/browse/OFBIZ-3708 Project: OFBiz Issue Type: Bug Components: framework Affects Versions: SVN trunk Reporter: Blas Rodriguez Somoza Priority: Minor Fix For: SVN trunk Attachments: CAL_after_flatgrey.jpg, CAL_after_tomahawk.jpg, CAL_before_bizznesstime.jpg, CAL_before_bluelight.jpg, CAL_before_droppingcrumbs.jpg, CAL_before_flatgrey.jpg, CAL_before_tomahawk.jpg, CAL_bizznesstime_after.jpg, CAL_bizznesstime_before.jpg, CAL_bluelight_after.jpg, LOOKUP_CAL_after_bizznesstime.jpg, LOOKUP_CAL_after_bluelight.jpg, LOOKUP_CAL_after_droppingcrumbs.jpg, LOOKUP_CAL_after_flatgrey.jpg, LOOKUP_CAL_after_tomahawk.jpg, LOOKUP_CAL_before_bizznesstime.jpg, LOOKUP_CAL_before_bluelight.jpg, LOOKUP_CAL_before_droppingcrumbs.jpg, LOOKUP_CAL_before_flatgrey.jpg, LOOKUP_CAL_before_tomahawk.jpg Field markup should be a valid inline element. Defining fields with div (block) instead of span (inline) creates several problems: - Missalignments in screen. (See LOOKUP_CAL screenshots) - Implies a end-of-line after the div. (See CAL screenshots) - If used inside inline elements which should be OK, becames XHTML validation errors. (Manufacturing - MRP - MRP log) Because this is a markup problem, it spans to all the themes. This patch contains 2 files in the framework/widget area and 5 in the themes area. Because the source of the problem is in the framework/widget area, I opt to assign the bug to the framework area. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (OFBIZ-3708) Fields should be defined with span not div. (radio, date, lookup)
[ https://issues.apache.org/jira/browse/OFBIZ-3708?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Blas Rodriguez Somoza updated OFBIZ-3708: - Attachment: CAL_bizznesstime_after.jpg CAL_bizznesstime_before.jpg CAL_bluelight_after.jpg Renaming attached files to ease viewing Fields should be defined with span not div. (radio, date, lookup) - Key: OFBIZ-3708 URL: https://issues.apache.org/jira/browse/OFBIZ-3708 Project: OFBiz Issue Type: Bug Components: framework Affects Versions: SVN trunk Reporter: Blas Rodriguez Somoza Priority: Minor Fix For: SVN trunk Attachments: CAL_after_flatgrey.jpg, CAL_after_tomahawk.jpg, CAL_before_bizznesstime.jpg, CAL_before_bluelight.jpg, CAL_before_droppingcrumbs.jpg, CAL_before_flatgrey.jpg, CAL_before_tomahawk.jpg, CAL_bizznesstime_after.jpg, CAL_bizznesstime_before.jpg, CAL_bluelight_after.jpg, LOOKUP_CAL_after_bizznesstime.jpg, LOOKUP_CAL_after_bluelight.jpg, LOOKUP_CAL_after_droppingcrumbs.jpg, LOOKUP_CAL_after_flatgrey.jpg, LOOKUP_CAL_after_tomahawk.jpg, LOOKUP_CAL_before_bizznesstime.jpg, LOOKUP_CAL_before_bluelight.jpg, LOOKUP_CAL_before_droppingcrumbs.jpg, LOOKUP_CAL_before_flatgrey.jpg, LOOKUP_CAL_before_tomahawk.jpg Field markup should be a valid inline element. Defining fields with div (block) instead of span (inline) creates several problems: - Missalignments in screen. (See LOOKUP_CAL screenshots) - Implies a end-of-line after the div. (See CAL screenshots) - If used inside inline elements which should be OK, becames XHTML validation errors. (Manufacturing - MRP - MRP log) Because this is a markup problem, it spans to all the themes. This patch contains 2 files in the framework/widget area and 5 in the themes area. Because the source of the problem is in the framework/widget area, I opt to assign the bug to the framework area. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (OFBIZ-3708) Fields should be defined with span not div. (radio, date, lookup)
[ https://issues.apache.org/jira/browse/OFBIZ-3708?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Blas Rodriguez Somoza updated OFBIZ-3708: - Attachment: (was: CAL_after_droppingcrumbs.jpg) Fields should be defined with span not div. (radio, date, lookup) - Key: OFBIZ-3708 URL: https://issues.apache.org/jira/browse/OFBIZ-3708 Project: OFBiz Issue Type: Bug Components: framework Affects Versions: SVN trunk Reporter: Blas Rodriguez Somoza Priority: Minor Fix For: SVN trunk Attachments: CAL_after_flatgrey.jpg, CAL_after_tomahawk.jpg, CAL_before_bizznesstime.jpg, CAL_before_bluelight.jpg, CAL_before_droppingcrumbs.jpg, CAL_before_flatgrey.jpg, CAL_before_tomahawk.jpg, CAL_bizznesstime_after.jpg, CAL_bizznesstime_before.jpg, CAL_bluelight_after.jpg, LOOKUP_CAL_after_bizznesstime.jpg, LOOKUP_CAL_after_bluelight.jpg, LOOKUP_CAL_after_droppingcrumbs.jpg, LOOKUP_CAL_after_flatgrey.jpg, LOOKUP_CAL_after_tomahawk.jpg, LOOKUP_CAL_before_bizznesstime.jpg, LOOKUP_CAL_before_bluelight.jpg, LOOKUP_CAL_before_droppingcrumbs.jpg, LOOKUP_CAL_before_flatgrey.jpg, LOOKUP_CAL_before_tomahawk.jpg Field markup should be a valid inline element. Defining fields with div (block) instead of span (inline) creates several problems: - Missalignments in screen. (See LOOKUP_CAL screenshots) - Implies a end-of-line after the div. (See CAL screenshots) - If used inside inline elements which should be OK, becames XHTML validation errors. (Manufacturing - MRP - MRP log) Because this is a markup problem, it spans to all the themes. This patch contains 2 files in the framework/widget area and 5 in the themes area. Because the source of the problem is in the framework/widget area, I opt to assign the bug to the framework area. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (OFBIZ-3708) Fields should be defined with span not div. (radio, date, lookup)
[ https://issues.apache.org/jira/browse/OFBIZ-3708?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Blas Rodriguez Somoza updated OFBIZ-3708: - Attachment: (was: CAL_before_bluelight.jpg) Fields should be defined with span not div. (radio, date, lookup) - Key: OFBIZ-3708 URL: https://issues.apache.org/jira/browse/OFBIZ-3708 Project: OFBiz Issue Type: Bug Components: framework Affects Versions: SVN trunk Reporter: Blas Rodriguez Somoza Priority: Minor Fix For: SVN trunk Attachments: CAL_bizznesstime_after.jpg, CAL_bizznesstime_before.jpg, CAL_bluelight_after.jpg Field markup should be a valid inline element. Defining fields with div (block) instead of span (inline) creates several problems: - Missalignments in screen. (See LOOKUP_CAL screenshots) - Implies a end-of-line after the div. (See CAL screenshots) - If used inside inline elements which should be OK, becames XHTML validation errors. (Manufacturing - MRP - MRP log) Because this is a markup problem, it spans to all the themes. This patch contains 2 files in the framework/widget area and 5 in the themes area. Because the source of the problem is in the framework/widget area, I opt to assign the bug to the framework area. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (OFBIZ-3708) Fields should be defined with span not div. (radio, date, lookup)
[ https://issues.apache.org/jira/browse/OFBIZ-3708?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Blas Rodriguez Somoza updated OFBIZ-3708: - Attachment: (was: CAL_before_flatgrey.jpg) Fields should be defined with span not div. (radio, date, lookup) - Key: OFBIZ-3708 URL: https://issues.apache.org/jira/browse/OFBIZ-3708 Project: OFBiz Issue Type: Bug Components: framework Affects Versions: SVN trunk Reporter: Blas Rodriguez Somoza Priority: Minor Fix For: SVN trunk Attachments: CAL_bizznesstime_after.jpg, CAL_bizznesstime_before.jpg, CAL_bluelight_after.jpg Field markup should be a valid inline element. Defining fields with div (block) instead of span (inline) creates several problems: - Missalignments in screen. (See LOOKUP_CAL screenshots) - Implies a end-of-line after the div. (See CAL screenshots) - If used inside inline elements which should be OK, becames XHTML validation errors. (Manufacturing - MRP - MRP log) Because this is a markup problem, it spans to all the themes. This patch contains 2 files in the framework/widget area and 5 in the themes area. Because the source of the problem is in the framework/widget area, I opt to assign the bug to the framework area. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (OFBIZ-3708) Fields should be defined with span not div. (radio, date, lookup)
[ https://issues.apache.org/jira/browse/OFBIZ-3708?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Blas Rodriguez Somoza updated OFBIZ-3708: - Attachment: (was: LOOKUP_CAL_after_bluelight.jpg) Fields should be defined with span not div. (radio, date, lookup) - Key: OFBIZ-3708 URL: https://issues.apache.org/jira/browse/OFBIZ-3708 Project: OFBiz Issue Type: Bug Components: framework Affects Versions: SVN trunk Reporter: Blas Rodriguez Somoza Priority: Minor Fix For: SVN trunk Attachments: CAL_bizznesstime_after.jpg, CAL_bizznesstime_before.jpg, CAL_bluelight_after.jpg Field markup should be a valid inline element. Defining fields with div (block) instead of span (inline) creates several problems: - Missalignments in screen. (See LOOKUP_CAL screenshots) - Implies a end-of-line after the div. (See CAL screenshots) - If used inside inline elements which should be OK, becames XHTML validation errors. (Manufacturing - MRP - MRP log) Because this is a markup problem, it spans to all the themes. This patch contains 2 files in the framework/widget area and 5 in the themes area. Because the source of the problem is in the framework/widget area, I opt to assign the bug to the framework area. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (OFBIZ-3708) Fields should be defined with span not div. (radio, date, lookup)
[ https://issues.apache.org/jira/browse/OFBIZ-3708?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Blas Rodriguez Somoza updated OFBIZ-3708: - Attachment: (was: LOOKUP_CAL_after_flatgrey.jpg) Fields should be defined with span not div. (radio, date, lookup) - Key: OFBIZ-3708 URL: https://issues.apache.org/jira/browse/OFBIZ-3708 Project: OFBiz Issue Type: Bug Components: framework Affects Versions: SVN trunk Reporter: Blas Rodriguez Somoza Priority: Minor Fix For: SVN trunk Attachments: CAL_bizznesstime_after.jpg, CAL_bizznesstime_before.jpg, CAL_bluelight_after.jpg Field markup should be a valid inline element. Defining fields with div (block) instead of span (inline) creates several problems: - Missalignments in screen. (See LOOKUP_CAL screenshots) - Implies a end-of-line after the div. (See CAL screenshots) - If used inside inline elements which should be OK, becames XHTML validation errors. (Manufacturing - MRP - MRP log) Because this is a markup problem, it spans to all the themes. This patch contains 2 files in the framework/widget area and 5 in the themes area. Because the source of the problem is in the framework/widget area, I opt to assign the bug to the framework area. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (OFBIZ-3708) Fields should be defined with span not div. (radio, date, lookup)
[ https://issues.apache.org/jira/browse/OFBIZ-3708?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Blas Rodriguez Somoza updated OFBIZ-3708: - Attachment: (was: LOOKUP_CAL_before_tomahawk.jpg) Fields should be defined with span not div. (radio, date, lookup) - Key: OFBIZ-3708 URL: https://issues.apache.org/jira/browse/OFBIZ-3708 Project: OFBiz Issue Type: Bug Components: framework Affects Versions: SVN trunk Reporter: Blas Rodriguez Somoza Priority: Minor Fix For: SVN trunk Attachments: CAL_bizznesstime_after.jpg, CAL_bizznesstime_before.jpg, CAL_bluelight_after.jpg Field markup should be a valid inline element. Defining fields with div (block) instead of span (inline) creates several problems: - Missalignments in screen. (See LOOKUP_CAL screenshots) - Implies a end-of-line after the div. (See CAL screenshots) - If used inside inline elements which should be OK, becames XHTML validation errors. (Manufacturing - MRP - MRP log) Because this is a markup problem, it spans to all the themes. This patch contains 2 files in the framework/widget area and 5 in the themes area. Because the source of the problem is in the framework/widget area, I opt to assign the bug to the framework area. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (OFBIZ-3708) Fields should be defined with span not div. (radio, date, lookup)
[ https://issues.apache.org/jira/browse/OFBIZ-3708?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Blas Rodriguez Somoza updated OFBIZ-3708: - Attachment: (was: CAL_after_flatgrey.jpg) Fields should be defined with span not div. (radio, date, lookup) - Key: OFBIZ-3708 URL: https://issues.apache.org/jira/browse/OFBIZ-3708 Project: OFBiz Issue Type: Bug Components: framework Affects Versions: SVN trunk Reporter: Blas Rodriguez Somoza Priority: Minor Fix For: SVN trunk Attachments: CAL_bizznesstime_after.jpg, CAL_bizznesstime_before.jpg, CAL_bluelight_after.jpg Field markup should be a valid inline element. Defining fields with div (block) instead of span (inline) creates several problems: - Missalignments in screen. (See LOOKUP_CAL screenshots) - Implies a end-of-line after the div. (See CAL screenshots) - If used inside inline elements which should be OK, becames XHTML validation errors. (Manufacturing - MRP - MRP log) Because this is a markup problem, it spans to all the themes. This patch contains 2 files in the framework/widget area and 5 in the themes area. Because the source of the problem is in the framework/widget area, I opt to assign the bug to the framework area. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (OFBIZ-3708) Fields should be defined with span not div. (radio, date, lookup)
[ https://issues.apache.org/jira/browse/OFBIZ-3708?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Blas Rodriguez Somoza updated OFBIZ-3708: - Attachment: (was: CAL_after_tomahawk.jpg) Fields should be defined with span not div. (radio, date, lookup) - Key: OFBIZ-3708 URL: https://issues.apache.org/jira/browse/OFBIZ-3708 Project: OFBiz Issue Type: Bug Components: framework Affects Versions: SVN trunk Reporter: Blas Rodriguez Somoza Priority: Minor Fix For: SVN trunk Attachments: CAL_bizznesstime_after.jpg, CAL_bizznesstime_before.jpg, CAL_bluelight_after.jpg Field markup should be a valid inline element. Defining fields with div (block) instead of span (inline) creates several problems: - Missalignments in screen. (See LOOKUP_CAL screenshots) - Implies a end-of-line after the div. (See CAL screenshots) - If used inside inline elements which should be OK, becames XHTML validation errors. (Manufacturing - MRP - MRP log) Because this is a markup problem, it spans to all the themes. This patch contains 2 files in the framework/widget area and 5 in the themes area. Because the source of the problem is in the framework/widget area, I opt to assign the bug to the framework area. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (OFBIZ-3708) Fields should be defined with span not div. (radio, date, lookup)
[ https://issues.apache.org/jira/browse/OFBIZ-3708?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Blas Rodriguez Somoza updated OFBIZ-3708: - Attachment: (was: LOOKUP_CAL_before_flatgrey.jpg) Fields should be defined with span not div. (radio, date, lookup) - Key: OFBIZ-3708 URL: https://issues.apache.org/jira/browse/OFBIZ-3708 Project: OFBiz Issue Type: Bug Components: framework Affects Versions: SVN trunk Reporter: Blas Rodriguez Somoza Priority: Minor Fix For: SVN trunk Attachments: CAL_bizznesstime_after.jpg, CAL_bizznesstime_before.jpg, CAL_bluelight_after.jpg Field markup should be a valid inline element. Defining fields with div (block) instead of span (inline) creates several problems: - Missalignments in screen. (See LOOKUP_CAL screenshots) - Implies a end-of-line after the div. (See CAL screenshots) - If used inside inline elements which should be OK, becames XHTML validation errors. (Manufacturing - MRP - MRP log) Because this is a markup problem, it spans to all the themes. This patch contains 2 files in the framework/widget area and 5 in the themes area. Because the source of the problem is in the framework/widget area, I opt to assign the bug to the framework area. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (OFBIZ-3708) Fields should be defined with span not div. (radio, date, lookup)
[ https://issues.apache.org/jira/browse/OFBIZ-3708?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Blas Rodriguez Somoza updated OFBIZ-3708: - Attachment: (was: LOOKUP_CAL_before_droppingcrumbs.jpg) Fields should be defined with span not div. (radio, date, lookup) - Key: OFBIZ-3708 URL: https://issues.apache.org/jira/browse/OFBIZ-3708 Project: OFBiz Issue Type: Bug Components: framework Affects Versions: SVN trunk Reporter: Blas Rodriguez Somoza Priority: Minor Fix For: SVN trunk Attachments: CAL_bizznesstime_after.jpg, CAL_bizznesstime_before.jpg, CAL_bluelight_after.jpg Field markup should be a valid inline element. Defining fields with div (block) instead of span (inline) creates several problems: - Missalignments in screen. (See LOOKUP_CAL screenshots) - Implies a end-of-line after the div. (See CAL screenshots) - If used inside inline elements which should be OK, becames XHTML validation errors. (Manufacturing - MRP - MRP log) Because this is a markup problem, it spans to all the themes. This patch contains 2 files in the framework/widget area and 5 in the themes area. Because the source of the problem is in the framework/widget area, I opt to assign the bug to the framework area. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (OFBIZ-3708) Fields should be defined with span not div. (radio, date, lookup)
[ https://issues.apache.org/jira/browse/OFBIZ-3708?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Blas Rodriguez Somoza updated OFBIZ-3708: - Attachment: (was: CAL_before_bizznesstime.jpg) Fields should be defined with span not div. (radio, date, lookup) - Key: OFBIZ-3708 URL: https://issues.apache.org/jira/browse/OFBIZ-3708 Project: OFBiz Issue Type: Bug Components: framework Affects Versions: SVN trunk Reporter: Blas Rodriguez Somoza Priority: Minor Fix For: SVN trunk Attachments: CAL_bizznesstime_after.jpg, CAL_bizznesstime_before.jpg, CAL_bluelight_after.jpg Field markup should be a valid inline element. Defining fields with div (block) instead of span (inline) creates several problems: - Missalignments in screen. (See LOOKUP_CAL screenshots) - Implies a end-of-line after the div. (See CAL screenshots) - If used inside inline elements which should be OK, becames XHTML validation errors. (Manufacturing - MRP - MRP log) Because this is a markup problem, it spans to all the themes. This patch contains 2 files in the framework/widget area and 5 in the themes area. Because the source of the problem is in the framework/widget area, I opt to assign the bug to the framework area. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (OFBIZ-3708) Fields should be defined with span not div. (radio, date, lookup)
[ https://issues.apache.org/jira/browse/OFBIZ-3708?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Blas Rodriguez Somoza updated OFBIZ-3708: - Attachment: (was: CAL_before_droppingcrumbs.jpg) Fields should be defined with span not div. (radio, date, lookup) - Key: OFBIZ-3708 URL: https://issues.apache.org/jira/browse/OFBIZ-3708 Project: OFBiz Issue Type: Bug Components: framework Affects Versions: SVN trunk Reporter: Blas Rodriguez Somoza Priority: Minor Fix For: SVN trunk Attachments: CAL_bizznesstime_after.jpg, CAL_bizznesstime_before.jpg, CAL_bluelight_after.jpg Field markup should be a valid inline element. Defining fields with div (block) instead of span (inline) creates several problems: - Missalignments in screen. (See LOOKUP_CAL screenshots) - Implies a end-of-line after the div. (See CAL screenshots) - If used inside inline elements which should be OK, becames XHTML validation errors. (Manufacturing - MRP - MRP log) Because this is a markup problem, it spans to all the themes. This patch contains 2 files in the framework/widget area and 5 in the themes area. Because the source of the problem is in the framework/widget area, I opt to assign the bug to the framework area. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (OFBIZ-3708) Fields should be defined with span not div. (radio, date, lookup)
[ https://issues.apache.org/jira/browse/OFBIZ-3708?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Blas Rodriguez Somoza updated OFBIZ-3708: - Attachment: (was: CAL_before_tomahawk.jpg) Fields should be defined with span not div. (radio, date, lookup) - Key: OFBIZ-3708 URL: https://issues.apache.org/jira/browse/OFBIZ-3708 Project: OFBiz Issue Type: Bug Components: framework Affects Versions: SVN trunk Reporter: Blas Rodriguez Somoza Priority: Minor Fix For: SVN trunk Attachments: CAL_bizznesstime_after.jpg, CAL_bizznesstime_before.jpg, CAL_bluelight_after.jpg Field markup should be a valid inline element. Defining fields with div (block) instead of span (inline) creates several problems: - Missalignments in screen. (See LOOKUP_CAL screenshots) - Implies a end-of-line after the div. (See CAL screenshots) - If used inside inline elements which should be OK, becames XHTML validation errors. (Manufacturing - MRP - MRP log) Because this is a markup problem, it spans to all the themes. This patch contains 2 files in the framework/widget area and 5 in the themes area. Because the source of the problem is in the framework/widget area, I opt to assign the bug to the framework area. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (OFBIZ-3708) Fields should be defined with span not div. (radio, date, lookup)
[ https://issues.apache.org/jira/browse/OFBIZ-3708?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Blas Rodriguez Somoza updated OFBIZ-3708: - Attachment: (was: LOOKUP_CAL_after_droppingcrumbs.jpg) Fields should be defined with span not div. (radio, date, lookup) - Key: OFBIZ-3708 URL: https://issues.apache.org/jira/browse/OFBIZ-3708 Project: OFBiz Issue Type: Bug Components: framework Affects Versions: SVN trunk Reporter: Blas Rodriguez Somoza Priority: Minor Fix For: SVN trunk Attachments: CAL_bizznesstime_after.jpg, CAL_bizznesstime_before.jpg, CAL_bluelight_after.jpg Field markup should be a valid inline element. Defining fields with div (block) instead of span (inline) creates several problems: - Missalignments in screen. (See LOOKUP_CAL screenshots) - Implies a end-of-line after the div. (See CAL screenshots) - If used inside inline elements which should be OK, becames XHTML validation errors. (Manufacturing - MRP - MRP log) Because this is a markup problem, it spans to all the themes. This patch contains 2 files in the framework/widget area and 5 in the themes area. Because the source of the problem is in the framework/widget area, I opt to assign the bug to the framework area. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (OFBIZ-3708) Fields should be defined with span not div. (radio, date, lookup)
[ https://issues.apache.org/jira/browse/OFBIZ-3708?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Blas Rodriguez Somoza updated OFBIZ-3708: - Attachment: (was: LOOKUP_CAL_after_tomahawk.jpg) Fields should be defined with span not div. (radio, date, lookup) - Key: OFBIZ-3708 URL: https://issues.apache.org/jira/browse/OFBIZ-3708 Project: OFBiz Issue Type: Bug Components: framework Affects Versions: SVN trunk Reporter: Blas Rodriguez Somoza Priority: Minor Fix For: SVN trunk Attachments: CAL_bizznesstime_after.jpg, CAL_bizznesstime_before.jpg, CAL_bluelight_after.jpg Field markup should be a valid inline element. Defining fields with div (block) instead of span (inline) creates several problems: - Missalignments in screen. (See LOOKUP_CAL screenshots) - Implies a end-of-line after the div. (See CAL screenshots) - If used inside inline elements which should be OK, becames XHTML validation errors. (Manufacturing - MRP - MRP log) Because this is a markup problem, it spans to all the themes. This patch contains 2 files in the framework/widget area and 5 in the themes area. Because the source of the problem is in the framework/widget area, I opt to assign the bug to the framework area. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (OFBIZ-3708) Fields should be defined with span not div. (radio, date, lookup)
[ https://issues.apache.org/jira/browse/OFBIZ-3708?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Blas Rodriguez Somoza updated OFBIZ-3708: - Attachment: (was: LOOKUP_CAL_before_bluelight.jpg) Fields should be defined with span not div. (radio, date, lookup) - Key: OFBIZ-3708 URL: https://issues.apache.org/jira/browse/OFBIZ-3708 Project: OFBiz Issue Type: Bug Components: framework Affects Versions: SVN trunk Reporter: Blas Rodriguez Somoza Priority: Minor Fix For: SVN trunk Attachments: CAL_bizznesstime_after.jpg, CAL_bizznesstime_before.jpg, CAL_bluelight_after.jpg Field markup should be a valid inline element. Defining fields with div (block) instead of span (inline) creates several problems: - Missalignments in screen. (See LOOKUP_CAL screenshots) - Implies a end-of-line after the div. (See CAL screenshots) - If used inside inline elements which should be OK, becames XHTML validation errors. (Manufacturing - MRP - MRP log) Because this is a markup problem, it spans to all the themes. This patch contains 2 files in the framework/widget area and 5 in the themes area. Because the source of the problem is in the framework/widget area, I opt to assign the bug to the framework area. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (OFBIZ-3708) Fields should be defined with span not div. (radio, date, lookup)
[ https://issues.apache.org/jira/browse/OFBIZ-3708?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Blas Rodriguez Somoza updated OFBIZ-3708: - Attachment: (was: LOOKUP_CAL_before_bizznesstime.jpg) Fields should be defined with span not div. (radio, date, lookup) - Key: OFBIZ-3708 URL: https://issues.apache.org/jira/browse/OFBIZ-3708 Project: OFBiz Issue Type: Bug Components: framework Affects Versions: SVN trunk Reporter: Blas Rodriguez Somoza Priority: Minor Fix For: SVN trunk Attachments: CAL_bizznesstime_after.jpg, CAL_bizznesstime_before.jpg, CAL_bluelight_after.jpg Field markup should be a valid inline element. Defining fields with div (block) instead of span (inline) creates several problems: - Missalignments in screen. (See LOOKUP_CAL screenshots) - Implies a end-of-line after the div. (See CAL screenshots) - If used inside inline elements which should be OK, becames XHTML validation errors. (Manufacturing - MRP - MRP log) Because this is a markup problem, it spans to all the themes. This patch contains 2 files in the framework/widget area and 5 in the themes area. Because the source of the problem is in the framework/widget area, I opt to assign the bug to the framework area. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (OFBIZ-3708) Fields should be defined with span not div. (radio, date, lookup)
[ https://issues.apache.org/jira/browse/OFBIZ-3708?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Blas Rodriguez Somoza updated OFBIZ-3708: - Attachment: CAL_flatgrey_after.jpg CAL_flatgrey_before.jpg CAL_tomahawk_after.jpg Fields should be defined with span not div. (radio, date, lookup) - Key: OFBIZ-3708 URL: https://issues.apache.org/jira/browse/OFBIZ-3708 Project: OFBiz Issue Type: Bug Components: framework Affects Versions: SVN trunk Reporter: Blas Rodriguez Somoza Priority: Minor Fix For: SVN trunk Attachments: CAL_bizznesstime_after.jpg, CAL_bizznesstime_before.jpg, CAL_bluelight_after.jpg, CAL_bluelight_before.jpg, CAL_droppingcrumbs_after.jpg, CAL_droppingcrumbs_before.jpg, CAL_flatgrey_after.jpg, CAL_flatgrey_before.jpg, CAL_tomahawk_after.jpg, CAL_tomahawk_before.jpg, LOOKUP_CAL_bizznesstime_after.jpg, LOOKUP_CAL_bizznesstime_before.jpg, LOOKUP_CAL_bluelight_after.jpg, LOOKUP_CAL_bluelight_before.jpg, LOOKUP_CAL_droppingcrumbs_after.jpg Field markup should be a valid inline element. Defining fields with div (block) instead of span (inline) creates several problems: - Missalignments in screen. (See LOOKUP_CAL screenshots) - Implies a end-of-line after the div. (See CAL screenshots) - If used inside inline elements which should be OK, becames XHTML validation errors. (Manufacturing - MRP - MRP log) Because this is a markup problem, it spans to all the themes. This patch contains 2 files in the framework/widget area and 5 in the themes area. Because the source of the problem is in the framework/widget area, I opt to assign the bug to the framework area. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (OFBIZ-3708) Fields should be defined with span not div. (radio, date, lookup)
[ https://issues.apache.org/jira/browse/OFBIZ-3708?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Blas Rodriguez Somoza updated OFBIZ-3708: - Attachment: CAL_bluelight_before.jpg CAL_droppingcrumbs_after.jpg CAL_droppingcrumbs_before.jpg Fields should be defined with span not div. (radio, date, lookup) - Key: OFBIZ-3708 URL: https://issues.apache.org/jira/browse/OFBIZ-3708 Project: OFBiz Issue Type: Bug Components: framework Affects Versions: SVN trunk Reporter: Blas Rodriguez Somoza Priority: Minor Fix For: SVN trunk Attachments: CAL_bizznesstime_after.jpg, CAL_bizznesstime_before.jpg, CAL_bluelight_after.jpg, CAL_bluelight_before.jpg, CAL_droppingcrumbs_after.jpg, CAL_droppingcrumbs_before.jpg, CAL_flatgrey_after.jpg, CAL_flatgrey_before.jpg, CAL_tomahawk_after.jpg, CAL_tomahawk_before.jpg, LOOKUP_CAL_bizznesstime_after.jpg, LOOKUP_CAL_bizznesstime_before.jpg, LOOKUP_CAL_bluelight_after.jpg, LOOKUP_CAL_bluelight_before.jpg, LOOKUP_CAL_droppingcrumbs_after.jpg Field markup should be a valid inline element. Defining fields with div (block) instead of span (inline) creates several problems: - Missalignments in screen. (See LOOKUP_CAL screenshots) - Implies a end-of-line after the div. (See CAL screenshots) - If used inside inline elements which should be OK, becames XHTML validation errors. (Manufacturing - MRP - MRP log) Because this is a markup problem, it spans to all the themes. This patch contains 2 files in the framework/widget area and 5 in the themes area. Because the source of the problem is in the framework/widget area, I opt to assign the bug to the framework area. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (OFBIZ-3708) Fields should be defined with span not div. (radio, date, lookup)
[ https://issues.apache.org/jira/browse/OFBIZ-3708?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Blas Rodriguez Somoza updated OFBIZ-3708: - Attachment: CAL_tomahawk_before.jpg LOOKUP_CAL_bizznesstime_after.jpg LOOKUP_CAL_bizznesstime_before.jpg Fields should be defined with span not div. (radio, date, lookup) - Key: OFBIZ-3708 URL: https://issues.apache.org/jira/browse/OFBIZ-3708 Project: OFBiz Issue Type: Bug Components: framework Affects Versions: SVN trunk Reporter: Blas Rodriguez Somoza Priority: Minor Fix For: SVN trunk Attachments: CAL_bizznesstime_after.jpg, CAL_bizznesstime_before.jpg, CAL_bluelight_after.jpg, CAL_bluelight_before.jpg, CAL_droppingcrumbs_after.jpg, CAL_droppingcrumbs_before.jpg, CAL_flatgrey_after.jpg, CAL_flatgrey_before.jpg, CAL_tomahawk_after.jpg, CAL_tomahawk_before.jpg, LOOKUP_CAL_bizznesstime_after.jpg, LOOKUP_CAL_bizznesstime_before.jpg, LOOKUP_CAL_bluelight_after.jpg, LOOKUP_CAL_bluelight_before.jpg, LOOKUP_CAL_droppingcrumbs_after.jpg Field markup should be a valid inline element. Defining fields with div (block) instead of span (inline) creates several problems: - Missalignments in screen. (See LOOKUP_CAL screenshots) - Implies a end-of-line after the div. (See CAL screenshots) - If used inside inline elements which should be OK, becames XHTML validation errors. (Manufacturing - MRP - MRP log) Because this is a markup problem, it spans to all the themes. This patch contains 2 files in the framework/widget area and 5 in the themes area. Because the source of the problem is in the framework/widget area, I opt to assign the bug to the framework area. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (OFBIZ-3708) Fields should be defined with span not div. (radio, date, lookup)
[ https://issues.apache.org/jira/browse/OFBIZ-3708?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Blas Rodriguez Somoza updated OFBIZ-3708: - Attachment: LOOKUP_CAL_bluelight_after.jpg LOOKUP_CAL_bluelight_before.jpg LOOKUP_CAL_droppingcrumbs_after.jpg Fields should be defined with span not div. (radio, date, lookup) - Key: OFBIZ-3708 URL: https://issues.apache.org/jira/browse/OFBIZ-3708 Project: OFBiz Issue Type: Bug Components: framework Affects Versions: SVN trunk Reporter: Blas Rodriguez Somoza Priority: Minor Fix For: SVN trunk Attachments: CAL_bizznesstime_after.jpg, CAL_bizznesstime_before.jpg, CAL_bluelight_after.jpg, CAL_bluelight_before.jpg, CAL_droppingcrumbs_after.jpg, CAL_droppingcrumbs_before.jpg, CAL_flatgrey_after.jpg, CAL_flatgrey_before.jpg, CAL_tomahawk_after.jpg, CAL_tomahawk_before.jpg, LOOKUP_CAL_bizznesstime_after.jpg, LOOKUP_CAL_bizznesstime_before.jpg, LOOKUP_CAL_bluelight_after.jpg, LOOKUP_CAL_bluelight_before.jpg, LOOKUP_CAL_droppingcrumbs_after.jpg Field markup should be a valid inline element. Defining fields with div (block) instead of span (inline) creates several problems: - Missalignments in screen. (See LOOKUP_CAL screenshots) - Implies a end-of-line after the div. (See CAL screenshots) - If used inside inline elements which should be OK, becames XHTML validation errors. (Manufacturing - MRP - MRP log) Because this is a markup problem, it spans to all the themes. This patch contains 2 files in the framework/widget area and 5 in the themes area. Because the source of the problem is in the framework/widget area, I opt to assign the bug to the framework area. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (OFBIZ-3708) Fields should be defined with span not div. (radio, date, lookup)
[ https://issues.apache.org/jira/browse/OFBIZ-3708?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Blas Rodriguez Somoza updated OFBIZ-3708: - Attachment: LOOKUP_CAL_tomahawk_after.jpg LOOKUP_CAL_tomahawk_before.jpg Fields should be defined with span not div. (radio, date, lookup) - Key: OFBIZ-3708 URL: https://issues.apache.org/jira/browse/OFBIZ-3708 Project: OFBiz Issue Type: Bug Components: framework Affects Versions: SVN trunk Reporter: Blas Rodriguez Somoza Priority: Minor Fix For: SVN trunk Attachments: CAL_bizznesstime_after.jpg, CAL_bizznesstime_before.jpg, CAL_bluelight_after.jpg, CAL_bluelight_before.jpg, CAL_droppingcrumbs_after.jpg, CAL_droppingcrumbs_before.jpg, CAL_flatgrey_after.jpg, CAL_flatgrey_before.jpg, CAL_tomahawk_after.jpg, CAL_tomahawk_before.jpg, LOOKUP_CAL_bizznesstime_after.jpg, LOOKUP_CAL_bizznesstime_before.jpg, LOOKUP_CAL_bluelight_after.jpg, LOOKUP_CAL_bluelight_before.jpg, LOOKUP_CAL_droppingcrumbs_after.jpg, LOOKUP_CAL_droppingcrumbs_before.jpg, LOOKUP_CAL_flatgrey_after.jpg, LOOKUP_CAL_flatgrey_before.jpg, LOOKUP_CAL_tomahawk_after.jpg, LOOKUP_CAL_tomahawk_before.jpg Field markup should be a valid inline element. Defining fields with div (block) instead of span (inline) creates several problems: - Missalignments in screen. (See LOOKUP_CAL screenshots) - Implies a end-of-line after the div. (See CAL screenshots) - If used inside inline elements which should be OK, becames XHTML validation errors. (Manufacturing - MRP - MRP log) Because this is a markup problem, it spans to all the themes. This patch contains 2 files in the framework/widget area and 5 in the themes area. Because the source of the problem is in the framework/widget area, I opt to assign the bug to the framework area. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (OFBIZ-3708) Fields should be defined with span not div. (radio, date, lookup)
[ https://issues.apache.org/jira/browse/OFBIZ-3708?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Blas Rodriguez Somoza updated OFBIZ-3708: - Attachment: LOOKUP_CAL_droppingcrumbs_before.jpg LOOKUP_CAL_flatgrey_after.jpg LOOKUP_CAL_flatgrey_before.jpg Fields should be defined with span not div. (radio, date, lookup) - Key: OFBIZ-3708 URL: https://issues.apache.org/jira/browse/OFBIZ-3708 Project: OFBiz Issue Type: Bug Components: framework Affects Versions: SVN trunk Reporter: Blas Rodriguez Somoza Priority: Minor Fix For: SVN trunk Attachments: CAL_bizznesstime_after.jpg, CAL_bizznesstime_before.jpg, CAL_bluelight_after.jpg, CAL_bluelight_before.jpg, CAL_droppingcrumbs_after.jpg, CAL_droppingcrumbs_before.jpg, CAL_flatgrey_after.jpg, CAL_flatgrey_before.jpg, CAL_tomahawk_after.jpg, CAL_tomahawk_before.jpg, LOOKUP_CAL_bizznesstime_after.jpg, LOOKUP_CAL_bizznesstime_before.jpg, LOOKUP_CAL_bluelight_after.jpg, LOOKUP_CAL_bluelight_before.jpg, LOOKUP_CAL_droppingcrumbs_after.jpg, LOOKUP_CAL_droppingcrumbs_before.jpg, LOOKUP_CAL_flatgrey_after.jpg, LOOKUP_CAL_flatgrey_before.jpg, LOOKUP_CAL_tomahawk_after.jpg, LOOKUP_CAL_tomahawk_before.jpg Field markup should be a valid inline element. Defining fields with div (block) instead of span (inline) creates several problems: - Missalignments in screen. (See LOOKUP_CAL screenshots) - Implies a end-of-line after the div. (See CAL screenshots) - If used inside inline elements which should be OK, becames XHTML validation errors. (Manufacturing - MRP - MRP log) Because this is a markup problem, it spans to all the themes. This patch contains 2 files in the framework/widget area and 5 in the themes area. Because the source of the problem is in the framework/widget area, I opt to assign the bug to the framework area. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: svn commit: r935278 - in /ofbiz/trunk/applications/accounting/webapp/accounting/WEB-INF/actions: invoice/ order/ payment/ reports/
On 18/04/2010, at 12:20 PM, Adam Heath wrote:
lekt...@apache.org wrote:
Author: lektran
Date: Sun Apr 18 00:16:52 2010
New Revision: 935278
URL: http://svn.apache.org/viewvc?rev=935278view=rev
Log:
A few examples of using groovy's first() list method instead of
EntityUtil.getFirst(List)
Modified:
ofbiz/trunk/applications/accounting/webapp/accounting/WEB-INF/actions/invoice/EditInvoice.groovy
ofbiz/trunk/applications/accounting/webapp/accounting/WEB-INF/actions/invoice/OrderListInvoiceItem.groovy
ofbiz/trunk/applications/accounting/webapp/accounting/WEB-INF/actions/order/BillingAccountOrders.groovy
ofbiz/trunk/applications/accounting/webapp/accounting/WEB-INF/actions/payment/BillingAccounts.groovy
ofbiz/trunk/applications/accounting/webapp/accounting/WEB-INF/actions/reports/GlAccountTrialBalance.groovy
ofbiz/trunk/applications/accounting/webapp/accounting/WEB-INF/actions/reports/TransactionTotals.groovy
Modified:
ofbiz/trunk/applications/accounting/webapp/accounting/WEB-INF/actions/invoice/EditInvoice.groovy
URL:
http://svn.apache.org/viewvc/ofbiz/trunk/applications/accounting/webapp/accounting/WEB-INF/actions/invoice/EditInvoice.groovy?rev=935278r1=935277r2=935278view=diff
==
---
ofbiz/trunk/applications/accounting/webapp/accounting/WEB-INF/actions/invoice/EditInvoice.groovy
(original)
+++
ofbiz/trunk/applications/accounting/webapp/accounting/WEB-INF/actions/invoice/EditInvoice.groovy
Sun Apr 18 00:16:52 2010
@@ -77,7 +77,8 @@ if (invoice) {
// also create a map with tax grand total amount by VAT tax: it is
also required in invoices by UE
taxRate = invoiceItem.getRelatedOne(TaxAuthorityRateProduct);
if (taxRate VAT_TAX.equals(taxRate.taxAuthorityRateTypeId)) {
-taxInfo =
EntityUtil.getFirst(EntityUtil.filterByDate(delegator.findByAnd(PartyTaxAuthInfo,
UtilMisc.toMap(partyId, billingParty.partyId, taxAuthGeoId,
taxRate.taxAuthGeoId, taxAuthPartyId, taxRate.taxAuthPartyId)),
invoice.invoiceDate));
+taxInfos =
EntityUtil.filterByDate(delegator.findByAnd(PartyTaxAuthInfo, [partyId :
billingParty.partyId, taxAuthGeoId : taxRate.taxAuthGeoId, taxAuthPartyId :
taxRate.taxAuthPartyId]), invoice.invoiceDate);
+taxInfo = taxInfos.first();
if (taxInfo) {
context.billingPartyTaxId = taxInfo.partyTaxId;
}
Why the split into multiple lines? None of the other changes do this.
Readability, that line was particularly long and comprised of multiple method
calls, I was concerned about people not reading to the end and expecting the
result to be a list.
Plus I don't really like 3 calls on one line.
Regards
Scott
smime.p7s
Description: S/MIME cryptographic signature
[jira] Commented: (OFBIZ-3708) Fields should be defined with span not div. (radio, date, lookup)
[ https://issues.apache.org/jira/browse/OFBIZ-3708?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12858246#action_12858246 ] Tim Ruppert commented on OFBIZ-3708: Yeah - this is going backwards - don't push to span - fix the CSS for the divs Fields should be defined with span not div. (radio, date, lookup) - Key: OFBIZ-3708 URL: https://issues.apache.org/jira/browse/OFBIZ-3708 Project: OFBiz Issue Type: Bug Components: framework Affects Versions: SVN trunk Reporter: Blas Rodriguez Somoza Priority: Minor Fix For: SVN trunk Attachments: CAL_bizznesstime_after.jpg, CAL_bizznesstime_before.jpg, CAL_bluelight_after.jpg, CAL_bluelight_before.jpg, CAL_droppingcrumbs_after.jpg, CAL_droppingcrumbs_before.jpg, CAL_flatgrey_after.jpg, CAL_flatgrey_before.jpg, CAL_tomahawk_after.jpg, CAL_tomahawk_before.jpg, LOOKUP_CAL_bizznesstime_after.jpg, LOOKUP_CAL_bizznesstime_before.jpg, LOOKUP_CAL_bluelight_after.jpg, LOOKUP_CAL_bluelight_before.jpg, LOOKUP_CAL_droppingcrumbs_after.jpg, LOOKUP_CAL_droppingcrumbs_before.jpg, LOOKUP_CAL_flatgrey_after.jpg, LOOKUP_CAL_flatgrey_before.jpg, LOOKUP_CAL_tomahawk_after.jpg, LOOKUP_CAL_tomahawk_before.jpg, OFBIZ-3708_framework_divspan.diff Field markup should be a valid inline element. Defining fields with div (block) instead of span (inline) creates several problems: - Missalignments in screen. (See LOOKUP_CAL screenshots) - Implies a end-of-line after the div. (See CAL screenshots) - If used inside inline elements which should be OK, becames XHTML validation errors. (Manufacturing - MRP - MRP log) Because this is a markup problem, it spans to all the themes. This patch contains 2 files in the framework/widget area and 5 in the themes area. Because the source of the problem is in the framework/widget area, I opt to assign the bug to the framework area. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (OFBIZ-3708) Fields should be defined with span not div. (radio, date, lookup)
[ https://issues.apache.org/jira/browse/OFBIZ-3708?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Blas Rodriguez Somoza updated OFBIZ-3708: - Attachment: OFBIZ-3708_framework_divspan.diff Fields should be defined with span not div. (radio, date, lookup) - Key: OFBIZ-3708 URL: https://issues.apache.org/jira/browse/OFBIZ-3708 Project: OFBiz Issue Type: Bug Components: framework Affects Versions: SVN trunk Reporter: Blas Rodriguez Somoza Priority: Minor Fix For: SVN trunk Attachments: CAL_bizznesstime_after.jpg, CAL_bizznesstime_before.jpg, CAL_bluelight_after.jpg, CAL_bluelight_before.jpg, CAL_droppingcrumbs_after.jpg, CAL_droppingcrumbs_before.jpg, CAL_flatgrey_after.jpg, CAL_flatgrey_before.jpg, CAL_tomahawk_after.jpg, CAL_tomahawk_before.jpg, LOOKUP_CAL_bizznesstime_after.jpg, LOOKUP_CAL_bizznesstime_before.jpg, LOOKUP_CAL_bluelight_after.jpg, LOOKUP_CAL_bluelight_before.jpg, LOOKUP_CAL_droppingcrumbs_after.jpg, LOOKUP_CAL_droppingcrumbs_before.jpg, LOOKUP_CAL_flatgrey_after.jpg, LOOKUP_CAL_flatgrey_before.jpg, LOOKUP_CAL_tomahawk_after.jpg, LOOKUP_CAL_tomahawk_before.jpg, OFBIZ-3708_framework_divspan.diff Field markup should be a valid inline element. Defining fields with div (block) instead of span (inline) creates several problems: - Missalignments in screen. (See LOOKUP_CAL screenshots) - Implies a end-of-line after the div. (See CAL screenshots) - If used inside inline elements which should be OK, becames XHTML validation errors. (Manufacturing - MRP - MRP log) Because this is a markup problem, it spans to all the themes. This patch contains 2 files in the framework/widget area and 5 in the themes area. Because the source of the problem is in the framework/widget area, I opt to assign the bug to the framework area. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (OFBIZ-3708) Fields should be defined with span not div. (radio, date, lookup)
[ https://issues.apache.org/jira/browse/OFBIZ-3708?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12858247#action_12858247 ] Blas Rodriguez Somoza commented on OFBIZ-3708: -- Do you have a reason for that ? Fields should be defined with span not div. (radio, date, lookup) - Key: OFBIZ-3708 URL: https://issues.apache.org/jira/browse/OFBIZ-3708 Project: OFBiz Issue Type: Bug Components: framework Affects Versions: SVN trunk Reporter: Blas Rodriguez Somoza Priority: Minor Fix For: SVN trunk Attachments: CAL_bizznesstime_after.jpg, CAL_bizznesstime_before.jpg, CAL_bluelight_after.jpg, CAL_bluelight_before.jpg, CAL_droppingcrumbs_after.jpg, CAL_droppingcrumbs_before.jpg, CAL_flatgrey_after.jpg, CAL_flatgrey_before.jpg, CAL_tomahawk_after.jpg, CAL_tomahawk_before.jpg, LOOKUP_CAL_bizznesstime_after.jpg, LOOKUP_CAL_bizznesstime_before.jpg, LOOKUP_CAL_bluelight_after.jpg, LOOKUP_CAL_bluelight_before.jpg, LOOKUP_CAL_droppingcrumbs_after.jpg, LOOKUP_CAL_droppingcrumbs_before.jpg, LOOKUP_CAL_flatgrey_after.jpg, LOOKUP_CAL_flatgrey_before.jpg, LOOKUP_CAL_tomahawk_after.jpg, LOOKUP_CAL_tomahawk_before.jpg, OFBIZ-3708_framework_divspan.diff Field markup should be a valid inline element. Defining fields with div (block) instead of span (inline) creates several problems: - Missalignments in screen. (See LOOKUP_CAL screenshots) - Implies a end-of-line after the div. (See CAL screenshots) - If used inside inline elements which should be OK, becames XHTML validation errors. (Manufacturing - MRP - MRP log) Because this is a markup problem, it spans to all the themes. This patch contains 2 files in the framework/widget area and 5 in the themes area. Because the source of the problem is in the framework/widget area, I opt to assign the bug to the framework area. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (OFBIZ-3708) Fields should be defined with span not div. (radio, date, lookup)
[ https://issues.apache.org/jira/browse/OFBIZ-3708?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12858248#action_12858248 ] Blas Rodriguez Somoza commented on OFBIZ-3708: -- To Adam Heath. No div and span are not the same. Just put a inline element after a div, see the CAL_* screenshots. And this is not a css problem, but a markup one. I'm surprised I get two comments very quickly, even before I put the patch, and I suspect before reviewing the screenshots. Fields should be defined with span not div. (radio, date, lookup) - Key: OFBIZ-3708 URL: https://issues.apache.org/jira/browse/OFBIZ-3708 Project: OFBiz Issue Type: Bug Components: framework Affects Versions: SVN trunk Reporter: Blas Rodriguez Somoza Priority: Minor Fix For: SVN trunk Attachments: CAL_bizznesstime_after.jpg, CAL_bizznesstime_before.jpg, CAL_bluelight_after.jpg, CAL_bluelight_before.jpg, CAL_droppingcrumbs_after.jpg, CAL_droppingcrumbs_before.jpg, CAL_flatgrey_after.jpg, CAL_flatgrey_before.jpg, CAL_tomahawk_after.jpg, CAL_tomahawk_before.jpg, LOOKUP_CAL_bizznesstime_after.jpg, LOOKUP_CAL_bizznesstime_before.jpg, LOOKUP_CAL_bluelight_after.jpg, LOOKUP_CAL_bluelight_before.jpg, LOOKUP_CAL_droppingcrumbs_after.jpg, LOOKUP_CAL_droppingcrumbs_before.jpg, LOOKUP_CAL_flatgrey_after.jpg, LOOKUP_CAL_flatgrey_before.jpg, LOOKUP_CAL_tomahawk_after.jpg, LOOKUP_CAL_tomahawk_before.jpg, OFBIZ-3708_framework_divspan.diff Field markup should be a valid inline element. Defining fields with div (block) instead of span (inline) creates several problems: - Missalignments in screen. (See LOOKUP_CAL screenshots) - Implies a end-of-line after the div. (See CAL screenshots) - If used inside inline elements which should be OK, becames XHTML validation errors. (Manufacturing - MRP - MRP log) Because this is a markup problem, it spans to all the themes. This patch contains 2 files in the framework/widget area and 5 in the themes area. Because the source of the problem is in the framework/widget area, I opt to assign the bug to the framework area. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (OFBIZ-3708) Fields should be defined with span not div. (radio, date, lookup)
[
https://issues.apache.org/jira/browse/OFBIZ-3708?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12858249#action_12858249
]
Adam Heath commented on OFBIZ-3708:
---
Sure, div and span are different. There default css properties are different.
But you can change that easily enough.
I did review the screenshots. Which is why I knew I could make my comment.
html
head
style
div {
border:1px solid red;
}
.span {
display:inline;
}
/style
/head
body
before
div class=div
a div
/div
middle
div class=span
another div
/div
after
/body
/html
Fields should be defined with span not div. (radio, date, lookup)
-
Key: OFBIZ-3708
URL: https://issues.apache.org/jira/browse/OFBIZ-3708
Project: OFBiz
Issue Type: Bug
Components: framework
Affects Versions: SVN trunk
Reporter: Blas Rodriguez Somoza
Priority: Minor
Fix For: SVN trunk
Attachments: CAL_bizznesstime_after.jpg, CAL_bizznesstime_before.jpg,
CAL_bluelight_after.jpg, CAL_bluelight_before.jpg,
CAL_droppingcrumbs_after.jpg, CAL_droppingcrumbs_before.jpg,
CAL_flatgrey_after.jpg, CAL_flatgrey_before.jpg, CAL_tomahawk_after.jpg,
CAL_tomahawk_before.jpg, LOOKUP_CAL_bizznesstime_after.jpg,
LOOKUP_CAL_bizznesstime_before.jpg, LOOKUP_CAL_bluelight_after.jpg,
LOOKUP_CAL_bluelight_before.jpg, LOOKUP_CAL_droppingcrumbs_after.jpg,
LOOKUP_CAL_droppingcrumbs_before.jpg, LOOKUP_CAL_flatgrey_after.jpg,
LOOKUP_CAL_flatgrey_before.jpg, LOOKUP_CAL_tomahawk_after.jpg,
LOOKUP_CAL_tomahawk_before.jpg, OFBIZ-3708_framework_divspan.diff
Field markup should be a valid inline element.
Defining fields with div (block) instead of span (inline) creates several
problems:
- Missalignments in screen. (See LOOKUP_CAL screenshots)
- Implies a end-of-line after the div. (See CAL screenshots)
- If used inside inline elements which should be OK, becames XHTML validation
errors. (Manufacturing - MRP - MRP log)
Because this is a markup problem, it spans to all the themes.
This patch contains 2 files in the framework/widget area and 5 in the themes
area.
Because the source of the problem is in the framework/widget area, I opt to
assign the bug to the framework area.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
https://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Issue Comment Edited: (OFBIZ-3708) Fields should be defined with span not div. (radio, date, lookup)
[
https://issues.apache.org/jira/browse/OFBIZ-3708?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12858249#action_12858249
]
Adam Heath edited comment on OFBIZ-3708 at 4/17/10 9:05 PM:
Sure, div and span are different. There default css properties are different.
But you can change that easily enough.
I did review the screenshots. Which is why I knew I could make my comment.
The following html shows a div being displayed inline, no newline before or
after. Very simple to do.
html
head
style
div {
border:1px solid red;
}
.span {
display:inline;
}
/style
/head
body
before
div class=div
a div
/div
middle
div class=span
another div
/div
after
/body
/html
was (Author: doogie):
Sure, div and span are different. There default css properties are
different. But you can change that easily enough.
I did review the screenshots. Which is why I knew I could make my comment.
html
head
style
div {
border:1px solid red;
}
.span {
display:inline;
}
/style
/head
body
before
div class=div
a div
/div
middle
div class=span
another div
/div
after
/body
/html
Fields should be defined with span not div. (radio, date, lookup)
-
Key: OFBIZ-3708
URL: https://issues.apache.org/jira/browse/OFBIZ-3708
Project: OFBiz
Issue Type: Bug
Components: framework
Affects Versions: SVN trunk
Reporter: Blas Rodriguez Somoza
Priority: Minor
Fix For: SVN trunk
Attachments: CAL_bizznesstime_after.jpg, CAL_bizznesstime_before.jpg,
CAL_bluelight_after.jpg, CAL_bluelight_before.jpg,
CAL_droppingcrumbs_after.jpg, CAL_droppingcrumbs_before.jpg,
CAL_flatgrey_after.jpg, CAL_flatgrey_before.jpg, CAL_tomahawk_after.jpg,
CAL_tomahawk_before.jpg, LOOKUP_CAL_bizznesstime_after.jpg,
LOOKUP_CAL_bizznesstime_before.jpg, LOOKUP_CAL_bluelight_after.jpg,
LOOKUP_CAL_bluelight_before.jpg, LOOKUP_CAL_droppingcrumbs_after.jpg,
LOOKUP_CAL_droppingcrumbs_before.jpg, LOOKUP_CAL_flatgrey_after.jpg,
LOOKUP_CAL_flatgrey_before.jpg, LOOKUP_CAL_tomahawk_after.jpg,
LOOKUP_CAL_tomahawk_before.jpg, OFBIZ-3708_framework_divspan.diff
Field markup should be a valid inline element.
Defining fields with div (block) instead of span (inline) creates several
problems:
- Missalignments in screen. (See LOOKUP_CAL screenshots)
- Implies a end-of-line after the div. (See CAL screenshots)
- If used inside inline elements which should be OK, becames XHTML validation
errors. (Manufacturing - MRP - MRP log)
Because this is a markup problem, it spans to all the themes.
This patch contains 2 files in the framework/widget area and 5 in the themes
area.
Because the source of the problem is in the framework/widget area, I opt to
assign the bug to the framework area.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
https://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (OFBIZ-1968) Enrich Groovy integration with Ofbiz framework
[
https://issues.apache.org/jira/browse/OFBIZ-1968?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12858252#action_12858252
]
Scott Gray commented on OFBIZ-1968:
---
Here's an example of using groovy's Categories with existing util classes:
{code}
import org.ofbiz.entity.util.EntityUtil;
taxInfos = delegator.findByAnd(PartyTaxAuthInfo, [partyId :
billingParty.partyId, taxAuthGeoId : taxRate.taxAuthGeoId, taxAuthPartyId :
taxRate.taxAuthPartyId])
use (EntityUtil) {
// Equivalent to EntityUtil.filterByDate(taxInfos);
dateFilteredTaxInfos = taxInfos.filterByDate();
}
{code}
Enrich Groovy integration with Ofbiz framework
--
Key: OFBIZ-1968
URL: https://issues.apache.org/jira/browse/OFBIZ-1968
Project: OFBiz
Issue Type: Improvement
Components: framework
Reporter: Anil K Patel
Priority: Minor
Enrich Groovy integration with Ofbiz framework in order to bring goodies of
Minilang to Groovy scripts. Start with simple things like use
findByPrimaryKey in groovy scripts without having to prefix it with delegator
and then automatically find values for primary key fields from environment if
they are not explicitly passed in the call. Later other similar goodies of
minilang can be added.
Use Groovy to add DSL where possible.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
https://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (OFBIZ-3708) Fields should be defined with span not div. (radio, date, lookup)
[ https://issues.apache.org/jira/browse/OFBIZ-3708?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12858253#action_12858253 ] Blas Rodriguez Somoza commented on OFBIZ-3708: -- Hi Adam I agree with you here, making unneeded changes is always a bad solution. But I don't like making changes greater that those really needed, and so I don't switch to span without a reason. Of course you don't know me and so you can't know what kind of things I do. Yes, xhtml forbids a block element (like div) to be inside a inline element (like span). I attach a very simple xhtml page which contains a div inside a span and which you can test at w3c validator. Just go to http://validator.w3.org/#validate_by_input and copy and paste the following xhtml page -- !DOCTYPE html PUBLIC -//W3C//DTD XHTML 1.0 Transitional//EN http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd; html lang=en dir=ltr xmlns=http://www.w3.org/1999/xhtml; head titlediv span example/title /head body span div Text /div /span /body /html -- As you can see the W3C validator give you a validation error with the following text: - Line 9, Column 7: document type does not allow element div here; missing one of object, applet, map, iframe, button, ins, del start-tag The mentioned element is not allowed to appear in the context in which you've placed it; the other mentioned elements are the only ones that are both allowed there and can contain the element mentioned. This might mean that you need a containing element, or possibly that you've forgotten to close a previous element. One possible cause for this message is that you have attempted to put a block-level element (such as p or table) inside an inline element (such as a, span, or font). - As you can see in the last line, putting block elements (DIV) inside a inline elements (SPAN) is not allowed. You can get a more lengthly explanation in the HTML standard sections 7.5.3 and 7.5.4 (http://www.w3.org/TR/html401/struct/global.html#h-7.5.3) What do you think now ? Fields should be defined with span not div. (radio, date, lookup) - Key: OFBIZ-3708 URL: https://issues.apache.org/jira/browse/OFBIZ-3708 Project: OFBiz Issue Type: Bug Components: framework Affects Versions: SVN trunk Reporter: Blas Rodriguez Somoza Priority: Minor Fix For: SVN trunk Attachments: CAL_bizznesstime_after.jpg, CAL_bizznesstime_before.jpg, CAL_bluelight_after.jpg, CAL_bluelight_before.jpg, CAL_droppingcrumbs_after.jpg, CAL_droppingcrumbs_before.jpg, CAL_flatgrey_after.jpg, CAL_flatgrey_before.jpg, CAL_tomahawk_after.jpg, CAL_tomahawk_before.jpg, LOOKUP_CAL_bizznesstime_after.jpg, LOOKUP_CAL_bizznesstime_before.jpg, LOOKUP_CAL_bluelight_after.jpg, LOOKUP_CAL_bluelight_before.jpg, LOOKUP_CAL_droppingcrumbs_after.jpg, LOOKUP_CAL_droppingcrumbs_before.jpg, LOOKUP_CAL_flatgrey_after.jpg, LOOKUP_CAL_flatgrey_before.jpg, LOOKUP_CAL_tomahawk_after.jpg, LOOKUP_CAL_tomahawk_before.jpg, OFBIZ-3708_framework_divspan.diff Field markup should be a valid inline element. Defining fields with div (block) instead of span (inline) creates several problems: - Missalignments in screen. (See LOOKUP_CAL screenshots) - Implies a end-of-line after the div. (See CAL screenshots) - If used inside inline elements which should be OK, becames XHTML validation errors. (Manufacturing - MRP - MRP log) Because this is a markup problem, it spans to all the themes. This patch contains 2 files in the framework/widget area and 5 in the themes area. Because the source of the problem is in the framework/widget area, I opt to assign the bug to the framework area. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (OFBIZ-3708) Fields should be defined with span not div. (radio, date, lookup)
[ https://issues.apache.org/jira/browse/OFBIZ-3708?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12858254#action_12858254 ] Adrian Crum commented on OFBIZ-3708: I agree with Blas. A div is a block element and a span is an inline element. If a field row is a block element, then using spans within that block element to style the individual artifacts (icons, indicators, etc) in that block is appropriate. Putting those inline elements inside a ul element is incorrect also. As far as I can tell, the markup in the patch is semantically correct. Fields should be defined with span not div. (radio, date, lookup) - Key: OFBIZ-3708 URL: https://issues.apache.org/jira/browse/OFBIZ-3708 Project: OFBiz Issue Type: Bug Components: framework Affects Versions: SVN trunk Reporter: Blas Rodriguez Somoza Priority: Minor Fix For: SVN trunk Attachments: CAL_bizznesstime_after.jpg, CAL_bizznesstime_before.jpg, CAL_bluelight_after.jpg, CAL_bluelight_before.jpg, CAL_droppingcrumbs_after.jpg, CAL_droppingcrumbs_before.jpg, CAL_flatgrey_after.jpg, CAL_flatgrey_before.jpg, CAL_tomahawk_after.jpg, CAL_tomahawk_before.jpg, LOOKUP_CAL_bizznesstime_after.jpg, LOOKUP_CAL_bizznesstime_before.jpg, LOOKUP_CAL_bluelight_after.jpg, LOOKUP_CAL_bluelight_before.jpg, LOOKUP_CAL_droppingcrumbs_after.jpg, LOOKUP_CAL_droppingcrumbs_before.jpg, LOOKUP_CAL_flatgrey_after.jpg, LOOKUP_CAL_flatgrey_before.jpg, LOOKUP_CAL_tomahawk_after.jpg, LOOKUP_CAL_tomahawk_before.jpg, OFBIZ-3708_framework_divspan.diff Field markup should be a valid inline element. Defining fields with div (block) instead of span (inline) creates several problems: - Missalignments in screen. (See LOOKUP_CAL screenshots) - Implies a end-of-line after the div. (See CAL screenshots) - If used inside inline elements which should be OK, becames XHTML validation errors. (Manufacturing - MRP - MRP log) Because this is a markup problem, it spans to all the themes. This patch contains 2 files in the framework/widget area and 5 in the themes area. Because the source of the problem is in the framework/widget area, I opt to assign the bug to the framework area. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (OFBIZ-3708) Fields should be defined with span not div. (radio, date, lookup)
[ https://issues.apache.org/jira/browse/OFBIZ-3708?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12858255#action_12858255 ] Adam Heath commented on OFBIZ-3708: --- You gave a list of 3 items as to why using div was bad. However, the first 2 were not accurate, as the css allows you to change alignments and end-of-line stuff. Changing to span when the field is already in some inline type element is fine. However, I hope the patch is minimal, and only fixes these inline problems, and doesn't just change all the div field stuff to span to fix some possible display problem. Fields should be defined with span not div. (radio, date, lookup) - Key: OFBIZ-3708 URL: https://issues.apache.org/jira/browse/OFBIZ-3708 Project: OFBiz Issue Type: Bug Components: framework Affects Versions: SVN trunk Reporter: Blas Rodriguez Somoza Priority: Minor Fix For: SVN trunk Attachments: CAL_bizznesstime_after.jpg, CAL_bizznesstime_before.jpg, CAL_bluelight_after.jpg, CAL_bluelight_before.jpg, CAL_droppingcrumbs_after.jpg, CAL_droppingcrumbs_before.jpg, CAL_flatgrey_after.jpg, CAL_flatgrey_before.jpg, CAL_tomahawk_after.jpg, CAL_tomahawk_before.jpg, LOOKUP_CAL_bizznesstime_after.jpg, LOOKUP_CAL_bizznesstime_before.jpg, LOOKUP_CAL_bluelight_after.jpg, LOOKUP_CAL_bluelight_before.jpg, LOOKUP_CAL_droppingcrumbs_after.jpg, LOOKUP_CAL_droppingcrumbs_before.jpg, LOOKUP_CAL_flatgrey_after.jpg, LOOKUP_CAL_flatgrey_before.jpg, LOOKUP_CAL_tomahawk_after.jpg, LOOKUP_CAL_tomahawk_before.jpg, OFBIZ-3708_framework_divspan.diff Field markup should be a valid inline element. Defining fields with div (block) instead of span (inline) creates several problems: - Missalignments in screen. (See LOOKUP_CAL screenshots) - Implies a end-of-line after the div. (See CAL screenshots) - If used inside inline elements which should be OK, becames XHTML validation errors. (Manufacturing - MRP - MRP log) Because this is a markup problem, it spans to all the themes. This patch contains 2 files in the framework/widget area and 5 in the themes area. Because the source of the problem is in the framework/widget area, I opt to assign the bug to the framework area. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (OFBIZ-3708) Fields should be defined with span not div. (radio, date, lookup)
[ https://issues.apache.org/jira/browse/OFBIZ-3708?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12858257#action_12858257 ] Blas Rodriguez Somoza commented on OFBIZ-3708: -- Hi Adam I partially agree about the 2 first items, I suppose it could be resolved, but I don't how difficult it could be and how each browser will behave. The solution could be easy or a nightmare, but surely it will make css styles more complex and not easier. Anyway, If we agree that those fields must be valid to be included inside a inline element, then patch attached is the minimal one. 1.- DIV changed to SPAN 2.- Removed UL and LI because UL is a block element and LI must be inside a list. (As Adrian says in his comment) 3.- CSS styles corrected to match the changes. (display changed from block to inline-block and alignment changed to maintain the vertical position) Is this OK for you ? Fields should be defined with span not div. (radio, date, lookup) - Key: OFBIZ-3708 URL: https://issues.apache.org/jira/browse/OFBIZ-3708 Project: OFBiz Issue Type: Bug Components: framework Affects Versions: SVN trunk Reporter: Blas Rodriguez Somoza Priority: Minor Fix For: SVN trunk Attachments: CAL_bizznesstime_after.jpg, CAL_bizznesstime_before.jpg, CAL_bluelight_after.jpg, CAL_bluelight_before.jpg, CAL_droppingcrumbs_after.jpg, CAL_droppingcrumbs_before.jpg, CAL_flatgrey_after.jpg, CAL_flatgrey_before.jpg, CAL_tomahawk_after.jpg, CAL_tomahawk_before.jpg, LOOKUP_CAL_bizznesstime_after.jpg, LOOKUP_CAL_bizznesstime_before.jpg, LOOKUP_CAL_bluelight_after.jpg, LOOKUP_CAL_bluelight_before.jpg, LOOKUP_CAL_droppingcrumbs_after.jpg, LOOKUP_CAL_droppingcrumbs_before.jpg, LOOKUP_CAL_flatgrey_after.jpg, LOOKUP_CAL_flatgrey_before.jpg, LOOKUP_CAL_tomahawk_after.jpg, LOOKUP_CAL_tomahawk_before.jpg, OFBIZ-3708_framework_divspan.diff Field markup should be a valid inline element. Defining fields with div (block) instead of span (inline) creates several problems: - Missalignments in screen. (See LOOKUP_CAL screenshots) - Implies a end-of-line after the div. (See CAL screenshots) - If used inside inline elements which should be OK, becames XHTML validation errors. (Manufacturing - MRP - MRP log) Because this is a markup problem, it spans to all the themes. This patch contains 2 files in the framework/widget area and 5 in the themes area. Because the source of the problem is in the framework/widget area, I opt to assign the bug to the framework area. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (OFBIZ-3708) Fields should be defined with span not div. (radio, date, lookup)
[ https://issues.apache.org/jira/browse/OFBIZ-3708?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12858258#action_12858258 ] Adam Heath commented on OFBIZ-3708: --- Yes. I'm a happy little butterfly, flapping my wings, causing eddies in the air, which ripple upward, affecting incoming cosmic rays, that deflect to your hard-drive, causing your code to magically be to my liking. Fields should be defined with span not div. (radio, date, lookup) - Key: OFBIZ-3708 URL: https://issues.apache.org/jira/browse/OFBIZ-3708 Project: OFBiz Issue Type: Bug Components: framework Affects Versions: SVN trunk Reporter: Blas Rodriguez Somoza Priority: Minor Fix For: SVN trunk Attachments: CAL_bizznesstime_after.jpg, CAL_bizznesstime_before.jpg, CAL_bluelight_after.jpg, CAL_bluelight_before.jpg, CAL_droppingcrumbs_after.jpg, CAL_droppingcrumbs_before.jpg, CAL_flatgrey_after.jpg, CAL_flatgrey_before.jpg, CAL_tomahawk_after.jpg, CAL_tomahawk_before.jpg, LOOKUP_CAL_bizznesstime_after.jpg, LOOKUP_CAL_bizznesstime_before.jpg, LOOKUP_CAL_bluelight_after.jpg, LOOKUP_CAL_bluelight_before.jpg, LOOKUP_CAL_droppingcrumbs_after.jpg, LOOKUP_CAL_droppingcrumbs_before.jpg, LOOKUP_CAL_flatgrey_after.jpg, LOOKUP_CAL_flatgrey_before.jpg, LOOKUP_CAL_tomahawk_after.jpg, LOOKUP_CAL_tomahawk_before.jpg, OFBIZ-3708_framework_divspan.diff Field markup should be a valid inline element. Defining fields with div (block) instead of span (inline) creates several problems: - Missalignments in screen. (See LOOKUP_CAL screenshots) - Implies a end-of-line after the div. (See CAL screenshots) - If used inside inline elements which should be OK, becames XHTML validation errors. (Manufacturing - MRP - MRP log) Because this is a markup problem, it spans to all the themes. This patch contains 2 files in the framework/widget area and 5 in the themes area. Because the source of the problem is in the framework/widget area, I opt to assign the bug to the framework area. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Issue Comment Edited: (OFBIZ-3708) Fields should be defined with span not div. (radio, date, lookup)
[ https://issues.apache.org/jira/browse/OFBIZ-3708?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12858257#action_12858257 ] Blas Rodriguez Somoza edited comment on OFBIZ-3708 at 4/17/10 10:30 PM: Hi Adam I partially agree about the 2 first items, I suppose it could be resolved, but I don't how difficult it could be and how each browser will behave. The solution could be easy or a nightmare, but surely it will make css styles more complex and not easier. Anyway, If we agree that those fields must be valid to be included inside a inline element, then patch attached is the minimal one. In html FormMacroLibrary (macros renderDateTimeField, renderRadioField, renderDateFindField and renderLookupField) - DIV changed to SPAN - Removed UL and LI because UL is a block element and LI must be inside a list. (As Adrian says in his comment) In themes CSS files - Styles corrected to match the changes. (display changed from block to inline-block and alignment changed to maintain the vertical position) Is this OK for you ? was (Author: brsomoza): Hi Adam I partially agree about the 2 first items, I suppose it could be resolved, but I don't how difficult it could be and how each browser will behave. The solution could be easy or a nightmare, but surely it will make css styles more complex and not easier. Anyway, If we agree that those fields must be valid to be included inside a inline element, then patch attached is the minimal one. 1.- DIV changed to SPAN 2.- Removed UL and LI because UL is a block element and LI must be inside a list. (As Adrian says in his comment) 3.- CSS styles corrected to match the changes. (display changed from block to inline-block and alignment changed to maintain the vertical position) Is this OK for you ? Fields should be defined with span not div. (radio, date, lookup) - Key: OFBIZ-3708 URL: https://issues.apache.org/jira/browse/OFBIZ-3708 Project: OFBiz Issue Type: Bug Components: framework Affects Versions: SVN trunk Reporter: Blas Rodriguez Somoza Priority: Minor Fix For: SVN trunk Attachments: CAL_bizznesstime_after.jpg, CAL_bizznesstime_before.jpg, CAL_bluelight_after.jpg, CAL_bluelight_before.jpg, CAL_droppingcrumbs_after.jpg, CAL_droppingcrumbs_before.jpg, CAL_flatgrey_after.jpg, CAL_flatgrey_before.jpg, CAL_tomahawk_after.jpg, CAL_tomahawk_before.jpg, LOOKUP_CAL_bizznesstime_after.jpg, LOOKUP_CAL_bizznesstime_before.jpg, LOOKUP_CAL_bluelight_after.jpg, LOOKUP_CAL_bluelight_before.jpg, LOOKUP_CAL_droppingcrumbs_after.jpg, LOOKUP_CAL_droppingcrumbs_before.jpg, LOOKUP_CAL_flatgrey_after.jpg, LOOKUP_CAL_flatgrey_before.jpg, LOOKUP_CAL_tomahawk_after.jpg, LOOKUP_CAL_tomahawk_before.jpg, OFBIZ-3708_framework_divspan.diff Field markup should be a valid inline element. Defining fields with div (block) instead of span (inline) creates several problems: - Missalignments in screen. (See LOOKUP_CAL screenshots) - Implies a end-of-line after the div. (See CAL screenshots) - If used inside inline elements which should be OK, becames XHTML validation errors. (Manufacturing - MRP - MRP log) Because this is a markup problem, it spans to all the themes. This patch contains 2 files in the framework/widget area and 5 in the themes area. Because the source of the problem is in the framework/widget area, I opt to assign the bug to the framework area. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Issue Comment Edited: (OFBIZ-3708) Fields should be defined with span not div. (radio, date, lookup)
[ https://issues.apache.org/jira/browse/OFBIZ-3708?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12858257#action_12858257 ] Blas Rodriguez Somoza edited comment on OFBIZ-3708 at 4/17/10 10:31 PM: Hi Adam I partially agree about the 2 first items, I suppose it could be resolved, but I don't how difficult it could be and how each browser will behave. The solution could be easy or a nightmare, but surely it will make css styles more complex and not easier. Anyway, If we agree that those fields must be valid to be included inside a inline element, then the patch attached is the minimal one. In html FormMacroLibrary (macros renderDateTimeField, renderRadioField, renderDateFindField and renderLookupField) - DIV changed to SPAN - Removed UL and LI because UL is a block element and LI must be inside a list. (As Adrian say in his comment) In themes CSS files - Styles corrected to match the changes. (display changed from block to inline-block and alignment changed to maintain the vertical position) Is this OK for you ? was (Author: brsomoza): Hi Adam I partially agree about the 2 first items, I suppose it could be resolved, but I don't how difficult it could be and how each browser will behave. The solution could be easy or a nightmare, but surely it will make css styles more complex and not easier. Anyway, If we agree that those fields must be valid to be included inside a inline element, then patch attached is the minimal one. In html FormMacroLibrary (macros renderDateTimeField, renderRadioField, renderDateFindField and renderLookupField) - DIV changed to SPAN - Removed UL and LI because UL is a block element and LI must be inside a list. (As Adrian says in his comment) In themes CSS files - Styles corrected to match the changes. (display changed from block to inline-block and alignment changed to maintain the vertical position) Is this OK for you ? Fields should be defined with span not div. (radio, date, lookup) - Key: OFBIZ-3708 URL: https://issues.apache.org/jira/browse/OFBIZ-3708 Project: OFBiz Issue Type: Bug Components: framework Affects Versions: SVN trunk Reporter: Blas Rodriguez Somoza Priority: Minor Fix For: SVN trunk Attachments: CAL_bizznesstime_after.jpg, CAL_bizznesstime_before.jpg, CAL_bluelight_after.jpg, CAL_bluelight_before.jpg, CAL_droppingcrumbs_after.jpg, CAL_droppingcrumbs_before.jpg, CAL_flatgrey_after.jpg, CAL_flatgrey_before.jpg, CAL_tomahawk_after.jpg, CAL_tomahawk_before.jpg, LOOKUP_CAL_bizznesstime_after.jpg, LOOKUP_CAL_bizznesstime_before.jpg, LOOKUP_CAL_bluelight_after.jpg, LOOKUP_CAL_bluelight_before.jpg, LOOKUP_CAL_droppingcrumbs_after.jpg, LOOKUP_CAL_droppingcrumbs_before.jpg, LOOKUP_CAL_flatgrey_after.jpg, LOOKUP_CAL_flatgrey_before.jpg, LOOKUP_CAL_tomahawk_after.jpg, LOOKUP_CAL_tomahawk_before.jpg, OFBIZ-3708_framework_divspan.diff Field markup should be a valid inline element. Defining fields with div (block) instead of span (inline) creates several problems: - Missalignments in screen. (See LOOKUP_CAL screenshots) - Implies a end-of-line after the div. (See CAL screenshots) - If used inside inline elements which should be OK, becames XHTML validation errors. (Manufacturing - MRP - MRP log) Because this is a markup problem, it spans to all the themes. This patch contains 2 files in the framework/widget area and 5 in the themes area. Because the source of the problem is in the framework/widget area, I opt to assign the bug to the framework area. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: [jira] Commented: (OFBIZ-3708) Fields should be defined with span not div. (radio, date, lookup)
Adam Heath (JIRA) wrote: [ https://issues.apache.org/jira/browse/OFBIZ-3708?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12858258#action_12858258 ] Adam Heath commented on OFBIZ-3708: --- Yes. I'm a happy little butterfly, flapping my wings, causing eddies in the air, which ripple upward, affecting incoming cosmic rays, that deflect to your hard-drive, causing your code to magically be to my liking. http://xkcd.com/378/
Re: ServiceXaWrapper is very very stupid and broken
Are on the same page here, as it were? It sounds your conclusion is the same
as my understanding, ie by the time it triggers these things either the commit
is already done or the rollback is already done (or at least the first phase of
them is done), and so it doesn't make sense to try to participate in the same
transaction. Is that what you're saying?
I'm wondering now what would happen if you did try to use the existing
transaction... my guess is that whether it was a commit or rollback the
transaction would not be in a state that would allow additional operations, so
you'd probably get an invalid state exception. Just guessing though, I haven't
actually tried it or looked at the docs to see if they say.
-David
On Apr 16, 2010, at 4:21 PM, Adam Heath wrote:
David E Jones wrote:
It sounds like everything is as it should be. Maybe you just had incorrect
assumptions about how this was supposed to work? In other words, is it
possible the problem isn't with the design? I don't know about the code, I
won't comment on that.
In any case, are you saying that if something is triggered by an already
established commit or rollback that a service triggered by it should be able
to modify that somehow? What would be the point of trying to work in the
context of a transaction that is already in the process of being committed
(I think this happens between phases 1 and 2 of a 2-phase commit, if I
remember right) or rolled back? Wouldn't it be a bad idea to do anything
with that transaction?
As fun as writing is, it's amazing how much more productive reading can be.
// Example code
boolean wasBad = false;
TransactionUtil.begin()
try {
CheckOutHelper.createOrder()
wasBad = ServicEUtil.isError(CheckOutHelper.processPayment());
} catch (Throwable t) {
wasBad = true;
} finally {
if (wasBad) {
TransactionUtil.rollback();
} else {
TransactionUtil.commit();
}
}
// GenericAbstractDispatcher:
// shows that the async flag is hard-coded to true.
public void addRollbackService(String serviceName, MapString, ?
extends Object context, boolean persist) throws GenericServiceException {
ServiceXaWrapper xa = new
ServiceXaWrapper(this.getDispatchContext());
xa.setRollbackService(serviceName, context, true, persist);
try {
xa.enlist();
} catch (XAException e) {
Debug.logError(e, module);
throw new GenericServiceException(e.getMessage(), e);
}
}
processPayment registers a rollback service, to unapply any payments.
This registration sets the persist flag to true. The context map of
that registration mentions an OrderPaymentPreference that was created
during the transaction.
GenericAbstractDispatcher, which is responsible for actually creating
a ServiceXaWrapper instance, will always make ServiceXaWrapper run the
registered service in async mode. This is a hard-coded boolean true.
Since all registered commit/rollback services are always in async
mode, there are 2 paths that they could end up taking. If the service
is persisted, it'll be saved to JobSandbox, and fetched from the job
poller with a slight delay. Or, the service could be submitted to the
job poller immediately, and then still processed slightly later, in
the case of the thread pool being busy. In either event, the service
is always run async.
In the given example, persist is true, and async is always
true(hard-coded), so the passed context will be serialized to disk.
When deserialized, it'll try to refresh a
value(OrderPaymentPreference) from the entity engine, but that fails,
as the original value got rolled back. Since the async service
failed, a retry is scheduled, again thru JobSandbox, and this failing
service continues on forever attempting to process something that will
never succeed.
With the rollback/commit event calls in ServiceXaWrapper creating
temporary new threads, there is no chance at all for them to see any
data that was altered by the parent transaction in the parent thread.
Plus, since the brand new child thread suspends the existing
transaction and creates a new one, again, there's no way for the
rollback/commit service to see any of the parent's data.
Are the rollback/comment callbacks in ServiceXaWrapper called before
or after the transaction has been rolled back or committed?
Ok, I'm answering my own question. The JTA spec says that enlisted
resources are run inside the parent transaction. This means that they
are allowed to see any data that was manipulated by the parent
transaction. However, in the ServiceXaWrapper case, this is not
happening. First, the internal runService helper method is in a
separate child thread. Secondly, the child thread creates brand new
transaction anyways, so the called service has no chance of seeing any
of it's parents data.
All this is fine in the
[jira] Commented: (OFBIZ-1968) Enrich Groovy integration with Ofbiz framework
[
https://issues.apache.org/jira/browse/OFBIZ-1968?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12858261#action_12858261
]
Scott Gray commented on OFBIZ-1968:
---
Here's an example I can actually get to work for building entity expressions:
{code}
entityCondition = expression.AND() {
equals (productId: 12345),
in (productId: [1, 2, 3, 4]),
like (productId: 1234%),
OR() {
equals (productId: 54321),
between (productId: [0, 1, 2, 3, 4, 5])
}
}
{code}
Any thoughts?
Enrich Groovy integration with Ofbiz framework
--
Key: OFBIZ-1968
URL: https://issues.apache.org/jira/browse/OFBIZ-1968
Project: OFBiz
Issue Type: Improvement
Components: framework
Reporter: Anil K Patel
Priority: Minor
Enrich Groovy integration with Ofbiz framework in order to bring goodies of
Minilang to Groovy scripts. Start with simple things like use
findByPrimaryKey in groovy scripts without having to prefix it with delegator
and then automatically find values for primary key fields from environment if
they are not explicitly passed in the call. Later other similar goodies of
minilang can be added.
Use Groovy to add DSL where possible.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
https://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
