[jira] [Commented] (OFBIZ-4379) Get first from list tag in screen's and form's action tag.
[ https://issues.apache.org/jira/browse/OFBIZ-4379?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13092927#comment-13092927 ] David E. Jones commented on OFBIZ-4379: --- Why not just use the [] syntax to get the first element? In other words, something like: > Get first from list tag in screen's and form's action tag. > -- > > Key: OFBIZ-4379 > URL: https://issues.apache.org/jira/browse/OFBIZ-4379 > Project: OFBiz > Issue Type: New Feature > Components: framework >Affects Versions: Release 10.04, SVN trunk >Reporter: Ankit Jain >Priority: Minor > Fix For: Release Branch 10.04, SVN trunk > > > In most of the cases we need to get first record from a list in screen and > form widgets then we have to do something like this: > for eg: > > Instead of using like this my idea is to add a tag like in > Screen & Form widget's action tag, so one can easily get first record from a > list. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (OFBIZ-4346) Support MySQL and Postgres's LIMIT and OFFSET options
[
https://issues.apache.org/jira/browse/OFBIZ-4346?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13068996#comment-13068996
]
David E. Jones commented on OFBIZ-4346:
---
The concern of the attribute is not so much if limit/offset are allowed, if
they are not supported the JDBC driver will eventually throw an exception.
The attribute would be used to configure the SQL syntax variation for the
offset/limit concept. The attribute might look something like:
{code}
{code}
The code for the SQL syntax options might look like:
{code}
if (databaseNode."@offset-style" == "limit") {
// use the LIMIT/OFFSET style
this.sqlTopLevel.append(" LIMIT ").append(limit ?: "ALL")
this.sqlTopLevel.append(" OFFSET ").append(offset ?: 0)
} else {
// use SQL2008 OFFSET/FETCH style by default
if (offset != null) this.sqlTopLevel.append(" OFFSET
").append(offset).append(" ROWS")
if (limit != null) this.sqlTopLevel.append(" FETCH FIRST
").append(limit).append(" ROWS ONLY")
}
{code}
This is how I would have implemented it in OFBiz, demonstrated by the fact that
this is how I implemented it Moqui.
> Support MySQL and Postgres's LIMIT and OFFSET options
> -
>
> Key: OFBIZ-4346
> URL: https://issues.apache.org/jira/browse/OFBIZ-4346
> Project: OFBiz
> Issue Type: Improvement
> Components: framework
>Affects Versions: SVN trunk
>Reporter: Shi Jinghai
>Priority: Minor
> Attachments: mysql_postgres_limit_offset_trunk.patch
>
>
> Two helper classes are added for MySQL and Postgres to support LIMIT and
> OFFSET options.
> These classes can be configured in entityengine.xml:
> helper-class="org.ofbiz.entity.datasource.postgres.PostgresHelperDAO" for
> Postgres
> and
> helper-class="org.ofbiz.entity.datasource.mysql.MysqlHelperDAO" for MySQL.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (OFBIZ-4346) Support MySQL and Postgres's LIMIT and OFFSET options
[ https://issues.apache.org/jira/browse/OFBIZ-4346?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13068828#comment-13068828 ] David E. Jones commented on OFBIZ-4346: --- Adding a class per database is not the preferred way to handle SQL variations (you'll notice that OOTB there are no such things for the entity engine). The better approach is to change the existing code to support the different syntax variations, and add an attribute to the datasource element in the entityengine.xml file so that the proper variation can be chosen for each database. That is how all current syntax variations are configured and coded. > Support MySQL and Postgres's LIMIT and OFFSET options > - > > Key: OFBIZ-4346 > URL: https://issues.apache.org/jira/browse/OFBIZ-4346 > Project: OFBiz > Issue Type: Improvement > Components: framework >Affects Versions: SVN trunk >Reporter: Shi Jinghai >Priority: Minor > Attachments: mysql_postgres_limit_offset_trunk.patch > > > Two helper classes are added for MySQL and Postgres to support LIMIT and > OFFSET options. > These classes can be configured in entityengine.xml: > helper-class="org.ofbiz.entity.datasource.postgres.PostgresHelperDAO" for > Postgres > and > helper-class="org.ofbiz.entity.datasource.mysql.MysqlHelperDAO" for MySQL. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (OFBIZ-4326) VAT Correction for ProductPrice that has priceWithTax =N is not correct (with patch)
[ https://issues.apache.org/jira/browse/OFBIZ-4326?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13056577#comment-13056577 ] David E. Jones commented on OFBIZ-4326: --- Stéphane, What is it you are trying to accomplish? I can tell you for sure that there is no reliable way to get an even number as desired when the ProductPrice amount does not include tax (ie it is stored in the database with tax excluded). I worked on this over the course of a few weeks last year for a client making little tweaks here and there to improve the accuracy and precision of the numbers, but there are ALWAYS edge cases, and we came up with a few that were simply not possible to accommodate when the ProductPrice did not have taxes included, it's simply not possible when working with only 3 decimal digits. The only solution is to store price with tax included, and calculate the tax based on the amount with tax included. In other words, the only way it will be mathematically correct is to follow the formulas dictated by most VAT/IVA/etc law. This is a REAL pain, but does work. OFBiz supports this OOTB in the trunk and the 11.04 release branch. The tax adjustments have an amountAlreadyIncluded of the tax amount, and the normal adjustment amount is always 0 so that you know how much the tax is, but you don't mess up the total by adding it in again. > VAT Correction for ProductPrice that has priceWithTax =N is not correct (with > patch) > > > Key: OFBIZ-4326 > URL: https://issues.apache.org/jira/browse/OFBIZ-4326 > Project: OFBiz > Issue Type: Bug > Components: accounting >Affects Versions: SVN trunk >Reporter: Stéphane DUCAS >Priority: Minor > Attachments: OFBIZ-4326_round_price_in_cart.patch, > vatCorrection.patch, vatCorrection_2.patch, vatCorrection_2.patch > > > The VAT correction adjustment is not correct because it's based on the price > not rounded (while tax adjustment is calculated from the rounded price). > I provide the patch for that. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (OFBIZ-4316) Widget $() escapes HTML. StringUtil.wrapString(contentText) throw an error
[
https://issues.apache.org/jira/browse/OFBIZ-4316?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13050907#comment-13050907
]
David E. Jones commented on OFBIZ-4316:
---
When FreeMarker says that an expression "is undefined" if often means that the
expression evaluated to null.
If you don't want FreeMarker to blow up like this for null values, add the
"?if_exists" built-in.
In general I highly recommend the documentation for FTL at: www.freemarker.org
> Widget $() escapes HTML. StringUtil.wrapString(contentText) throw an error
> --
>
> Key: OFBIZ-4316
> URL: https://issues.apache.org/jira/browse/OFBIZ-4316
> Project: OFBiz
> Issue Type: Bug
> Components: content, framework, specialpurpose/ecommerce
>Affects Versions: SVN trunk
>Reporter: BJ Freeman
> Labels: html, rendering, widget
> Fix For: SVN trunk
>
>
> from the ForumScreens.xml#ViewForumMessage
> {code}
>
>${contentText}
> {code}
> show escaped html
> {code}
> * Data Source * Marketing Campaign * Tracking Affiliate
> programs * Segment * Contact List * Reports class="postlink"
> href="https://demo-trunk.ofbiz.apache.org/marketing/control/main"USERNAME=flexadmin&PASSWORD=ofbiz&JavaScriptEnabled=Y";>Demo
> Marketing
> {code}
> replacing
> {code}${contentText}{code}
> with
> {code}${StringUtil.wrapString(contentText).toString()}{code}
> give this error
> 2011-06-15 18:16:43,200 (TP-Processor13) [ UtilXml.java:1043:ERROR]
> XmlFileLoader: File
> file:specialpurpose/ecommerce/widget/ForumScreens.xml
> process error. Line: 151. Error message: cvc-complex-type.2.3: Element
> 'condition' cannot have character [children], because the type's content
> type is element-only.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (OFBIZ-4282) TransactionUtil performance optimisations
[ https://issues.apache.org/jira/browse/OFBIZ-4282?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13037656#comment-13037656 ] David E. Jones commented on OFBIZ-4282: --- *** For #1: I did a little more research, and it looks like you're right Philippe, the synchronized is no longer needed. It was there originally because before JTA 1.1 the setTransactionTimeout method was defined like this: "Modify the timeout value that is associated with transactions started by subsequent invocations of the begin method." In JTA 1.1 the definition was changed to fix just this issue and now reads like this: "Modify the timeout value that is associated with transactions started by subsequent invocations of the begin method by the current thread." As long as the JTA implementation used follows this rule, then leaving the method unsynchronized should be fine. *** For #2: I didn't say I'm against a configurable setting, like a properties file setting. I said I'm against changing the default in the code for all of OFBiz without making it configurable. On the topic of configuration: I'm against business-level configuration in properties files (that should go in the DB), I'm not against technical or system configuration in properties files, in fact that's just where it belongs. > TransactionUtil performance optimisations > - > > Key: OFBIZ-4282 > URL: https://issues.apache.org/jira/browse/OFBIZ-4282 > Project: OFBiz > Issue Type: Improvement > Components: framework >Affects Versions: SVN trunk >Reporter: Philippe Mouawad > Labels: PERFORMANCE > Attachments: patch-OFBIZ-4282.patch > > > Hello, > Reviewing TransactionUtil code, I have seen 2 problems: > - internalBegin is uselessly synchronized , since it is a static method it is > a very big useless Contention Point since not unthread safe instance variable > is used > - debugResources is true which creates a DebugXAResource (that creates an > Exception) , it should be false and made an option for debuging > These 2 modifications have been in our production for a while and we noticed > CPU reduction and no more contention on TransactionUtil#begin > Regards > Philippe Mouawad > http://www.ubik-ingenierie.com -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (OFBIZ-4282) TransactionUtil performance optimisations
[ https://issues.apache.org/jira/browse/OFBIZ-4282?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13037454#comment-13037454 ] David E. Jones commented on OFBIZ-4282: --- Philippe: did you consider the down-sides to these changes? It's fine if you want to make these changes locally, but consider undesirable behavior if they were the default: 1. If internalBegin is not synchronized the timeout for a transaction would bleed over into other transactions; unfortunately this is a major weakness with the JTA API: you can only change timeout for the entire transaction manager, you can't set it for a single transaction. 2. If the debug stack is not maintained it makes it harder to track down transaction and various database-related issues, even in production. If you haven't found it to be useful, then again, it's fine to change locally but it is valuable information to have when tracking down bad code or certain lower-level problems. Also, have you done performance measurements with and without to see how much of a change there is? About the synchronization problem, that is a significant performance issue that I have seen while working with clients. However, the real cause of the problem is higher up because by default all screens are run within a transaction, and really it's pretty rare that a screen needs to be run in a transaction, so that is where a change should be made. Either way, performance "improvements" without metrics and tracking down the main cause of problems is likely to produce as many problems as it solves. Based on that, I'd say these changes should NOT be committed. > TransactionUtil performance optimisations > - > > Key: OFBIZ-4282 > URL: https://issues.apache.org/jira/browse/OFBIZ-4282 > Project: OFBiz > Issue Type: Improvement > Components: framework >Affects Versions: SVN trunk >Reporter: Philippe Mouawad > Labels: PERFORMANCE > Attachments: patch-OFBIZ-4282.patch > > > Hello, > Reviewing TransactionUtil code, I have seen 2 problems: > - internalBegin is uselessly synchronized , since it is a static method it is > a very big useless Contention Point since not unthread safe instance variable > is used > - debugResources is true which creates a DebugXAResource (that creates an > Exception) , it should be false and made an option for debuging > These 2 modifications have been in our production for a while and we noticed > CPU reduction and no more contention on TransactionUtil#begin > Regards > Philippe Mouawad > http://www.ubik-ingenierie.com -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (OFBIZ-4252) wrong prefixes for DATA_MEASURE units in UnitData.xml
[ https://issues.apache.org/jira/browse/OFBIZ-4252?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13019844#comment-13019844 ] David E. Jones commented on OFBIZ-4252: --- I'm not sure if I understand, are you arguing against having two sets of units (one for decimal and one for binary multipliers)? BTW, to increase chances of something happening for this, or any, issue the best thing to do is submit a patch with the changes you propone. > wrong prefixes for DATA_MEASURE units in UnitData.xml > - > > Key: OFBIZ-4252 > URL: https://issues.apache.org/jira/browse/OFBIZ-4252 > Project: OFBiz > Issue Type: Improvement > Components: framework >Affects Versions: Release Branch 10.04 >Reporter: Seweryn Niemiec >Priority: Minor > Labels: unit, > Original Estimate: 1h > Remaining Estimate: 1h > > Units from DATA_MEASURE section use multipliers for binary prefixes, but > symbols for decimal prefixes. Symbols for binary prefixes are defined in IEC > 60027 standard and are: Ki, Mi, Gi, etc. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (OFBIZ-4252) wrong prefixes for DATA_MEASURE units in UnitData.xml
[ https://issues.apache.org/jira/browse/OFBIZ-4252?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13019384#comment-13019384 ] David E. Jones commented on OFBIZ-4252: --- If we made any change based on this it would probably need to include 2 sets of data measure units, one for the decimal multipliers and one for the binary multipliers. However, I'm not sure we should change it. Are you saying you have a need for both, or just hoping for some disambiguation? As for the IEC 60027 standard: it isn't commonly used and seems largely rejected... IMO it's because they chose the funny names for the less commonly used approach of decimal multipliers, and the prefixes they chose sound funny in general (kibi-, mebi-, etc). IMO, unless we had sets with both multipliers and a link to http://en.wikipedia.org/wiki/Binary_prefix, this change would be MORE confusing and not less. > wrong prefixes for DATA_MEASURE units in UnitData.xml > - > > Key: OFBIZ-4252 > URL: https://issues.apache.org/jira/browse/OFBIZ-4252 > Project: OFBiz > Issue Type: Improvement > Components: framework >Affects Versions: Release Branch 10.04 >Reporter: Seweryn Niemiec >Priority: Minor > Labels: unit, > Original Estimate: 1h > Remaining Estimate: 1h > > Units from DATA_MEASURE section use multipliers for binary prefixes, but > symbols for decimal prefixes. Symbols for binary prefixes are defined in IEC > 60027 standard and are: Ki, Mi, Gi, etc. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (OFBIZ-4103) missCountExpired and missCountExpired always equal to 0 in UtilCache
[ https://issues.apache.org/jira/browse/OFBIZ-4103?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12979377#action_12979377 ] David E. Jones commented on OFBIZ-4103: --- BTW, this is not an issue, it is a question. The dev mailing list might be a better place for it. > missCountExpired and missCountExpired always equal to 0 in UtilCache > > > Key: OFBIZ-4103 > URL: https://issues.apache.org/jira/browse/OFBIZ-4103 > Project: OFBiz > Issue Type: Bug > Components: framework >Affects Versions: SVN trunk >Reporter: Philippe Mouawad > > Working on new Cache implementation plugin, I noticed these 2 fields are > never modified. > I plan to remove them in the new Cache interface and administration interface > is it a problem ? > Thank you > Regards > Philippe -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (OFBIZ-4103) missCountExpired and missCountExpired always equal to 0 in UtilCache
[ https://issues.apache.org/jira/browse/OFBIZ-4103?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12979376#action_12979376 ] David E. Jones commented on OFBIZ-4103: --- That field is actually used in the OFBiz cache implementation. It is also supported by ehcache: ehcache.getSampledCacheStatistics().getCacheMissExpiredMostRecentSample() > missCountExpired and missCountExpired always equal to 0 in UtilCache > > > Key: OFBIZ-4103 > URL: https://issues.apache.org/jira/browse/OFBIZ-4103 > Project: OFBiz > Issue Type: Bug > Components: framework >Affects Versions: SVN trunk >Reporter: Philippe Mouawad > > Working on new Cache implementation plugin, I noticed these 2 fields are > never modified. > I plan to remove them in the new Cache interface and administration interface > is it a problem ? > Thank you > Regards > Philippe -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (OFBIZ-4098) Ability to plug a new Cache Implementation
[ https://issues.apache.org/jira/browse/OFBIZ-4098?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12979117#action_12979117 ] David E. Jones commented on OFBIZ-4098: --- This is an interesting request. For Moqui (www.moqui.org) I decided to go with ehcache itself for the cache implementation. The cache interface design I started with was based on the OFBiz cache API, and most of it worked pretty well but there were a few mismatches, and quite a few things I got rid of in the cache design because ehcache just doesn't support them. Anyway, the implementation ends up being quite simple, the cache wrapper and factory in Moqui are complete and available here: http://moqui.svn.sourceforge.net/viewvc/moqui/trunk/moqui/framework/impl/src/org/moqui/impl/context/CacheImpl.groovy?view=markup http://moqui.svn.sourceforge.net/viewvc/moqui/trunk/moqui/framework/impl/src/org/moqui/impl/context/CacheFacadeImpl.groovy?view=markup Chances are it would only take a few hours to implement this in OFBiz (plus time for whatever configuration mechanism you decide on, which is messy), but you would have to leave out (effectively disable) certain features that the OFBiz UtilCache supports. For example, I never could figure out how to get soft references working in ehcache. > Ability to plug a new Cache Implementation > -- > > Key: OFBIZ-4098 > URL: https://issues.apache.org/jira/browse/OFBIZ-4098 > Project: OFBiz > Issue Type: New Feature > Components: framework >Affects Versions: SVN trunk >Reporter: Philippe Mouawad > Original Estimate: 96h > Remaining Estimate: 96h > > Hello, > I would like to contribute a patch to enable switching from Ofbiz native > Cache (today UtilCache) to another implementation like EhCache for example. > To avoid big code impacts, UtilCache would stay the same and delegate to the > real > cache implementation this will impact less classes and big impacts > would stay in UtilCache package. > Ability to plug another implementation like EhCache for example would enable > easily plugin with Terracota for example which on big Web Site gives much > performance enhancements. > Is the format to contribute this kind of evolution also a patch ? > Thank you > Regards > Philippe > http://www.ubik-ingenierie.com -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (OFBIZ-4053) Implement an Entity Query Builder
[
https://issues.apache.org/jira/browse/OFBIZ-4053?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12971033#action_12971033
]
David E. Jones commented on OFBIZ-4053:
---
First off, I like this general direction. A while back (years ago) when
thinking about cleaning up the delegator API it seems like we discussed the
idea of using a query object with various methods instead of the find* methods
with their large numbers of parameters, that are individually sometimes complex
anyway. Scott's idea earlier this summer was an extension of that where the
various methods instead of returning void would return the query object to
allow chaining (definitely tightens up the code).
Anyway, in the Moqui framework here is what I've done with those ideas, for
those interested. Here is the EntityFind interface (for the query object):
http://moqui.svn.sourceforge.net/viewvc/moqui/trunk/moqui/framework/src-api/org/moqui/entity/EntityFind.java?revision=25&content-type=text/plain
This is called from the find method on the EntityFacade interface (the
equivalent of the delegator in Moqui), and there are no other find methods:
http://moqui.svn.sourceforge.net/viewvc/moqui/trunk/moqui/framework/src-api/org/moqui/entity/EntityFind.java?revision=25&content-type=text/plain
With this EntityFind interface the idea is that you are setting up the details
of the query, and you could potentially run more than query with the same
object. You'll also notice that Moqui includes a EntityList interface in
addition to the EntityListIterator concept instead of returning a generic
List, and that might be something useful in OFBiz too (mostly to
have convenience methods right there instead of using EntityUtil).
I actually started with the EntityFindOptions class and then expanded it based
on the various parameter and return value options for the delegator find
methods. The result has a LOT less redundancy, and the code should be more
readable (and more similar to the XML "code" where markup describes everything
instead of having to know which parameter means what).
Another detail: should the query object be immutable? I decided that it should
not be in Moqui, and the various methods on EntityFind that return an
EntityFind just return a this reference as it is ONLY for convenience and
having an immutable object would result in all sorts of unused query objects
being created.
Anyway, there are some thoughts, for what it's worth...
It would also be nice if the ShoppingCart and ShoppingCartItem worked in a
similar way... ;)
> Implement an Entity Query Builder
> -
>
> Key: OFBIZ-4053
> URL: https://issues.apache.org/jira/browse/OFBIZ-4053
> Project: OFBiz
> Issue Type: New Feature
> Components: framework
>Affects Versions: SVN trunk
>Reporter: Scott Gray
>Assignee: Scott Gray
> Attachments: builder.patch
>
>
> As discussed on the dev list here:
> http://ofbiz.markmail.org/thread/l6kiywqzfj656dhc
> Attached is an initial implementation of builder classes (of sorts) that make
> use of method chaining in order to simplify use of the Delegator interface to
> query entities.
> Rather than taking all possible query parameters into a single method as the
> delegator does, this implementation instead builds a query through a
> succession of distinct method calls.
> A simple example:
> {code}
> // Using the Delegator interface directly
> eli = delegator.find("FinAccountTrans", condition, null, null,
> UtilMisc.toList("-transactionDate"), null);
> // Using the new implementation
> eli =
> EntityBuilderUtil.list(delegator).from("FinAccountTrans").where(condition).orderBy("-transactionDate").iterator();
> {code}
> A more complex example:
> {code}
> // Delegator
> EntityCondition queryConditionsList =
> EntityCondition.makeCondition(allConditions, EntityOperator.AND);
> EntityFindOptions options = new EntityFindOptions(true,
> EntityFindOptions.TYPE_SCROLL_INSENSITIVE,
> EntityFindOptions.CONCUR_READ_ONLY, true);
> options.setMaxRows(viewSize * (viewIndex + 1));
> EntityListIterator iterator = delegator.find("OrderHeader",
> queryConditionsList, null, null, UtilMisc.toList("orderDate DESC"), options);
> // becomes
> EntityListIterator iterator = EntityBuilderUtil.list(delegator).distinct()
>
> .from("OrderHeader")
>
> .where(allConditions)
>
> .orderBy("orderDate DESC")
>
> .maxRows(viewSize * (viewIndex + 1))
>
> .cursorScrollInsensitive()
>
[jira] Commented: (OFBIZ-1262) Complete the support for VAT (Value-Added-Tax)
[ https://issues.apache.org/jira/browse/OFBIZ-1262?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12964638#action_12964638 ] David E. Jones commented on OFBIZ-1262: --- I don't know that the work I've done can replace these changes, or that I'll be doing any work that will replace them. The work I did was to make various calculations more accurate, but there is still an issue where in certain cases we just can't get the calculated total based on prices without tax included to exactly match the total based on a calculation based on prices with tax included. What that means is that the only solution seems to be to do the calculation based on prices with tax included, and then calculate how much of that should be taken out as tax. There just doesn't seem to be any way to avoid that, and that will eventually need to be implemented (preferably based on existing settings on the ProductStore and the ProductPrice records to see if there are prices with tax included). > Complete the support for VAT (Value-Added-Tax) > -- > > Key: OFBIZ-1262 > URL: https://issues.apache.org/jira/browse/OFBIZ-1262 > Project: OFBiz > Issue Type: Improvement > Components: order, specialpurpose/ecommerce >Affects Versions: SVN trunk >Reporter: Marco Risaliti >Assignee: David E. Jones >Priority: Minor > Fix For: SVN trunk > > Attachments: CalculateVatTax2.patch, ecommerceEu.zip > > > I have tried to implement a different of VAT Tax calculation without total > change the actual calculation of tax for USA. > I have add a new field into the ProductStore to understand if for a store the > vat tax has to be calculated (calculateVatTax). > The old field showPricesWithVatTax it will be used only if the > calculateVatTax will be set to yes for show the prices with tax included or > excluded. > I have created a sample application (ecommerceEu) to show how it's working. > For the moment I have used only two product with vat tax calculated (GZ-1000 > and GZ-1001). -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (OFBIZ-3974) Wrong tax calculating
[ https://issues.apache.org/jira/browse/OFBIZ-3974?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12916922#action_12916922 ] David E. Jones commented on OFBIZ-3974: --- You wrote: "When we configure our shop with "show prices with vat tax == N". Means our product price is stored with vat in the db. " Actually, it does NOT mean that, it simply means that tax should not be added to prices for display. There is no setting in OFBiz right now to say that taxes are already included in the prices in the DB. In other words, the OFBiz tax code always assumes that the prices in the db do NOT have taxes included. The problem with making the change you propose is that non-VAT jurisdictions will have this set to N, and after your change the code would assume that taxes are already included in prices, which they are not, and it would mess up the total in the other direction. If you want to support prices that already have VAT included in them you'll have to add a new setting and write code for that. BTW, keep in mind that with this you'll have to have different sets of prices for different jurisdictions because of possibly different tax rates in each. > Wrong tax calculating > -- > > Key: OFBIZ-3974 > URL: https://issues.apache.org/jira/browse/OFBIZ-3974 > Project: OFBiz > Issue Type: Bug > Components: accounting >Affects Versions: SVN trunk >Reporter: Sascha Rodekamp >Priority: Critical > Fix For: SVN trunk > > Attachments: OFBIZ-3974_TaxAuthorityServices.java.patch > > > Hi, > another Patch for today, > we had problems with the taxation. When we configure our shop with "show > prices with vat tax == N". Means our product price is stored with vat in the > db. > During the checkout process ofbiz doesn't differs between the "show prices > with vat tax" options when calculating the taxes. The result is a wrong order > amount! > i.e. > A product is stored with a price of: 100€ (Gross price). > Vat (19% in Germany) should be 15,97€ > But ofbiz tread this price like a net price. > This patch differs the calculating. And looks what is configured in the shop > setup. > Cheers 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-3877) New Web Service Style
[ https://issues.apache.org/jira/browse/OFBIZ-3877?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12896280#action_12896280 ] David E. Jones commented on OFBIZ-3877: --- I don't have any immediate opinions, not at the minute anyway, and I don't really have anything real to apply it to or try it on right now (nothing currently on the docket anyway). I'll see if I can shift some priorities and get a couple of my people on this soon, and hopefully you'll hear some feedback from them in the next little while. > New Web Service Style > - > > Key: OFBIZ-3877 > URL: https://issues.apache.org/jira/browse/OFBIZ-3877 > Project: OFBiz > Issue Type: New Feature > Components: framework > Environment: Windows, Ubuntu Linux >Reporter: Chatree Srichart >Assignee: Hans Bakker > Attachments: webservice.zip > > > This is a new stub for new web service style that use a normal style (not > hash map [key/value]). > [[ Installation ]] > - Extract webservice.zip file (attached file) to hot-deploy directory of > OFBiz framework > - run ant task for apply patch in webservice directory with: >ant reapply-ofbiz-patches > [[ Features ]] > 1.) New classes > > There is new important class > > org.ofbiz.webapp.webservice.event.WebServiceEventHandler > > which corresponds to earlier > > org.ofbiz.webapp.event.SOAPEventHandler > > but tries to support document style web services using > SOAP with XML-format, or REST with XML and JSON-formats. > This handler class uses other class: > > org.ofbiz.webapp.webservice.WebServiceModel > > which wraps inside class > > org.ofbiz.service.ModelService > > and contains support for WSDL-generation, WADL-generation > and conversion between Java Maps and XML-object models. > WSDL=Web Service Definition Language for SOAP-interface > http://www.w3.org/TR/wsdl > WADL=Web Application Description Language for REST-interface > http://www.w3.org/Submission/wadl/ > > 2.) Service definitions > > Web service interface can be used only if service definition > file services.xml is completed with additional definitions. > Schema of this file is extended. > > attribute-elements can have nested attribute elements > which describe structure of Java maps and lists. > If attribute has type Map, it should have nested attributes > which describe contents of this map. > If attribute has type List, it should have nested attributes > which describe element contents of this list. > If List has simple elements, there must be only one > nested attribute, which describes element. > If List has element which is map or other list, there > must be one nested attribute stating that the element > is Map or List, and then this attribute should have > nested attributes describing structure of Map or > structure of list element. > There are also two new modes for attributes > ERROR which means that attribute is responded as error message > OUTERROR which means that attribute is responded as error > or as success message > These modes are needed for web services to describe > which parameters will go to detail-elements of SOAP Fault response > or REST error messages. Also in WSDL- and WADL-files will be > generated XML-schema for general response messages. > > File framework\webapp\servicedef\services_test.xml > can be used as example of attribute definitions. > This file is used in unit tests of web service interface. > > 3.) Web service requests > > In REST-services HTTP GET-method is used in services whose > name start with words "find" or "get". These services should > have input parameters in one level, so that they can be > given as query parameters in URL. HTTP DELETE-method is used > with services whose name start with word "remove". Other services > are used with HTTP POST-method and PUT-method. Service must > look itself for method name POST or PUT, if it is required > to operate differently in insert or update cases. > > List of links to all WSDL-documents can be requested with URL: > > /webtools/control/WebService?wsdl > > Specific WSDL-document is requested with URL: > > /webtools/control/WebService/?wsdl > > SOAP web service is called with URL: > > /webtools/control/WebService > > Notice that no service name is added to URL. Operation > name in request message specifies the service name. > > List of links to all WADL-documents can be requested with URL: > > /webtools/control/WebService?wadl > > Specific WADL-document is requested with URL: > > /webtools/control/WebService/?wadl > > REST web service is called with URL: > > /webtools/control/WebService/ > > SOAP and REST web service requests are selected by > request URL, where REST web service has appended > service name in URL. > > 4.) Unit tests > > org.ofbiz.webapp.webservice.test.WebServiceTest
[jira] Commented: (OFBIZ-3863) selectall.js jquery transformation
[ https://issues.apache.org/jira/browse/OFBIZ-3863?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12893545#action_12893545 ] David E. Jones commented on OFBIZ-3863: --- I don't know if this will cause a conflict with these autocompleter changes or not, but I fixed two bugs in the current autocompleter stuff in the trunk in SVN rev 980348. > selectall.js jquery transformation > -- > > Key: OFBIZ-3863 > URL: https://issues.apache.org/jira/browse/OFBIZ-3863 > Project: OFBiz > Issue Type: Sub-task > Components: ALL COMPONENTS >Affects Versions: jQuery >Reporter: Sascha Rodekamp >Assignee: Erwan de FERRIERES > Fix For: jQuery > > Attachments: jeditable.zip, OFBIZ-3863_autocomplete.patch, > OFBIZ-3863_autocomplete.patch, OFBIZ-3863_autocomplete_inplaceedit.patch, > OFBIZ-3863_toggleScreenlet.patch > > > Hi, > i started to change the selectall.js methods. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (OFBIZ-3821) Using number value with calcop operator does not work as thought
[
https://issues.apache.org/jira/browse/OFBIZ-3821?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12879357#action_12879357
]
David E. Jones commented on OFBIZ-3821:
---
The attached patch is not an adequate fix for this problem. The fix should be
to do number parsing in a locale sensitive way. If you get rid of all commas
and it is in a locale where a comma is used for the decimal point, then the
parsed value will be 10^{number of decimal digits} greater than it should be.
> Using number value with calcop operator does not work as thought
>
>
> Key: OFBIZ-3821
> URL: https://issues.apache.org/jira/browse/OFBIZ-3821
> Project: OFBiz
> Issue Type: Bug
> Components: framework
>Reporter: Jacques Le Roux
> Fix For: Release Branch 10.04, SVN trunk
>
> Attachments: Patch_OFBIZ-3821.patch
>
>
> For instance if you use
> {code}
>
>
> {code}
> and have a value > 1000 in conversionFactor you will get 1,000 for number
> value. It works well if you replace by
> {code}
>
>
>
> {code}
> The problem exists in trunk and certainly R10.04 (not tested) maybe in
> previous release though I don't think so, it looks like something introduced
> with UEL
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (OFBIZ-3582) unable to intialize tenant Database
[ https://issues.apache.org/jira/browse/OFBIZ-3582?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12853058#action_12853058 ] David E. Jones commented on OFBIZ-3582: --- Seriously, what's the big deal? If you load the demo data this record will be there. If you don't load the demo data (for example you just load the seed data) then it won't be there. How you want to use it is totally up to you, ie if you want to use the demo data or if you want to setup your own Tenant records. Is this really that tough? You guys have experience with OFBiz and should know the difference between seed and demo data, and that demo Tenant records should only go in the demo data. Isn't that what you would expect? Or, am I totally off base and you are expecting something totally different? I've already sent some basic information about the tenant stuff, and I'm not going to be goaded or pressured or attacked into doing more. Sorry. > unable to intialize tenant Database > --- > > Key: OFBIZ-3582 > URL: https://issues.apache.org/jira/browse/OFBIZ-3582 > Project: OFBiz > Issue Type: Bug >Affects Versions: Release Candidate Branch 10.04, SVN trunk > Environment: SINCE version 927271 using the Tenant login. >Reporter: BJ Freeman >Assignee: Jacques Le Roux >Priority: Trivial > > use the line > java -Xmx512m -XX:MaxPermSize=128m -jar ofbiz.jar -install > -delegator=default#DEMO1 > when the Delegator is created it looks for a Tenant record with then new > delegator for DEMO1, but it has not been loaded yet so get a error. > log of error. > 2010-03-28 15:25:31,406 (main) [ EntityEcaUtil.java:128:INFO ] Loaded > [1] E > ntity ECA definitions from > C:/projects/java/ofbizf_new/applications/commonext/en > titydef/eecas.xml in loader main > 2010-03-28 15:25:31,437 (main) [DelegatorFactoryImpl.java:35 :ERROR] > exception report > -- > Error creating delegator > Exception: org.ofbiz.entity.GenericEntityException > Message: No Tenant record found for delegator [default#DEMO1] with tenantId > [DEM > O1] > stack trace > --- > org.ofbiz.entity.GenericEntityException: No Tenant record found for delegator > [d > efault#DEMO1] with tenantId [DEMO1] > org.ofbiz.entity.GenericDelegator.(GenericDelegator.java:230) > org.ofbiz.entity.DelegatorFactoryImpl.getInstance(DelegatorFactoryImpl.java:33) > org.ofbiz.entity.DelegatorFactoryImpl.getInstance(DelegatorFactoryImpl.java:25) > org.ofbiz.base.util.UtilObject.getObjectFromFactory(UtilObject.java:202) > org.ofbiz.entity.DelegatorFactory.getDelegator(DelegatorFactory.java:47) > org.ofbiz.entityext.data.EntityDataLoadContainer.start(EntityDataLoadContainer.j > ava:230) > org.ofbiz.base.container.ContainerLoader.start(ContainerLoader.java:100) > org.ofbiz.base.start.Start.startStartLoaders(Start.java:272) > org.ofbiz.base.start.Start.startServer(Start.java:322) > org.ofbiz.base.start.Start.start(Start.java:326) > org.ofbiz.base.start.Start.main(Start.java:411) > > Exception in thread "main" java.lang.NullPointerException > 2010-03-28 15:25:31,437 (main) [ DelegatorFactory.java:49 :ERROR] > exception report > -- > Exception: java.lang.ClassNotFoundException > Message: java.lang.Class > stack trace > --- > java.lang.ClassNotFoundException: java.lang.Class > org.ofbiz.base.util.UtilObject.getObjectFromFactory(UtilObject.java:207) > org.ofbiz.entity.DelegatorFactory.getDelegator(DelegatorFactory.java:47) > org.ofbiz.entityext.data.EntityDataLoadContainer.start(EntityDataLoadContainer.j > ava:230) > org.ofbiz.base.container.ContainerLoader.start(ContainerLoader.java:100) > org.ofbiz.base.start.Start.startStartLoaders(Start.java:272) > org.ofbiz.base.start.Start.startServer(Start.java:322) > org.ofbiz.base.start.Start.start(Start.java:326) > org.ofbiz.base.start.Start.main(Start.java:411) > > at java.util.concurrent.ConcurrentHashMap.putIfAbsent(Unknown Source) > at > org.ofbiz.entity.DelegatorFactory.getDelegator(DelegatorFactory.java: > 52) > at > org.ofbiz.entityext.data.EntityDataLoadContainer.start(EntityDataLoad > Container.java:230) > at > org.ofbiz.base.container.ContainerLoader.start(ContainerLoader.java:1 > 00) > at org.ofbiz.base.start.Start.startStartLoaders(Start.java:272) > at org.ofbiz.base.start.Start.startServer(Start.java:322) > at org.ofbiz.base.start.Start.start(Start.java:326) >
[jira] Commented: (OFBIZ-3582) unable to intialize tenant Database
[ https://issues.apache.org/jira/browse/OFBIZ-3582?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12853004#action_12853004 ] David E. Jones commented on OFBIZ-3582: --- Actually BJ what I said was the exact cause of the problem: the record was missing. The problem seems to be that you didn't believe me and so you're looking in the wrong place. > unable to intialize tenant Database > --- > > Key: OFBIZ-3582 > URL: https://issues.apache.org/jira/browse/OFBIZ-3582 > Project: OFBiz > Issue Type: Bug >Affects Versions: Release Candidate Branch 10.04, SVN trunk > Environment: SINCE version 927271 using the Tenant login. >Reporter: BJ Freeman >Assignee: Jacques Le Roux >Priority: Trivial > > use the line > java -Xmx512m -XX:MaxPermSize=128m -jar ofbiz.jar -install > -delegator=default#DEMO1 > when the Delegator is created it looks for a Tenant record with then new > delegator for DEMO1, but it has not been loaded yet so get a error. > log of error. > 2010-03-28 15:25:31,406 (main) [ EntityEcaUtil.java:128:INFO ] Loaded > [1] E > ntity ECA definitions from > C:/projects/java/ofbizf_new/applications/commonext/en > titydef/eecas.xml in loader main > 2010-03-28 15:25:31,437 (main) [DelegatorFactoryImpl.java:35 :ERROR] > exception report > -- > Error creating delegator > Exception: org.ofbiz.entity.GenericEntityException > Message: No Tenant record found for delegator [default#DEMO1] with tenantId > [DEM > O1] > stack trace > --- > org.ofbiz.entity.GenericEntityException: No Tenant record found for delegator > [d > efault#DEMO1] with tenantId [DEMO1] > org.ofbiz.entity.GenericDelegator.(GenericDelegator.java:230) > org.ofbiz.entity.DelegatorFactoryImpl.getInstance(DelegatorFactoryImpl.java:33) > org.ofbiz.entity.DelegatorFactoryImpl.getInstance(DelegatorFactoryImpl.java:25) > org.ofbiz.base.util.UtilObject.getObjectFromFactory(UtilObject.java:202) > org.ofbiz.entity.DelegatorFactory.getDelegator(DelegatorFactory.java:47) > org.ofbiz.entityext.data.EntityDataLoadContainer.start(EntityDataLoadContainer.j > ava:230) > org.ofbiz.base.container.ContainerLoader.start(ContainerLoader.java:100) > org.ofbiz.base.start.Start.startStartLoaders(Start.java:272) > org.ofbiz.base.start.Start.startServer(Start.java:322) > org.ofbiz.base.start.Start.start(Start.java:326) > org.ofbiz.base.start.Start.main(Start.java:411) > > Exception in thread "main" java.lang.NullPointerException > 2010-03-28 15:25:31,437 (main) [ DelegatorFactory.java:49 :ERROR] > exception report > -- > Exception: java.lang.ClassNotFoundException > Message: java.lang.Class > stack trace > --- > java.lang.ClassNotFoundException: java.lang.Class > org.ofbiz.base.util.UtilObject.getObjectFromFactory(UtilObject.java:207) > org.ofbiz.entity.DelegatorFactory.getDelegator(DelegatorFactory.java:47) > org.ofbiz.entityext.data.EntityDataLoadContainer.start(EntityDataLoadContainer.j > ava:230) > org.ofbiz.base.container.ContainerLoader.start(ContainerLoader.java:100) > org.ofbiz.base.start.Start.startStartLoaders(Start.java:272) > org.ofbiz.base.start.Start.startServer(Start.java:322) > org.ofbiz.base.start.Start.start(Start.java:326) > org.ofbiz.base.start.Start.main(Start.java:411) > > at java.util.concurrent.ConcurrentHashMap.putIfAbsent(Unknown Source) > at > org.ofbiz.entity.DelegatorFactory.getDelegator(DelegatorFactory.java: > 52) > at > org.ofbiz.entityext.data.EntityDataLoadContainer.start(EntityDataLoad > Container.java:230) > at > org.ofbiz.base.container.ContainerLoader.start(ContainerLoader.java:1 > 00) > at org.ofbiz.base.start.Start.startStartLoaders(Start.java:272) > at org.ofbiz.base.start.Start.startServer(Start.java:322) > at org.ofbiz.base.start.Start.start(Start.java:326) > at org.ofbiz.base.start.Start.main(Start.java:411) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (OFBIZ-3632) Extending the service model to specify more complex permissions using permission service
[
https://issues.apache.org/jira/browse/OFBIZ-3632?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12852466#action_12852466
]
David E. Jones commented on OFBIZ-3632:
---
Yet another reason to use simple-methods instead of Java as much as possible.
> Extending the service model to specify more complex permissions using
> permission service
>
>
> Key: OFBIZ-3632
> URL: https://issues.apache.org/jira/browse/OFBIZ-3632
> Project: OFBiz
> Issue Type: Improvement
> Components: framework, product
>Reporter: Vikas Mayur
>Priority: Minor
> Fix For: SVN trunk
>
> Attachments: permission.patch
>
>
> At present in the service definition allows only one
> permission service. I have extended the tag to
> specify more then one permission services by doing an AND/OR operation.
> For instance the following code in service definition
> {code}
>
> main-action="CREATE"/>
> main-action="UPDATE"/>
>
> {code}
> will replace the following code in service implementation.
> {code}
>
>
>
>
>
>
> {code}
> Similarly the code
> {code}
>
> main-action="CREATE"/>
> main-action="UPDATE"/>
>
> {code}
> will replace
> {code}
>
>
>
>
>
> {code}
> The patch also contains additional changes where the permission service is
> defined in the service definition.
> EDITS: Added missing ending \{code\} tag for the last code snippet
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (OFBIZ-3632) Extending the service model to specify more complex permissions using permission service
[
https://issues.apache.org/jira/browse/OFBIZ-3632?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12852456#action_12852456
]
David E. Jones commented on OFBIZ-3632:
---
A better solution to this right now would be to use the permission-service tag
and implement it in a simple-method or Java. Either way, we've been trying to
move away from definitions tied too closely to service definitions and
implementations both. Having a separate permission service helps a little with
this, but the external declarative permissions are the real way to go (just not
easy to implement, especially the way OFBiz is currently architected, and even
tougher since discussions about it haven't been very productive, it seems like
it's hard for some people to understand the point of things like run-time call
chain inheritance of permissions as opposed to location based inheritance of
permissions).
If the point is to try to save a couple of lines of code... I guess that would
make sense only if this is something you'll be doing dozens or hundreds of
times.
> Extending the service model to specify more complex permissions using
> permission service
>
>
> Key: OFBIZ-3632
> URL: https://issues.apache.org/jira/browse/OFBIZ-3632
> Project: OFBiz
> Issue Type: Improvement
> Components: framework, product
>Reporter: Vikas Mayur
>Priority: Minor
> Fix For: SVN trunk
>
> Attachments: permission.patch
>
>
> At present in the service definition allows only one
> permission service. I have extended the tag to
> specify more then one permission services by doing an AND/OR operation.
> For instance the following code in service definition
> {code}
>
> main-action="CREATE"/>
> main-action="UPDATE"/>
>
> {code}
> will replace the following code in service implementation.
> {code}
>
>
>
>
>
>
> {code}
> Similarly the code
> {code}
>
> main-action="CREATE"/>
> main-action="UPDATE"/>
>
> {code}
> will replace
> {code}
>
>
>
>
>
> {code}
> The patch also contains additional changes where the permission service is
> defined in the service definition.
> EDITS: Added missing ending \{code\} tag for the last code snippet
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (OFBIZ-3582) unable to intialize tenant Database
[ https://issues.apache.org/jira/browse/OFBIZ-3582?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12850998#action_12850998 ] David E. Jones commented on OFBIZ-3582: --- As far as I can tell this is caused what I described before to BJ. The error message "No Tenant record found for delegator [default#DEMO1] with tenantId [DEMO1]" pretty much explains it, ie there is no record in the Tenant entity's table with the ID of DEMO1. So, to reproduce just make sure there is no record in the database with the ID "DEMO1" and then try to use the tenant. This isn't an error, it is the expected behavior (ie if the Tenant hasn't been configured, then an error should result when you try to use it). > unable to intialize tenant Database > --- > > Key: OFBIZ-3582 > URL: https://issues.apache.org/jira/browse/OFBIZ-3582 > Project: OFBiz > Issue Type: Bug >Affects Versions: Release Candidate Branch 10.04, SVN trunk > Environment: SINCE version 927271 using the Tenant login. >Reporter: BJ Freeman >Priority: Trivial > > use the line > java -Xmx512m -XX:MaxPermSize=128m -jar ofbiz.jar -install > -delegator=default#DEMO1 > when the Delegator is created it looks for a Tenant record with then new > delegator for DEMO1, but it has not been loaded yet so get a error. > log of error. > 2010-03-28 15:25:31,406 (main) [ EntityEcaUtil.java:128:INFO ] Loaded > [1] E > ntity ECA definitions from > C:/projects/java/ofbizf_new/applications/commonext/en > titydef/eecas.xml in loader main > 2010-03-28 15:25:31,437 (main) [DelegatorFactoryImpl.java:35 :ERROR] > exception report > -- > Error creating delegator > Exception: org.ofbiz.entity.GenericEntityException > Message: No Tenant record found for delegator [default#DEMO1] with tenantId > [DEM > O1] > stack trace > --- > org.ofbiz.entity.GenericEntityException: No Tenant record found for delegator > [d > efault#DEMO1] with tenantId [DEMO1] > org.ofbiz.entity.GenericDelegator.(GenericDelegator.java:230) > org.ofbiz.entity.DelegatorFactoryImpl.getInstance(DelegatorFactoryImpl.java:33) > org.ofbiz.entity.DelegatorFactoryImpl.getInstance(DelegatorFactoryImpl.java:25) > org.ofbiz.base.util.UtilObject.getObjectFromFactory(UtilObject.java:202) > org.ofbiz.entity.DelegatorFactory.getDelegator(DelegatorFactory.java:47) > org.ofbiz.entityext.data.EntityDataLoadContainer.start(EntityDataLoadContainer.j > ava:230) > org.ofbiz.base.container.ContainerLoader.start(ContainerLoader.java:100) > org.ofbiz.base.start.Start.startStartLoaders(Start.java:272) > org.ofbiz.base.start.Start.startServer(Start.java:322) > org.ofbiz.base.start.Start.start(Start.java:326) > org.ofbiz.base.start.Start.main(Start.java:411) > > Exception in thread "main" java.lang.NullPointerException > 2010-03-28 15:25:31,437 (main) [ DelegatorFactory.java:49 :ERROR] > exception report > -- > Exception: java.lang.ClassNotFoundException > Message: java.lang.Class > stack trace > --- > java.lang.ClassNotFoundException: java.lang.Class > org.ofbiz.base.util.UtilObject.getObjectFromFactory(UtilObject.java:207) > org.ofbiz.entity.DelegatorFactory.getDelegator(DelegatorFactory.java:47) > org.ofbiz.entityext.data.EntityDataLoadContainer.start(EntityDataLoadContainer.j > ava:230) > org.ofbiz.base.container.ContainerLoader.start(ContainerLoader.java:100) > org.ofbiz.base.start.Start.startStartLoaders(Start.java:272) > org.ofbiz.base.start.Start.startServer(Start.java:322) > org.ofbiz.base.start.Start.start(Start.java:326) > org.ofbiz.base.start.Start.main(Start.java:411) > > at java.util.concurrent.ConcurrentHashMap.putIfAbsent(Unknown Source) > at > org.ofbiz.entity.DelegatorFactory.getDelegator(DelegatorFactory.java: > 52) > at > org.ofbiz.entityext.data.EntityDataLoadContainer.start(EntityDataLoad > Container.java:230) > at > org.ofbiz.base.container.ContainerLoader.start(ContainerLoader.java:1 > 00) > at org.ofbiz.base.start.Start.startStartLoaders(Start.java:272) > at org.ofbiz.base.start.Start.startServer(Start.java:322) > at org.ofbiz.base.start.Start.start(Start.java:326) > at org.ofbiz.base.start.Start.main(Start.java:411) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (OFBIZ-3540) Multi-Tenant Support (Login Based)
[ https://issues.apache.org/jira/browse/OFBIZ-3540?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David E. Jones updated OFBIZ-3540: -- Attachment: (was: ecommercetenatsadd.patch) > Multi-Tenant Support (Login Based) > -- > > Key: OFBIZ-3540 > URL: https://issues.apache.org/jira/browse/OFBIZ-3540 > Project: OFBiz > Issue Type: New Feature > Components: framework >Affects Versions: SVN trunk >Reporter: David E. Jones >Assignee: David E. Jones >Priority: Minor > Fix For: SVN trunk > > Attachments: MultiTenant20100305.patch, MultiTenant20100305.patch, > MultiTenant20100305.patch > > > Support multiple tenants in a single instance of OFBiz. Each tenant will have > its own databases (one for each entity group). Database settings will > override the settings on the delegator with parameters from an entity record > so that new tenants can be added on the fly without restarting the server > (new tenants will still need to have data loaded in their databases just like > any other). > If valid Tenant ID is specified when user logs in then webapp context will be > setup with tools for that tenant as a variation of the base delegator > (including delegator, dispatcher, security, authz, visit, server hit, etc > handled for it). > Demo data includes a couple of sample tenants. After loading demo data (ant > run-install) try logging in to webtools or any other admin app with the > Tenant ID of "DEMO1". > NOTE: this patch also addresses some stability issues with the LoginWorker, > ControlServlet, Visit, and ServerHit functionality that was exposed while > developing this. For example, after a logout functionality that runs in the > ControlServlet may fail because things that were in the session before are > not there any more. In this patch there is code to rebuild the request and > session after logout (necessary for changing tenants, helpful for these other > issues). -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (OFBIZ-3540) Multi-Tenant Support (Login Based)
[ https://issues.apache.org/jira/browse/OFBIZ-3540?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12850352#action_12850352 ] David E. Jones commented on OFBIZ-3540: --- BJ: Please don't add patches to an issue that are outside the scope of the issue. The additional ecommerce webapps should go in a separate issue so they can be evaluated separately and have their own issue lifecycle. I'm removing it from this issue to make this easier to manage. About the problem you're seeing: the error message says there is no Tenant record for that ID, meaning there is no record in the Tenant entity's database table for that ID. Based on what you wrote here it is because you are only loading the seed data and the OOTB Tenant records are demo data since there is nothing inherent to the system about them, and even the IDs are meant to convey that they are for demo purposes only (ie "DEMO1" and "DEMO2"). > Multi-Tenant Support (Login Based) > -- > > Key: OFBIZ-3540 > URL: https://issues.apache.org/jira/browse/OFBIZ-3540 > Project: OFBiz > Issue Type: New Feature > Components: framework >Affects Versions: SVN trunk >Reporter: David E. Jones >Assignee: David E. Jones >Priority: Minor > Fix For: SVN trunk > > Attachments: ecommercetenatsadd.patch, MultiTenant20100305.patch, > MultiTenant20100305.patch, MultiTenant20100305.patch > > > Support multiple tenants in a single instance of OFBiz. Each tenant will have > its own databases (one for each entity group). Database settings will > override the settings on the delegator with parameters from an entity record > so that new tenants can be added on the fly without restarting the server > (new tenants will still need to have data loaded in their databases just like > any other). > If valid Tenant ID is specified when user logs in then webapp context will be > setup with tools for that tenant as a variation of the base delegator > (including delegator, dispatcher, security, authz, visit, server hit, etc > handled for it). > Demo data includes a couple of sample tenants. After loading demo data (ant > run-install) try logging in to webtools or any other admin app with the > Tenant ID of "DEMO1". > NOTE: this patch also addresses some stability issues with the LoginWorker, > ControlServlet, Visit, and ServerHit functionality that was exposed while > developing this. For example, after a logout functionality that runs in the > ControlServlet may fail because things that were in the session before are > not there any more. In this patch there is code to rebuild the request and > session after logout (necessary for changing tenants, helpful for these other > issues). -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (OFBIZ-3540) Multi-Tenant Support (Login Based)
[ https://issues.apache.org/jira/browse/OFBIZ-3540?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David E. Jones closed OFBIZ-3540. - Resolution: Fixed The multi-tenant branch has now been merged into the trunk so the original scope of this issue is complete. Discussions about multi-tenancy in general are probably best done on the dev mailing list. > Multi-Tenant Support (Login Based) > -- > > Key: OFBIZ-3540 > URL: https://issues.apache.org/jira/browse/OFBIZ-3540 > Project: OFBiz > Issue Type: New Feature > Components: framework >Affects Versions: SVN trunk >Reporter: David E. Jones >Assignee: David E. Jones >Priority: Minor > Fix For: SVN trunk > > Attachments: ecommercetenatsadd.patch, MultiTenant20100305.patch, > MultiTenant20100305.patch, MultiTenant20100305.patch > > > Support multiple tenants in a single instance of OFBiz. Each tenant will have > its own databases (one for each entity group). Database settings will > override the settings on the delegator with parameters from an entity record > so that new tenants can be added on the fly without restarting the server > (new tenants will still need to have data loaded in their databases just like > any other). > If valid Tenant ID is specified when user logs in then webapp context will be > setup with tools for that tenant as a variation of the base delegator > (including delegator, dispatcher, security, authz, visit, server hit, etc > handled for it). > Demo data includes a couple of sample tenants. After loading demo data (ant > run-install) try logging in to webtools or any other admin app with the > Tenant ID of "DEMO1". > NOTE: this patch also addresses some stability issues with the LoginWorker, > ControlServlet, Visit, and ServerHit functionality that was exposed while > developing this. For example, after a logout functionality that runs in the > ControlServlet may fail because things that were in the session before are > not there any more. In this patch there is code to rebuild the request and > session after logout (necessary for changing tenants, helpful for these other > issues). -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (OFBIZ-3540) Multi-Tenant Support (Login Based)
[ https://issues.apache.org/jira/browse/OFBIZ-3540?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12843519#action_12843519 ] David E. Jones commented on OFBIZ-3540: --- I've added the initial code to a branch which is available at this URL: https://svn.apache.org/repos/asf/ofbiz/branches/multitenant20100310 This includes my original changes and Scott's update. With it in a branch it will be a lot easier to keep track of changes and allow others to collaborate on this. > Multi-Tenant Support (Login Based) > -- > > Key: OFBIZ-3540 > URL: https://issues.apache.org/jira/browse/OFBIZ-3540 > Project: OFBiz > Issue Type: New Feature > Components: framework >Affects Versions: SVN trunk >Reporter: David E. Jones >Assignee: David E. Jones >Priority: Minor > Fix For: SVN trunk > > Attachments: MultiTenant20100305.patch, MultiTenant20100305.patch, > MultiTenant20100305.patch > > > Support multiple tenants in a single instance of OFBiz. Each tenant will have > its own databases (one for each entity group). Database settings will > override the settings on the delegator with parameters from an entity record > so that new tenants can be added on the fly without restarting the server > (new tenants will still need to have data loaded in their databases just like > any other). > If valid Tenant ID is specified when user logs in then webapp context will be > setup with tools for that tenant as a variation of the base delegator > (including delegator, dispatcher, security, authz, visit, server hit, etc > handled for it). > Demo data includes a couple of sample tenants. After loading demo data (ant > run-install) try logging in to webtools or any other admin app with the > Tenant ID of "DEMO1". > NOTE: this patch also addresses some stability issues with the LoginWorker, > ControlServlet, Visit, and ServerHit functionality that was exposed while > developing this. For example, after a logout functionality that runs in the > ControlServlet may fail because things that were in the session before are > not there any more. In this patch there is code to rebuild the request and > session after logout (necessary for changing tenants, helpful for these other > issues). -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (OFBIZ-3540) Multi-Tenant Support (Login Based)
[ https://issues.apache.org/jira/browse/OFBIZ-3540?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12842714#action_12842714 ] David E. Jones commented on OFBIZ-3540: --- In the web.xml file you can specify a delegator name and to specify a specific tenant use a delegator name like "default#DEMO1". > Multi-Tenant Support (Login Based) > -- > > Key: OFBIZ-3540 > URL: https://issues.apache.org/jira/browse/OFBIZ-3540 > Project: OFBiz > Issue Type: New Feature > Components: framework >Affects Versions: SVN trunk >Reporter: David E. Jones >Assignee: David E. Jones >Priority: Minor > Fix For: SVN trunk > > Attachments: MultiTenant20100305.patch, MultiTenant20100305.patch, > MultiTenant20100305.patch > > > Support multiple tenants in a single instance of OFBiz. Each tenant will have > its own databases (one for each entity group). Database settings will > override the settings on the delegator with parameters from an entity record > so that new tenants can be added on the fly without restarting the server > (new tenants will still need to have data loaded in their databases just like > any other). > If valid Tenant ID is specified when user logs in then webapp context will be > setup with tools for that tenant as a variation of the base delegator > (including delegator, dispatcher, security, authz, visit, server hit, etc > handled for it). > Demo data includes a couple of sample tenants. After loading demo data (ant > run-install) try logging in to webtools or any other admin app with the > Tenant ID of "DEMO1". > NOTE: this patch also addresses some stability issues with the LoginWorker, > ControlServlet, Visit, and ServerHit functionality that was exposed while > developing this. For example, after a logout functionality that runs in the > ControlServlet may fail because things that were in the session before are > not there any more. In this patch there is code to rebuild the request and > session after logout (necessary for changing tenants, helpful for these other > issues). -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (OFBIZ-3540) Multi-Tenant Support (Login Based)
[ https://issues.apache.org/jira/browse/OFBIZ-3540?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David E. Jones updated OFBIZ-3540: -- Attachment: MultiTenant20100305.patch Attached initially complete (still fairly simple) implementation of multi-tenant support. > Multi-Tenant Support (Login Based) > -- > > Key: OFBIZ-3540 > URL: https://issues.apache.org/jira/browse/OFBIZ-3540 > Project: OFBiz > Issue Type: New Feature > Components: framework >Affects Versions: SVN trunk >Reporter: David E. Jones >Assignee: David E. Jones >Priority: Minor > Fix For: SVN trunk > > Attachments: MultiTenant20100305.patch > > > Support multiple tenants in a single instance of OFBiz. Each tenant will have > its own databases (one for each entity group). Database settings will > override the settings on the delegator with parameters from an entity record > so that new tenants can be added on the fly without restarting the server > (new tenants will still need to have data loaded in their databases just like > any other). > If valid Tenant ID is specified when user logs in then webapp context will be > setup with tools for that tenant as a variation of the base delegator > (including delegator, dispatcher, security, authz, visit, server hit, etc > handled for it). > Demo data includes a couple of sample tenants. After loading demo data (ant > run-install) try logging in to webtools or any other admin app with the > Tenant ID of "DEMO1". > NOTE: this patch also addresses some stability issues with the LoginWorker, > ControlServlet, Visit, and ServerHit functionality that was exposed while > developing this. For example, after a logout functionality that runs in the > ControlServlet may fail because things that were in the session before are > not there any more. In this patch there is code to rebuild the request and > session after logout (necessary for changing tenants, helpful for these other > issues). -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (OFBIZ-3540) Multi-Tenant Support (Login Based)
Multi-Tenant Support (Login Based) -- Key: OFBIZ-3540 URL: https://issues.apache.org/jira/browse/OFBIZ-3540 Project: OFBiz Issue Type: New Feature Components: framework Affects Versions: SVN trunk Reporter: David E. Jones Assignee: David E. Jones Priority: Minor Fix For: SVN trunk Support multiple tenants in a single instance of OFBiz. Each tenant will have its own databases (one for each entity group). Database settings will override the settings on the delegator with parameters from an entity record so that new tenants can be added on the fly without restarting the server (new tenants will still need to have data loaded in their databases just like any other). If valid Tenant ID is specified when user logs in then webapp context will be setup with tools for that tenant as a variation of the base delegator (including delegator, dispatcher, security, authz, visit, server hit, etc handled for it). Demo data includes a couple of sample tenants. After loading demo data (ant run-install) try logging in to webtools or any other admin app with the Tenant ID of "DEMO1". NOTE: this patch also addresses some stability issues with the LoginWorker, ControlServlet, Visit, and ServerHit functionality that was exposed while developing this. For example, after a logout functionality that runs in the ControlServlet may fail because things that were in the session before are not there any more. In this patch there is code to rebuild the request and session after logout (necessary for changing tenants, helpful for these other issues). -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (OFBIZ-3520) revision 897605 breaks certain delegator.find() EntityListIterator calls
[ https://issues.apache.org/jira/browse/OFBIZ-3520?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12838978#action_12838978 ] David E. Jones commented on OFBIZ-3520: --- In rev 916781 this "COUNT(DISTINCT " stuff has been disabled with some comments about the issues. You'll want to update past 916782 as well since that undoes a stupid thing I left on accident from starting to test this, before realizing that giving up is the better approach here. There are just too many issues with it. > revision 897605 breaks certain delegator.find() EntityListIterator calls > > > Key: OFBIZ-3520 > URL: https://issues.apache.org/jira/browse/OFBIZ-3520 > Project: OFBiz > Issue Type: Bug > Components: framework >Affects Versions: SVN trunk >Reporter: Adam Heath >Assignee: David E. Jones > Attachments: 897606-testcase.patch > > > We recently upgraded our internal ofbiz package to a newer trunk version, one > from the end of January. Ean then deployed that to the server it was > developing on. This broke requirements processing. I have reduced it, > however, to a simple patch, that works if I revert 897606, but breaks when it > is applied. > Test case will be attached. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (OFBIZ-3520) revision 897605 breaks certain delegator.find() EntityListIterator calls
[ https://issues.apache.org/jira/browse/OFBIZ-3520?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12838969#action_12838969 ] David E. Jones commented on OFBIZ-3520: --- When you write 897606 do you mean 897605, ie the same revision as in the header? Which revision of the trunk did you test with, the most recent? You wrote: "a newer trunk version, one from the end of January." Does that mean you updated to a trunk revision from the end of January? Also, the test case does not have any assertions, which brings up a couple of questions: 1. what happened when you ran this? (any errors, exceptions, etc?) 2. how is that different from what you expected to happen? One last thing (I think last anyway), since this deals with SQL generation that is database sensitive, which database were you running this against? > revision 897605 breaks certain delegator.find() EntityListIterator calls > > > Key: OFBIZ-3520 > URL: https://issues.apache.org/jira/browse/OFBIZ-3520 > Project: OFBiz > Issue Type: Bug > Components: framework >Affects Versions: SVN trunk >Reporter: Adam Heath >Assignee: David E. Jones > Attachments: 897606-testcase.patch > > > We recently upgraded our internal ofbiz package to a newer trunk version, one > from the end of January. Ean then deployed that to the server it was > developing on. This broke requirements processing. I have reduced it, > however, to a simple patch, that works if I revert 897606, but breaks when it > is applied. > Test case will be attached. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (OFBIZ-3486) In some cases when you pass a list of GenericValues to
[
https://issues.apache.org/jira/browse/OFBIZ-3486?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12835511#action_12835511
]
David E. Jones commented on OFBIZ-3486:
---
This is maybe unfortunate, but there is an easy work-around (a hack) that I'll
admit I've used a number of times:
With this the states variable is set in the groovy script and not by the set
action. It's basically a hack for running an inline script (which would be nice
to support under the script action, but that currently only support calling
external scripts).
Jacques: HTH
> In some cases when you pass a list of GenericValues to widget you get an error saying GenericValues are not Map
>
>
> Key: OFBIZ-3486
> URL: https://issues.apache.org/jira/browse/OFBIZ-3486
> Project: OFBiz
> Issue Type: Bug
> Components: ALL APPLICATIONS
>Affects Versions: SVN trunk
>Reporter: Jacques Le Roux
>Priority: Critical
> Fix For: SVN trunk
>
>
> In some cases when you pass a list of GenericValues to widget you get an error saying GenericValue is not Map.
> Of course this is true. But also this was working some days ago. At least it
> was working with the 909312 revision.
> It's easy to reproduce. In any OOTB form widget add these snippets:
> {code}
> type="List"/>
> {code}
> {code}
>
>
> description="${geoName}"/>
>
>
> {code}
> The error is
> cause
> -
> Exception: java.lang.ClassCastException
> Message: Not a map
> stack trace
> ---
> java.lang.ClassCastException: Not a map
> org.ofbiz.base.util.UtilGenerics.checkMap(UtilGenerics.java:77)
> org.ofbiz.widget.form.ModelFormField$ListOptions.addOptionValues(ModelFormField.java:1648)
> org.ofbiz.widget.form.ModelFormField$FieldInfoWithOptions.getAllOptionValues(ModelFormField.java:1529)
> org.ofbiz.widget.form.MacroFormRenderer.renderDropDownField(MacroFormRenderer.java:666)
> org.ofbiz.widget.form.ModelFormField$DropDownField.renderFieldString(ModelFormField.java:3043)
> org.ofbiz.widget.form.ModelFormField.renderFieldString(ModelFormField.java:595)
> org.ofbiz.widget.form.ModelForm.renderSingleFormString(ModelForm.java:1054)
> org.ofbiz.widget.form.ModelForm.renderFormString(ModelForm.java:837)
> org.ofbiz.widget.screen.ModelScreenWidget$Form.renderWidgetString(ModelScreenWidget.java:841)
> org.ofbiz.widget.screen.MacroScreenRenderer.renderScreenletSubWidget(MacroScreenRenderer.java:704)
> org.ofbiz.widget.screen.ModelScreenWidget$Screenlet.renderWidgetString(ModelScreenWidget.java:408)
> org.ofbiz.widget.screen.ModelScreenWidget.renderSubWidgetsString(ModelScreenWidget.java:137)
> org.ofbiz.widget.screen.ModelScreenWidget$DecoratorSection.renderWidgetString(ModelScreenWidget.java:704)
> org.ofbiz.widget.screen.ModelScreenWidget$SectionsRenderer.render(ModelScreenWidget.java:167)
> org.ofbiz.widget.screen.ModelScreenWidget$DecoratorSectionInclude.renderWidgetString(ModelScreenWidget.java:736)
> org.ofbiz.widget.screen.ModelScreenWidget.renderSubWidgetsString(ModelScreenWidget.java:137)
> org.ofbiz.widget.screen.ModelScreenWidget$Section.renderWidgetString(ModelScreenWidget.java:228)
> org.ofbiz.widget.screen.ModelScreenWidget.renderSubWidgetsString(ModelScreenWidget.java:137)
> org.ofbiz.widget.screen.ModelScreenWidget$DecoratorSection.renderWidgetString(ModelScreenWidget.java:704)
> org.ofbiz.widget.screen.ModelScreenWidget$SectionsRenderer.render(ModelScreenWidget.java:167)
> org.ofbiz.widget.screen.ModelScreenWidget$DecoratorSectionInclude.renderWidgetString(ModelScreenWidget.java:736)
> org.ofbiz.widget.screen.ModelScreenWidget.renderSubWidgetsString(ModelScreenWidget.java:137)
> org.ofbiz.widget.screen.ModelScreenWidget$Container.renderWidgetString(ModelScreenWidget.java:296)
> org.ofbiz.widget.screen.ModelScreenWidget.renderSubWidgetsString(ModelScreenWidget.java:137)
> org.ofbiz.widget.screen.ModelScreenWidget$Section.renderWidgetString(ModelScreenWidget.java:228)
> org.ofbiz.widget.screen.ModelScreen.renderScreenString(ModelScreen.java:394)
> org.ofbiz.widget.screen.ModelScreenWidget$IncludeScreen.renderWidgetString(ModelScreenWidget.java:576)
> org.ofbiz.widget.screen.ModelScreenWidget.renderSubWidgetsString(ModelScreenWidget.java:137)
> org.ofbiz.widget.screen.ModelScreenWidget$Section.renderWidgetString(ModelScreenWidget.java:228)
> org.ofbiz.widget.screen.ModelScreen.renderScreenString(ModelScreen.java:394)
> org.ofbiz.widget.screen.ModelScreenWidget$DecoratorScreen.renderWidgetString(ModelScreenWidget.java:672)
> org.ofbiz.widget.screen.ModelScreenWidget.renderSubWidgetsString(ModelScreenWidget.java:137)
[jira] Closed: (OFBIZ-3473) SimpleMapProcessor don't stop after the first error
[ https://issues.apache.org/jira/browse/OFBIZ-3473?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David E. Jones closed OFBIZ-3473. - Resolution: Not A Problem Fix Version/s: SVN trunk Assignee: David E. Jones The description isn't totally clear on the code that produced this behavior, but based on the description it sounds like this is what it should be doing. This patch should not be committed. If it was committed it would break and/or impede the function of existing code. The intent of simple-method validation is to allow for a set of validations to be done and then the result of all of them reported back to a user so that they don't get stuck in a frustrating loop of having to deal with one issue at a time (a real nightmare for large forms). In your simple-method you can quit any time with the check-errors operation. For more information about both of these parts of the simple-methods, please read the MiniLang Guide. > SimpleMapProcessor don't stop after the first error > --- > > Key: OFBIZ-3473 > URL: https://issues.apache.org/jira/browse/OFBIZ-3473 > Project: OFBiz > Issue Type: Bug > Components: framework >Affects Versions: SVN trunk >Reporter: Dimitri Unruh >Assignee: David E. Jones > Fix For: SVN trunk > > Attachments: SimpleMapProcess.patch > > > Hi @all, > the SimpleMapProcessor don't stop the validation for a given field after the > first error. > For example: > I need to validate a birthdate from an input field. So I process two > validation for the field: > 1. isDate > 2. isDateBeforeToday > If the string is not a proper date, the process should stop here, because the > secand validation would throw an exception. > I modified this. Hopefully you like it :) > Dimitri -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (OFBIZ-3406) Adding party relationship roles - error message is confusing.
[
https://issues.apache.org/jira/browse/OFBIZ-3406?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12798730#action_12798730
]
David E. Jones commented on OFBIZ-3406:
---
This is probably best discussed on the dev mailing list, and in fact there was
a recent discussion related to this about automatically adding users to roles
in a relationship instead of returning any sort of error message.
> Adding party relationship roles - error message is confusing.
> -
>
> Key: OFBIZ-3406
> URL: https://issues.apache.org/jira/browse/OFBIZ-3406
> Project: OFBiz
> Issue Type: Bug
> Components: party
>Affects Versions: SVN trunk
>Reporter: chris snow
>
> On a few occasions I have tried to add party relationships, but have failed
> with an error message similar to the following. The error message provided
> no help in identifying the problem:
> {code}
> Error trying to begin transaction, could not process method: The current
> transaction is marked for rollback, not beginning a new transaction and
> aborting
> current operation; the rollbackOnly was caused by: Failure in create
> operation for entity [PartyRole]: org.ofbiz.entity.GenericEntityException:
> Error while
> inserting: [GenericEntity:PartyRole][createdStamp,2010-01-11
> 14:04:02.002(java.sql.Timestamp)][createdTxStamp,2010-01-11
> 14:04:01.966(java.sql.Timestamp)][lastUpdatedStamp,2010-01-11
> 14:04:02.002(java.sql.Timestamp)][lastUpdatedTxStamp,2010-01-11
> 14:04:01.966(java.sql.Timestamp)][partyId,11(java.lang.String)][roleTypeId,_NA_(java.lang.String)]
> (SQL Exception while executing the
> following:INSERT INTO OFBIZ.PARTY_ROLE (PARTY_ID, ROLE_TYPE_ID,
> LAST_UPDATED_STAMP, LAST_UPDATED_TX_STAMP, CREATED_STAMP,
> CREATED_TX_STAMP) VALUES (?, ?, ?, ?, ?, ?) (INSERT on table 'PARTY_ROLE'
> caused a violation of foreign key constraint 'PARTY_RLE_PARTY' for
> key (11). The statement has been rolled back.)). Rolling back
> transaction.org.ofbiz.entity.GenericEntityException: Error while inserting:
> [GenericEntity:PartyRole][createdStamp,2010-01-11
> 14:04:02.002(java.sql.Timestamp)][createdTxStamp,2010-01-11
> 14:04:01.966(java.sql.Timestamp)]
> [lastUpdatedStamp,2010-01-11
> 14:04:02.002(java.sql.Timestamp)][lastUpdatedTxStamp,2010-01-11
> 14:04:01.966(java.sql.Timestamp)]
> [partyId,11(java.lang.String)][roleTypeId,_NA_(java.lang.String)] (SQL
> Exception while executing the following:INSERT INTO OFBIZ.PARTY_ROLE
> (PARTY_ID, ROLE_TYPE_ID, LAST_UPDATED_STAMP, LAST_UPDATED_TX_STAMP,
> CREATED_STAMP, CREATED_TX_STAMP) VALUES (?, ?, ?, ?,
> ?, ?) (INSERT on table 'PARTY_ROLE' caused a violation of foreign key
> constraint 'PARTY_RLE_PARTY' for key (11). The statement has been rolled
> back.)) (Error while inserting:
> [GenericEntity:PartyRole][createdStamp,2010-01-11
> 14:04:02.002(java.sql.Timestamp)][createdTxStamp,2010-01-11
> 14:04:01.966(java.sql.Timestamp)][lastUpdatedStamp,2010-01-11
> 14:04:02.002(java.sql.Timestamp)][lastUpdatedTxStamp,2010-01-11
> 14:04:01.966(java.sql.Timestamp)][partyId,11(java.lang.String)][roleTypeId,_NA_(java.lang.String)]
> (SQL Exception while executing the
> following:INSERT INTO OFBIZ.PARTY_ROLE (PARTY_ID, ROLE_TYPE_ID,
> LAST_UPDATED_STAMP, LAST_UPDATED_TX_STAMP, CREATED_STAMP,
> CREATED_TX_STAMP) VALUES (?, ?, ?, ?, ?, ?) (INSERT on table 'PARTY_ROLE'
> caused a violation of foreign key constraint 'PARTY_RLE_PARTY' for
> key (11). The statement has been rolled back.)))
> {code}
> If validation code was put into the createPartyRelationship service, a more
> friendly error message could be returned to the user:
> {code}
> short-description="createPartyRelationship">
> field="parameters.roleTypeIdFrom" value="_NA_"/>
> field="parameters.roleTypeIdTo" value="_NA_"/>
> field="parameters.partyIdFrom" from-field="userLogin.partyId"/>
> field="parameters.fromDate"/>
>
> filter-by-date="true">
> from-field="parameters.partyIdFrom"/>
> from-field="parameters.roleTypeIdFrom"/>
> from-field="parameters.partyIdTo"/>
> from-field="parameters.roleTypeIdTo"/>
>
>
>operator="not-equals" value="_NA_">
>value-field="lookedUpToPartyRole">
>from-field="parameters.partyIdTo"/>
>from-field="parameters.roleTypeIdTo"/>
>
>
>
>
>
>message="${failMessage}"/>
>
>
>operator="not-equals" value="_NA_">
>
[jira] Commented: (OFBIZ-3403) webtools xml data export to browser not working
[ https://issues.apache.org/jira/browse/OFBIZ-3403?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12798453#action_12798453 ] David E. Jones commented on OFBIZ-3403: --- The test output to the browser is XML, and the browser is probably interpreting it as HTML. Did you try a view source? > webtools xml data export to browser not working > --- > > Key: OFBIZ-3403 > URL: https://issues.apache.org/jira/browse/OFBIZ-3403 > Project: OFBiz > Issue Type: Bug > Components: framework >Affects Versions: SVN trunk >Reporter: chris snow > > Assumption, demo data is installed. > Steps: > 1) Select webtools > 2) Select XML Data Export > 3) Select "OR to Browser" > 4) Select an entity > 5) Click export > 6) Click Click Here to Get Data (or save to file) > Empty screen is shown. > In the console, the following is seen: > 2010-01-10 08:31:08,437 (TP-Processor8) [ RequestHandler.java:733:INFO ] > Rendering View [xmldsrawdump], sessionId=6B8CA710E0CBF49D7E0ED5169918187F.jvm1 > 2010-01-10 08:31:08,467 (TP-Processor8) [TransactionUtil.java:269:WARN ] > [TransactionUtil.commit] Not committing transaction, status is No Transaction > (6) > 2010-01-10 08:31:08,482 (TP-Processor8) [ ControlServlet.java:321:INFO ] > [[[xmldsrawdump] Request Done- total:0.183,since last([xmldsrawdump] > Re...):0.183]] -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (OFBIZ-3375) Adding description to checkboxes
[
https://issues.apache.org/jira/browse/OFBIZ-3375?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12793689#action_12793689
]
David E. Jones commented on OFBIZ-3375:
---
Thanks Erwan, that's a good catch. I'm not sure why that wasn't working, but
the patch looks good for fixing it.
> Adding description to checkboxes
>
>
> Key: OFBIZ-3375
> URL: https://issues.apache.org/jira/browse/OFBIZ-3375
> Project: OFBiz
> Issue Type: Improvement
> Components: ALL APPLICATIONS
>Affects Versions: SVN trunk
>Reporter: Erwan de FERRIERES
>Priority: Minor
> Fix For: SVN trunk
>
> Attachments: checkbox_after.png, checkbox_before.png, OFBIZ-3375.diff
>
>
> When using a field calling all the values, the descriptions are not displayed
> near the checkboxes, like on the checkboxes_before.png. The improvement will
> display the descriptions (checkboxes_after.png). A form has been added in
> example to show how to use it.
> {code}
>
>
>description="${description}" entity-name="ExampleType"/>
>
>
> {code}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Closed: (OFBIZ-3257) Security concern in the way to populate parameters map in the context
[ https://issues.apache.org/jira/browse/OFBIZ-3257?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David E. Jones closed OFBIZ-3257. - Resolution: Fixed Fix Version/s: SVN trunk Assignee: David E. Jones Thanks for the idea Patrick. I've made this little change in the trunk in SVN rev 890831. For now I'm planning to not change this in the release branches. > Security concern in the way to populate parameters map in the context > - > > Key: OFBIZ-3257 > URL: https://issues.apache.org/jira/browse/OFBIZ-3257 > Project: OFBiz > Issue Type: Bug > Components: framework >Affects Versions: SVN trunk >Reporter: Patrick Antivackis >Assignee: David E. Jones > Fix For: SVN trunk > > > In the parameters map available in the context, get or post parameters can > override session and application attributes. > The way to create the parameters map is the following in > UtilHttp.getCombinedMap : > combinedMap.putAll(getServletContextMap(request, namesToSkip)); // > bottom level application attributes > combinedMap.putAll(getSessionMap(request, namesToSkip));// > session overrides application > combinedMap.putAll(getParameterMap(request)); // > parameters override session > combinedMap.putAll(getAttributeMap(request)); // > attributes trump them all > I understand that session can override application attributes, but I dont > understand why Parameters can override them. > For example if you try the following : > https://localhost:8443/webtools/control/main?mainDecoratorLocation=component://ecommerce/widget/CommonScreens.xml > You will be surprised. This also mean, that whatever personal configuration > parameters you are putting in the web.xml, they can be overriden by get or > post parameters. > I propose to do the following instead : > combinedMap.putAll(getParameterMap(request)); // > parameters shouldn't override anything > combinedMap.putAll(getServletContextMap(request, namesToSkip)); // > bottom level application attributes > combinedMap.putAll(getSessionMap(request, namesToSkip));// > session overrides application > combinedMap.putAll(getAttributeMap(request)); // > attributes trump them all > What do you think ? > [from the dev list : > http://n4.nabble.com/Security-concern-in-the-way-to-populate-context-td787134.html] -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (OFBIZ-3245) Sandbox: Integrating The New Conversion Framework Into The Entity Engine
[ https://issues.apache.org/jira/browse/OFBIZ-3245?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12783206#action_12783206 ] David E. Jones commented on OFBIZ-3245: --- Then let's just use the java-type attribute, and not introduce a new one. For most (all?) databases this means that no changes will be needed to the fieldtype*.xml files. > Sandbox: Integrating The New Conversion Framework Into The Entity Engine > > > Key: OFBIZ-3245 > URL: https://issues.apache.org/jira/browse/OFBIZ-3245 > Project: OFBiz > Issue Type: Improvement > Components: framework >Affects Versions: SVN trunk >Reporter: Adrian Crum >Assignee: Adrian Crum >Priority: Minor > Attachments: conversion.patch, conversion.patch, conversion.patch, > conversion.patch > > > This issue contains a patch intended for evaluation before it is committed. > See comments for details. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (OFBIZ-3257) Security concern in the way to populate parameters map in the context
[ https://issues.apache.org/jira/browse/OFBIZ-3257?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12782985#action_12782985 ] David E. Jones commented on OFBIZ-3257: --- It could have side-effects, but nowhere that I'm aware of. Most places rely on request attributes overriding request parameters, but I don't think anything relies on request parameters overriding session attributes or application/ServletContext attributes. It doesn't seem like a logical thing to do actually, so I don't think we'll find it done anywhere. > Security concern in the way to populate parameters map in the context > - > > Key: OFBIZ-3257 > URL: https://issues.apache.org/jira/browse/OFBIZ-3257 > Project: OFBiz > Issue Type: Bug > Components: framework >Affects Versions: SVN trunk >Reporter: Patrick Antivackis > > In the parameters map available in the context, get or post parameters can > override session and application attributes. > The way to create the parameters map is the following in > UtilHttp.getCombinedMap : > combinedMap.putAll(getServletContextMap(request, namesToSkip)); // > bottom level application attributes > combinedMap.putAll(getSessionMap(request, namesToSkip));// > session overrides application > combinedMap.putAll(getParameterMap(request)); // > parameters override session > combinedMap.putAll(getAttributeMap(request)); // > attributes trump them all > I understand that session can override application attributes, but I dont > understand why Parameters can override them. > For example if you try the following : > https://localhost:8443/webtools/control/main?mainDecoratorLocation=component://ecommerce/widget/CommonScreens.xml > You will be surprised. This also mean, that whatever personal configuration > parameters you are putting in the web.xml, they can be overriden by get or > post parameters. > I propose to do the following instead : > combinedMap.putAll(getParameterMap(request)); // > parameters shouldn't override anything > combinedMap.putAll(getServletContextMap(request, namesToSkip)); // > bottom level application attributes > combinedMap.putAll(getSessionMap(request, namesToSkip));// > session overrides application > combinedMap.putAll(getAttributeMap(request)); // > attributes trump them all > What do you think ? > [from the dev list : > http://n4.nabble.com/Security-concern-in-the-way-to-populate-context-td787134.html] -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (OFBIZ-3257) Security concern in the way to populate parameters map in the context
[ https://issues.apache.org/jira/browse/OFBIZ-3257?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12782957#action_12782957 ] David E. Jones commented on OFBIZ-3257: --- My first thought was to make sure all code sensitive to things like this just doesn't use the parameters Maps that are around so much. Like the mainDecoratorLocation probably just should use that. On the other hand it's an interesting idea to allow any of the "internal" attributes to override the URL parameters. That changes the semantics a little bit, but may actually a really useful change. I've mulled this over a bit now and I can't think of any major issues with it, so I like it as a solution. If no one complains or comes up with a deal killer issue, I'd say we go for it. > Security concern in the way to populate parameters map in the context > - > > Key: OFBIZ-3257 > URL: https://issues.apache.org/jira/browse/OFBIZ-3257 > Project: OFBiz > Issue Type: Bug > Components: framework >Affects Versions: SVN trunk >Reporter: Patrick Antivackis > > In the parameters map available in the context, get or post parameters can > override session and application attributes. > The way to create the parameters map is the following in > UtilHttp.getCombinedMap : > combinedMap.putAll(getServletContextMap(request, namesToSkip)); // > bottom level application attributes > combinedMap.putAll(getSessionMap(request, namesToSkip));// > session overrides application > combinedMap.putAll(getParameterMap(request)); // > parameters override session > combinedMap.putAll(getAttributeMap(request)); // > attributes trump them all > I understand that session can override application attributes, but I dont > understand why Parameters can override them. > For example if you try the following : > https://localhost:8443/webtools/control/main?mainDecoratorLocation=component://ecommerce/widget/CommonScreens.xml > You will be surprised. This also mean, that whatever personal configuration > parameters you are putting in the web.xml, they can be overriden by get or > post parameters. > I propose to do the following instead : > combinedMap.putAll(getParameterMap(request)); // > parameters shouldn't override anything > combinedMap.putAll(getServletContextMap(request, namesToSkip)); // > bottom level application attributes > combinedMap.putAll(getSessionMap(request, namesToSkip));// > session overrides application > combinedMap.putAll(getAttributeMap(request)); // > attributes trump them all > What do you think ? > [from the dev list : > http://n4.nabble.com/Security-concern-in-the-way-to-populate-context-td787134.html] -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (OFBIZ-3245) Sandbox: Integrating The New Conversion Framework Into The Entity Engine
[ https://issues.apache.org/jira/browse/OFBIZ-3245?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12782951#action_12782951 ] David E. Jones commented on OFBIZ-3245: --- It sounds like you're still misunderstanding Adrian. Remember that you are adding the idea of supporting multiple object types externally, and that didn't exist before. The Entity Engine previously dealt with only one object type for each field type, and that object type was the same for the external API as it was for the JDBC driver. This was done by using the JDBC API to set a specific type of object when writing, and also using the JDBC API to get a specific type of object when reading. There is nothing that just does a get and lets the JDBC driver choose what sort of object to return. So, in other words there was only a need for one object type. With what you have going now, I still think there is only a need for one java object type. Having multiple attributes for this would be confusing, or at least it is to me... I still don't see an answer to the question of what you would do with the current java-type attribute if you introduced a new one, no matter what it was named. So, what would it be used for? If it's not used for anything else in your scheme, then let's use it for what it has always been used for and that is to specify the main java object type that will be used to represent a field, and in the case of supporting conversions it would be the one that we trying to convert to before setting in the JDBC API, and for getting the one we would use to get a specific object type from the JDBC API before possibly converting it to the object type requested by the calling code (if you plan to support that, possibly using existing GenericEntity.get* methods). In short, if we're changing the semantics, why does it matter what sort of interpretation you had before for the java-type attribute? Why not just use it instead of introducing something else that makes it tough to figure out what these things mean... since it sounds like there wouldn't be any sort of meaning for the java-type attribute any more. > Sandbox: Integrating The New Conversion Framework Into The Entity Engine > > > Key: OFBIZ-3245 > URL: https://issues.apache.org/jira/browse/OFBIZ-3245 > Project: OFBiz > Issue Type: Improvement > Components: framework >Affects Versions: SVN trunk >Reporter: Adrian Crum >Assignee: Adrian Crum >Priority: Minor > Attachments: conversion.patch, conversion.patch, conversion.patch, > conversion.patch > > > This issue contains a patch intended for evaluation before it is committed. > See comments for details. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (OFBIZ-3245) Sandbox: Integrating The New Conversion Framework Into The Entity Engine
[ https://issues.apache.org/jira/browse/OFBIZ-3245?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12782321#action_12782321 ] David E. Jones commented on OFBIZ-3245: --- Actually the java-type IS the object that the database driver expects. Historically it has only been used to check the incoming type and log a warning if they are different. Why not just use the java-type attribute instead of introducing a new one? Or, on the other hand, if the sql-object-type is what the conversion code will use, then what will the java-type be used for? Or am I getting this backward? > Sandbox: Integrating The New Conversion Framework Into The Entity Engine > > > Key: OFBIZ-3245 > URL: https://issues.apache.org/jira/browse/OFBIZ-3245 > Project: OFBiz > Issue Type: Improvement > Components: framework >Affects Versions: SVN trunk >Reporter: Adrian Crum >Assignee: Adrian Crum >Priority: Minor > Attachments: conversion.patch, conversion.patch, conversion.patch > > > This issue contains a patch intended for evaluation before it is committed. > See comments for details. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (OFBIZ-3245) Sandbox: Integrating The New Conversion Framework Into The Entity Engine
[ https://issues.apache.org/jira/browse/OFBIZ-3245?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12782130#action_12782130 ] David E. Jones commented on OFBIZ-3245: --- Mainly just put it in a file instead of in the db. Also though, consider using what has been used in OFBiz since the beginning, and what everyone is used to: the fieldtypes*.xml files. > Sandbox: Integrating The New Conversion Framework Into The Entity Engine > > > Key: OFBIZ-3245 > URL: https://issues.apache.org/jira/browse/OFBIZ-3245 > Project: OFBiz > Issue Type: Improvement > Components: framework >Affects Versions: SVN trunk >Reporter: Adrian Crum >Assignee: Adrian Crum >Priority: Minor > Attachments: conversion.patch, conversion.patch > > > This issue contains a patch intended for evaluation before it is committed. > See comments for details. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (OFBIZ-3245) Sandbox: Integrating The New Conversion Framework Into The Entity Engine
[ https://issues.apache.org/jira/browse/OFBIZ-3245?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12782101#action_12782101 ] David E. Jones commented on OFBIZ-3245: --- Looking at the patch there isn't anything that populates the EntityDataTypes entity, which may be related to the problem Erwan is seeing. I was looking at to see more about this idea of storing data types in the database... which I really don't like. That is a framework/technical level configuration and IMO it belongs in a file, NOT in the database. > Sandbox: Integrating The New Conversion Framework Into The Entity Engine > > > Key: OFBIZ-3245 > URL: https://issues.apache.org/jira/browse/OFBIZ-3245 > Project: OFBiz > Issue Type: Improvement > Components: framework >Affects Versions: SVN trunk >Reporter: Adrian Crum >Assignee: Adrian Crum >Priority: Minor > Attachments: conversion.patch, conversion.patch > > > This issue contains a patch intended for evaluation before it is committed. > See comments for details. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (OFBIZ-3245) Sandbox: Integrating The New Conversion Framework Into The Entity Engine
[ https://issues.apache.org/jira/browse/OFBIZ-3245?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12781285#action_12781285 ] David E. Jones commented on OFBIZ-3245: --- In C++ or Java switch statements are pretty close to free... but I'm not sure what you mean by "complicated conditionals"... and if you mean a long series of switch statements then those are certainly more expensive, especially if each if clause involved a significant compare or prepare/compare operation. Still, it is nearly nothing compared to other things that impact performance more. It's not like we're writing something to go through millions of data points already loaded into memory... No, I haven't tried to run it. > Sandbox: Integrating The New Conversion Framework Into The Entity Engine > > > Key: OFBIZ-3245 > URL: https://issues.apache.org/jira/browse/OFBIZ-3245 > Project: OFBiz > Issue Type: Improvement > Components: framework >Affects Versions: SVN trunk >Reporter: Adrian Crum >Assignee: Adrian Crum >Priority: Minor > Attachments: conversion.patch, conversion.patch > > > This issue contains a patch intended for evaluation before it is committed. > See comments for details. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (OFBIZ-3245) Sandbox: Integrating The New Conversion Framework Into The Entity Engine
[ https://issues.apache.org/jira/browse/OFBIZ-3245?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12781089#action_12781089 ] David E. Jones commented on OFBIZ-3245: --- This is an interesting change. Just to clarify: this is a change in the way the Entity Engine works from an external (ie API usage). Previously the Entity Engine expected you to pass a valid data type, would warn you if it wasn't what was expected (according to the fieldtypes*.xml file that was active), and then pass it on as-is to the JDBC driver to handle, or to blow up on. After this change the Entity Engine will attempt to convert whatever is passed in to whatever the JDBC driver expects. Quick question: why not just convert to the java-type specified in the fieldtypes*.xml file? Performance comment: doing a data type check and possible data type conversion will always be slower than what was done before; on a side note long if/else blocks do take a number of operations to work through, but switch statements are as close to free as you can get in terms of performance (usually a single low-level operation to jump to the desired code block); either way the performance impact of this will be so small compared to more expensive operations that are commonly done, like serialization/network/deserialization that the JDBC driver and database have to do, that I wouldn't expect to see any noticeable difference in performance > Sandbox: Integrating The New Conversion Framework Into The Entity Engine > > > Key: OFBIZ-3245 > URL: https://issues.apache.org/jira/browse/OFBIZ-3245 > Project: OFBiz > Issue Type: Improvement > Components: framework >Affects Versions: SVN trunk >Reporter: Adrian Crum >Assignee: Adrian Crum >Priority: Minor > Attachments: conversion.patch, conversion.patch > > > This issue contains a patch intended for evaluation before it is committed. > See comments for details. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (OFBIZ-3071) assigning security group to a party without validations
[ https://issues.apache.org/jira/browse/OFBIZ-3071?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12768372#action_12768372 ] David E. Jones commented on OFBIZ-3071: --- There are good reasons sometimes to have records with overlapping dates. The pattern generally used (hopefully always used!) for finding a unique record is to filter out all records where the current date is outside the record's date range, and also sort by the fromDate (most recent, ie highest, first). There are some nice things you can do with that, like setting up a temporary override that will become active with the fromDate comes up and will automatically revert to the previous record once the thruDate is crossed. > assigning security group to a party without validations > --- > > Key: OFBIZ-3071 > URL: https://issues.apache.org/jira/browse/OFBIZ-3071 > Project: OFBiz > Issue Type: Bug >Reporter: Abdullah Shaikh >Priority: Minor > Attachments: OFBIZ-3071_assigning security group to a party without > validations.patch > > > When adding user login to Security Group, the fromDate & thruDate input > fields are not mandatory, if not specified the fromDate is set to current > timestamop and thruDate is entered in database as null, which means the user > login is assigned that Security Group forever, but when if the same Security > Group is added, it again adds it, but instead it should check that if the > thruDate is null in the already entered record then shouldn't add new record. > If incase the thruDate is specified during the creation of 1st record then > while adding the 2nd record for the same Security Group, it should check if > the thruDate of previous record is before the fromDate of the new record, > this check also doesn't happen. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (OFBIZ-2833) Receive offline payment (May be the Entity Engine) has decimal precision problem
[ https://issues.apache.org/jira/browse/OFBIZ-2833?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12753212#action_12753212 ] David E. Jones commented on OFBIZ-2833: --- Based on the description this doesn't sound like a database problem, but rather a problem where rounding is missing in the code. My guess is that this would happen on any database... just based on the description thought, I haven't tested it. > Receive offline payment (May be the Entity Engine) has decimal precision > problem > > > Key: OFBIZ-2833 > URL: https://issues.apache.org/jira/browse/OFBIZ-2833 > Project: OFBiz > Issue Type: Bug > Components: framework, order >Affects Versions: Release Branch 9.04, SVN trunk > Environment: The Database I'm used for testing is the built in Derby. > I'm not sure if other DBMS has same problem. >Reporter: Miles Huang > > Reproduce the problem is simple. In Order Manager Application, simply enter > an offline payment for a sales order with amount $65.30, the payment amount > stored in the DB will change to $65.29. > Digging into the code, in the > org.ofbiz.order.OrderManagerEvents.receiveOfflinePayment method, although the > passed in amountStr is "65.30", the parsed out BigDecimal paymentTypeAmount > have value "65.2971578290569595992565155029296875". Checking the > payment amount stored in the Payments entity use web tools, the result is > 65.29. And the order still has $0.01 outstanding amount. > Parse the BigDecimal value from string directly may solve the problem > partially. But imagine if someone enters $65.299, the problem is still there. > Or a better and safe solution, in Entity Engine, always round half up > BigDecimal value to the same precision as the corresponding DB column before > insert/update? -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (OFBIZ-2455) Few Columns have ambiguous data size in different entities
[ https://issues.apache.org/jira/browse/OFBIZ-2455?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12751954#action_12751954 ] David E. Jones commented on OFBIZ-2455: --- Why not just get the information from the entity definitions and the data type dictionary (ie the fieldtype*.xml files). > Few Columns have ambiguous data size in different entities > -- > > Key: OFBIZ-2455 > URL: https://issues.apache.org/jira/browse/OFBIZ-2455 > Project: OFBiz > Issue Type: Bug > Components: ALL COMPONENTS >Reporter: Harmeet Bedi > Attachments: GenDataDictionary.java > > > e.g. accountName can have different size in EftAccount, PartyCarrierAccount, > PartyGroup, PayrollPreference. > Perhaps this is a typo or perhaps the name should be changed to be more > specific. e.g. eftAccountName, carrierAccountName, groupAccountName, > payrollAccountName. > unambiguous column names should help improve quality of data dictionary. > Attached is a list of ambiguous ones i know of: > entitysize.accountNumber=EftAccount:255,PartyCarrierAccount:20,PartyGroup:100,PayrollPreference:60 > entitysize.cardNumber=CreditCard:255,GiftCard:255,GiftCardFulfillment:255,ValueLinkFulfillment:60 > entitysize.city=PostalAddress:100,ZipSalesRuleLookup:60,ZipSalesTaxLookup:60 > entitysize.contentId=CommEventContentAssoc:20,Content:20,ContentApproval:20,ContentAssoc:20,ContentAttribute:20,ContentMetaData:20,ContentPurpose:20,ContentRevision:20,ContentRevisionItem:20,ContentRole:20,CustRequestContent:20,OrderContent:20,PartyContent:20,PartyResume:20,ProdConfItemContent:20,ProductCategoryContent:20,ProductContent:20,ServerHit:255,ServerHitBin:255,SubscriptionResource:20,SurveyResponseAnswer:20,WebPage:20,WebSiteContent:20,WebSitePathAlias:20,WebSitePublishPoint:20,WorkEffortContent:20 > entitysize.countryCode=CountryCapital:20,CountryCode:20,CountryTeleCode:20,TelecomNumber:10 > entitysize.description=AccommodationClass:255,AccommodationMapType:255,AccommodationSpot:255,AcctgTrans:255,AcctgTransEntry:255,AcctgTransEntryType:255,AcctgTransType:255,Agreement:255,AgreementItemType:255,AgreementTerm:255,AgreementType:255,BenefitType:255,BillingAccount:255,BudgetItemType:255,BudgetReviewResultType:255,BudgetScenario:255,BudgetType:255,CharacterSet:255,CommContentAssocType:255,CommunicationEventPrpTyp:255,CommunicationEventPurpose:255,CommunicationEventType:255,CommunicationEventWorkEff:255,ConfigOptionProductOption:255,ContactList:255,ContactListType:255,ContactMechPurposeType:255,ContactMechType:255,Container:255,ContainerType:255,Content:255,ContentAssocPredicate:255,ContentAssocType:255,ContentOperation:255,ContentPurposeType:255,ContentType:255,CostComponentCalc:255,CostComponentType:255,CurrencyDimension:255,CustRequest:255,CustRequestCategory:255,CustRequestItem:255,CustRequestResolution:255,CustRequestType:255,CustomMethod:255,CustomMethodType:255,DataResourceType:255,DataSource:255,DataSourceType:255,DataTemplateType:255,DateDimension:255,DeductionType:255,Deliverable:255,DeliverableType:255,DepreciationMethod:255,DocumentType:255,EmplLeave:255,EmplLeaveType:255,EmplPositionClassType:255,EmplPositionType:255,EmploymentAppSourceType:255,Enumeration:255,EnumerationType:255,Example:255,ExampleFeature:255,ExampleFeatureApplType:255,ExampleItem:255,ExampleType:255,Facility:255,FacilityGroup:255,FacilityGroupType:255,FacilityType:255,FinAccountTransType:255,FinAccountType:255,FixedAssetIdentType:255,FixedAssetProductType:255,FixedAssetStdCostType:255,FixedAssetType:255,GeoAssocType:255,GeoType:255,GlAccount:255,GlAccountClass:255,GlAccountGroup:255,GlAccountGroupType:255,GlAccountType:255,GlFiscalType:255,GlReconciliation:255,GlResourceType:255,GlXbrlClass:255,GoodIdentificationType:255,InventoryItemDetail:255,InventoryItemLabel:255,InventoryItemLabelType:255,InventoryItemType:255,Invoice:255,InvoiceItem:255,InvoiceItemType:255,InvoiceTerm:255,InvoiceType:255,MetaDataPredicate:255,MimeType:255,MrpEventType:255,NeedType:255,OagisMessageErrorInfo:2147483647,OrderAdjustment:255,OrderAdjustmentType:255,OrderBlacklistType:255,OrderContentType:255,OrderItemAssocType:255,OrderItemPriceInfo:255,OrderItemType:255,OrderTerm:255,OrderType:255,Party:2147483647,PartyClassification:255,PartyClassificationGroup:255,PartyClassificationType:255,PartyContentType:255,PartyNeed:255,PartyQualType:255,PartyRelationshipType:255,PartyTimeTracker:60,PartyType:255,PaymentMethod:255,PaymentMethodType:255,PaymentType:255,PerfRatingType:255,PerfReviewItemType:255,PeriodType:255,Picklist:255,PortalPage:255,PortalPortlet:255,PriorityType:255,ProdCatalogCategoryType:255,ProdConfItemContentType:255,Product:255,ProductAssocType:255,ProductCategory:255,ProductCategoryContentType:255,ProductCategoryType:255,ProductConfig:255,ProductConfigConfig:255,ProductConfigItem:255,Pr
[jira] Commented: (OFBIZ-2527) When editing items, Promotion Codes are getting deleted when we click Update Items.
[ https://issues.apache.org/jira/browse/OFBIZ-2527?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12751953#action_12751953 ] David E. Jones commented on OFBIZ-2527: --- Sorry, I haven't touched any of this stuff. If the changes are tested, really tested and not just assuming stuff will work, then there is nothing I could do that would help. As for the branch... I think the point of it is pretty clear. > When editing items, Promotion Codes are getting deleted when we click Update > Items. > --- > > Key: OFBIZ-2527 > URL: https://issues.apache.org/jira/browse/OFBIZ-2527 > Project: OFBiz > Issue Type: Improvement > Components: order >Affects Versions: SVN trunk >Reporter: Chirag Manocha >Assignee: Ashish Vijaywargiya > Fix For: Release Branch 9.04, SVN trunk > > Attachments: PromotionFix_OFBiz-2527.patch, > PromotionFix_OFBiz-2527.patch, PromotionFix_OFBiz-2527.patch, > PromotionFix_OFBiz-2527.patch > > > When edit items from order view screen and clicks on update items, the > promotion codes applied at the time of order creation, gets deleted from the > order. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (OFBIZ-2889) action list in form inheritance
[ https://issues.apache.org/jira/browse/OFBIZ-2889?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12750618#action_12750618 ] David E. Jones commented on OFBIZ-2889: --- The run-parent-actions element would have the advantage of making it possible to specify when the parent actions run, ie you could have stuff run before and/or after the parent actions. That is a big advantage... > action list in form inheritance > --- > > Key: OFBIZ-2889 > URL: https://issues.apache.org/jira/browse/OFBIZ-2889 > Project: OFBiz > Issue Type: Improvement >Reporter: Harmeet Bedi > Fix For: SVN trunk > > Attachments: ModelForm.java.diff, widget-form.xsd.diff > > > Purpose: make inheritance options more flexible and document them better for > end user consumption. > Following XSD attributes > > > If form derives from parent, form actions > may > override existing parent form actions, append to parent > form actions or ignore > parent form actions > > > > > > append form actions to list of > parent form actions > > > > > prepend form actions to list of > parent form actions > > > > > If action block exists, ignore > parent action list. > If action block does not exist use > the parent action list > > > > > > Ignore parent form actions. > Same as override with no actions > specified in actions block. > > > > > > > same for > > > > Attaching patches for xsd and ModelForm -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (OFBIZ-2872) How to get OFBiz project web site (http://docs.ofbiz.org/display/OFBADMIN/OFBiz+Related+Books) updated?
[ https://issues.apache.org/jira/browse/OFBIZ-2872?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12749079#action_12749079 ] David E. Jones commented on OFBIZ-2872: --- Creating an issue here is a fine way to go. Be careful though... if you do it enough you might just end up with the permissions to make changes yourself... ;) We can definitely use more documentation help. > How to get OFBiz project web site > (http://docs.ofbiz.org/display/OFBADMIN/OFBiz+Related+Books) updated? > --- > > Key: OFBIZ-2872 > URL: https://issues.apache.org/jira/browse/OFBIZ-2872 > Project: OFBiz > Issue Type: Question > Environment: Apache OFBiz website >Reporter: Ruth Hoffman >Priority: Minor > > Would like to add two entries to the Resources & Tools -> Books website. Who > should I contact to do that? I've got two graphics, two book summary > descriptions and contact info. > TIA > Ruth -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (OFBIZ-2813) ProductStore did not allow the default timezone to be set
[ https://issues.apache.org/jira/browse/OFBIZ-2813?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12740804#action_12740804 ] David E. Jones commented on OFBIZ-2813: --- As a side bonus, it is also much more consistent with the other settings... > ProductStore did not allow the default timezone to be set > - > > Key: OFBIZ-2813 > URL: https://issues.apache.org/jira/browse/OFBIZ-2813 > Project: OFBiz > Issue Type: Improvement > Components: product >Affects Versions: SVN trunk >Reporter: Bob Morley >Priority: Minor > Attachments: OFBIZ-2813.patch > > > The ProductStore has the defaultLocaleString and the defaultCurrencyUomId but > does not have a defaultTimeZoneString. What happens when a store is selected > (from e-commerce or the pos) is that it will look to the user for a > lastTimeZone and if that is not set, it would simply revert to the > TimeZone.getDefault() (so the timezone based on the server). > The trouble we had was that you may have an application server that is > running in a completely different timezone than what is desired for the store. > I will be attaching a patch to this ticket with changes related to this > improvement. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (OFBIZ-2747) Security : The remote web server is prone to cross-site scripting attacks.
[ https://issues.apache.org/jira/browse/OFBIZ-2747?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12733936#action_12733936 ] David E. Jones commented on OFBIZ-2747: --- Thanks Scott and Alexandre, that additional detail helps. The weird thing is: why are arbitrary parameters from the URL being put into the output HTML... will have to look into that. > Security : The remote web server is prone to cross-site scripting attacks. > --- > > Key: OFBIZ-2747 > URL: https://issues.apache.org/jira/browse/OFBIZ-2747 > Project: OFBiz > Issue Type: Bug > Components: specialpurpose/ecommerce >Affects Versions: SVN trunk >Reporter: Alexandre Mazari >Priority: Critical > > The pollbox seems to be subjet to request argument injection, without any > strip of html tags (ex : ). > Nessus scan log : > Web Server Generic XSS > Synopsis : > The remote web server is prone to cross-site scripting attacks. > Description : > The remote host is running a web server that fails to adequately > sanitize request strings of malicious JavaScript. By leveraging this > issue, an attacker may be able to cause arbitrary HTML and script code > to be executed in a user's browser within the security context of the > affected site. > See also : > http://en.wikipedia.org/wiki/Cross-site_scripting > Solution : > Contact the vendor for a patch or upgrade. > Risk factor : > Medium / CVSS Base Score : 4.3 > (CVSS2#AV:N/AC:M/Au:N/C:N/I:P/A:N) > Plugin output : > The request string used to detect this flaw was : > /?