Sorry forget it, I was wrong, I did the type=Timestamp removing in the
wrong screen !
So yes I was able to reproduce the problem with Timestamp.
Not sure why ViewFacilityInventoryItemsDetails works on this new installation
though :/
Jacques
From: Jacques Le Roux [EMAIL PROTECTED]
Hi Scott,
I suppose it was a problem with my Postgres installation since with a new Postgres 8.3 installation
ViewFacilityInventoryItemsDetails works.
I also wondered why nobody was complaining about this issue but me.
I think we can forget it, as the changes I done (suggested by Adrian) are
harmless
Are you actually getting any results displayed? I doesn't work on
mine but the error only shows up in the logs...
Thanks
Scott
2008/10/14 Jacques Le Roux [EMAIL PROTECTED]:
Sorry forget it, I was wrong, I did the type=Timestamp removing in the
wrong screen !
So yes I was able to reproduce
Done
Jacques
From: Jacques Le Roux [EMAIL PROTECTED]
Thanks Jacopo,
I think I will make a FAQ for that...
Jacques
From: Jacopo Cappellato [EMAIL PROTECTED]
On Sep 30, 2008, at 5:28 AM, Hans Bakker wrote:
Hi Jacopo,
the point below is very important, does it mean the ledger posting is
I get this on screen
org.ofbiz.widget.screen.ScreenRenderException: Error rendering screen
[component://marketing/widget/MarketingReportScreens.xml#MarketingCampaignReport]: org.ofbiz.base.util.GeneralException: Error
running Groovy script at location
How did you resolve the import issues with org.ofbiz.order.shoppingcart package
?
I guess it's the reason while it's not done OOTB in
CommonEvents.setSessionCurrencyUom
Jacques
From: Abhishake Agarwal [EMAIL PROTECTED]
Hi,
I have one more query related to this,
Suppose I changed currency
The userPrefGroupId field on UserPrefGroupType should be userPrefGroupTypeId,
as per conventions
-
Key: OFBIZ-1996
URL:
[
https://issues.apache.org/jira/browse/OFBIZ-1996?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ravindra Mandre updated OFBIZ-1996:
---
Attachment: UserPrefGroupTypeId.patch
Patch is uploaded with corresponding changes.
The
Thanks Jacques for interest.
Please find the patch at https://issues.apache.org/jira/browse/OFBIZ-1996
, as it has framework files and I do not have rights.
- Vikas
On Oct 12, 2008, at 9:57 PM, Jacques Le Roux wrote:
+1 (64 occurences in code, ie *.bsh, *.ftl, *.gro*, *.java, *.xml)
[
https://issues.apache.org/jira/browse/OFBIZ-1232?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jacques Le Roux updated OFBIZ-1232:
---
Attachment: filter_views.patch
Better version with generic and fix a bug I introduced. If
Hi Vikas,
Did not look into detail yet, but did you think about any needs to fill
http://docs.ofbiz.org/display/OFBTECH/Upgrading+OFBiz+from+earlier+revisions ?
Jacques
From: Vikas Mayur [EMAIL PROTECTED]
Thanks Jacques for interest.
Please find the patch at
I think it would be good to document such change.
- Vikas
On Oct 13, 2008, at 8:36 PM, Jacques Le Roux wrote:
Hi Vikas,
Did not look into detail yet, but did you think about any needs to
fill http://docs.ofbiz.org/display/OFBTECH/Upgrading+OFBiz+from+earlier+revisions
?
Jacques
From:
Hi Scott,
I just commited a bug fix (typo) for MarketingCampaignReport.groovy in r704013.
It's an easy way to try with Timestamp.
If you remove type=Timestamp from lines
set field=fromDate from-field=requestParameters.fromDate
type=Timestamp/
set field=thruDate
I was able to reproduce the problem here (with timestamps I haven't
tried doubles) on a fresh install, could you please double check that
it's working?
Thanks
Scott
2008/10/13 Jacques Le Roux [EMAIL PROTECTED]:
I suppose it was a problem with my Postgres installation since with a new
Postgres
Yes, you are right.
https://localhost:8443/facility/control/ViewFacilityInventoryItemsDetails works with postgres 8.2.9
Maybe it even comes from my own Postgres 8.3 installation. I will try with a new one.
Thanks
Jacques
From: Scott Gray [EMAIL PROTECTED]
Hi Jacques
I really don't think it
Hi Jacques,
Actually all our code resides in hot-deploy, when ever we require change in
any of the files, we copy the file to hot-deploy desired path, so I haven't
faced any import issues.
Regards,
Abhishake
On Mon, Oct 13, 2008 at 7:13 PM, Jacques Le Roux
[EMAIL PROTECTED] wrote:
How did
Yes this makes sense indeed
But to avoid such confusion, please use rather user ML. The dev ML is about
developing OFBiz OOTB, not using it.
This is explained here
http://docs.ofbiz.org/display/OFBADMIN/Mailing+Lists#MailingLists-DeveloperList:dev@ofbiz.apache.org
Thanks
Jacques
From:
This has been a potential problem for a while, but the decision was
made quite a while back to not enforce the correct object type.
There is code in the GenericEntity.java file (lines 410-415) to check
to see if the value passed in matches the object type for the field it
is being set
I would prefer handling object types in higher level code - due to
ambiguity in how some types would be converted from a String (currency,
date, time, etc).
-Adrian
David E Jones wrote:
This has been a potential problem for a while, but the decision was made
quite a while back to not
That is a very good point, and I agree.
To me that means we go with the fail-fast approach and have it throw
an exception if you pass in something that is not the correct object
type.
Is that what you meant?
-David
On Oct 13, 2008, at 4:57 PM, Adrian Crum wrote:
I would prefer
I'm referring to the exception I described in the GenericEntity.java
file, lines 410-415. Right now it is just a warning in the log (and
has been for years). The reason to do it there instead of letting the
JDBC driver do it is that not all developers will test on all possible
databases,
I understood your alternatives. I apologize for being unclear.
You said, or to just throw an exception when the wrong data type is
passed like the commented out code in GenericEntity referenced above does.
And I'm saying we could do that, but it's going to get interesting
because a lot of
Here's the problem as I see it:
Postgresql used to allow you to specify parameter types which did not
match the column type, in the timestamp case if you passed in a
parameter specified as varchar it would automatically attempt to
convert it to a timestamp. Now Postgresql requires that you either
Scott, are you referring to the call to PreparedStatement.setString on
SQLProcessor line 553? In other words, the difference in the Postgres
JDBC driver is that they used to auto-convert from a String to
whatever the database needs in the setString method, but now they don't?
What I'm
Inline:
2008/10/14 David E Jones [EMAIL PROTECTED]:
Scott, are you referring to the call to PreparedStatement.setString on
SQLProcessor line 553? In other words, the difference in the Postgres JDBC
driver is that they used to auto-convert from a String to whatever the
database needs in the
25 matches
Mail list logo
