Re: duplicate transaction ids for authorized.net
Hi Adam, Though this is not directly related to the problem that you are facing, but i think it makes sense to add this here in case someone picks up to amend the code. Credit card processing has another problem when we have multiple items in an order and a given item has to cancelled. For eg. if there are 2 items in an order, say X is costing $60 and Y is costing $40. When the order is placed, an authorization of $100 is made but if say later when the order is processed and X is to be shipped while Y is to be cancelled, ofbiz correctly charges the credit card $60, but at the same time makes another authorization for $40 for the item Y which is cancelled and would not be processed or shipped. This happens in spite of the order being marked as 'Completed'. I think its a completely redundant and un-necessary authorization, and also the business ends up paying additional authorization fees. I think a Jira issue, can be opened for this. If this is not a bug, i guess it sure does not make any business logic. Please let me know your comments. Thanks, Rohit - http://www.saanjhi.com saanjhi.com -- View this message in context: http://ofbiz.135035.n4.nabble.com/duplicate-transaction-ids-for-authorized-net-tp3079207p3079679.html Sent from the OFBiz - Dev mailing list archive at Nabble.com.
[jira] Commented: (OFBIZ-4032) There are issues whit search in eCommerce
[ https://issues.apache.org/jira/browse/OFBIZ-4032?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12969653#action_12969653 ] Jacques Le Roux commented on OFBIZ-4032: Thanks Scott, I still get the same error > There are issues whit search in eCommerce > - > > Key: OFBIZ-4032 > URL: https://issues.apache.org/jira/browse/OFBIZ-4032 > Project: OFBiz > Issue Type: Bug > Components: specialpurpose/ecommerce >Affects Versions: Release Branch 10.04, jQuery, SVN trunk >Reporter: Jacques Le Roux > > Try gz-1000 or "gift card" and follow [this comment from > OFBIZ-3789|https://issues.apache.org/jira/browse/OFBIZ-3789?focusedCommentId=12910997&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#action_12910997] > (last one) > I guess it's also an issue for R10.04 (I did not try) R9.04 seems OK -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: svn commit: r1042542 - in /ofbiz/trunk/applications: accounting/src/org/ofbiz/accounting/tax/ order/data/ order/entitydef/ order/src/org/ofbiz/order/order/ product/entitydef/ product/script/org/of
Great! Thanks David Jacques From: "David E Jones" On Dec 8, 2010, at 2:22 PM, Jacques Le Roux wrote: From: "David E Jones" On Dec 7, 2010, at 11:58 PM, Jacques Le Roux wrote: From: "David E Jones" On Dec 7, 2010, at 3:39 AM, Jacques Le Roux wrote: If there are no plans to prevent the use of the new fields for the other types Price Types than Default, I'd like latter to add a small js script to handle it. Of course being able to use it with Price Rules and Promo would be great. Why would we want to prevent using these fields for other price types? I thought only the Default Price is really using VAT included price. So to prevent users thinking they can use VAT included price with other price types. Any price could, and should if applicable, have tax authority settings and have VAT tax included. Does this means that Price Rules and Promo work with Gross Prices? That's actually the main point of doing things this way, ie to properly and accurately support all of these various features that OFBiz does OOTB. -David
Re: findByAnd(Map) ws findList(EntityCondition)
On 9/12/2010, at 11:50 AM, Adam Heath wrote:
> On 12/08/2010 03:00 PM, Scott Gray wrote:
>> On 8/12/2010, at 4:29 AM, Adam Heath wrote:
>>
>>> I've deprecated findByAnd locally, replacing calls with a variant that
>>> takes a boolean, which specifies whether to use the cache.
>>>
>>> Initially, my replacement just added a new findByAnd. However, I'm
>>> now starting to lean towards replacing with findList instead.
>>> However, in my opinion, I think that will make programming ofbiz more
>>> difficult.
>>>
>>> I'd like to add a findList variant, that takes a Map instead of an
>>> EntityCondition. Without this new variant, there would be ton of
>>> variants that would only need to import EntityCondition, just to
>>> create a condition.
>>>
>>> There are also performance considerations to consider.
>>>
>>> EntityCondition.makeCondition(Map) directly takes the map, doing no
>>> processing. However, EntityCondition.makeCondition(Object...)
>>> eventually calls EntityUtil.makeFields, which does a little more than
>>> UtilMisc. In addition to the iteration over the array, it also does a
>>> check on the value for Comparable/Serializable. This latter check
>>> seems a bit superfluous, as eventually the base condition classes
>>> check the values against the model.
>>>
>>> So, from a purist stand point, even tho findByAnd could be replaced by
>>> findList, I think it is too useful; it saves enough code in
>>> application layers, imho.
>>>
>>
>> This reminded me of the query objects with method chaining that I suggested
>> a while back so I threw them together this morning.
>>
>> Here are some examples:
>> thisContent = delegator.findByPrimaryKeyCache("Content",
>> UtilMisc.toMap("contentId", assocContentId));
>> // becomes
>> thisContent = EntityOne.query(delegator).from("Content").where("contentId",
>> assocContentId).cache().find();
>
> api:
> EntityOne(delegator).from()
>
> in foo.groovy:
> use(DelegatorCategory) {
>
> }
>
> class DelegatorCategory {
> public static EntityOneBuilder EntityOne(Delegator delegator) {
>return new EntityOneBuilder(delegator);
> }
> }
> class EntityOneBuilder {
> public EntityOneBuilder from(String entityName) {
>return this;
> }
>
> public GenericValue query() {
>return delegator.findOne();
> }
> }
>
> This is almost like what you suggested, but it removes the query() method
> that starts thte builder, and changes the find() to query().
>
> EntityList would be done the same one.
>
> The way you have it, is that the start(EntityOne, EntityList) and the
> end(find(), list()), are 2 things that have to be remembered. My version
> just has one thing(the start of the call).
This is all groovy DSL related though right? I hadn't worried about groovy too
much because I knew we had a fair bit of flexibility thanks to the language
features. The API I've written to date was solely intended for java
development but seems succinct enough that not much would need to change for
groovy.
Also EntityList's execute methods so far are:
list()
iterator()
first()
count()
I'm trying to cover everything the delegator does for SELECTs and a bit of the
more common EntityUtil methods within those two Entity* classes. With some
good javadocs I think it will work pretty well.
Regards
Scott
smime.p7s
Description: S/MIME cryptographic signature
[jira] Created: (OFBIZ-4049) Bug in service 'discVirtualsWithDiscVariants'
Bug in service 'discVirtualsWithDiscVariants' - Key: OFBIZ-4049 URL: https://issues.apache.org/jira/browse/OFBIZ-4049 Project: OFBiz Issue Type: Bug Components: product Affects Versions: Release Branch 10.04, jQuery, SVN trunk Reporter: Atul Vani Fix For: Release Branch 10.04, jQuery, SVN trunk Attachments: discVirtualsWithDiscVariantsBugFix.patch There's a bug in service 'discVirtualsWithDiscVariants'. The service has got no code to set discontinuation date in database for virtual product. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (OFBIZ-4049) Bug in service 'discVirtualsWithDiscVariants'
[ https://issues.apache.org/jira/browse/OFBIZ-4049?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Atul Vani updated OFBIZ-4049: - Attachment: discVirtualsWithDiscVariantsBugFix.patch Patch for the fix attached. > Bug in service 'discVirtualsWithDiscVariants' > - > > Key: OFBIZ-4049 > URL: https://issues.apache.org/jira/browse/OFBIZ-4049 > Project: OFBiz > Issue Type: Bug > Components: product >Affects Versions: Release Branch 10.04, jQuery, SVN trunk >Reporter: Atul Vani > Fix For: Release Branch 10.04, jQuery, SVN trunk > > Attachments: discVirtualsWithDiscVariantsBugFix.patch > > > There's a bug in service 'discVirtualsWithDiscVariants'. The service has got > no code to set discontinuation date in database for virtual product. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (OFBIZ-4041) Materialized views
[ https://issues.apache.org/jira/browse/OFBIZ-4041?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12969573#action_12969573 ] Marc Morin commented on OFBIZ-4041: --- Adam, are you commenting on the materialized view problem vs the bulk operations? Either way, both use the same logic of cascading possible operations to dependent model items (either in the cache) or materlalized views. If you look at the patch, the materialized views use the EXACT same ModelConversion information that the cache uses to propage, but instead of clearing values, it clears and rebuilds. > Materialized views > -- > > Key: OFBIZ-4041 > URL: https://issues.apache.org/jira/browse/OFBIZ-4041 > Project: OFBiz > Issue Type: New Feature > Components: framework >Affects Versions: Release Branch 10.04 >Reporter: Marc Morin > Attachments: OFBIZ-4041.patch > > > We make extensive use of view entities in our ofbiz application. We have > noticed that when there is a large dataset and under some complex views, the > query performance was not the best (not a index issue, just complex joins, > etc...). > With some commercial databases like Oracle, etc... we would have used > materialized view semantics available for these dbms, but we are using > PostgreSQL. > So, we have extended the entity layer in Ofbiz to perform the > materialization. This is pretty slick as all you need to do is the following: > ... > and the system will do the following: > - create a backing entity called "myView" that has the same fields as the view > - backing entity has all the indexes inherited from the component entities > - relations (fk,...) inherited from the component entities. > - perform all the ECA actions automatically on all entities used in the view > (direct members and nested members if case of view on views). (This is an > eager update strategy only). > So, the application doesn't change, it still accesses "myView", but now, it's > result is returned from the backing entity instead of the complex SQL > statement. > We're pretty excited about this feature!!! Really pushes Ofbiz framework to > next level and allows materialized views to be more broadly used on dbms that > don't naturally support it. > We are prepared to contribute this feature back to the community if desired. > A note of caution about it though we have added a visitor pattern to the > model entities and this feature makes use of it. It would need to come with > it. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: findByAnd(Map) ws findList(EntityCondition)
On 12/08/2010 03:00 PM, Scott Gray wrote:
On 8/12/2010, at 4:29 AM, Adam Heath wrote:
I've deprecated findByAnd locally, replacing calls with a variant that
takes a boolean, which specifies whether to use the cache.
Initially, my replacement just added a new findByAnd. However, I'm
now starting to lean towards replacing with findList instead.
However, in my opinion, I think that will make programming ofbiz more
difficult.
I'd like to add a findList variant, that takes a Map instead of an
EntityCondition. Without this new variant, there would be ton of
variants that would only need to import EntityCondition, just to
create a condition.
There are also performance considerations to consider.
EntityCondition.makeCondition(Map) directly takes the map, doing no
processing. However, EntityCondition.makeCondition(Object...)
eventually calls EntityUtil.makeFields, which does a little more than
UtilMisc. In addition to the iteration over the array, it also does a
check on the value for Comparable/Serializable. This latter check
seems a bit superfluous, as eventually the base condition classes
check the values against the model.
So, from a purist stand point, even tho findByAnd could be replaced by
findList, I think it is too useful; it saves enough code in
application layers, imho.
This reminded me of the query objects with method chaining that I suggested a
while back so I threw them together this morning.
Here are some examples:
thisContent = delegator.findByPrimaryKeyCache("Content",
UtilMisc.toMap("contentId", assocContentId));
// becomes
thisContent = EntityOne.query(delegator).from("Content").where("contentId",
assocContentId).cache().find();
api:
EntityOne(delegator).from()
in foo.groovy:
use(DelegatorCategory) {
}
class DelegatorCategory {
public static EntityOneBuilder EntityOne(Delegator delegator) {
return new EntityOneBuilder(delegator);
}
}
class EntityOneBuilder {
public EntityOneBuilder from(String entityName) {
return this;
}
public GenericValue query() {
return delegator.findOne();
}
}
This is almost like what you suggested, but it removes the query()
method that starts thte builder, and changes the find() to query().
EntityList would be done the same one.
The way you have it, is that the start(EntityOne, EntityList) and the
end(find(), list()), are 2 things that have to be remembered. My
version just has one thing(the start of the call).
List productNodesList = delegator.findByAndCache("ProductAssoc",
UtilMisc.toMap("productIdTo", productId, "productAssocTypeId", bomType));
productNodesList = EntityUtil.filterByDate(productNodesList, inDate);
// becomes
List productNodesList =
EntityList.query(delegator).from("ProductAssoc").where("productIdTo", productId,
"productAssocTypeId", bomType).cache().filterByDate().list();
List inventoryItems = delegator.findByAnd("InventoryItem", ecl,
null, null, null, false);
// becomes
List inventoryItems =
EntityList.query(delegator).from("InventoryItem").where(ecl).list();
// all this (long winded example)
EntityFindOptions efo = new EntityFindOptions();
efo.setDistinct(true);
efo.setResultSetType(EntityFindOptions.TYPE_SCROLL_INSENSITIVE);
if (maxResults != null) {
efo.setMaxRows(maxResults);
}
eli = delegator.findListIteratorByCondition(dynamicViewEntity, whereCondition,
null, fieldsToSelect, orderByList, efo);
// becomes
eli =
EntityList.query(delegator).from(dynamicViewEntity).where(whereCondition).select(fieldsToSelect).orderBy(orderByList).distinct().cursorScrollInsensitive().maxRows(maxResults).iterator();
They aren't necessarily shorter, but they are easier to write, easier to read
and would be easier to remember (for things like groovy).
Regards
Scott
HotWax Media
http://www.hotwaxmedia.com
Re: svn commit: r1042542 - in /ofbiz/trunk/applications: accounting/src/org/ofbiz/accounting/tax/ order/data/ order/entitydef/ order/src/org/ofbiz/order/order/ product/entitydef/ product/script/org/of
On Dec 8, 2010, at 2:22 PM, Jacques Le Roux wrote: > From: "David E Jones" >> On Dec 7, 2010, at 11:58 PM, Jacques Le Roux wrote: >> >>> From: "David E Jones" On Dec 7, 2010, at 3:39 AM, Jacques Le Roux wrote: > If there are no plans to prevent the use of the new fields for the other > types Price Types than Default, I'd like latter to add > a small js script to handle it. Of course being able to use it with Price > Rules and Promo would be great. Why would we want to prevent using these fields for other price types? >>> >>> I thought only the Default Price is really using VAT included price. So to >>> prevent users thinking they can use VAT included price >>> with other price types. >> >> Any price could, and should if applicable, have tax authority settings and >> have VAT tax included. > > Does this means that Price Rules and Promo work with Gross Prices? That's actually the main point of doing things this way, ie to properly and accurately support all of these various features that OFBiz does OOTB. -David
Re: svn commit: r1042542 - in /ofbiz/trunk/applications: accounting/src/org/ofbiz/accounting/tax/ order/data/ order/entitydef/ order/src/org/ofbiz/order/order/ product/entitydef/ product/script/org/of
From: "David E Jones"
On Dec 7, 2010, at 11:58 PM, Jacques Le Roux wrote:
From: "David E Jones"
On Dec 7, 2010, at 3:39 AM, Jacques Le Roux wrote:
If there are no plans to prevent the use of the new fields for the other types
Price Types than Default, I'd like latter to add
a small js script to handle it. Of course being able to use it with Price Rules
and Promo would be great.
Why would we want to prevent using these fields for other price types?
I thought only the Default Price is really using VAT included price. So to
prevent users thinking they can use VAT included price
with other price types.
Any price could, and should if applicable, have tax authority settings and have
VAT tax included.
Does this means that Price Rules and Promo work with Gross Prices?
Also what for is used taxAuthCombinedId? I don't see an use at the UI level.
With a combined ID you can select the tax authority in a drop-down instead of
forcing the user to handle two separate fields
that are not correlated, making the UI significantly more cumbersome and
difficult to use.
Yes but then I think we need to expose a bit more how to enter a combined ID, I
will add a tooltip somewhere in the screen
A user wouldn't generally enter the combined ID manually, that would be a bad
UI. The combined ID is just meant to be the ID in a
drop-down (or perhaps a lookup).
OK, we need to amend the OOTB UI anyway
BTW, thanks for this improvement David, I believe it's really a good base for next step. I mean I really prefer that it's you, who
already designed and wrote the Tax Auth stuff, who wrote this new part!
Jacques
-David
From: "David E Jones"
I commented before that my previous efforts only made calculations more
accurate, and those efforts made it clear that the
only way to be sure is to calculate things based on prices with tax included.
So, now OFBiz has low-level support for prices with tax included and
calculating VAT instead of sales tax with adjustments
that represent amounts already included in the prices.
Note that this does not include any UI changes, and so unless changes are done
to allow entry of prices with tax included and
to show the VAT_TAX adjustments (specifically the new amountAlreadyIncluded
field, which was added so that it wouldn't
interfere with the current amount field).
-David
On Dec 6, 2010, at 8:39 AM, Jacques Le Roux wrote:
Hi David,
Interesting, what decided you to finally shift your ground?
Is it still true that only Default Price can be used, and if yes is there any
blocking reasons?
Thanks
Jacques
From:
Author: jonesde
Date: Mon Dec 6 08:05:44 2010
New Revision: 1042542
URL: http://svn.apache.org/viewvc?rev=1042542&view=rev
Log:
Implemented alternative way of saving ProductPrices with tax included in the
price, and then calculating VAT tax as an
exclusive instead of inclusive amount that goes on a new field on
OrderAdjustment; also added a method to OrderReadHelper to
get tax for display; there are various changes to service descriptions and
entity fields to describe these changes
Modified:
ofbiz/trunk/applications/accounting/src/org/ofbiz/accounting/tax/TaxAuthorityServices.java
ofbiz/trunk/applications/order/data/OrderTypeData.xml
ofbiz/trunk/applications/order/entitydef/entitymodel.xml
ofbiz/trunk/applications/order/src/org/ofbiz/order/order/OrderReadHelper.java
ofbiz/trunk/applications/product/entitydef/entitymodel.xml
ofbiz/trunk/applications/product/script/org/ofbiz/product/price/PriceServices.xml
ofbiz/trunk/applications/product/servicedef/services.xml
Modified:
ofbiz/trunk/applications/accounting/src/org/ofbiz/accounting/tax/TaxAuthorityServices.java
URL:
http://svn.apache.org/viewvc/ofbiz/trunk/applications/accounting/src/org/ofbiz/accounting/tax/TaxAuthorityServices.java?rev=1042542&r1=1042541&r2=1042542&view=diff
==
---
ofbiz/trunk/applications/accounting/src/org/ofbiz/accounting/tax/TaxAuthorityServices.java
(original)
+++
ofbiz/trunk/applications/accounting/src/org/ofbiz/accounting/tax/TaxAuthorityServices.java
Mon Dec 6 08:05:44 2010
@@ -391,11 +391,38 @@ public class TaxAuthorityServices {
// TODO: what to do if no TaxAuthorityGlAccount found? Use
some default, or is that done elsewhere later
on?
}
+GenericValue productPrice = null;
+if (product != null && taxAuthPartyId != null && taxAuthGeoId
!= null) {
+// find a ProductPrice for the productId and taxAuth*
valxues, and see if it has a priceWithTax value
+Map priceFindMap = UtilMisc.toMap("productId",
product.getString("productId"),
+"taxAuthPartyId", taxAuthPartyId, "taxAuthGeoId",
taxAuthGeoId,
+"productPriceTypeId", "DEFAULT_PRICE",
"productPricePurposeId", "PURCHASE");
+List productPriceList =
delegator.find
[jira] Closed: (OFBIZ-4010) Keyword Search & Last Search Display shows incomplete encoded element
[ https://issues.apache.org/jira/browse/OFBIZ-4010?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jacques Le Roux closed OFBIZ-4010. -- Resolution: Duplicate Assignee: Jacques Le Roux OFBIZ-4042 was a duplicate > Keyword Search & Last Search Display shows incomplete encoded element > - > > Key: OFBIZ-4010 > URL: https://issues.apache.org/jira/browse/OFBIZ-4010 > Project: OFBiz > Issue Type: Bug > Components: specialpurpose/ecommerce >Affects Versions: Release Branch 09.04, Release Branch 10.04, SVN trunk > Environment: irrelevant; issue on FTL >Reporter: Carsten Schinzer >Assignee: Jacques Le Roux >Priority: Minor > Fix For: Release Branch 09.04, Release Branch 10.04, SVN trunk > > Original Estimate: 0.5h > Remaining Estimate: 0.5h > > On the keyword search result page, the search refinement options show an > "nbsp;" text which indicates an incomplete " " HTML element. > Further, the wording of related UI Lables will be reviewed as they seem > wierd (at least in German local). -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: [jira] Commented: (OFBIZ-4048) Demo Data fails to load
From: "Adam Heath" On 12/08/2010 09:32 AM, Scott Gray (JIRA) wrote: [ https://issues.apache.org/jira/browse/OFBIZ-4048?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12969344#action_12969344 ] Scott Gray commented on OFBIZ-4048: --- Hi Georg, That in itself is actually a bug, it should always be possible to remove a special purpose component and still have the rest of the system function correctly. Replying in list first: ebay/ebaystore components need to be resolved. They weren't both supposed to stay around this long. Hans, please fix this. ++1 Jacques PS: but we already know praying doesn't help in such cases (there are others I mean) Regards Scott Demo Data fails to load --- Key: OFBIZ-4048 URL: https://issues.apache.org/jira/browse/OFBIZ-4048 Project: OFBiz Issue Type: Bug Components: specialpurpose/ecommerce Affects Versions: Release Branch 10.04, SVN trunk Environment: Windows XP Reporter: Georg Koester Original Estimate: 0.5h Remaining Estimate: 0.5h Foreign key violation PROD_CTGRY_TYPE on 15064. Checking DemoProduct.xml it looks quite obvious: https://fisheye6.atlassian.com/browse/ofbiz/trunk/specialpurpose/ecommerce/data/DemoProduct.xml?r=1040914#l260 eBay_Category and eBay_ECom_Category share the same categoryName. One of them looks superfluous, but further down a rollup is defined integrating both of them. ashish committed all of this, maybe he can validate the basic correctness of this all? I'll do some more testing and provide a patch if I get to something. I checked and it looks the same in trunk.
Re: findByAnd(Map) ws findList(EntityCondition)
I like the chaining stuff, I have always loved function composition, in
computing also
Jacques
From: "Adrian Crum"
Anything that makes Java/Groovy more fluent will get a big +1 from me.
-Adrian
On 12/8/2010 1:00 PM, Scott Gray wrote:
On 8/12/2010, at 4:29 AM, Adam Heath wrote:
I've deprecated findByAnd locally, replacing calls with a variant that
takes a boolean, which specifies whether to use the cache.
Initially, my replacement just added a new findByAnd. However, I'm
now starting to lean towards replacing with findList instead.
However, in my opinion, I think that will make programming ofbiz more
difficult.
I'd like to add a findList variant, that takes a Map instead of an
EntityCondition. Without this new variant, there would be ton of
variants that would only need to import EntityCondition, just to
create a condition.
There are also performance considerations to consider.
EntityCondition.makeCondition(Map) directly takes the map, doing no
processing. However, EntityCondition.makeCondition(Object...)
eventually calls EntityUtil.makeFields, which does a little more than
UtilMisc. In addition to the iteration over the array, it also does a
check on the value for Comparable/Serializable. This latter check
seems a bit superfluous, as eventually the base condition classes
check the values against the model.
So, from a purist stand point, even tho findByAnd could be replaced by
findList, I think it is too useful; it saves enough code in
application layers, imho.
This reminded me of the query objects with method chaining that I suggested a
while back so I threw them together this morning.
Here are some examples:
thisContent = delegator.findByPrimaryKeyCache("Content",
UtilMisc.toMap("contentId", assocContentId));
// becomes
thisContent = EntityOne.query(delegator).from("Content").where("contentId",
assocContentId).cache().find();
List productNodesList = delegator.findByAndCache("ProductAssoc", UtilMisc.toMap("productIdTo", productId, "productAssocTypeId",
bomType));
productNodesList = EntityUtil.filterByDate(productNodesList, inDate);
// becomes
List productNodesList = EntityList.query(delegator).from("ProductAssoc").where("productIdTo", productId, "productAssocTypeId",
bomType).cache().filterByDate().list();
List inventoryItems = delegator.findByAnd("InventoryItem", ecl,
null, null, null, false);
// becomes
List inventoryItems =
EntityList.query(delegator).from("InventoryItem").where(ecl).list();
// all this (long winded example)
EntityFindOptions efo = new EntityFindOptions();
efo.setDistinct(true);
efo.setResultSetType(EntityFindOptions.TYPE_SCROLL_INSENSITIVE);
if (maxResults != null) {
efo.setMaxRows(maxResults);
}
eli = delegator.findListIteratorByCondition(dynamicViewEntity, whereCondition,
null, fieldsToSelect, orderByList, efo);
// becomes
eli =
EntityList.query(delegator).from(dynamicViewEntity).where(whereCondition).select(fieldsToSelect).orderBy(orderByList).distinct().cursorScrollInsensitive().maxRows(maxResults).iterator();
They aren't necessarily shorter, but they are easier to write, easier to read and would be easier to remember (for things like
groovy).
Regards
Scott
HotWax Media
http://www.hotwaxmedia.com
duplicate transaction ids for authorized.net
We recently had some payments get rejected by authorized.net. The ofbiz install in this situation allows for multiple ship groups. The duplicate detection code on the authorized.net side checks the credit card info, plus payment amount, and if they match, rejects the request, saying it is a duplicate. The issue here, is the grandmother situation. A grandmother could buy 5 copies of a book, or a sweater, or something, and send them to her 5 grandchildren. This will cause 5 payment method requests, all identical, to occur. If separate AUTH/CAPTURE methods are used, the AUTH will succeed, a transaction refnum will be returned, and the final CAPTURE will also succeed. However, when the combined AUTH_CAPTURE is used, there is no intermediate transaction refnum, so this duplicate error shows up. Adding a x_duplicate_window=0 is the suggested fix(as returned by the google), but that disables the security feature, so I don't know if it is correct. Is there a better way for this to be fixed? Maybe ofbiz should aggregate all payments requests that can be issued at the same time. Maybe it could have a request falloff algorithm, that is per-credit card(or other classification), to support not hitting the processor so quickly. Or maybe something else. I plan on committing x_duplicate_window=0 into the buildAuthTransaction method of AIMPaymentServices in the next few days, unless others speak up with alternative plans of action.
Re: svn commit: r1042542 - in /ofbiz/trunk/applications: accounting/src/org/ofbiz/accounting/tax/ order/data/ order/entitydef/ order/src/org/ofbiz/order/order/ product/entitydef/ product/script/org/of
On Dec 7, 2010, at 11:58 PM, Jacques Le Roux wrote:
> From: "David E Jones"
>> On Dec 7, 2010, at 3:39 AM, Jacques Le Roux wrote:
>>
>>> If there are no plans to prevent the use of the new fields for the other
>>> types Price Types than Default, I'd like latter to add a small js script to
>>> handle it. Of course being able to use it with Price Rules and Promo would
>>> be great.
>>
>> Why would we want to prevent using these fields for other price types?
>
> I thought only the Default Price is really using VAT included price. So to
> prevent users thinking they can use VAT included price with other price types.
Any price could, and should if applicable, have tax authority settings and have
VAT tax included.
>>> Also what for is used taxAuthCombinedId? I don't see an use at the UI level.
>>
>> With a combined ID you can select the tax authority in a drop-down instead
>> of forcing the user to handle two separate fields that are not correlated,
>> making the UI significantly more cumbersome and difficult to use.
>
> Yes but then I think we need to expose a bit more how to enter a combined ID,
> I will add a tooltip somewhere in the screen
A user wouldn't generally enter the combined ID manually, that would be a bad
UI. The combined ID is just meant to be the ID in a drop-down (or perhaps a
lookup).
-David
>>
>>> From: "David E Jones"
I commented before that my previous efforts only made calculations more
accurate, and those efforts made it clear that the only way to be sure is
to calculate things based on prices with tax included.
So, now OFBiz has low-level support for prices with tax included and
calculating VAT instead of sales tax with adjustments that represent
amounts already included in the prices.
Note that this does not include any UI changes, and so unless changes are
done to allow entry of prices with tax included and to show the VAT_TAX
adjustments (specifically the new amountAlreadyIncluded field, which was
added so that it wouldn't interfere with the current amount field).
-David
On Dec 6, 2010, at 8:39 AM, Jacques Le Roux wrote:
> Hi David,
>
> Interesting, what decided you to finally shift your ground?
>
> Is it still true that only Default Price can be used, and if yes is there
> any blocking reasons?
>
> Thanks
>
> Jacques
>
> From:
>> Author: jonesde
>> Date: Mon Dec 6 08:05:44 2010
>> New Revision: 1042542
>>
>> URL: http://svn.apache.org/viewvc?rev=1042542&view=rev
>> Log:
>> Implemented alternative way of saving ProductPrices with tax included in
>> the price, and then calculating VAT tax as an exclusive instead of
>> inclusive amount that goes on a new field on OrderAdjustment; also added
>> a method to OrderReadHelper to get tax for display; there are various
>> changes to service descriptions and entity fields to describe these
>> changes
>>
>> Modified:
>> ofbiz/trunk/applications/accounting/src/org/ofbiz/accounting/tax/TaxAuthorityServices.java
>> ofbiz/trunk/applications/order/data/OrderTypeData.xml
>> ofbiz/trunk/applications/order/entitydef/entitymodel.xml
>> ofbiz/trunk/applications/order/src/org/ofbiz/order/order/OrderReadHelper.java
>> ofbiz/trunk/applications/product/entitydef/entitymodel.xml
>> ofbiz/trunk/applications/product/script/org/ofbiz/product/price/PriceServices.xml
>> ofbiz/trunk/applications/product/servicedef/services.xml
>>
>> Modified:
>> ofbiz/trunk/applications/accounting/src/org/ofbiz/accounting/tax/TaxAuthorityServices.java
>> URL:
>> http://svn.apache.org/viewvc/ofbiz/trunk/applications/accounting/src/org/ofbiz/accounting/tax/TaxAuthorityServices.java?rev=1042542&r1=1042541&r2=1042542&view=diff
>> ==
>> ---
>> ofbiz/trunk/applications/accounting/src/org/ofbiz/accounting/tax/TaxAuthorityServices.java
>> (original)
>> +++
>> ofbiz/trunk/applications/accounting/src/org/ofbiz/accounting/tax/TaxAuthorityServices.java
>> Mon Dec 6 08:05:44 2010
>> @@ -391,11 +391,38 @@ public class TaxAuthorityServices {
>> // TODO: what to do if no TaxAuthorityGlAccount found?
>> Use some default, or is that done elsewhere later on?
>> }
>>
>> +GenericValue productPrice = null;
>> +if (product != null && taxAuthPartyId != null &&
>> taxAuthGeoId != null) {
>> +// find a ProductPrice for the productId and
>> taxAuth* valxues, and see if it has a priceWithTax value
>> +Map priceFindMap =
>> UtilMisc.toMap("productId", product.getString("productId"),
>> +"taxAuthPartyId", taxAuthPartyId,
>>
Re: findByAnd(Map) ws findList(EntityCondition)
Anything that makes Java/Groovy more fluent will get a big +1 from me.
-Adrian
On 12/8/2010 1:00 PM, Scott Gray wrote:
On 8/12/2010, at 4:29 AM, Adam Heath wrote:
I've deprecated findByAnd locally, replacing calls with a variant that
takes a boolean, which specifies whether to use the cache.
Initially, my replacement just added a new findByAnd. However, I'm
now starting to lean towards replacing with findList instead.
However, in my opinion, I think that will make programming ofbiz more
difficult.
I'd like to add a findList variant, that takes a Map instead of an
EntityCondition. Without this new variant, there would be ton of
variants that would only need to import EntityCondition, just to
create a condition.
There are also performance considerations to consider.
EntityCondition.makeCondition(Map) directly takes the map, doing no
processing. However, EntityCondition.makeCondition(Object...)
eventually calls EntityUtil.makeFields, which does a little more than
UtilMisc. In addition to the iteration over the array, it also does a
check on the value for Comparable/Serializable. This latter check
seems a bit superfluous, as eventually the base condition classes
check the values against the model.
So, from a purist stand point, even tho findByAnd could be replaced by
findList, I think it is too useful; it saves enough code in
application layers, imho.
This reminded me of the query objects with method chaining that I suggested a
while back so I threw them together this morning.
Here are some examples:
thisContent = delegator.findByPrimaryKeyCache("Content",
UtilMisc.toMap("contentId", assocContentId));
// becomes
thisContent = EntityOne.query(delegator).from("Content").where("contentId",
assocContentId).cache().find();
List productNodesList = delegator.findByAndCache("ProductAssoc",
UtilMisc.toMap("productIdTo", productId, "productAssocTypeId", bomType));
productNodesList = EntityUtil.filterByDate(productNodesList, inDate);
// becomes
List productNodesList =
EntityList.query(delegator).from("ProductAssoc").where("productIdTo", productId,
"productAssocTypeId", bomType).cache().filterByDate().list();
List inventoryItems = delegator.findByAnd("InventoryItem", ecl,
null, null, null, false);
// becomes
List inventoryItems =
EntityList.query(delegator).from("InventoryItem").where(ecl).list();
// all this (long winded example)
EntityFindOptions efo = new EntityFindOptions();
efo.setDistinct(true);
efo.setResultSetType(EntityFindOptions.TYPE_SCROLL_INSENSITIVE);
if (maxResults != null) {
efo.setMaxRows(maxResults);
}
eli = delegator.findListIteratorByCondition(dynamicViewEntity, whereCondition,
null, fieldsToSelect, orderByList, efo);
// becomes
eli =
EntityList.query(delegator).from(dynamicViewEntity).where(whereCondition).select(fieldsToSelect).orderBy(orderByList).distinct().cursorScrollInsensitive().maxRows(maxResults).iterator();
They aren't necessarily shorter, but they are easier to write, easier to read
and would be easier to remember (for things like groovy).
Regards
Scott
HotWax Media
http://www.hotwaxmedia.com
[jira] Commented: (OFBIZ-4041) Materialized views
[ https://issues.apache.org/jira/browse/OFBIZ-4041?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12969490#action_12969490 ] Adam Heath commented on OFBIZ-4041: --- The view caching system I wrote has support for that kind of access; a map of values can have a 'partial' match on cached view result lists, which then up causing the cached result to be cleared. This seems to be the same kind of thing. > Materialized views > -- > > Key: OFBIZ-4041 > URL: https://issues.apache.org/jira/browse/OFBIZ-4041 > Project: OFBiz > Issue Type: New Feature > Components: framework >Affects Versions: Release Branch 10.04 >Reporter: Marc Morin > Attachments: OFBIZ-4041.patch > > > We make extensive use of view entities in our ofbiz application. We have > noticed that when there is a large dataset and under some complex views, the > query performance was not the best (not a index issue, just complex joins, > etc...). > With some commercial databases like Oracle, etc... we would have used > materialized view semantics available for these dbms, but we are using > PostgreSQL. > So, we have extended the entity layer in Ofbiz to perform the > materialization. This is pretty slick as all you need to do is the following: > ... > and the system will do the following: > - create a backing entity called "myView" that has the same fields as the view > - backing entity has all the indexes inherited from the component entities > - relations (fk,...) inherited from the component entities. > - perform all the ECA actions automatically on all entities used in the view > (direct members and nested members if case of view on views). (This is an > eager update strategy only). > So, the application doesn't change, it still accesses "myView", but now, it's > result is returned from the backing entity instead of the complex SQL > statement. > We're pretty excited about this feature!!! Really pushes Ofbiz framework to > next level and allows materialized views to be more broadly used on dbms that > don't naturally support it. > We are prepared to contribute this feature back to the community if desired. > A note of caution about it though we have added a visitor pattern to the > model entities and this feature makes use of it. It would need to come with > it. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: findByAnd(Map) ws findList(EntityCondition)
On 8/12/2010, at 4:29 AM, Adam Heath wrote:
> I've deprecated findByAnd locally, replacing calls with a variant that
> takes a boolean, which specifies whether to use the cache.
>
> Initially, my replacement just added a new findByAnd. However, I'm
> now starting to lean towards replacing with findList instead.
> However, in my opinion, I think that will make programming ofbiz more
> difficult.
>
> I'd like to add a findList variant, that takes a Map instead of an
> EntityCondition. Without this new variant, there would be ton of
> variants that would only need to import EntityCondition, just to
> create a condition.
>
> There are also performance considerations to consider.
>
> EntityCondition.makeCondition(Map) directly takes the map, doing no
> processing. However, EntityCondition.makeCondition(Object...)
> eventually calls EntityUtil.makeFields, which does a little more than
> UtilMisc. In addition to the iteration over the array, it also does a
> check on the value for Comparable/Serializable. This latter check
> seems a bit superfluous, as eventually the base condition classes
> check the values against the model.
>
> So, from a purist stand point, even tho findByAnd could be replaced by
> findList, I think it is too useful; it saves enough code in
> application layers, imho.
>
This reminded me of the query objects with method chaining that I suggested a
while back so I threw them together this morning.
Here are some examples:
thisContent = delegator.findByPrimaryKeyCache("Content",
UtilMisc.toMap("contentId", assocContentId));
// becomes
thisContent = EntityOne.query(delegator).from("Content").where("contentId",
assocContentId).cache().find();
List productNodesList = delegator.findByAndCache("ProductAssoc",
UtilMisc.toMap("productIdTo", productId, "productAssocTypeId", bomType));
productNodesList = EntityUtil.filterByDate(productNodesList, inDate);
// becomes
List productNodesList =
EntityList.query(delegator).from("ProductAssoc").where("productIdTo",
productId, "productAssocTypeId", bomType).cache().filterByDate().list();
List inventoryItems = delegator.findByAnd("InventoryItem", ecl,
null, null, null, false);
// becomes
List inventoryItems =
EntityList.query(delegator).from("InventoryItem").where(ecl).list();
// all this (long winded example)
EntityFindOptions efo = new EntityFindOptions();
efo.setDistinct(true);
efo.setResultSetType(EntityFindOptions.TYPE_SCROLL_INSENSITIVE);
if (maxResults != null) {
efo.setMaxRows(maxResults);
}
eli = delegator.findListIteratorByCondition(dynamicViewEntity, whereCondition,
null, fieldsToSelect, orderByList, efo);
// becomes
eli =
EntityList.query(delegator).from(dynamicViewEntity).where(whereCondition).select(fieldsToSelect).orderBy(orderByList).distinct().cursorScrollInsensitive().maxRows(maxResults).iterator();
They aren't necessarily shorter, but they are easier to write, easier to read
and would be easier to remember (for things like groovy).
Regards
Scott
HotWax Media
http://www.hotwaxmedia.com
smime.p7s
Description: S/MIME cryptographic signature
[jira] Commented: (OFBIZ-4041) Materialized views
[ https://issues.apache.org/jira/browse/OFBIZ-4041?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12969444#action_12969444 ] Scott Gray commented on OFBIZ-4041: --- Hi Adam, Perhaps you misunderstand, when I say "bulk" what I mean is that a single SQL query affects multiple rows in the database. There is no way to hook ECAs into this type of query, the only solution would be to perform a select and then update/remove each row individually. > Materialized views > -- > > Key: OFBIZ-4041 > URL: https://issues.apache.org/jira/browse/OFBIZ-4041 > Project: OFBiz > Issue Type: New Feature > Components: framework >Affects Versions: Release Branch 10.04 >Reporter: Marc Morin > Attachments: OFBIZ-4041.patch > > > We make extensive use of view entities in our ofbiz application. We have > noticed that when there is a large dataset and under some complex views, the > query performance was not the best (not a index issue, just complex joins, > etc...). > With some commercial databases like Oracle, etc... we would have used > materialized view semantics available for these dbms, but we are using > PostgreSQL. > So, we have extended the entity layer in Ofbiz to perform the > materialization. This is pretty slick as all you need to do is the following: > ... > and the system will do the following: > - create a backing entity called "myView" that has the same fields as the view > - backing entity has all the indexes inherited from the component entities > - relations (fk,...) inherited from the component entities. > - perform all the ECA actions automatically on all entities used in the view > (direct members and nested members if case of view on views). (This is an > eager update strategy only). > So, the application doesn't change, it still accesses "myView", but now, it's > result is returned from the backing entity instead of the complex SQL > statement. > We're pretty excited about this feature!!! Really pushes Ofbiz framework to > next level and allows materialized views to be more broadly used on dbms that > don't naturally support it. > We are prepared to contribute this feature back to the community if desired. > A note of caution about it though we have added a visitor pattern to the > model entities and this feature makes use of it. It would need to come with > it. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (OFBIZ-4041) Materialized views
[ https://issues.apache.org/jira/browse/OFBIZ-4041?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12969419#action_12969419 ] Adam Heath commented on OFBIZ-4041: --- Hmm. There are some things in the delegator that are direct api calls. findOne, delee, update. Then there are other things that are used to reduce code in the applications; the so-called bulk operations. This latter set of code should not have any ecas connected to them, ever. Instead, the bulk operations should just call the lower-level methods, which then would have the ecas attached to them. Maybe the bulk operations should be moved to a DelegatorHelper or Worker class. > Materialized views > -- > > Key: OFBIZ-4041 > URL: https://issues.apache.org/jira/browse/OFBIZ-4041 > Project: OFBiz > Issue Type: New Feature > Components: framework >Affects Versions: Release Branch 10.04 >Reporter: Marc Morin > Attachments: OFBIZ-4041.patch > > > We make extensive use of view entities in our ofbiz application. We have > noticed that when there is a large dataset and under some complex views, the > query performance was not the best (not a index issue, just complex joins, > etc...). > With some commercial databases like Oracle, etc... we would have used > materialized view semantics available for these dbms, but we are using > PostgreSQL. > So, we have extended the entity layer in Ofbiz to perform the > materialization. This is pretty slick as all you need to do is the following: > ... > and the system will do the following: > - create a backing entity called "myView" that has the same fields as the view > - backing entity has all the indexes inherited from the component entities > - relations (fk,...) inherited from the component entities. > - perform all the ECA actions automatically on all entities used in the view > (direct members and nested members if case of view on views). (This is an > eager update strategy only). > So, the application doesn't change, it still accesses "myView", but now, it's > result is returned from the backing entity instead of the complex SQL > statement. > We're pretty excited about this feature!!! Really pushes Ofbiz framework to > next level and allows materialized views to be more broadly used on dbms that > don't naturally support it. > We are prepared to contribute this feature back to the community if desired. > A note of caution about it though we have added a visitor pattern to the > model entities and this feature makes use of it. It would need to come with > it. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (OFBIZ-4041) Materialized views
[ https://issues.apache.org/jira/browse/OFBIZ-4041?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12969414#action_12969414 ] Marc Morin commented on OFBIZ-4041: --- Good point Scott. We have "removed" the bulk operations in our implementation for specifically that reason... We've noticed that even though these are bulk operations, they don't appear to be from an API point of view. There isn't much to help guide the developer that using these API's will circumvent all ECA activity We had thought about only doing the bulk operation iff there are no ECAs defined for the entity and operation defined. Otherwise, leave it as bulk. But that too would appear to be dangerous since there are unknown side affects of not running the ECA. Not sure what the best/good compromise is for the bulk vs normal operation is. Just seems incorrect to bypass the ECA. Not that "disabling" the eca via the entityengine.xml also causes the materialized views to not always maintaining it's results. > Materialized views > -- > > Key: OFBIZ-4041 > URL: https://issues.apache.org/jira/browse/OFBIZ-4041 > Project: OFBiz > Issue Type: New Feature > Components: framework >Affects Versions: Release Branch 10.04 >Reporter: Marc Morin > Attachments: OFBIZ-4041.patch > > > We make extensive use of view entities in our ofbiz application. We have > noticed that when there is a large dataset and under some complex views, the > query performance was not the best (not a index issue, just complex joins, > etc...). > With some commercial databases like Oracle, etc... we would have used > materialized view semantics available for these dbms, but we are using > PostgreSQL. > So, we have extended the entity layer in Ofbiz to perform the > materialization. This is pretty slick as all you need to do is the following: > ... > and the system will do the following: > - create a backing entity called "myView" that has the same fields as the view > - backing entity has all the indexes inherited from the component entities > - relations (fk,...) inherited from the component entities. > - perform all the ECA actions automatically on all entities used in the view > (direct members and nested members if case of view on views). (This is an > eager update strategy only). > So, the application doesn't change, it still accesses "myView", but now, it's > result is returned from the backing entity instead of the complex SQL > statement. > We're pretty excited about this feature!!! Really pushes Ofbiz framework to > next level and allows materialized views to be more broadly used on dbms that > don't naturally support it. > We are prepared to contribute this feature back to the community if desired. > A note of caution about it though we have added a visitor pattern to the > model entities and this feature makes use of it. It would need to come with > it. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (OFBIZ-4000) JMSListener starts in two threads - receive JMS message twice
[ https://issues.apache.org/jira/browse/OFBIZ-4000?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12969408#action_12969408 ] Scott Gray commented on OFBIZ-4000: --- oh and getInstance should probably be synchronized > JMSListener starts in two threads - receive JMS message twice > - > > Key: OFBIZ-4000 > URL: https://issues.apache.org/jira/browse/OFBIZ-4000 > Project: OFBiz > Issue Type: Bug > Components: ALL APPLICATIONS >Affects Versions: SVN trunk >Reporter: Sascha Rodekamp > Fix For: SVN trunk > > Attachments: OFBIZ-4000_JmsListenerFactory.java.patch > > > Hi, > i noticed that the JMS Listener starts in two threads, the result is that > ofbiz received every JMS message twice. Creating the object with singleton > procedure should help. > Have a nice day > Sascha -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (OFBIZ-4000) JMSListener starts in two threads - receive JMS message twice
[ https://issues.apache.org/jira/browse/OFBIZ-4000?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12969403#action_12969403 ] Scott Gray commented on OFBIZ-4000: --- Hi Sascha, I don't think we want a singleton here but instead we need one (and only one) instance per dispatcher. > JMSListener starts in two threads - receive JMS message twice > - > > Key: OFBIZ-4000 > URL: https://issues.apache.org/jira/browse/OFBIZ-4000 > Project: OFBiz > Issue Type: Bug > Components: ALL APPLICATIONS >Affects Versions: SVN trunk >Reporter: Sascha Rodekamp > Fix For: SVN trunk > > Attachments: OFBIZ-4000_JmsListenerFactory.java.patch > > > Hi, > i noticed that the JMS Listener starts in two threads, the result is that > ofbiz received every JMS message twice. Creating the object with singleton > procedure should help. > Have a nice day > Sascha -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (OFBIZ-4010) Keyword Search & Last Search Display shows incomplete encoded element
[ https://issues.apache.org/jira/browse/OFBIZ-4010?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12969402#action_12969402 ] Scott Gray commented on OFBIZ-4010: --- Hi Carsten, I can't see the nbsp on first glance, could you provide some steps to reproduce and be more specific about where the text is located? > Keyword Search & Last Search Display shows incomplete encoded element > - > > Key: OFBIZ-4010 > URL: https://issues.apache.org/jira/browse/OFBIZ-4010 > Project: OFBiz > Issue Type: Bug > Components: specialpurpose/ecommerce >Affects Versions: Release Branch 09.04, Release Branch 10.04, SVN trunk > Environment: irrelevant; issue on FTL >Reporter: Carsten Schinzer >Priority: Minor > Fix For: Release Branch 09.04, Release Branch 10.04, SVN trunk > > Original Estimate: 0.5h > Remaining Estimate: 0.5h > > On the keyword search result page, the search refinement options show an > "nbsp;" text which indicates an incomplete " " HTML element. > Further, the wording of related UI Lables will be reviewed as they seem > wierd (at least in German local). -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Issue Comment Edited: (OFBIZ-3814) jQuery Implementtion - Umbrella Main Task
[ https://issues.apache.org/jira/browse/OFBIZ-3814?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12903420#action_12903420 ] Sascha Rodekamp edited comment on OFBIZ-3814 at 12/8/10 1:02 PM: - # Outstanding jQuery Transformations # Hey everybody, i like to give you a short update, what we have done in our jQuery migration project so far and which tasks are still pending. Maybe someone have time to take the one or other point! 1.) -js Files in Order Modul- 2.) -Framework / common / JavaScriptTests- 3.) -HTML Editor (we have to discuss which one we should use)- 4.) -specialpurpose / ecommerce (Ankit started to migrate the OnePageCheckout process)- 5.) -specialpurpose / ofbizwebsite- 6.) -specialpurpose / webpos- 7.) -Update all Themes- 8.) -Delete all old javascript libraries and plugins (prototype and dojo)- I hope i don't forget any tasks. Cheers -- Edit: The most things are done :-) was (Author: sascha): # Outstanding jQuery Transformations # Hey everybody, i like to give you a short update, what we have done in our jQuery migration project so far and which tasks are still pending. Maybe someone have time to take the one or other point! 1.) -js Files in Order Modul- 2.) -Framework / common / JavaScriptTests- 3.) HTML Editor (we have to discuss which one we should use) 4.) -specialpurpose / ecommerce (Ankit started to migrate the OnePageCheckout process)- 5.) -specialpurpose / ofbizwebsite- 6.) -specialpurpose / webpos- 7.) -Update all Themes- 8.) Delete all old javascript libraries and plugins (prototype and dojo) I hope i don't forget any tasks. Cheers -- Edit: The most things are done :-) > jQuery Implementtion - Umbrella Main Task > - > > Key: OFBIZ-3814 > URL: https://issues.apache.org/jira/browse/OFBIZ-3814 > Project: OFBiz > Issue Type: New Feature > Components: ALL COMPONENTS >Reporter: Sascha Rodekamp >Assignee: Erwan de FERRIERES > Fix For: jQuery > > > This task is to group the related sub-tasks. > We plan to replace all prototype/ dojo based javascript Code with jQuery > based code. > For this task a special development branch exists: jquery. > It will be merged into the trunk after all problems/issue are solved. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (OFBIZ-4030) We need to replace all references to whizzywig.js
[ https://issues.apache.org/jira/browse/OFBIZ-4030?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sascha Rodekamp updated OFBIZ-4030: --- Attachment: OFBIZ-4030_WysiwygEditorReplaced.patch Hey Jacques, as promised here the new editor patch. I fixed the editor on the location you mentioned and searched for all visual-editor calls in the xml forms. Works like a charm :-) Cheers and have a good evening Sascha > We need to replace all references to whizzywig.js > - > > Key: OFBIZ-4030 > URL: https://issues.apache.org/jira/browse/OFBIZ-4030 > Project: OFBiz > Issue Type: Sub-task >Reporter: Jacques Le Roux >Assignee: Jacques Le Roux > Attachments: OFBIZ-4030_WysiwygEditorReplaced.patch, > OFBIZ-4030_WysiwygEditorReplaced.patch > > -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (OFBIZ-4032) There are issues whit search in eCommerce
[ https://issues.apache.org/jira/browse/OFBIZ-4032?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12969396#action_12969396 ] Scott Gray commented on OFBIZ-4032: --- Hi Jacques, could you try to reproduce this again at some point? I recently committed a fix for a very similar search issue. I think this one may need a different fix but it is worth trying first. > There are issues whit search in eCommerce > - > > Key: OFBIZ-4032 > URL: https://issues.apache.org/jira/browse/OFBIZ-4032 > Project: OFBiz > Issue Type: Bug > Components: specialpurpose/ecommerce >Affects Versions: Release Branch 10.04, jQuery, SVN trunk >Reporter: Jacques Le Roux > > Try gz-1000 or "gift card" and follow [this comment from > OFBIZ-3789|https://issues.apache.org/jira/browse/OFBIZ-3789?focusedCommentId=12910997&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#action_12910997] > (last one) > I guess it's also an issue for R10.04 (I did not try) R9.04 seems OK -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (OFBIZ-4041) Materialized views
[ https://issues.apache.org/jira/browse/OFBIZ-4041?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12969373#action_12969373 ] Scott Gray commented on OFBIZ-4041: --- It's worth noting that GenericDelegator.storeByCondition(...) and GenericDelegator.removeByCondition(...) currently do not trigger ECAs because they are bulk operations. Just mentioning it because the ramifications could be a bit more significant for a feature such as ECA-dependent materialized views. > Materialized views > -- > > Key: OFBIZ-4041 > URL: https://issues.apache.org/jira/browse/OFBIZ-4041 > Project: OFBiz > Issue Type: New Feature > Components: framework >Affects Versions: Release Branch 10.04 >Reporter: Marc Morin > Attachments: OFBIZ-4041.patch > > > We make extensive use of view entities in our ofbiz application. We have > noticed that when there is a large dataset and under some complex views, the > query performance was not the best (not a index issue, just complex joins, > etc...). > With some commercial databases like Oracle, etc... we would have used > materialized view semantics available for these dbms, but we are using > PostgreSQL. > So, we have extended the entity layer in Ofbiz to perform the > materialization. This is pretty slick as all you need to do is the following: > ... > and the system will do the following: > - create a backing entity called "myView" that has the same fields as the view > - backing entity has all the indexes inherited from the component entities > - relations (fk,...) inherited from the component entities. > - perform all the ECA actions automatically on all entities used in the view > (direct members and nested members if case of view on views). (This is an > eager update strategy only). > So, the application doesn't change, it still accesses "myView", but now, it's > result is returned from the backing entity instead of the complex SQL > statement. > We're pretty excited about this feature!!! Really pushes Ofbiz framework to > next level and allows materialized views to be more broadly used on dbms that > don't naturally support it. > We are prepared to contribute this feature back to the community if desired. > A note of caution about it though we have added a visitor pattern to the > model entities and this feature makes use of it. It would need to come with > it. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: [jira] Commented: (OFBIZ-4048) Demo Data fails to load
On 12/08/2010 09:32 AM, Scott Gray (JIRA) wrote: [ https://issues.apache.org/jira/browse/OFBIZ-4048?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12969344#action_12969344 ] Scott Gray commented on OFBIZ-4048: --- Hi Georg, That in itself is actually a bug, it should always be possible to remove a special purpose component and still have the rest of the system function correctly. Replying in list first: ebay/ebaystore components need to be resolved. They weren't both supposed to stay around this long. Hans, please fix this. Regards Scott Demo Data fails to load --- Key: OFBIZ-4048 URL: https://issues.apache.org/jira/browse/OFBIZ-4048 Project: OFBiz Issue Type: Bug Components: specialpurpose/ecommerce Affects Versions: Release Branch 10.04, SVN trunk Environment: Windows XP Reporter: Georg Koester Original Estimate: 0.5h Remaining Estimate: 0.5h Foreign key violation PROD_CTGRY_TYPE on 15064. Checking DemoProduct.xml it looks quite obvious: https://fisheye6.atlassian.com/browse/ofbiz/trunk/specialpurpose/ecommerce/data/DemoProduct.xml?r=1040914#l260 eBay_Category and eBay_ECom_Category share the same categoryName. One of them looks superfluous, but further down a rollup is defined integrating both of them. ashish committed all of this, maybe he can validate the basic correctness of this all? I'll do some more testing and provide a patch if I get to something. I checked and it looks the same in trunk.
[jira] Commented: (OFBIZ-4048) Demo Data fails to load
[ https://issues.apache.org/jira/browse/OFBIZ-4048?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12969344#action_12969344 ] Scott Gray commented on OFBIZ-4048: --- Hi Georg, That in itself is actually a bug, it should always be possible to remove a special purpose component and still have the rest of the system function correctly. Regards Scott > Demo Data fails to load > --- > > Key: OFBIZ-4048 > URL: https://issues.apache.org/jira/browse/OFBIZ-4048 > Project: OFBiz > Issue Type: Bug > Components: specialpurpose/ecommerce >Affects Versions: Release Branch 10.04, SVN trunk > Environment: Windows XP >Reporter: Georg Koester > Original Estimate: 0.5h > Remaining Estimate: 0.5h > > Foreign key violation PROD_CTGRY_TYPE on 15064. > Checking DemoProduct.xml it looks quite obvious: > https://fisheye6.atlassian.com/browse/ofbiz/trunk/specialpurpose/ecommerce/data/DemoProduct.xml?r=1040914#l260 > eBay_Category and eBay_ECom_Category share the same categoryName. > One of them looks superfluous, but further down a rollup is defined > integrating both of them. > ashish committed all of this, maybe he can validate the basic correctness of > this all? > I'll do some more testing and provide a patch if I get to something. > I checked and it looks the same in trunk. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (OFBIZ-4048) Demo Data fails to load
[ https://issues.apache.org/jira/browse/OFBIZ-4048?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Georg Koester closed OFBIZ-4048. Resolution: Invalid Too fast: This just happened because I disabled the Ebay component - on which data the DemoProduct data was relying. Sorry! On the other hand I still don't quite understand how the two product categories can have the same names... > Demo Data fails to load > --- > > Key: OFBIZ-4048 > URL: https://issues.apache.org/jira/browse/OFBIZ-4048 > Project: OFBiz > Issue Type: Bug > Components: specialpurpose/ecommerce >Affects Versions: Release Branch 10.04, SVN trunk > Environment: Windows XP >Reporter: Georg Koester > Original Estimate: 0.5h > Remaining Estimate: 0.5h > > Foreign key violation PROD_CTGRY_TYPE on 15064. > Checking DemoProduct.xml it looks quite obvious: > https://fisheye6.atlassian.com/browse/ofbiz/trunk/specialpurpose/ecommerce/data/DemoProduct.xml?r=1040914#l260 > eBay_Category and eBay_ECom_Category share the same categoryName. > One of them looks superfluous, but further down a rollup is defined > integrating both of them. > ashish committed all of this, maybe he can validate the basic correctness of > this all? > I'll do some more testing and provide a patch if I get to something. > I checked and it looks the same in trunk. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (OFBIZ-4048) Demo Data fails to load
Demo Data fails to load --- Key: OFBIZ-4048 URL: https://issues.apache.org/jira/browse/OFBIZ-4048 Project: OFBiz Issue Type: Bug Components: specialpurpose/ecommerce Affects Versions: Release Branch 10.04, SVN trunk Environment: Windows XP Reporter: Georg Koester Foreign key violation PROD_CTGRY_TYPE on 15064. Checking DemoProduct.xml it looks quite obvious: https://fisheye6.atlassian.com/browse/ofbiz/trunk/specialpurpose/ecommerce/data/DemoProduct.xml?r=1040914#l260 eBay_Category and eBay_ECom_Category share the same categoryName. One of them looks superfluous, but further down a rollup is defined integrating both of them. ashish committed all of this, maybe he can validate the basic correctness of this all? I'll do some more testing and provide a patch if I get to something. I checked and it looks the same in trunk. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
