[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-tabpanelfocusedCommentId=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:
set field=websiteContent from-field=websiteContentList[0]/
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:
set field=websiteContent value=${groovy:
org.ofbiz.entity.util.EntityUtil.getFirst(websiteContentList);}/
Instead of using like this my idea is to add a tag like first-from-list/ 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-tabpanelfocusedCommentId=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-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-tabpanelfocusedCommentId=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}
xs:attribute name=offset-style default=fetch
xs:simpleTypexs:restriction base=xs:token
xs:enumeration value=fetch/
xs:enumeration value=limit/
/xs:restriction/xs:simpleType
/xs:attribute
{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-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-tabpanelfocusedCommentId=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-tabpanelfocusedCommentId=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}
container style=forumtext
label${contentText}/label
{code}
show escaped html
{code}
* Data Sourcebr / * Marketing Campaignbr / * Tracking Affiliate
programsbr / * Segmentbr / * Contact Listbr / * Reportsbr / a
class=postlink
href=https://demo-trunk.ofbiz.apache.org/marketing/control/mainUSERNAME=flexadminPASSWORD=ofbizJavaScriptEnabled=Y;Demo
Marketing/a
{code}
replacing
{code}label${contentText}/label{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-tabpanelfocusedCommentId=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-tabpanelfocusedCommentId=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-tabpanelfocusedCommentId=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-tabpanelfocusedCommentId=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-tabpanelfocusedCommentId=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-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-tabpanelfocusedCommentId=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-4053) Implement an Entity Query Builder
[
https://issues.apache.org/jira/browse/OFBIZ-4053?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=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=25content-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=25content-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
ListEntityValue, 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()
.iterator();
{code}
A couple of issues with the
[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-tabpanelfocusedCommentId=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-tabpanelfocusedCommentId=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-tabpanelfocusedCommentId=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/service name here?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/service name here?wadl REST web service is called with URL: /webtools/control/WebService/service name here 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.WebServiceTests This has 14 different tests which are: 1. Conversion of XML-object model
[jira] Commented: (OFBIZ-3863) selectall.js jquery transformation
[ https://issues.apache.org/jira/browse/OFBIZ-3863?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=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-tabpanelfocusedCommentId=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}
calcop operator=multiply field=parameters.numberSpecified
number value=${uomConversion.conversionFactor}/
{code}
and have a value 1000 in conversionFactor you will get 1,000 for number
value. It works well if you replace by
{code}
calcop operator=multiply
calcop operator=get field=parameters.numberSpecified/
calcop operator=get field=uomConversion.conversionFactor/
{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-tabpanelfocusedCommentId=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.init(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
[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-tabpanelfocusedCommentId=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 permission-service in the service definition allows only one
permission service. I have extended the required-permissions tag to
specify more then one permission services by doing an AND/OR operation.
For instance the following code in service definition
{code}
required-permissions join-type=AND
permission-service service-name=facilityGenericPermission
main-action=CREATE/
permission-service service-name=facilityGenericPermission
main-action=UPDATE/
/required-permissions
{code}
will replace the following code in service implementation.
{code}
check-permission permission=FACILITY action=_CREATE
fail-message message=Security Error: to run
setShipmentSettingsFromPrimaryOrder you must have the FACILITY_CREATE or
FACILITY_ADMIN permission/
/check-permission
check-permission permission=FACILITY action=_UPDATE
fail-message message=Security Error: to run
setShipmentSettingsFromPrimaryOrder you must have the FACILITY_UPDATE or
FACILITY_ADMIN permission/
/check-permission
{code}
Similarly the code
{code}
required-permissions join-type=OR
permission-service service-name=facilityGenericPermission
main-action=CREATE/
permission-service service-name=facilityGenericPermission
main-action=UPDATE/
/required-permissions
{code}
will replace
{code}
check-permission permission=FACILITY action=_CREATE
alt-permission permission=FACILITY action=_UPDATE/
fail-message message=Security Error: to run createShipmentItem you must
have the FACILITY_CREATE, FACILITY_UPDATE or FACILITY_ADMIN permission/
/check-permission
check-errors/
{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-tabpanelfocusedCommentId=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 permission-service in the service definition allows only one
permission service. I have extended the required-permissions tag to
specify more then one permission services by doing an AND/OR operation.
For instance the following code in service definition
{code}
required-permissions join-type=AND
permission-service service-name=facilityGenericPermission
main-action=CREATE/
permission-service service-name=facilityGenericPermission
main-action=UPDATE/
/required-permissions
{code}
will replace the following code in service implementation.
{code}
check-permission permission=FACILITY action=_CREATE
fail-message message=Security Error: to run
setShipmentSettingsFromPrimaryOrder you must have the FACILITY_CREATE or
FACILITY_ADMIN permission/
/check-permission
check-permission permission=FACILITY action=_UPDATE
fail-message message=Security Error: to run
setShipmentSettingsFromPrimaryOrder you must have the FACILITY_UPDATE or
FACILITY_ADMIN permission/
/check-permission
{code}
Similarly the code
{code}
required-permissions join-type=OR
permission-service service-name=facilityGenericPermission
main-action=CREATE/
permission-service service-name=facilityGenericPermission
main-action=UPDATE/
/required-permissions
{code}
will replace
{code}
check-permission permission=FACILITY action=_CREATE
alt-permission permission=FACILITY action=_UPDATE/
fail-message message=Security Error: to run createShipmentItem you must
have the FACILITY_CREATE, FACILITY_UPDATE or FACILITY_ADMIN permission/
/check-permission
check-errors/
{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-tabpanelfocusedCommentId=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.init(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] 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-tabpanelfocusedCommentId=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] 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-tabpanelfocusedCommentId=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-tabpanelfocusedCommentId=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] 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] 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] 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-tabpanelfocusedCommentId=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-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-tabpanelfocusedCommentId=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-3486) In some cases when you pass a list of GenericValues to list-option in form widget you get an error saying GenericValues are not Map
[
https://issues.apache.org/jira/browse/OFBIZ-3486?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=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:
set field=foo value=${groovy: states =
org.ofbiz.common.CommonWorkers.getAssociatedStateList(delegator, null)}/
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 list-option in form
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 list-option in form
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}
set field=states value=${groovy:
org.ofbiz.common.CommonWorkers.getAssociatedStateList(delegator, null)}
type=List/
{code}
{code}
field name=stateProvinceGeoId
drop-down allow-empty=false
list-options list-name=states key-name=geoId
description=${geoName}/
/drop-down
/field
{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)
[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-tabpanelfocusedCommentId=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}
simple-method method-name=createPartyRelationship
short-description=createPartyRelationship
if-empty field=parameters.roleTypeIdFromset
field=parameters.roleTypeIdFrom value=_NA_//if-empty
if-empty field=parameters.roleTypeIdToset
field=parameters.roleTypeIdTo value=_NA_//if-empty
if-empty field=parameters.partyIdFromset
field=parameters.partyIdFrom from-field=userLogin.partyId//if-empty
if-empty field=parameters.fromDatenow-timestamp
field=parameters.fromDate//if-empty
!-- check if not already exist --
entity-and entity-name=PartyRelationship list=partyRels
filter-by-date=true
field-map field-name=partyIdFrom
from-field=parameters.partyIdFrom/
field-map field-name=roleTypeIdFrom
from-field=parameters.roleTypeIdFrom/
field-map field-name=partyIdTo
from-field=parameters.partyIdTo/
field-map field-name=roleTypeIdTo
from-field=parameters.roleTypeIdTo/
/entity-and
!-- MORE HELPFUL ERROR MESSAGE START --
if-compare field=parameters.roleTypeIdTo
operator=not-equals value=_NA_
entity-one entity-name=PartyRole
[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-tabpanelfocusedCommentId=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-tabpanelfocusedCommentId=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}
field name=ExampleTypeId
check
entity-options key-field-name=exampleTypeId
description=${description} entity-name=ExampleType/
/check
/field
{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-tabpanelfocusedCommentId=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-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-tabpanelfocusedCommentId=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-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-tabpanelfocusedCommentId=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-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-tabpanelfocusedCommentId=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-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-tabpanelfocusedCommentId=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-tabpanelfocusedCommentId=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-tabpanelfocusedCommentId=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-tabpanelfocusedCommentId=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-tabpanelfocusedCommentId=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-tabpanelfocusedCommentId=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-tabpanelfocusedCommentId=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-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-tabpanelfocusedCommentId=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-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-tabpanelfocusedCommentId=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
[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-tabpanelfocusedCommentId=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 xs:attribute name=extends-actions default=override xs:annotation xs:documentationIf form derives from parent, form actions may override existing parent form actions, append to parent form actions or ignore parent form actions/xs:documentation /xs:annotation xs:simpleType xs:restriction base=xs:token xs:enumeration value=append xs:annotation xs:documentationappend form actions to list of parent form actions/xs:documentation /xs:annotation /xs:enumeration xs:enumeration value=prepend xs:annotation xs:documentationprepend form actions to list of parent form actions/xs:documentation /xs:annotation /xs:enumeration xs:enumeration value=override xs:annotation xs:documentationIf action block exists, ignore parent action list. If action block does not exist use the parent action list /xs:documentation /xs:annotation /xs:enumeration xs:enumeration value=ignore xs:annotation xs:documentationIgnore parent form actions. Same as override with no actions specified in actions block. /xs:documentation /xs:annotation /xs:enumeration /xs:restriction /xs:simpleType /xs:attribute same for xs:attribute name=extends-row-actions default=override /xs:attribute 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-tabpanelfocusedCommentId=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-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-tabpanelfocusedCommentId=12733892#action_12733892 ] David E. Jones commented on OFBIZ-2747: --- Which version/revision of OFBiz did you test? What was the actual URL the request went to and what data was submitted? If you're reporting this based on the general testing a few years ago, and this is not a newer issue, then this has already been thoroughly fixed. For more details search for XSS here in Jira and also on the OFBiz dev mailing list. There are a number of Jira issues, and dozens of messages (including some with very detailed discussions of the problem and solution). Please looks into this and comment about whether or not this is still an issue. If it is an issue we need a list of steps to reproduce, because if you try this in general right now you'll see that the HTML is either not accepted, or that the script and other elements are filtered out (depending on if the field you enter text into has HTML not allowed or safe HTML allowed). Also, we need to know exactly which output screen is not encoding the HTML output because all of that should too, except cases where it is explicitly allowed because it is expected that HTML will be coming from the database (like managed content). 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 : script). 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 : /?scriptcross_site_scripting.nasl/script The output was : HTTP/1.1 200 OK Server: Apache-Coyote/1.1 X-Powered-By: JSP/2.1 Set-Cookie: OFBiz.Visitor=12065; Expires=Wed, 21-Jul-2010 21:31:20 GMT; Path=/ Content-Type: text/html;charset=UTF-8 Transfer-Encoding: chunked Date: Tue, 21 Jul 2009 21:31:19 GMT [...] h3Mouse Hand Poll/h3 div class=screenlet-body form method=post action=/control/minipoll/main style=margin: 0; input type=hidden name=scriptcross_site_scripting.nasl/script value=/ input type=hidden name=surveyId value=1004/ table width=100% border=0 cellpadding=2 cellspacing=0 [...] CVE : CVE-2002-1060, CVE-2003-1543, CVE-2005-2453, CVE-2006-1681 BID : 5305, 7344, 7353, 8037, 14473, 17408 Other references : OSVDB:4989, OSVDB:18525, OSVDB:24469, OSVDB:42314 Nessus ID : 10815 -- 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-tabpanelfocusedCommentId=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 : script). 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 : /?scriptcross_site_scripting.nasl/script The output was : HTTP/1.1 200 OK Server: Apache-Coyote/1.1 X-Powered-By: JSP/2.1 Set-Cookie: OFBiz.Visitor=12065; Expires=Wed, 21-Jul-2010 21:31:20 GMT; Path=/ Content-Type: text/html;charset=UTF-8 Transfer-Encoding: chunked Date: Tue, 21 Jul 2009 21:31:19 GMT [...] h3Mouse Hand Poll/h3 div class=screenlet-body form method=post action=/control/minipoll/main style=margin: 0; input type=hidden name=scriptcross_site_scripting.nasl/script value=/ input type=hidden name=surveyId value=1004/ table width=100% border=0 cellpadding=2 cellspacing=0 [...] CVE : CVE-2002-1060, CVE-2003-1543, CVE-2005-2453, CVE-2006-1681 BID : 5305, 7344, 7353, 8037, 14473, 17408 Other references : OSVDB:4989, OSVDB:18525, OSVDB:24469, OSVDB:42314 Nessus ID : 10815 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (OFBIZ-2657) 'from emailadress' baseurl baseSecureUrl defined in many places and therefore difficult to maintain
[ https://issues.apache.org/jira/browse/OFBIZ-2657?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12724569#action_12724569 ] David E. Jones commented on OFBIZ-2657: --- How will this relate to the stuff in url.properties? 'from emailadress' baseurl baseSecureUrl defined in many places and therefore difficult to maintain --- Key: OFBIZ-2657 URL: https://issues.apache.org/jira/browse/OFBIZ-2657 Project: OFBiz Issue Type: Improvement Components: ALL COMPONENTS Affects Versions: Release Branch 9.04 Reporter: Hans Bakker Fix For: Release Branch 9.04 Currently many entities have a 'from emailaddress' defined. That is fine if it is used for an override of a default 'from address' which is however missing. the proposal is to add a 'default.from.emailaddress' to the general.properties file and change the seed/demo data to have the 'from emailaddresss' not defined(null). Obviously change the programs that when this field is null it should take it from the general properties file. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (OFBIZ-2657) 'from emailadress' baseurl baseSecureUrl defined in many places and therefore difficult to maintain
[ https://issues.apache.org/jira/browse/OFBIZ-2657?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12724794#action_12724794 ] David E. Jones commented on OFBIZ-2657: --- Please no. The URL settings have been in the url.properties file for about 8 years now, and various documentation points to them (such as the technical production setup guide, and various others). Also, please note that there are URL fields on the WebSite entity that override the fields in the url.properties file. 'from emailadress' baseurl baseSecureUrl defined in many places and therefore difficult to maintain --- Key: OFBIZ-2657 URL: https://issues.apache.org/jira/browse/OFBIZ-2657 Project: OFBiz Issue Type: Improvement Components: ALL COMPONENTS Affects Versions: Release Branch 9.04 Reporter: Hans Bakker Fix For: Release Branch 9.04 Currently many entities have a 'from emailaddress' defined. That is fine if it is used for an override of a default 'from address' which is however missing. the proposal is to add a 'default.from.emailaddress' to the general.properties file and change the seed/demo data to have the 'from emailaddresss' not defined(null). Obviously change the programs that when this field is null it should take it from the general properties file. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (OFBIZ-2657) 'from emailadress' defined in many places and therefore difficult to maintain
[ https://issues.apache.org/jira/browse/OFBIZ-2657?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12723890#action_12723890 ] David E. Jones commented on OFBIZ-2657: --- About the seed data loading causing the data to be set back: that is what the seed-initial data loader is for, ie those will only be loaded once. 'from emailadress' defined in many places and therefore difficult to maintain - Key: OFBIZ-2657 URL: https://issues.apache.org/jira/browse/OFBIZ-2657 Project: OFBiz Issue Type: Improvement Components: ALL COMPONENTS Affects Versions: Release Branch 9.04 Reporter: Hans Bakker Fix For: Release Branch 9.04 Currently many entities have a 'from emailaddress' defined. That is fine if it is used for an override of a default 'from address' which is however missing. the proposal is to add a 'default.from.emailaddress' to the general.properties file and change the seed/demo data to have the 'from emailaddresss' not defined(null). Obviously change the programs that when this field is null it should take it from the general properties file. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (OFBIZ-2645) allow-html in service validation is too restrictive
[ https://issues.apache.org/jira/browse/OFBIZ-2645?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12722656#action_12722656 ] David E. Jones commented on OFBIZ-2645: --- OFBiz already has functionality to encode output in addition to the functionality that filters input. In discussions about this security aspect of the project we decided that doing both would be best, especially since there are possibilities of holes for both filtering input and encoding output. Please consider that we want the defaults to be as secure as possible and allow ways of doing things in a less restricted way when it is needed. If you find a field that needs to have HTML or special characters related to HTML then change the allow-html attribute to support that. In general I would say no, it would not be a good idea to relax the default security. Is there a specific place where you have run into this and would like to discuss a change for that, or are you mostly just looking at things generally? If we do want to consider changing this general policy we should have a discussion on the mailing list and see what people think. If there is a general consensus then we will go with that, and if not we can always vote on it. The best way to start such a discussion would be to write up a proposal and send it to the mailing list. allow-html in service validation is too restrictive --- Key: OFBIZ-2645 URL: https://issues.apache.org/jira/browse/OFBIZ-2645 Project: OFBiz Issue Type: Bug Components: framework Affects Versions: SVN trunk Reporter: Harmeet Bedi Fix For: SVN trunk Attachments: allow-html.diff Service 'IN' parameters are validated. Default is allow-html='none' This filters out all the html chars. e.g one cannot set this text Tom's age is likely Paul's age '' is not allowed Rederers already escape html, so it may be best to keep validation alllow-html='any'. If service has a need to constrain, service should specify allow-html explicitly. Attaching patch. Please let me if this does not make sense. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (OFBIZ-2640) Anonymous user should be able to verify and unsubscribe his email address from Contact List subscription
[ https://issues.apache.org/jira/browse/OFBIZ-2640?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12722200#action_12722200 ] David E. Jones commented on OFBIZ-2640: --- If something does not exist, how can it have a bug in it? I believe Ashish is correct: this is a new feature (an extension of an existing feature), and not a bug. The current contact list subscription stuff was not designed to handle anonymous users. Anonymous user should be able to verify and unsubscribe his email address from Contact List subscription Key: OFBIZ-2640 URL: https://issues.apache.org/jira/browse/OFBIZ-2640 Project: OFBiz Issue Type: New Feature Components: specialpurpose/ecommerce Affects Versions: Release Branch 9.04, SVN trunk Reporter: Ashish Nagar Assignee: Ashish Vijaywargiya Fix For: Release Branch 9.04, SVN trunk When anonymous user signs up for newsletter, no verification mail is sent to the user. The partyId is set to _NA_ and the statusId is set to CLPT_ACCEPTED in the ContactListParty entity. A verification mail should be sent to the email address entered for sign up by the anonymous user, so that he should be able to verify his email address before getting it subscribed for Contact List. The mail will contain a link following which an anonymous user should be able to subscribe and unsubscribe for newsletter subscription. Any comments would be appreciated. Thanks Regards, -- Ashish Nagar -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (OFBIZ-1172) Order Entry unclear error when no ProductStore set
[ https://issues.apache.org/jira/browse/OFBIZ-1172?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12721395#action_12721395 ] David E. Jones commented on OFBIZ-1172: --- Yes, this does sound like a bug. I remember that at one point things had to be changed to get information from other places for a purchase order, and it may be that something else is creeped and that will have to be changed. Has anyone looked into this yet, i.e. where the code is that it is depending on a product store for a purchase order? Order Entry unclear error when no ProductStore set -- Key: OFBIZ-1172 URL: https://issues.apache.org/jira/browse/OFBIZ-1172 Project: OFBiz Issue Type: Improvement Components: order Affects Versions: Release Branch 4.0, SVN trunk Reporter: Wickersheimer Jeremy Priority: Minor Attachments: ofbiz-1172.patch I ran into this issue because our staff accidentally removed the ProductStore from the OrderEntry Website. The symptom was an java NPE display when trying to create a Purchase Order. Because it took me some time to debug it i wrote a patch to make this behavior more obvious. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (OFBIZ-2606) Setup a new SecurityGroup specific for Accounting component.
[ https://issues.apache.org/jira/browse/OFBIZ-2606?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12719434#action_12719434 ] David E. Jones commented on OFBIZ-2606: --- About this record: RoleType description=Accountant hasTable=N parentTypeId=EMPLOYEE roleTypeId=ACCOUNTANT/ Is an Accountant really always an Employee? Just off the top of my head I can think of a number of small and large companies that provide accounting services... and they don't do so as employees of their clients. Setup a new SecurityGroup specific for Accounting component. Key: OFBIZ-2606 URL: https://issues.apache.org/jira/browse/OFBIZ-2606 Project: OFBiz Issue Type: Improvement Components: accounting Affects Versions: SVN trunk Reporter: Sumit Pandit Priority: Minor Attachments: OFBIZ_2606.patch To setup of a new SecurityGroup which is dedicated to Accounting component only. It will assigned by all SecurityPermission which are required to handle variuos accounting operations. Purpose of this will be to be able to create a UserLogin, who will have restricted access to Accounting component only. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (OFBIZ-2601) checkStoreCustomerRole support is incomplete.
[ https://issues.apache.org/jira/browse/OFBIZ-2601?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12719071#action_12719071 ] David E. Jones commented on OFBIZ-2601: --- The point of the require customer role option on the ProductStore is to restrict access to certain stores, ie so that only customers associated with the store can login there. When using that option ProductStoreRole records should NOT be added automatically because the whole point is to be able to specify a limited set of customers that are able to access the store. checkStoreCustomerRole support is incomplete. - Key: OFBIZ-2601 URL: https://issues.apache.org/jira/browse/OFBIZ-2601 Project: OFBiz Issue Type: Improvement Components: product Affects Versions: Release Branch 9.04, SVN trunk Reporter: BJ Freeman Fix For: Release Branch 9.04, SVN trunk This goes back to Jria 503. there is no supporting CRUD tied into supporting this feature. so if the a customer signs up they are not associated wih the product store thru the productstorerole. the Require Customer Role in product store is set to N -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (OFBIZ-2577) typos in serverstats.properties
[ https://issues.apache.org/jira/browse/OFBIZ-2577?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12718531#action_12718531 ] David E. Jones commented on OFBIZ-2577: --- Yes, I agree we should just change it to false instead of ftrue. It's not worth the hassle trying to explain it... typos in serverstats.properties --- Key: OFBIZ-2577 URL: https://issues.apache.org/jira/browse/OFBIZ-2577 Project: OFBiz Issue Type: Bug Components: framework Affects Versions: Release Branch 9.04, SVN trunk Reporter: BJ Freeman Priority: Minor Fix For: Release Branch 9.04, SVN trunk Attachments: OFBIZ-2577-serverstat.patch found some ftrue typos corrected them -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Assigned: (OFBIZ-2577) typos in serverstats.properties
[ https://issues.apache.org/jira/browse/OFBIZ-2577?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David E. Jones reassigned OFBIZ-2577: - Assignee: (was: David E. Jones) typos in serverstats.properties --- Key: OFBIZ-2577 URL: https://issues.apache.org/jira/browse/OFBIZ-2577 Project: OFBiz Issue Type: Bug Components: framework Affects Versions: Release Branch 9.04, SVN trunk Reporter: BJ Freeman Priority: Minor Fix For: Release Branch 9.04, SVN trunk Attachments: OFBIZ-2577-serverstat.patch found some ftrue typos corrected them -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Reopened: (OFBIZ-2577) typos in serverstats.properties
[ https://issues.apache.org/jira/browse/OFBIZ-2577?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David E. Jones reopened OFBIZ-2577: --- typos in serverstats.properties --- Key: OFBIZ-2577 URL: https://issues.apache.org/jira/browse/OFBIZ-2577 Project: OFBiz Issue Type: Bug Components: framework Affects Versions: Release Branch 9.04, SVN trunk Reporter: BJ Freeman Priority: Minor Fix For: Release Branch 9.04, SVN trunk Attachments: OFBIZ-2577-serverstat.patch found some ftrue typos corrected them -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (OFBIZ-2577) typos in serverstats.properties
[ https://issues.apache.org/jira/browse/OFBIZ-2577?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David E. Jones closed OFBIZ-2577. - Resolution: Won't Fix Assignee: David E. Jones This isn't a typo. Anything but true is false, and this makes it easier to edit. typos in serverstats.properties --- Key: OFBIZ-2577 URL: https://issues.apache.org/jira/browse/OFBIZ-2577 Project: OFBiz Issue Type: Bug Components: framework Affects Versions: Release Branch 9.04, SVN trunk Reporter: BJ Freeman Assignee: David E. Jones Priority: Minor Fix For: Release Branch 9.04, SVN trunk Attachments: OFBIZ-2577-serverstat.patch found some ftrue typos corrected them -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Assigned: (OFBIZ-2570) Parties associated to the shipment should also go with creation of shipment
[ https://issues.apache.org/jira/browse/OFBIZ-2570?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David E. Jones reassigned OFBIZ-2570: - Assignee: David E. Jones Parties associated to the shipment should also go with creation of shipment --- Key: OFBIZ-2570 URL: https://issues.apache.org/jira/browse/OFBIZ-2570 Project: OFBiz Issue Type: Improvement Components: product Affects Versions: SVN trunk Reporter: Pranay Pandey Assignee: David E. Jones Fix For: SVN trunk Attachments: Shipment_Party_OFBIZ-2570.patch Parties associated to the shipment should also go with creation of shipment in following processes: 1. Verfy Pick 2. Packing 3. Quick Ship When shipment is created during these processes then parties associated to it (partyIdTo, partyIdFrom) should also go with it. -- Pranay Pandey -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (OFBIZ-2570) Parties associated to the shipment should also go with creation of shipment
[ https://issues.apache.org/jira/browse/OFBIZ-2570?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12716828#action_12716828 ] David E. Jones commented on OFBIZ-2570: --- Based on a quick read through the patch this looks good Pranay. Parties associated to the shipment should also go with creation of shipment --- Key: OFBIZ-2570 URL: https://issues.apache.org/jira/browse/OFBIZ-2570 Project: OFBiz Issue Type: Improvement Components: product Affects Versions: SVN trunk Reporter: Pranay Pandey Fix For: SVN trunk Attachments: Shipment_Party_OFBIZ-2570.patch Parties associated to the shipment should also go with creation of shipment in following processes: 1. Verfy Pick 2. Packing 3. Quick Ship When shipment is created during these processes then parties associated to it (partyIdTo, partyIdFrom) should also go with it. -- Pranay Pandey -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (OFBIZ-2570) Parties associated to the shipment should also go with creation of shipment
[ https://issues.apache.org/jira/browse/OFBIZ-2570?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David E. Jones closed OFBIZ-2570. - Resolution: Fixed This is in SVN, in the trunk, in rev 782190. This won't go into the release branch as it is new functionality. However, this does seem to be a bit of a grey area so if anyone feels it should be otherwise let's discuss it. Parties associated to the shipment should also go with creation of shipment --- Key: OFBIZ-2570 URL: https://issues.apache.org/jira/browse/OFBIZ-2570 Project: OFBiz Issue Type: Improvement Components: product Affects Versions: SVN trunk Reporter: Pranay Pandey Assignee: David E. Jones Fix For: SVN trunk Attachments: Shipment_Party_OFBIZ-2570.patch Parties associated to the shipment should also go with creation of shipment in following processes: 1. Verfy Pick 2. Packing 3. Quick Ship When shipment is created during these processes then parties associated to it (partyIdTo, partyIdFrom) should also go with it. -- Pranay Pandey -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (OFBIZ-2502) Add functionality for store credit either in fin account or billing account while performing return.
[ https://issues.apache.org/jira/browse/OFBIZ-2502?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12715978#action_12715978 ] David E. Jones commented on OFBIZ-2502: --- How this is described to work looks great. It's wonderful to finally have support for this OOTB! Add functionality for store credit either in fin account or billing account while performing return. Key: OFBIZ-2502 URL: https://issues.apache.org/jira/browse/OFBIZ-2502 Project: OFBiz Issue Type: Improvement Components: order Affects Versions: SVN trunk Reporter: Santosh Malviya Priority: Minor Fix For: SVN trunk Attachments: FinAccountOrBillingAccount.patch, OFBIZ-2502.patch Currently OFBiz creates a Store Credit as a Payment associated with a Billing Account (creating a new BA if one doesn't already exist). Do same for fin account. Following are the steps to do this: (1) Add a field to the ProductStore entity to specify whether returns should go on a Financial Account or a Billing Account. (2) Extend the processCreditReturn service to look at that setting and if set for a Financial Account find one for the customer (create one if necessary) and add a credit transaction to it for the credit and associate that credit transaction to the ReturnItem it came from (just like currently done with BillingAccount Payment). -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (OFBIZ-2559) NamingServiceContainer binds to all network interfaces
[ https://issues.apache.org/jira/browse/OFBIZ-2559?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12715981#action_12715981 ] David E. Jones commented on OFBIZ-2559: --- This looks pretty good Deyan. +1 from me. NamingServiceContainer binds to all network interfaces -- Key: OFBIZ-2559 URL: https://issues.apache.org/jira/browse/OFBIZ-2559 Project: OFBiz Issue Type: Improvement Components: framework Affects Versions: Release Branch 9.04 Reporter: Deyan Attachments: NamingServiceContainer_rmi_registry_bind_interface.patch, NamingServiceContainer_rmi_registry_bind_interface_v2.patch, Tabs_Issue.png org.ofbiz.base.container.NamingServiceContainer by default binds a server socket to all available network interfaces. Configuration of this container is done in framework/base/config/ofbiz-containers.xml !-- load the naming (JNDI) server -- container name=naming-container class=org.ofbiz.base.container.NamingServiceContainer property name=port value=1099/ /container Only the port can be configured. Additional configuration property needs to be implemented: property name=host value=0.0.0.0/ -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (OFBIZ-2480) Item should not be shown if it is out of stock
[ https://issues.apache.org/jira/browse/OFBIZ-2480?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12712143#action_12712143 ] David E. Jones commented on OFBIZ-2480: --- I agree, we need this to be configurable and the default in the trunk should be that out of stock items ARE shown (which has been the default as far back as I can remember). This should definitely go on the ProductStore, where it can be with similar inventory fields, like the requireInventory field which determines whether or not to allow an add-to-cart when an item is out of stock. This should not go in a properties file... in fact we have a general direction in the project of moving business-level configurations (as opposed to technical-level ones) from properties files to the database and not the other way around. Item should not be shown if it is out of stock -- Key: OFBIZ-2480 URL: https://issues.apache.org/jira/browse/OFBIZ-2480 Project: OFBiz Issue Type: New Feature Components: order, product Affects Versions: SVN trunk Reporter: Vivek Mishra Assignee: Vikas Mayur Fix For: SVN trunk Attachments: ItemShouldNotBeShown_OFBIZ-2480.patch, ItemShouldNotBeShown_OFBIZ-2480.patch Item should not be shown if it is out of stock. Usually pages which shows multiple products do not perform inventory check. Add a service which will run timely and perform the check for the status of the product availability in inventory and set the flag in product entity accordingly. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (OFBIZ-2379) Encrypt EFT Account number
[ https://issues.apache.org/jira/browse/OFBIZ-2379?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12707757#action_12707757 ] David E. Jones commented on OFBIZ-2379: --- Thanks Hans, that's a good point. For a reason why to NOT encrypt it: if it is encrypted we cannot have the database do a query on that field, so we can't effectively search it without going through EVERY record, decrypting, and then doing the compare. Encrypt EFT Account number -- Key: OFBIZ-2379 URL: https://issues.apache.org/jira/browse/OFBIZ-2379 Project: OFBiz Issue Type: Improvement Components: accounting Affects Versions: SVN trunk Reporter: Wickersheimer Jeremy Assignee: Jacques Le Roux Priority: Minor Fix For: SVN trunk Attachments: 2379.patch Account numbers could be encrypted just like credit card numbers. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (OFBIZ-2418) entity-engine-transform-xml does not support component:// notation?
[ https://issues.apache.org/jira/browse/OFBIZ-2418?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David E. Jones closed OFBIZ-2418. - Resolution: Fixed This should be fixed now, with SVN rev 771193 in the trunk and 771196 in the release09.04 branch. entity-engine-transform-xml does not support component:// notation? --- Key: OFBIZ-2418 URL: https://issues.apache.org/jira/browse/OFBIZ-2418 Project: OFBiz Issue Type: Bug Components: specialpurpose/ecommerce Affects Versions: Release Branch 4.0, Release Branch 9.04 Reporter: Hans Bakker Assignee: David E. Jones Fix For: Release Branch 4.0, Release Branch 9.04 now the classpath has been changed the demo files DemoTree.xml, DemoContent.xml and DemoTopic do not load anymore. I modified these files, but still the files are not found -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (OFBIZ-2383) Security Re-Implementation - New Seed Data
[ https://issues.apache.org/jira/browse/OFBIZ-2383?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David E. Jones updated OFBIZ-2383: -- Attachment: AuthzExampleComponentSupport.patch Patch to show use of new security in the example component since that is reverted. Note that this can be produced with a svn diff -r 770083:r770408 AuthzExampleComponentSupport.patch from the ofbiz/framework/exmaple directory. Security Re-Implementation - New Seed Data -- Key: OFBIZ-2383 URL: https://issues.apache.org/jira/browse/OFBIZ-2383 Project: OFBiz Issue Type: Improvement Components: ALL COMPONENTS Affects Versions: SVN trunk Reporter: Andrew Zeneski Fix For: SVN trunk Attachments: AuthzExampleComponentSupport.patch Parent task for seed data definitions for new Authorization API -- see http://docs.ofbiz.org/x/JR4 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (OFBIZ-2388) Add a page that shows orders with the pick sheet printed date field
[ https://issues.apache.org/jira/browse/OFBIZ-2388?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12704927#action_12704927 ] David E. Jones commented on OFBIZ-2388: --- Question from Divesh: But here the confusion is , Entries in ItemIssuance Entity is not done when we do Verify Pick (only done when shipment is created in Packed status). So Entries are not present in ItemIssuance entity for Orders which have shipment in Input, Picked, and Scheduled status. So IMO above given logic will not help . Please let me know if I am wrong. Answer from David: When an OrderItem is added to a Shipment there should ALWAYS be an ItemIssuance along with it. Why is that not done in the Verify Pick process like it is for the Packing screens that those are based on? The main service called for this is the issueOrderItemShipGrpInvResToShipment service, and it is called from the AddItemsFromOrder screen for manual shipments, and the issueItemToShipment method in the PackingSession.java class. In other words, the best solution to that problem would be to issue the items to the shipment as they are marked picked. In fact, how else would you keep track of them? Add a page that shows orders with the pick sheet printed date field - Key: OFBIZ-2388 URL: https://issues.apache.org/jira/browse/OFBIZ-2388 Project: OFBiz Issue Type: Sub-task Components: product Affects Versions: SVN trunk Reporter: Pranay Pandey Assignee: Vikas Mayur Fix For: SVN trunk Attachments: ofbiz-2388.patch * Add page that shows orders with the pick sheet printed date field set that do not have a Shipment associated with them that is in the Input or Scheduled statuses (should be in Input status, but just in case Scheduled is eventually used), sorted by the oldest date first to see the ones that have gone the longest without being picked and verified. * Link to new page from the PicklistOptions page. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (OFBIZ-2388) Add a page that shows orders with the pick sheet printed date field
[ https://issues.apache.org/jira/browse/OFBIZ-2388?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12704114#action_12704114 ] David E. Jones commented on OFBIZ-2388: --- The way this is implemented will not scale adequately for deployments with large numbers of orders. In the ReviewOrdersNotPickedOrPacked.groovy file the first line of code gets ALL OrderHeader records from the database, ie: orderHeaders = delegator.findList(OrderHeader, null, null, null, null, false); This is not acceptable as there could be hundreds of thousands of millions of orders in the database, and so this line will fail. Later on down in the file the code looks for Shipment records with a primaryOrderId that matches the orderId on each OrderHeader, and then looks at other things on the Shipment record(s) corresponding. All of this can, and should, be done with a view entity. In fact, it must be done with a view entity so that the work is done in a query in the database and not in a script on the app server which is hugely inefficient, so much so that in even moderately large systems it simply WILL NOT WORK! An addition note: looking for shipments by matching the OrderHeader.orderId with the Shipment.primaryOrderId is not adequate. Please change it to match the OrderHeader.orderId with the ItemIssuance.orderId and then ItemIssuance.shipmentId with Shipment.shipmentId. Not that there will be many records for a single OrderHeader and Shipment combination since the ItemIssuance really ties a OrderItem to a ShipmentItem, but that is fine since in this case all we care about is the OrderHeader to Shipment relationship. Why do we need this? Because it is possible for a single Shipment to have items from different orders on it, and simply looking at the Shipment.primaryOrderId won't capture that... that field is only the PRIMARY orderId. Add a page that shows orders with the pick sheet printed date field - Key: OFBIZ-2388 URL: https://issues.apache.org/jira/browse/OFBIZ-2388 Project: OFBiz Issue Type: Sub-task Components: product Affects Versions: SVN trunk Reporter: Pranay Pandey Assignee: Vikas Mayur Fix For: SVN trunk Attachments: ofbiz-2388.patch * Add page that shows orders with the pick sheet printed date field set that do not have a Shipment associated with them that is in the Input or Scheduled statuses (should be in Input status, but just in case Scheduled is eventually used), sorted by the oldest date first to see the ones that have gone the longest without being picked and verified. * Link to new page from the PicklistOptions page. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (OFBIZ-2288) Update the image / content scroller on index.html
[ https://issues.apache.org/jira/browse/OFBIZ-2288?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12701068#action_12701068 ] David E. Jones commented on OFBIZ-2288: --- Thanks Ryan, that's a great improvement. There are a couple of issues with this submission: 1. the index.patch file appears to undo a number of changes in recent revision to the index.html file; did you update before making changes to the file and work on a file that was checked out from SVN (ie as opposed to an older copy of the file that was not from SVN)? 2. what are we supposed to do with the images.zip file? generally for changes do what you can in the patch and then attach an archive with only the images/etc to add, plus a list of images/etc to remove Update the image / content scroller on index.html - Key: OFBIZ-2288 URL: https://issues.apache.org/jira/browse/OFBIZ-2288 Project: OFBiz Issue Type: Improvement Components: site Affects Versions: SVN trunk Reporter: Tim Ruppert Assignee: Tim Ruppert Fix For: SVN trunk Attachments: images.zip, index.patch, ofbizSiteTemplate.zip Currently there is a JavaScript scroller on the index.html page, but it's not clear to everyone that it is there. Let's do this: 1. Make it so that they scroll ever 10 seconds between what is there. 2. Put a pause on it - which will stop the scrolling, but allow you to start it up again. 3. Make it so what comes up first is totally random 4. Make it so it scrolls around to the beginning again instead of stopping at the last one (in either direction) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (OFBIZ-2288) Update the image / content scroller on index.html
[ https://issues.apache.org/jira/browse/OFBIZ-2288?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12701087#action_12701087 ] David E. Jones commented on OFBIZ-2288: --- With source repositories you either use them right, or they are useless... and a real pain on top of useless. The first rule is to always work in your sandbox... always. That means work on the files right in the directory you checked out. It's easy to kill other people's changes if you copy a file into a checkout directory that is based on a different checkout revision than the one you copy it into. Keep in mind that SVN (or whatever) keeps track of the differences between your file and the version you checked out. That way when you update it knows which lines you changed and can merge them with lines others changed. If you lose the link between the file you're editing and the source repo revision it is based on, problems happen. A couple of common scenarios that will cause problems: 1. checkout in directory A, edit a file; checkout in directory B with a different revision (usually a later checkout); copy file from A to B and when you do a diff in B it will undo all changes in the repository between the revisions for A and B 2. checkout in directory A; copy a file into directory X and edit it there; update the sandbox/checkout in directory A; copy the file back from directory X to directory A; SVN will think the file is based on the latest revision, just it is based on the earlier revision... and that will cause it to undo all the changes In general: please read through the patch file your produce and check each line! Remember that when you submit a patch you are asking the committer who volunteers to review every line of the patch (that's what they _should_ be doing anyway). = Back to the main point of the new patch (indexUpdate.patch): the file is 1749 lines long, with lots of changes that don't seem to have anything to do with the changes described, and that means it takes a LONG time to review it and significantly increases the chance of problems with the patch. There are a couple of files added by it that I'm not sure about the purpose of, namely full.html, subpage.html, and style.html. There are lots of lines changed that appear to have no change other than formatting, but it's hard to tell by reviewing them manually. Please avoid formatting changes, this helps to make patches a LOT smaller and makes things way easier to review. There are still changes in the index.html file that appear to move things around to different parts of the file that were changed in recent revisions, which is specifically what leads me to believe that this file got mixed up with the wrong revision. Update the image / content scroller on index.html - Key: OFBIZ-2288 URL: https://issues.apache.org/jira/browse/OFBIZ-2288 Project: OFBiz Issue Type: Improvement Components: site Affects Versions: SVN trunk Reporter: Tim Ruppert Assignee: Tim Ruppert Fix For: SVN trunk Attachments: Archive.zip, images.zip, index.patch, indexUpdate.patch, ofbizSiteTemplate.zip Currently there is a JavaScript scroller on the index.html page, but it's not clear to everyone that it is there. Let's do this: 1. Make it so that they scroll ever 10 seconds between what is there. 2. Put a pause on it - which will stop the scrolling, but allow you to start it up again. 3. Make it so what comes up first is totally random 4. Make it so it scrolls around to the beginning again instead of stopping at the last one (in either direction) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (OFBIZ-2322) Old logo removed, but new logo not referenced in ecommerce
[ https://issues.apache.org/jira/browse/OFBIZ-2322?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David E. Jones closed OFBIZ-2322. - Resolution: Fixed Assignee: David E. Jones Thanks Tim, this should be fixed in SVN rev 766426 in the trunk, and 766427 in the release09.04 branch. Old logo removed, but new logo not referenced in ecommerce -- Key: OFBIZ-2322 URL: https://issues.apache.org/jira/browse/OFBIZ-2322 Project: OFBiz Issue Type: Bug Components: framework Affects Versions: Release Branch 9.04, SVN trunk Reporter: Tim Ruppert Assignee: David E. Jones Fix For: Release Branch 9.04, SVN trunk Currently on this page - https://demo.ofbiz.org/images/ofbiz_logo.jpg and https://demo904.ofbiz.org/images/ofbiz_logo.jpg - the OFBiz logo in the top corner appears to not be referenceable. This is also a problem for the favicon - https://demo.ofbiz.org/images/ofbiz.ico - which doesn't show up either :( Please update this with the proper logo file. Here's a find looking for it, but I'm not sure which one we're supposed to use: rover:ofbiz-trunk ruppert$ find . -name ofbiz_logo.* ./specialpurpose/cmssite/webapp/ofbizsite/images/.svn/prop-base/ofbiz_logo.jpg.svn-base ./specialpurpose/cmssite/webapp/ofbizsite/images/.svn/text-base/ofbiz_logo.jpg.svn-base ./specialpurpose/cmssite/webapp/ofbizsite/images/ofbiz_logo.jpg ./themes/bluelight/webapp/bluelight/.svn/prop-base/ofbiz_logo.gif.svn-base ./themes/bluelight/webapp/bluelight/.svn/text-base/ofbiz_logo.gif.svn-base ./themes/bluelight/webapp/bluelight/ofbiz_logo.gif ./themes/flatgrey/webapp/flatgrey/.svn/prop-base/ofbiz_logo.jpg.svn-base ./themes/flatgrey/webapp/flatgrey/.svn/text-base/ofbiz_logo.jpg.svn-base ./themes/flatgrey/webapp/flatgrey/ofbiz_logo.jpg Let's make sure it's the new one though -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (OFBIZ-2319) View Entities cause errors in web tools export
[ https://issues.apache.org/jira/browse/OFBIZ-2319?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David E. Jones closed OFBIZ-2319. - Resolution: Fixed Assignee: David E. Jones Thanks for reporting this BJ, it is fixed in SVN rev 766431 for the trunk and rev 766432 for the release09.04 branch. View Entities cause errors in web tools export -- Key: OFBIZ-2319 URL: https://issues.apache.org/jira/browse/OFBIZ-2319 Project: OFBiz Issue Type: Bug Components: framework Affects Versions: Release Branch 9.04, SVN trunk Reporter: BJ Freeman Assignee: David E. Jones Fix For: Release Branch 9.04, SVN trunk used to be when a entityview was selected for export the log would show it could not be exported. that may be so, still but the error is in the way. Steps to show error: https://demo.ofbiz.org/webtools/control/xmldsdump fill in a directory to write to check ContactMechDetail click on export get the followning errors Message: Error rendering screen [component://webtools/widget/EntityScreens.xml#xmldsdump]: org.ofbiz.base.util.GeneralException: Error running Groovy script at location [component://webtools/webapp/webtools/WEB-INF/actions/entity/XmlDsDump.groovy] (The current transaction is marked for rollback, not beginning a new transaction and aborting current operation; the rollbackOnly was caused by: Error reading data for XML export:org.ofbiz.entity.GenericModelException: Field with name createdTxStamp not found in the ContactMechDetail Entity (Field with name createdTxStamp not found in the ContactMechDetail Entity)) (Error running Groovy script at location [component://webtools/webapp/webtools/WEB-INF/actions/entity/XmlDsDump.groovy] (The current transaction is marked for rollback, not beginning a new transaction and aborting current operation; the rollbackOnly was caused by: Error reading data for XML export:org.ofbiz.entity.GenericModelException: Field with name createdTxStamp not found in the ContactMechDetail Entity (Field with name createdTxStamp not found in the ContactMechDetail Entity))) cause - Exception: org.ofbiz.base.util.GeneralException Message: Error running Groovy script at location [component://webtools/webapp/webtools/WEB-INF/actions/entity/XmlDsDump.groovy] (The current transaction is marked for rollback, not beginning a new transaction and aborting current operation; the rollbackOnly was caused by: Error reading data for XML export:org.ofbiz.entity.GenericModelException: Field with name createdTxStamp not found in the ContactMechDetail Entity (Field with name createdTxStamp not found in the ContactMechDetail Entity)) cause - Exception: org.ofbiz.entity.transaction.GenericTransactionException Message: The current transaction is marked for rollback, not beginning a new transaction and aborting current operation; the rollbackOnly was caused by: Error reading data for XML export:org.ofbiz.entity.GenericModelException: Field with name createdTxStamp not found in the ContactMechDetail Entity (Field with name createdTxStamp not found in the ContactMechDetail Entity) cause - Exception: org.ofbiz.entity.GenericModelException Message: Field with name createdTxStamp not found in the ContactMechDetail Entity -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (OFBIZ-2310) WFA createLead service does not store addresses
[ https://issues.apache.org/jira/browse/OFBIZ-2310?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David E. Jones closed OFBIZ-2310. - Resolution: Fixed Assignee: David E. Jones Thanks Ean, this is in SVN rev 766236 (and in the release09.04 branch as well). WFA createLead service does not store addresses - Key: OFBIZ-2310 URL: https://issues.apache.org/jira/browse/OFBIZ-2310 Project: OFBiz Issue Type: Bug Components: marketing Affects Versions: SVN trunk Reporter: Ean Schuessler Assignee: David E. Jones Fix For: SVN trunk Attachments: lead_address_fix.patch WFA createLead service does not store addresses -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (OFBIZ-1959) Multiple Security Issues (XSRF, XSS, Session Hijacking): exploitation and mitigation
[ https://issues.apache.org/jira/browse/OFBIZ-1959?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12700543#action_12700543 ] David E. Jones commented on OFBIZ-1959: --- Thanks for your review Michele. I'm not sure if I understand the threat you're talking about correctly... are you saying that the HTML use in the attack would somehow have to get a user to enter their username and password? We did discuss a few things related to tokens and such and after looking into various options I wrote up the follow email. The options listed at the bottom are the ones that are now implemented. If there are ways you know of to get around some of the issues with tokens please do share! We could certainly implement those or other measures but the trick is how to do so without significantly impacting the end-user experience. Thanks again, -David Proposal Message Below: I've been thinking more about the XSRF problem and what we can do to make OFBiz more secure from this sort of attack. This is related to OFBIZ-1959 and there is more discussion and introduction to it there. The trick is that we want to allow certain things: 1. the client's IP address can change during a session (also an attacker could be behind the same NAT router as the victim) 2. the client may have multiple browser windows or tabs open that are part of the same session 3. the client can jump from any page in an application to any other page in that application 4. once authenticated the client stays authenticated for the remainder of the session (doesn't have to re-auth for each page request) Because of these once a user has authenticated the main secure token they pass around is their session ID. In many cases this session ID is NOT communicated in a secure, ie it is passed over the network in plain text (it is often in the URL, or the user may hit HTTP requests and HTTPS requests). In any case, if an attacker can find the jsessionid then they can forge a request and act like the original user. In reality this is a problem that app servers should take care of, and could take care of in a generic way, but they don't (not any I know of anyway). For example they could do things like using different jsessionid values for secure and non-secure communication (ie different values for HTTPS and HTTP) and only allow the non-secure one (HTTP) to go in the URL. Even with that in place we'd still have to do certain things, but these would be very doable in OFBiz. For example we'd have to make a few small changes so that requests with https=true simply cannot be accessed through HTTP (this is not strictly enforced right now). And even with that they may still be issues, and would certainly be issues for requests that don't use HTTPS. One option is to have the framework generate a random token that is generated for each request so that the next request to the server MUST pass that token otherwise we treat it as if the user is not logged in, and in fact we would just logout the user and make them re-auth. That's an annoyance for the false positive cases, but much more secure. The major false positive case that concerns me related to this is the use of 2 common browser features: 1. the back button: if you go back you'll have a page with an old token in the links and clicking on any link or submitting any form would require you to re-auth 2. multiple windows/tabs: if you begin your session in one tab, then open another page in the same webapp in another tab it will be part of the session; if you then go back to the original tab and click on something the random token will be stale/old and you'll have to re-auth, and that will cause the token to update so when you go back to the second tab and hit any link you'll again have to re-auth The solution of a random token wouldn't be too hard to implement, but this constraint is a real pain. We could restrict this to secure pages only, but basically it means that for those pages users can't use the back button or multiple tabs/windows... and I don't like that one bit! The only solution I can think of to this would basically make the whole thing useless. We could remember past tokens so that as long as you have one of the valid tokens for the session then it's okay. However, if we do that then the random tokens will be no more secure than the jsessionid. We could try harder to keep them more secret, but if they go into a parameter or even a cookie then they aren't really secure. Maybe we could change all links to form submissions somehow... or maybe not. We'd be back to where intercepting a request that is part of a session could easily reveal the jsessionid AND a random token that would be valid for the rest of that session. Ie, we're back to square one. BTW, even if we go
[jira] Commented: (OFBIZ-2312) Styling flaws in smoothfeather
[ https://issues.apache.org/jira/browse/OFBIZ-2312?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12700083#action_12700083 ] David E. Jones commented on OFBIZ-2312: --- Issue 1 should be resolved by SVN rev 765888. Styling flaws in smoothfeather -- Key: OFBIZ-2312 URL: https://issues.apache.org/jira/browse/OFBIZ-2312 Project: OFBiz Issue Type: Sub-task Affects Versions: SVN trunk Environment: XP FF3 Reporter: Jacques Le Roux Fix For: SVN trunk I was to create an issue for each styling flaws in smoothfeather, but it's far too mcuh work. So I have created only one issue to list what we find. We can create a numbered comment for each issue to separate them and refer easily to them whe fixed. Here we go -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (OFBIZ-2315) TransactionUtil : 3 Map corruptions related to mis synchronization
[ https://issues.apache.org/jira/browse/OFBIZ-2315?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12700357#action_12700357 ] David E. Jones commented on OFBIZ-2315: --- Thanks Phillippe, I'll take a look at this. TransactionUtil : 3 Map corruptions related to mis synchronization -- Key: OFBIZ-2315 URL: https://issues.apache.org/jira/browse/OFBIZ-2315 Project: OFBiz Issue Type: Bug Affects Versions: Release Branch 4.0, SVN trunk Reporter: Philippe Mouawad Attachments: ContentionLog.txt, patch-TransactionUtil.patch Randomly we are having Thread contention problems in production related to synchronization issues in this class. See attached log file. As you can see, a lot of threads are locked by some code called by TransactionUtil.setTransactionBeginStack that has been running for 180165 ms : Thread[default-invoker-Thread-4582999,5,main]:4590333, stackTrace: javolution.util.FastMap.mapEntry(Unknown Source) javolution.util.FastMap.access$1200(Unknown Source) javolution.util.FastMap$3.run(Unknown Source) javax.realtime.MemoryArea.executeInArea(Unknown Source) javolution.util.FastMap.resizeTable(Unknown Source) javolution.util.FastMap.mapEntry(Unknown Source) javolution.util.FastMap.addEntry(Unknown Source) javolution.util.FastMap.put(Unknown Source) org.ofbiz.entity.transaction.TransactionUtil.setTransactionBeginStack(TransactionUtil.java:657) org.ofbiz.entity.transaction.TransactionUtil.setTransactionBeginStack(TransactionUtil.java:646) org.ofbiz.entity.transaction.TransactionUtil.begin(TransactionUtil.java:135) org.ofbiz.service.ServiceDispatcher.runSync(ServiceDispatcher.java:297) org.ofbiz.service.ServiceDispatcher.runSync(ServiceDispatcher.java:208) org.ofbiz.service.GenericDispatcher.runSync(GenericDispatcher.java:149) org.ofbiz.service.job.GenericServiceJob.exec(GenericServiceJob.java:69) org.ofbiz.service.job.JobInvoker.run(JobInvoker.java:240) java.lang.Thread.run(Thread.java:595) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (OFBIZ-2294) Remove HotWax contribution from the Infra link
[ https://issues.apache.org/jira/browse/OFBIZ-2294?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David E. Jones closed OFBIZ-2294. - Resolution: Later The PMC will discuss this and take whatever action is decided. Thanks for the voluntary good will on the issue. Remove HotWax contribution from the Infra link -- Key: OFBIZ-2294 URL: https://issues.apache.org/jira/browse/OFBIZ-2294 Project: OFBiz Issue Type: Improvement Components: site Affects Versions: SVN trunk Reporter: Tim Ruppert Assignee: David E. Jones Priority: Minor Fix For: SVN trunk Attachments: removeHotWaxInfraContribution.patch Just so it's clear and documented, Contegix provides this server to the community in order to host various functions that are not supported by the ASF on their infrastructure at the moment. Contegix is an official ASF resource for other ASF projects like Maven and we look forward to getting this accreditation so that this can become more official. Contegix provides this box at a very steep discount and manages all aspects of it. HotWax Media picks up the rest of the cost. That is the reason that this is put on the site - not for our marketing purposes, but because of the fact that this stuff does not come for free. I have created a patch to remove the HotWax contribution to infrastructure because while it didn't seem to be an issue before all of these new upgrades to the site and the additional professionalism (and press) that comes from it - everyone wants to be front and center now - I'd rather leave this discussion off the table. We're more than happy to do this as a contribution to the community and not have much press for it :) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (OFBIZ-2261) Update the Look and Feel of the ofbiz.apache.org website
[ https://issues.apache.org/jira/browse/OFBIZ-2261?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David E. Jones closed OFBIZ-2261. - Resolution: Fixed Assignee: David E. Jones This is now in SVN, and updated on the live site. Update the Look and Feel of the ofbiz.apache.org website Key: OFBIZ-2261 URL: https://issues.apache.org/jira/browse/OFBIZ-2261 Project: OFBiz Issue Type: Improvement Components: site Affects Versions: SVN trunk Reporter: Tim Ruppert Assignee: David E. Jones Fix For: SVN trunk Attachments: examplesOfAllElements.png, indexNewLookAndFeel.patch, indexNewLookAndFeel.patch, indexNewLookAndFeel.patch, indexNewLookAndFeelImages.zip, indexNewLookAndFeelImages.zip, indexNewLookAndFeelImages.zip, Mainpage.jpg, staticMainPageExample.png Following ApacheCon, much of the focus of the project was to focus on marketing the project - because many felt that what we had was already technically superior to the other options out there. Erik Schuessler of Brainfood came up with a concept that we have run with to enhance: 1. The website 2. The docs.ofbiz.org website 3. The backend theme of OFBiz 4. The frontend of the default ecommerce look and feel The other three will be described in other issues. Please provide feedback as quickly as possible as it would be nice to get this going in time for the release. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (OFBIZ-2275) /framework/common/servicedef/services.xml does not have correct location for PeriodServices.xml
[ https://issues.apache.org/jira/browse/OFBIZ-2275?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12696409#action_12696409 ] David E. Jones commented on OFBIZ-2275: --- Thanks for reporting this CJ. I must have slipped these over when I was moving the find server. This should be fixed in SVN rev 762624. /framework/common/servicedef/services.xml does not have correct location for PeriodServices.xml --- Key: OFBIZ-2275 URL: https://issues.apache.org/jira/browse/OFBIZ-2275 Project: OFBiz Issue Type: Bug Components: accounting Affects Versions: SVN trunk Reporter: CJ Horton Priority: Minor Fix For: SVN trunk Attachments: 762561.patch, services.xml.patch It looks like the file PeriodServices.xml was moved from: component://common/script/org/ofbiz/common/period/ to: component://accounting/script/org/ofbiz/accounting/period PeriodServices.xml is referenced in two files: component://accounting/servicedef/services_ledger.xml and component://common/servicedef/services.xml The location is correct in services_ledger.xml, but not services.xml. I attached a patch that points /framework/common/servicedef/services.xml to the current location of PeriodServices.xml. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (OFBIZ-2275) /framework/common/servicedef/services.xml does not have correct location for PeriodServices.xml
[ https://issues.apache.org/jira/browse/OFBIZ-2275?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David E. Jones closed OFBIZ-2275. - Resolution: Fixed Assignee: David E. Jones /framework/common/servicedef/services.xml does not have correct location for PeriodServices.xml --- Key: OFBIZ-2275 URL: https://issues.apache.org/jira/browse/OFBIZ-2275 Project: OFBiz Issue Type: Bug Components: accounting Affects Versions: SVN trunk Reporter: CJ Horton Assignee: David E. Jones Priority: Minor Fix For: SVN trunk Attachments: 762561.patch, services.xml.patch It looks like the file PeriodServices.xml was moved from: component://common/script/org/ofbiz/common/period/ to: component://accounting/script/org/ofbiz/accounting/period PeriodServices.xml is referenced in two files: component://accounting/servicedef/services_ledger.xml and component://common/servicedef/services.xml The location is correct in services_ledger.xml, but not services.xml. I attached a patch that points /framework/common/servicedef/services.xml to the current location of PeriodServices.xml. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (OFBIZ-2269) Move payment.properties to PaymentGatewayConfig entities
[ https://issues.apache.org/jira/browse/OFBIZ-2269?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12695884#action_12695884 ] David E. Jones commented on OFBIZ-2269: --- In this case the paymentService field should be changed to reflect it's new meaning. The generic recommended (and mostly used) pattern (that is REALLY annoying when it is not used, but alas I have missed commenting on a few over the years) is when creating a field that points to a foreign key then use the name of the foreign field with a prefix. In this case instead of paymentService use paymentCustomMethodId. Also, in the relation element use the prefix attribute to help clarify. In this case where the field is paymentCustomMethodId the prefix should be Payment. Move payment.properties to PaymentGatewayConfig entities Key: OFBIZ-2269 URL: https://issues.apache.org/jira/browse/OFBIZ-2269 Project: OFBiz Issue Type: New Feature Components: ALL COMPONENTS Affects Versions: SVN trunk Reporter: Marco Risaliti Assignee: Marco Risaliti Priority: Minor Fix For: SVN trunk Attachments: Payment Gateway Configuration.pdf, PaymentGateways.patch, Product Store Payments.pdf -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (OFBIZ-2260) Secure URLs in Freemarker templates files
[ https://issues.apache.org/jira/browse/OFBIZ-2260?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12695965#action_12695965 ] David E. Jones commented on OFBIZ-2260: --- A couple of quick notes: 1. there is no need to change links that do not result in a service call... they should just stay as anchor (a) tags 2. please keep the javascript in the link simple, ie don't include things like document.addCommonToCartForm.method='post', that should be on the form element (ie the method=post) Secure URLs in Freemarker templates files - Key: OFBIZ-2260 URL: https://issues.apache.org/jira/browse/OFBIZ-2260 Project: OFBiz Issue Type: Improvement Components: ALL COMPONENTS Affects Versions: Release Branch 4.0, Release Branch 9.3 Reporter: Jacques Le Roux Assignee: Jacques Le Roux Fix For: Release Branch 4.0, Release Branch 9.3 Attachments: OFBIZ-2256.patch, OFBIZ-2260.patch, OFBIZ-2260.patch Follow OFBIZ-2256 but for FTL files only -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (OFBIZ-2269) Move payment.properties to PaymentGatewayConfig entities
[ https://issues.apache.org/jira/browse/OFBIZ-2269?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12695682#action_12695682 ] David E. Jones commented on OFBIZ-2269: --- Looks like a great start Marco. One small note: service names should start with a lower-case letter, just like Java method names do. Move payment.properties to PaymentGatewayConfig entities Key: OFBIZ-2269 URL: https://issues.apache.org/jira/browse/OFBIZ-2269 Project: OFBiz Issue Type: New Feature Components: ALL COMPONENTS Affects Versions: SVN trunk Reporter: Marco Risaliti Assignee: Marco Risaliti Priority: Minor Fix For: SVN trunk Attachments: Payment Gateway Configuration.pdf, PaymentGateways.patch, Product Store Payments.pdf -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (OFBIZ-2260) Secure URLs in Freemarker templates files
[ https://issues.apache.org/jira/browse/OFBIZ-2260?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12694260#action_12694260 ] David E. Jones commented on OFBIZ-2260: --- Yes, JavaScript is kind of the only way to do this (unless there is an image or we have a highly styled form submit button). So far all of these links use JavaScript this way, including the Form/Screen/Menu widget changes that I did (just take a look at the HTML that is generated on any of those widgets you've been working on for examples). Secure URLs in Freemarker templates files - Key: OFBIZ-2260 URL: https://issues.apache.org/jira/browse/OFBIZ-2260 Project: OFBiz Issue Type: Improvement Components: ALL COMPONENTS Affects Versions: Release Branch 4.0, Release Branch 9.3 Reporter: Jacques Le Roux Assignee: Jacques Le Roux Fix For: Release Branch 4.0, Release Branch 9.3 Attachments: OFBIZ-2256.patch, OFBIZ-2260.patch, OFBIZ-2260.patch Follow OFBIZ-2256 but for FTL files only -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (OFBIZ-2259) Testing - Rollback database changes after each test-suite using the GenericDelegator
[ https://issues.apache.org/jira/browse/OFBIZ-2259?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12693978#action_12693978 ] David E. Jones commented on OFBIZ-2259: --- This looks pretty good in general. One small issue: it is not thread safe. At some point we may decide that running test suites one at a time is too slow. In other words, chances are running a few at a time will result in an over all performance increase compared to running them in serial. One way we could possibly do this is to clone the delegator and use one instance per test suite. That's the first that comes to mind anyway, there are probably better options... A ThreadLocal variable is something I always consider to be a bit of a hack, but they do have their place. In this case that might not work as a test case could have multiple threads (not sure if any do...). Testing - Rollback database changes after each test-suite using the GenericDelegator Key: OFBIZ-2259 URL: https://issues.apache.org/jira/browse/OFBIZ-2259 Project: OFBiz Issue Type: New Feature Components: framework Reporter: Scott Gray Assignee: Scott Gray Attachments: rollback.patch During testing have the delegator keep track of all changes made to the database and then roll them back at the end of each test suite. This will allow the same demo data to be reused across test suites without having to worry about what changes previous tests have made to the data and solves this problem regardless of the database being used. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (OFBIZ-2259) Testing - Rollback database changes after each test-suite using the GenericDelegator
[ https://issues.apache.org/jira/browse/OFBIZ-2259?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12693980#action_12693980 ] David E. Jones commented on OFBIZ-2259: --- Thinking about this more I like the idea of a sort of cloned delegator. In other words instead of doing something like: modelSuite.getDelegator().setTestMode(true); we would do something like: GenericDelegator testDelegator = modelSuite.getDelegator().makeTestDelegator(); and the later on near the end instead of: modelSuite.getDelegator().performUndo(); modelSuite.getDelegator().setTestMode(false); maybe something like: testDelegator.rollback(); Testing - Rollback database changes after each test-suite using the GenericDelegator Key: OFBIZ-2259 URL: https://issues.apache.org/jira/browse/OFBIZ-2259 Project: OFBiz Issue Type: New Feature Components: framework Reporter: Scott Gray Assignee: Scott Gray Attachments: rollback.patch During testing have the delegator keep track of all changes made to the database and then roll them back at the end of each test suite. This will allow the same demo data to be reused across test suites without having to worry about what changes previous tests have made to the data and solves this problem regardless of the database being used. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (OFBIZ-2256) Secure URLs
[ https://issues.apache.org/jira/browse/OFBIZ-2256?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12693641#action_12693641 ] David E. Jones commented on OFBIZ-2256: --- We might want to leave this open for the FTL files. You can certainly give a S/R a try but based on doing it a few times manually I don't think that will be all that easy... it is MUCH more error prone than the form widget stuff as we're dealing with plain HTML there... and anything can be put into those so they aren't as consistent. There's also the trick of creating the form name, and making sure it has a suffix if needed to make each form name unique on the page. Secure URLs --- Key: OFBIZ-2256 URL: https://issues.apache.org/jira/browse/OFBIZ-2256 Project: OFBiz Issue Type: Bug Components: ALL COMPONENTS Affects Versions: SVN trunk Reporter: Jacques Le Roux Assignee: Jacques Le Roux Fix For: Release Branch 9.3 Attachments: OFBIZ-2256.patch, OFBIZ-2256.patch You may add here in coments any URL that must be secured. And after they have been secured use \-secured\- to show the -secured- URLs in following comments (here I escaped - using \ to show how to do it) Some URLs from the user ML Page:(Show and Edit yield same issue) https://localhost:8443/manufacturing/control/ShowProductionRun?productionRunId=1 https://localhost:8443/manufacturing/control/EditProductionRun?productionRunId=1 Links: https://localhost:8443/manufacturing/control/scheduleProductionRun?productionRunId=1statusId=PRUN_SCHEDULED https://localhost:8443/manufacturing/control/changeProductionRunStatusToPrinted?productionRunId=1 https://localhost:8443/manufacturing/control/quickChangeProductionRunStatus?productionRunId=1statusId=PRUN_COMPLETED https://localhost:8443/manufacturing/control/quickChangeProductionRunStatus?productionRunId=1statusId=PRUN_CLOSED https://localhost:8443/manufacturing/control/cancelProductionRun?productionRunId=1 Page: https://localhost:8443/manufacturing/control/ProductionRunTasks?productionRunId=1 Links: https://localhost:8443/manufacturing/control/deleteProductionRunRoutingTask?workEffortId=10001productionRunId=1 Page: https://localhost:8443/manufacturing/control/ProductionRunComponents?productionRunId=1 Links: https://localhost:8443/manufacturing/control/deleteProductionRunComponent?workEffortId=10001fromDate=2009-03-25%2018:17:52.023productId=ETH_BRANDworkEffortGoodStdTypeId=PRUNT_PROD_NEEDEDproductionRunId=1 Page: https://localhost:8443/manufacturing/control/ProductionRunFixedAssets?productionRunId=1 Links: https://localhost:8443/manufacturing/control/removeWorkEffortFixedAssetAssign?workEffortId=10001fixedAssetId=DEMO_MACHINE_GROUPfromDate=2009-03-25%2018:17:50.858productionRunId=1 Page: https://localhost:8443/manufacturing/control/EditRoutingTaskAssoc?workEffortId=10010 Links: https://localhost:8443/manufacturing/control/RemoveRoutingTaskAssoc?workEffortId=10010workEffortIdFrom=10010workEffortIdTo=TASK01fromDate=2009-03-26%2013:55:55.447workEffortAssocTypeId=ROUTING_COMPONENT Page: https://localhost:8443/manufacturing/control/EditRoutingProductLink?workEffortId=10010 Links: https://localhost:8443/manufacturing/control/removeRoutingProductLink?workEffortId=10010productId=PC001fromDate=2009-03-26%2013:55:27.000workEffortGoodStdTypeId=ROU_PROD_TEMPLATE Page: https://localhost:8443/manufacturing/control/FindCalendar Links: https://localhost:8443/manufacturing/control/RemoveCalendar?calendarId=DEFAULT Page: https://localhost:8443/manufacturing/control/ListCalendarWeek Links: https://localhost:8443/manufacturing/control/RemoveCalendarWeek?calendarWeekId=DEFAULT Page: https://localhost:8443/manufacturing/control/EditCostCalcs Links: https://localhost:8443/manufacturing/control/removeCostComponentCalc?costComponentCalcId=EXAMPLE_COST Here are some more as of 758871: Page: https://localhost:8443/ecommerce/control/orderstatus?orderId=WSCO10001 Links: https://localhost:8443/ecommerce/control/cancelOrderItem?orderItemSeqId=3 Page: https://localhost:8443/ecommerce/control/updatePostalAddress Links: https://localhost:8443/ecommerce/control/createPartyContactMechPurpose?contactMechId=10003useValues=true Page: https://localhost:8443/ecommerce/control/viewprofile Links: https://localhost:8443/ecommerce/control/setprofiledefault/viewprofile?productStoreId=9000defaultPayMeth=10001partyId=1 https://localhost:8443/ecommerce/control/deleteCustomerTaxAuthInfo?partyId=1taxAuthPartyId=ON_TAXMANtaxAuthGeoId=ONfromDate=2009-03-26%2017:48:43.350 https://localhost:8443/ecommerce/control/readmessage?communicationEventId=10001 Page: https://localhost:8443/ecommerce/control/messagelist?showSent=true Links:
[jira] Commented: (OFBIZ-2243) In hyperlink and sub-hyperlink elements, replacement of target parameters by parameter sub-elements
[ https://issues.apache.org/jira/browse/OFBIZ-2243?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12693646#action_12693646 ] David E. Jones commented on OFBIZ-2243: --- Wow... that's quite the set of regexps... In hyperlink and sub-hyperlink elements, replacement of target parameters by parameter sub-elements --- Key: OFBIZ-2243 URL: https://issues.apache.org/jira/browse/OFBIZ-2243 Project: OFBiz Issue Type: Improvement Components: ALL COMPONENTS Affects Versions: SVN trunk Reporter: Jacques Le Roux Assignee: Jacques Le Roux Fix For: Release Branch 9.3, SVN trunk This issue is intended to replace, in all hyperlink and sub-hyperlink elements used in forms, screens and menus widgets, target parameters by parameter sub-elements using Eclipse regexp S/R -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Assigned: (OFBIZ-2252) Exception occurs while changing the order status
[ https://issues.apache.org/jira/browse/OFBIZ-2252?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David E. Jones reassigned OFBIZ-2252: - Assignee: David E. Jones Exception occurs while changing the order status Key: OFBIZ-2252 URL: https://issues.apache.org/jira/browse/OFBIZ-2252 Project: OFBiz Issue Type: Improvement Components: order Affects Versions: SVN trunk Reporter: Deepesh Kapoor Assignee: David E. Jones Fix For: SVN trunk Attachments: OFBIZ-2252.patch, OFBIZ-2252.patch When the Status of the Order is changed then as parameters are passed as url parameters on the secured port, Exception org.ofbiz.webapp.event.EventHandlerException: Found URL parameter [orderId] passed to secure (https) request-map with uri [changeOrderStatus] occurs. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (OFBIZ-2252) Exception occurs while changing the order status
[
https://issues.apache.org/jira/browse/OFBIZ-2252?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
David E. Jones closed OFBIZ-2252.
-
Resolution: Fixed
I'm applying this patch and making some changes right away since this really
needs to be fixed ASAP.
1. First and most important, please don't change links that still work, there
is no need and it just makes the code more complicated without any benefit (for
example the orderview and order.pdf links do not need to be changed). It is
easy to figure this out, just click on the links and if it works then leave it
as-is.
2. Second, there is no need to use the getElementById() function. It is better
to just use the name attribute on the form instead of the id attribute and
refer to it directly. Instead of:
document.getElementById('OrderCreated').submit()
simply use:
document.OrderCreated.submit()
3. The names of the forms could be better, ie be similar to the target they
correspond to. For example for the form changing to the status ORDER_APPROVED
instead of using OrderCreated for the name, I've changed it to
OrderApproveOrder.
4. Kind of related to #1, there are a few more links on this page that need to
be changed to forms, but that is fine in another issue.
Thanks again for your help. Some modified changes are in SVN rev 758502.
Exception occurs while changing the order status
Key: OFBIZ-2252
URL: https://issues.apache.org/jira/browse/OFBIZ-2252
Project: OFBiz
Issue Type: Improvement
Components: order
Affects Versions: SVN trunk
Reporter: Deepesh Kapoor
Assignee: David E. Jones
Fix For: SVN trunk
Attachments: OFBIZ-2252.patch, OFBIZ-2252.patch
When the Status of the Order is changed then as parameters are passed as url
parameters on the secured port, Exception
org.ofbiz.webapp.event.EventHandlerException: Found URL parameter [orderId]
passed to secure (https) request-map with uri [changeOrderStatus] occurs.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (OFBIZ-2252) Exception occurs while changing the order status
[
https://issues.apache.org/jira/browse/OFBIZ-2252?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12688809#action_12688809
]
David E. Jones commented on OFBIZ-2252:
---
This looks good in general Deepesh, and thanks for looking at all of the links
on that page.
Some opportunities for improvement:
1. keep things simple: instead of calling a JS method to submit the form just
use a URL like javascript:document.${formName}.submit()
2. avoid reformatting the file and keep your changes localized (ie in small
sets) so the patch is clean and it is easy to see what you have changed and
what you haven't; when you're a committer feel free to do more reformatting,
but for now this only delays reviews as it requires a lot more work from
committers who review it; for example these lines don't seem to have any
changes other than formatting:
-div class=screenlet-title-bar
-ul
-#if orderHeader.externalId?has_content
- #assign externalOrder = ( + orderHeader.externalId + )/
-/#if
-#assign orderType = orderHeader.getRelatedOne(OrderType)/
3. it was good that you followed up on the user mailing list, but a link to the
issue would have been easier to follow than a link to the patch
Thanks again! Looking forward to updates...
Exception occurs while changing the order status
Key: OFBIZ-2252
URL: https://issues.apache.org/jira/browse/OFBIZ-2252
Project: OFBiz
Issue Type: Improvement
Components: order
Affects Versions: SVN trunk
Reporter: Deepesh Kapoor
Fix For: SVN trunk
Attachments: OFBIZ-2252.patch
When the Status of the Order is changed then as parameters are passed as url
parameters on the secured port, Exception
org.ofbiz.webapp.event.EventHandlerException: Found URL parameter [orderId]
passed to secure (https) request-map with uri [changeOrderStatus] occurs.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Closed: (OFBIZ-2231) Escaped ampersands in xml import need to be reencoded
[
https://issues.apache.org/jira/browse/OFBIZ-2231?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
David E. Jones closed OFBIZ-2231.
-
Resolution: Fixed
Assignee: David E. Jones (was: Jacques Le Roux)
Escaped ampersands in xml import need to be reencoded
--
Key: OFBIZ-2231
URL: https://issues.apache.org/jira/browse/OFBIZ-2231
Project: OFBiz
Issue Type: Bug
Components: framework
Affects Versions: SVN trunk
Environment: Windows XP
Reporter: Stephen Rufle
Assignee: David E. Jones
Fix For: SVN trunk
Attachments: 2009-03-06_WebToolsServices.patch
While trying to import
{code:xml}
PostalAddress toName=To stateProvinceGeoId=NJ postalCode=08873
countryGeoId=USA contactMechId=001 city=SOMERSET attnName=Steve
address2=100 Some Ave address1=Firstamp;Broadway/
{code}
got the following exception. I think that the recent security stuff encodes
the xml so it is no longer valid during the reader.parse call in
org.ofbiz.webtools.WebToolsServices.parseEntityXmlFile(...)
My solution is to make a call to
{code}
xmltext= StringUtil.replaceString(xmltext, , \amp;);
{code}
before reader.parse is called
{code}
An error occurred saving the data, rolling back transaction (true)
Exception: org.xml.sax.SAXException
Message: Error storing value
stack trace
---
org.ofbiz.entity.GenericEntityException: Error while inserting:
[GenericEntity:PartyRelationship]...
javolution.xml.sax.XMLReaderImpl.parseAll(Unknown Source)
javolution.xml.sax.XMLReaderImpl.parse(Unknown Source)
org.ofbiz.entity.util.EntitySaxReader.parse(EntitySaxReader.java:258)
org.ofbiz.entity.util.EntitySaxReader.parse(EntitySaxReader.java:209)
org.ofbiz.webtools.WebToolsServices.parseEntityXmlFile(WebToolsServices.java:459)
sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
java.lang.reflect.Method.invoke(Unknown Source)
org.ofbiz.service.engine.StandardJavaEngine.serviceInvoker(StandardJavaEngine.java:96)
org.ofbiz.service.engine.StandardJavaEngine.runSync(StandardJavaEngine.java:54)
org.ofbiz.service.ServiceDispatcher.runSync(ServiceDispatcher.java:384)
org.ofbiz.service.ServiceDispatcher.runSync(ServiceDispatcher.java:213)
org.ofbiz.service.GenericDispatcher.runSync(GenericDispatcher.java:148)
org.ofbiz.webtools.WebToolsServices.entityImport(WebToolsServices.java:203)
sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
java.lang.reflect.Method.invoke(Unknown Source)
org.ofbiz.service.engine.StandardJavaEngine.serviceInvoker(StandardJavaEngine.java:96)
org.ofbiz.service.engine.StandardJavaEngine.runSync(StandardJavaEngine.java:54)
org.ofbiz.service.ServiceDispatcher.runSync(ServiceDispatcher.java:384)
org.ofbiz.service.ServiceDispatcher.runSync(ServiceDispatcher.java:213)
org.ofbiz.service.GenericDispatcher.runSync(GenericDispatcher.java:148)
org.ofbiz.webapp.event.ServiceEventHandler.invoke(ServiceEventHandler.java:328)
org.ofbiz.webapp.control.RequestHandler.runEvent(RequestHandler.java:530)
org.ofbiz.webapp.control.RequestHandler.doRequest(RequestHandler.java:328)
org.ofbiz.webapp.control.ControlServlet.doGet(ControlServlet.java:201)
org.ofbiz.webapp.control.ControlServlet.doPost(ControlServlet.java:77)
javax.servlet.http.HttpServlet.service(HttpServlet.java:710)
javax.servlet.http.HttpServlet.service(HttpServlet.java:803)
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290)
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
org.ofbiz.webapp.control.ContextFilter.doFilter(ContextFilter.java:259)
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:233)
org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:175)
org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:128)
org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102)
org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:568)
org.ofbiz.catalina.container.CrossSubdomainSessionValve.invoke(CrossSubdomainSessionValve.java:44)
org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:286)
