[jira] [Commented] (OFBIZ-235) POS Z report
[ https://issues.apache.org/jira/browse/OFBIZ-235?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15398534#comment-15398534 ] Scott Gray commented on OFBIZ-235: -- Do a lot of these tickets you're closing not apply equally to webpos? Couldn't you just change the component? > POS Z report > > > Key: OFBIZ-235 > URL: https://issues.apache.org/jira/browse/OFBIZ-235 > Project: OFBiz > Issue Type: New Feature > Components: specialpurpose/pos, specialpurpose/webpos >Affects Versions: Trunk >Reporter: Jacques Le Roux >Assignee: Jacques Le Roux >Priority: Minor > > This is generally used as a daily report but should still take a date range > to be really useful. > show total sales by tender type, with VAT breakdown by rates > transaction count (number of sales) > number of items sold / average per customer > average spend per customer > totals of discounts > This issue was initially created by Ray Barlow -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (OFBIZ-7808) Add Gradle Interactive tasks
[ https://issues.apache.org/jira/browse/OFBIZ-7808?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15396605#comment-15396605 ] Scott Gray commented on OFBIZ-7808: --- Thirded by me. If the history of this project has taught us anything, it's that we can't spend all our time worrying about the ease of migration from previous releases, it literally hamstrings the project because virtually any change can be objected to using this rationale. In order to progress cleanly we need to always focus as if the next release were the first ever. > Add Gradle Interactive tasks > > > Key: OFBIZ-7808 > URL: https://issues.apache.org/jira/browse/OFBIZ-7808 > Project: OFBiz > Issue Type: Improvement > Components: framework >Affects Versions: Trunk >Reporter: Jacques Le Roux >Assignee: Jacques Le Roux > Fix For: Upcoming Branch > > > As explained in OFBIZ-7772 and OFBIZ-7773 we want to test the possiblity to > add Gradle Interactive tasks using > https://github.com/tkruse/gradle-groovysh-plugin > The idea is to have a good general solution to allow users to not feel a > funtional regression with the 3 interactive tasks we had before, namely > create-component > create-admin-user-login > create-tenant and all tasks it depends on -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (OFBIZ-7808) Add Gradle Interactive tasks
[ https://issues.apache.org/jira/browse/OFBIZ-7808?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15393546#comment-15393546 ] Scott Gray commented on OFBIZ-7808: --- It's a sad state of affairs really, there had been consensus on that topic for many years (long before the ASF, but in those days it was a matter of not directly including a driver rather than having a download task). But eventually someone managed to slip it in and gain a couple of people who agreed, and no one has the energy to argue over a minor thing (except those in favor, and so strongly). Even if it is seemingly nonsensical and a source of frustration every time you hear about it or see it in the code. > Add Gradle Interactive tasks > > > Key: OFBIZ-7808 > URL: https://issues.apache.org/jira/browse/OFBIZ-7808 > Project: OFBiz > Issue Type: Improvement > Components: framework >Affects Versions: Trunk >Reporter: Jacques Le Roux >Assignee: Jacques Le Roux > Fix For: Upcoming Branch > > > As explained in OFBIZ-7772 and OFBIZ-7773 we want to test the possiblity to > add Gradle Interactive tasks using > https://github.com/tkruse/gradle-groovysh-plugin > The idea is to have a good general solution to allow users to not feel a > funtional regression with the 3 interactive tasks we had before, namely > create-component > create-admin-user-login > create-tenant and all tasks it depends on -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (OFBIZ-7808) Add Gradle Interactive tasks
[ https://issues.apache.org/jira/browse/OFBIZ-7808?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15393426#comment-15393426 ] Scott Gray commented on OFBIZ-7808: --- I tend to agree with Taher on this, I don't think interactive tasks serve much purpose. Anyone capable of using a command line is familiar with the concept of passing arguments to a command and if the arguments aren't known then textual help should be available. If I do something frequently enough and continuously fail to recall the arguments I need then I create myself a shell script which takes about 1 minute of effort. I don't think we need to spoon-feed developers with such basic things. This is also why I disagree with the "convenience" downloads for JDBC jars. > Add Gradle Interactive tasks > > > Key: OFBIZ-7808 > URL: https://issues.apache.org/jira/browse/OFBIZ-7808 > Project: OFBiz > Issue Type: Improvement > Components: framework >Affects Versions: Trunk >Reporter: Jacques Le Roux >Assignee: Jacques Le Roux > Fix For: Upcoming Branch > > > As explained in OFBIZ-7772 and OFBIZ-7773 we want to test the possiblity to > add Gradle Interactive tasks using > https://github.com/tkruse/gradle-groovysh-plugin > The idea is to have a good general solution to allow users to not feel a > funtional regression with the 3 interactive tasks we had before, namely > create-component > create-admin-user-login > create-tenant and all tasks it depends on -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (OFBIZ-7929) Scrum find Total Backlog Item is not working in non-English language
[
https://issues.apache.org/jira/browse/OFBIZ-7929?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15392989#comment-15392989
]
Scott Gray commented on OFBIZ-7929:
---
A couple of minor points:
1. It isn't necessary to use UtilValidate.isEmpty() in groovy for String
values, you can simply use: if (parameters.custRequestTypeId). Google "Groovy
Truth" for more info
2. I notice there are actually 4 instances of in the file, but only two have
been fixed.
> Scrum find Total Backlog Item is not working in non-English language
>
>
> Key: OFBIZ-7929
> URL: https://issues.apache.org/jira/browse/OFBIZ-7929
> Project: OFBiz
> Issue Type: Bug
> Components: specialpurpose/scrum
>Affects Versions: Trunk
>Reporter: Montalbano Florian
>Assignee: Jacques Le Roux
> Labels: backlog, find, item, scrum
> Fix For: Upcoming Branch
>
> Attachments: OFBIZ-7929.patch, OFBIZ-7929.patch
>
>
> The Find form for Product Backlog Item does not work in language other than
> English when no "statusId" or "custRequestTypeId" are selected.
> Step to reproduce :
> - Go to the Scrum component and select a product
> - Go to the "Total Backlog" tab
> or use this linl :
> https://localhost:8443/scrum/control/ViewTotalBacklog?productId=DEMO-PRODUCT-1
> - Hit the search button, the find action is performed and return a non-empty
> list.
> - Set your language preference to a non english language (french for
> example).
> - Click again on the "Total Backlog" tab, and hit the "Rechercher" button.
> - No results are found.
> Where does the problem come from ?
> The results displayed are from a list named "backlogList" which is built in
> the following script : FindProductBacklogItem.groovy .
> In this script, there were a check on the parameter "custRequestTypeId" and
> on the parameter "statusId".
> But the value was hardcoded :
> {code}
> if("Any".equals(parameters.custRequestTypeId))
> {code}
> and
> {code}
> if(!"Any".equals(parameters.statusId))
> {code}
> Obviously, when the form is in another language than english, those
> conditions aren't valid anymore (for exemple, "Any" is "Dont" in French")
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Comment Edited] (OFBIZ-7929) Scrum find Total Backlog Item is not working in non-English language
[
https://issues.apache.org/jira/browse/OFBIZ-7929?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15392989#comment-15392989
]
Scott Gray edited comment on OFBIZ-7929 at 7/26/16 1:27 AM:
A couple of minor points:
1. It isn't necessary to use UtilValidate.isEmpty() in groovy for String
values, you can simply use: if (parameters.custRequestTypeId). Google "Groovy
Truth" for more info
2. I notice there are actually 4 instances of {code}{code} in the file, but only two
have been fixed.
was (Author: lektran):
A couple of minor points:
1. It isn't necessary to use UtilValidate.isEmpty() in groovy for String
values, you can simply use: if (parameters.custRequestTypeId). Google "Groovy
Truth" for more info
2. I notice there are actually 4 instances of in the file, but only two have
been fixed.
> Scrum find Total Backlog Item is not working in non-English language
>
>
> Key: OFBIZ-7929
> URL: https://issues.apache.org/jira/browse/OFBIZ-7929
> Project: OFBiz
> Issue Type: Bug
> Components: specialpurpose/scrum
>Affects Versions: Trunk
>Reporter: Montalbano Florian
>Assignee: Jacques Le Roux
> Labels: backlog, find, item, scrum
> Fix For: Upcoming Branch
>
> Attachments: OFBIZ-7929.patch, OFBIZ-7929.patch
>
>
> The Find form for Product Backlog Item does not work in language other than
> English when no "statusId" or "custRequestTypeId" are selected.
> Step to reproduce :
> - Go to the Scrum component and select a product
> - Go to the "Total Backlog" tab
> or use this linl :
> https://localhost:8443/scrum/control/ViewTotalBacklog?productId=DEMO-PRODUCT-1
> - Hit the search button, the find action is performed and return a non-empty
> list.
> - Set your language preference to a non english language (french for
> example).
> - Click again on the "Total Backlog" tab, and hit the "Rechercher" button.
> - No results are found.
> Where does the problem come from ?
> The results displayed are from a list named "backlogList" which is built in
> the following script : FindProductBacklogItem.groovy .
> In this script, there were a check on the parameter "custRequestTypeId" and
> on the parameter "statusId".
> But the value was hardcoded :
> {code}
> if("Any".equals(parameters.custRequestTypeId))
> {code}
> and
> {code}
> if(!"Any".equals(parameters.statusId))
> {code}
> Obviously, when the form is in another language than english, those
> conditions aren't valid anymore (for exemple, "Any" is "Dont" in French")
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (OFBIZ-7906) Have a gradle build file for the cmssite component
[ https://issues.apache.org/jira/browse/OFBIZ-7906?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15389012#comment-15389012 ] Scott Gray commented on OFBIZ-7906: --- bq. PMC didn't enable the contributor involved to do more, because they didn't/don't like him (enough) What a strange analysis, contributions are judged on their value, not on who the contributor is. Particularly in this case, Tom was nothing but communicative, personable and persistent in his endeavors and the bottleneck to progress was opposition to the design approach which is perfectly valid IMO. It is true that if a contributor is consistently dismissive of feedback and difficult to work with then naturally committers are going to be less likely to engage, that's their right as an unpaid volunteer. But that certainly wasn't the case with Tom. > Have a gradle build file for the cmssite component > -- > > Key: OFBIZ-7906 > URL: https://issues.apache.org/jira/browse/OFBIZ-7906 > Project: OFBiz > Issue Type: Bug > Components: specialpurpose/cmssite >Reporter: Pierre Smits >Assignee: Pierre Smits >Priority: Blocker > Attachments: OFBIZ-7906-cmssite.patch > > > The cmssite component uses a specific set of external libraries. These were > removed as a result of the migration from Ant to Gradle. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (OFBIZ-3379) Email sending process using one connection for To/CC/BCC causing issues
[ https://issues.apache.org/jira/browse/OFBIZ-3379?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15275759#comment-15275759 ] Scott Gray commented on OFBIZ-3379: --- Hi Jacques, the change was made in this commit: http://svn.apache.org/viewvc?rev=894236=rev > Email sending process using one connection for To/CC/BCC causing issues > --- > > Key: OFBIZ-3379 > URL: https://issues.apache.org/jira/browse/OFBIZ-3379 > Project: OFBiz > Issue Type: Bug > Components: framework >Affects Versions: Release Branch 09.04, Trunk >Reporter: Pranay Pandey >Assignee: Scott Gray > Attachments: OFBIZ-3379-2.patch, OFBIZ-3379.patch, OFBIZ-3379.patch, > OFBIZ-3379.patch > > > Typically BCCs are handled via the sending mail client. That is, when the > client sees a BCC in an email, it will open up two connections to the mail > server, the first for the To/CC fields, the second for BCC fields, this way > the addresses are masked from the headers and there is that layer of > anonymity that BCC is used for. > What appears to be happening is that OFBiz is sending all of the information > in one connection to the mail server and having the mail server sort out the > details. So when sendTo encountering an invalid email, and then terminating > the remaining execution of the outgoing process and no email sent to BCC > address which is usually going to be a valid address from email settings for > the company. > To fix the issue, we need to send this via two connection to mail client. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (OFBIZ-6689) Have more flexibility in framework and applications regarding theming frameworks.
[ https://issues.apache.org/jira/browse/OFBIZ-6689?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15098824#comment-15098824 ] Scott Gray commented on OFBIZ-6689: --- Adding pre-processors doesn't really add to the skill set burden because it only needs to be done once per CSS framework. The pre-processing would really only handle the OFBiz -> CSS framework class mappings, once that is done and shared with the community then users can carry on with customizing the CSS framework classes as per their needs. You call it flexibility but I call it complexity. I don't really care if support is added to the framework for it but I wouldn't like to see it used in the project's code. > Have more flexibility in framework and applications regarding theming > frameworks. > - > > Key: OFBIZ-6689 > URL: https://issues.apache.org/jira/browse/OFBIZ-6689 > Project: OFBiz > Issue Type: Improvement > Components: ALL APPLICATIONS, framework, themes >Affects Versions: Trunk >Reporter: Pierre Smits >Assignee: Pierre Smits > > Modern theming frameworks like Bootstrap and Foundation define their own > styling elements. In order to facilitate these frameworks (and others), the > framework and applications need to be improved. > This is an umbrella issue to track associated issues and sub tasks. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (OFBIZ-6689) Have more flexibility in framework and applications regarding theming frameworks.
[
https://issues.apache.org/jira/browse/OFBIZ-6689?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15097324#comment-15097324
]
Scott Gray commented on OFBIZ-6689:
---
It seems to me like a lot of the DOM manipulation in bootified.js could be
replaced by using a CSS pre-processor like Sass or LESS
For example the file contains:
{code:javascript}
//Transform a:buttontext
jQuery('a.buttontext').removeClass('buttontext').addClass('btn btn-link
btn-sm');
{code}
Which could be done in Sass with something like:
{code}
a.buttontext {
@extend .btn, .btn-link, .btn-sm;
}
{code}
My point is, I think it would be simpler to extend the CSS framework than it
would to try and make CSS class names configurable throughout the entire
application suite.
> Have more flexibility in framework and applications regarding theming
> frameworks.
> -
>
> Key: OFBIZ-6689
> URL: https://issues.apache.org/jira/browse/OFBIZ-6689
> Project: OFBiz
> Issue Type: Improvement
> Components: ALL APPLICATIONS, framework, themes
>Affects Versions: Trunk
>Reporter: Pierre Smits
>Assignee: Pierre Smits
>
> Modern theming frameworks like Bootstrap and Foundation define their own
> styling elements. In order to facilitate these frameworks (and others), the
> framework and applications need to be improved.
> This is an umbrella issue to track associated issues and sub tasks.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (OFBIZ-6697) CommunicationServices.createAttachmentContent duplicates attachments for existing CommunicationEvents
[ https://issues.apache.org/jira/browse/OFBIZ-6697?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15082334#comment-15082334 ] Scott Gray commented on OFBIZ-6697: --- Ah right sorry, I missed that it was a private method. > CommunicationServices.createAttachmentContent duplicates attachments for > existing CommunicationEvents > - > > Key: OFBIZ-6697 > URL: https://issues.apache.org/jira/browse/OFBIZ-6697 > Project: OFBiz > Issue Type: Bug > Components: party >Affects Versions: Trunk >Reporter: Gareth Carter >Assignee: Nicolas Malin >Priority: Minor > Attachments: FixDuplicateCommEventAttachments.patch > > > When sending an email from a CommunicationEvent that exists in the database > prior to calling sendMail/sendMailMultiPart, the seca > updateCommEventAfterEmail will call createAttachmentContent and store any > attachments into ImageDataResource and be referenced by the > CommunicationEvent even if the attachments already exist in the database (and > stored somewhere else). -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (OFBIZ-6784) JobSandbox : reload crashed job maybe duplicate pending service
[ https://issues.apache.org/jira/browse/OFBIZ-6784?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15080525#comment-15080525 ] Scott Gray commented on OFBIZ-6784: --- bq. Right the job run immediately, but the job is also planned one hour later. Weird, I thought this had been fixed already. reloadCrashedJobs shouldn't store recurrence/temporal info on the new job if the crashed job's status is SERVICE_RUNNING, because the init() of the crashed job will have already scheduled it before the server went down. It's just a matter of setting tempExprId and recurrenceInfoId to null before storing the new job. > JobSandbox : reload crashed job maybe duplicate pending service > --- > > Key: OFBIZ-6784 > URL: https://issues.apache.org/jira/browse/OFBIZ-6784 > Project: OFBiz > Issue Type: Bug > Components: framework >Affects Versions: Trunk >Reporter: Nicolas Malin >Assignee: Nicolas Malin > Labels: jobsandbox > Attachments: OFBIZ-6784.patch > > > When the JobPoller run reloadCrashedJobs() after an OFBiz restart, if you > have a large service that crash that already replenish the pool receive a new > run instant for it. > Example: If you have a service like loadExternalOrder that run each hours. > You stop your OFBiz during their activity and at restart you have : > * job1 loadExternalOrder RUNINNG > * job2 loadExternalOrder PENDING at t+1h (normal schedule) > * job1.1 loadExternalOrder PENDING at t+1h (crashed schedule) > I propose to exclude from the process reloadCrashedJobs() all jobs that have > already a new scheduled instance -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (OFBIZ-6746) removePartyContent request is called twice,
[
https://issues.apache.org/jira/browse/OFBIZ-6746?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15076469#comment-15076469
]
Scott Gray commented on OFBIZ-6746:
---
That URL style is used to retrieve a specific view in place of whatever is
normally defined in the controller. The javascript method that retrieves the
UiLabels via ajax is using a relative URL which causes the ajax request to end
up looking like /partymgr/control/removePartyContent/getJSONuiLabelArray
which causes the target to be triggered again.
The only solutions I can think of are:
1. Change the override view logic to actually do a request redirect rather than
just render the view, or;
2. Find some way to give the javascript an absolute URL to that ajax target
> removePartyContent request is called twice,
>
>
> Key: OFBIZ-6746
> URL: https://issues.apache.org/jira/browse/OFBIZ-6746
> Project: OFBiz
> Issue Type: Bug
> Components: party
>Affects Versions: Trunk
>Reporter: Deepak Dixit
>Priority: Minor
>
> Comments from OFBIZ-6708:
> Not sure why the removePartyContent request is called twice and the 2nd
> fails, and I have no time to investigate.
> {code}
> [java] 2015-11-21 22:52:38,110 |http-bio-8443-exec-6 |ControlServlet
>|T| [[[removePartyContent(Domain:https://localhost)] Request Begun,
> encoding=[UTF-8]- total:0.0,since last(Begin):0.0]]
> [java] 2015-11-21 22:52:38,134 |http-bio-8443-exec-6 |ServiceDispatcher
>|T| Sync service [partymgr/removePartyContent] finished in [18]
> milliseconds
> [java] 2015-11-21 22:52:38,134 |http-bio-8443-exec-6 |RequestHandler
>|I| Ran Event [service:#removePartyContent] from [request], result
> is [success]
> [java] 2015-11-21 22:52:38,135 |http-bio-8443-exec-6 |RequestHandler
>|I| Rendering View [viewprofile],
> sessionId=56DBE28A391381E1B44D53CD49968F7E.jvm1
> [java] 2015-11-21 22:52:38,136 |http-bio-8443-exec-6 |ServiceDispatcher
>|T| Sync service [partymgr/getUserPreferenceGroup] finished in [1]
> milliseconds
> [java] 2015-11-21 22:52:38,138 |http-bio-8443-exec-6 |ServiceDispatcher
>|T| Sync service [partymgr/getVisualThemeResources] finished in
> [1] milliseconds
> [java] 2015-11-21 22:52:38,163 |http-bio-8443-exec-6 |ScreenFactory
>|I| Got 39 screens in 0.008s from:
> file:/C:/projectASF-Mars/ofbiz/applications/party/widget/partymgr/PartyScreens.xml
> [java] 2015-11-21 22:52:38,210 |http-bio-8443-exec-6 |ScreenFactory
>|I| Got 4 screens in 0.005s from:
> file:/C:/projectASF-Mars/ofbiz/applications/party/widget/partymgr/CommonScreens.xml
> [java] 2015-11-21 22:52:38,216 |http-bio-8443-exec-6 |ScreenFactory
>|I| Got 1 screens in 0.005s from:
> file:/C:/projectASF-Mars/ofbiz/applications/commonext/widget/CommonScreens.xml
> [java] 2015-11-21 22:52:38,284 |http-bio-8443-exec-6 |ServiceDispatcher
>|T| Sync service [partymgr/getLastSystemInfoNote] finished in [17]
> milliseconds
> [java] 2015-11-21 22:52:38,286 |http-bio-8443-exec-6 |PrimaryKeyFinder
>|I| Returning null because found incomplete primary key in find:
> [GenericEntity:PartyAcctgPrefAndGroup][partyId,Company
> (java.lang.String)][roleTypeId,null()]
> [java] 2015-11-21 22:52:38,293 |http-bio-8443-exec-6 |ScreenFactory
>|I| Got 24 screens in 0.006s from:
> file:/C:/projectASF-Mars/ofbiz/framework/common/widget/CommonScreens.xml
> [java] 2015-11-21 22:52:38,392 |http-bio-8443-exec-6 |ServiceEcaRule
>|I| For Service ECA [partyBasePermissionCheck] on [return] got
> false for condition: [hasPermission][equals][false][true
> ][Boolean]
> [java] 2015-11-21 22:52:38,393 |http-bio-8443-exec-6 |ServiceDispatcher
>|T| Sync service [partymgr/partyBasePermissionCheck] finished in
> [46] milliseconds
> [java] 2015-11-21 22:52:38,401 |http-bio-8443-exec-6 |ServiceEcaRule
>|I| For Service ECA [partyBasePermissionCheck] on [return] got
> false for condition: [hasPermission][equals][false][true
> ][Boolean]
> [java] 2015-11-21 22:52:38,402 |http-bio-8443-exec-6 |ServiceDispatcher
>|T| Sync service [partymgr/partyBasePermissionCheck] finished in
> [1] milliseconds
> [java] 2015-11-21 22:52:38,419 |http-bio-8443-exec-6 |ServiceDispatcher
>|T| Sync service [partymgr/acctgBasePermissionCheck] finished in
> [12] milliseconds
> [java] 2015-11-21 22:52:38,421 |http-bio-8443-exec-6 |ServiceEcaRule
>|I| For Service ECA [partyBasePermissionCheck] on [return] got
> false for condition: [hasPermission][equals][false][true
> ][Boolean]
> [java] 2015-11-21 22:52:38,423
[jira] [Commented] (OFBIZ-6408) Adding a group order generates an error
[
https://issues.apache.org/jira/browse/OFBIZ-6408?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15076480#comment-15076480
]
Scott Gray commented on OFBIZ-6408:
---
If I'm not mistaken it should look like this:
{code}
{code}
i.e. the two boolean evaluations should reside in the same "groovy" scriptlet.
> Adding a group order generates an error
> ---
>
> Key: OFBIZ-6408
> URL: https://issues.apache.org/jira/browse/OFBIZ-6408
> Project: OFBiz
> Issue Type: Bug
> Components: product
>Affects Versions: Trunk, 13.07.01
>Reporter: Pierre Smits
> Labels: GroupOrder, catalog
>
> When adding a Group Order for a product the following error is returned:
> {code}
> org.ofbiz.widget.renderer.ScreenRenderException: Error rendering screen
> [component://product/widget/catalog/ProductScreens.xml#ViewProductGroupOrder]:
> org.ofbiz.widget.renderer.ScreenRenderException: Error rendering screen
> [component://product/widget/catalog/ProductScreens.xml#CommonProductDecorator]:
> org.ofbiz.widget.renderer.ScreenRenderException: Error rendering screen
> [component://product/widget/catalog/CommonScreens.xml#main-decorator]:
> org.ofbiz.widget.renderer.ScreenRenderException: Error rendering screen
> [component://commonext/widget/CommonScreens.xml#ApplicationDecorator]:
> org.ofbiz.widget.renderer.ScreenRenderException: Error rendering screen
> [component://common/widget/CommonScreens.xml#GlobalDecorator]:
> java.lang.RuntimeException: Error rendering included form named
> [ListProductGroupOrder] at location
> [component://product/widget/catalog/ProductForms.xml]:
> java.lang.IllegalArgumentException: Error evaluating BeanShell use-when
> condition [true&&] on the field editLink of form ListProductGroupOrder: In
> file: inline evaluation of: ``true&&;'' Encountered ";" at line 1, column 7.
> java.lang.IllegalArgumentException: Error evaluating BeanShell use-when
> condition [true&&] on the field editLink of form ListProductGroupOrder: In
> file: inline evaluation of: ``true&&;'' Encountered ";" at line 1, column 7.
> (Error rendering included form named [ListProductGroupOrder] at location
> [component://product/widget/catalog/ProductForms.xml]:
> java.lang.IllegalArgumentException: Error evaluating BeanShell use-when
> condition [true&&] on the field editLink of form ListProductGroupOrder: In
> file: inline evaluation of: ``true&&;'' Encountered ";" at line 1, column 7.
> java.lang.IllegalArgumentException: Error evaluating BeanShell use-when
> condition [true&&] on the field editLink of form ListProductGroupOrder: In
> file: inline evaluation of: ``true&&;'' Encountered ";" at line 1, column 7.
> ) (Error rendering screen
> [component://common/widget/CommonScreens.xml#GlobalDecorator]:
> java.lang.RuntimeException: Error rendering included form named
> [ListProductGroupOrder] at location
> [component://product/widget/catalog/ProductForms.xml]:
> java.lang.IllegalArgumentException: Error evaluating BeanShell use-when
> condition [true&&] on the field editLink of form ListProductGroupOrder: In
> file: inline evaluation of: ``true&&;'' Encountered ";" at line 1, column 7.
> java.lang.IllegalArgumentException: Error evaluating BeanShell use-when
> condition [true&&] on the field editLink of form ListProductGroupOrder: In
> file: inline evaluation of: ``true&&;'' Encountered ";" at line 1, column 7.
> (Error rendering included form named [ListProductGroupOrder] at location
> [component://product/widget/catalog/ProductForms.xml]:
> java.lang.IllegalArgumentException: Error evaluating BeanShell use-when
> condition [true&&] on the field editLink of form ListProductGroupOrder: In
> file: inline evaluation of: ``true&&;'' Encountered ";" at line 1, column 7.
> java.lang.IllegalArgumentException: Error evaluating BeanShell use-when
> condition [true&&] on the field editLink of form ListProductGroupOrder: In
> file: inline evaluation of: ``true&&;'' Encountered ";" at line 1, column 7.
> )) (Error rendering screen
> [component://commonext/widget/CommonScreens.xml#ApplicationDecorator]:
> org.ofbiz.widget.renderer.ScreenRenderException: Error rendering screen
> [component://common/widget/CommonScreens.xml#GlobalDecorator]:
> java.lang.RuntimeException: Error rendering included form named
> [ListProductGroupOrder] at location
> [component://product/widget/catalog/ProductForms.xml]:
> java.lang.IllegalArgumentException: Error evaluating BeanShell use-when
> condition [true&&] on the field editLink of form ListProductGroupOrder: In
> file: inline evaluation of: ``true&&;'' Encountered ";" at line 1, column 7.
> java.lang.IllegalArgumentException: Error evaluating BeanShell use-when
> condition [true&&] on the field editLink of form ListProductGroupOrder: In
> file: inline evaluation of:
[jira] [Commented] (OFBIZ-6774) ACCTG TRANS ENTRIES PDF link on invoiceOverview does not work
[
https://issues.apache.org/jira/browse/OFBIZ-6774?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15076465#comment-15076465
]
Scott Gray commented on OFBIZ-6774:
---
These are links to the BIRT component that wasn't included in the 13.07
release. The accounting -> birt dependency shouldn't have been created and
these links should be removed from all versions.
> ACCTG TRANS ENTRIES PDF link on invoiceOverview does not work
> -
>
> Key: OFBIZ-6774
> URL: https://issues.apache.org/jira/browse/OFBIZ-6774
> Project: OFBiz
> Issue Type: Bug
> Components: order, specialpurpose/birt
>Affects Versions: Release Branch 13.07
> Environment: Ubuntu linux 15.04, JVM 7u91-2.6.3-0ubuntu0.15.04.1
>Reporter: Morten Jensen
>Priority: Minor
>
> Whenever I click on the ACCTG TRANS ENTRIES PDF link in the invoice overview
> screen I get the following error:
> org.ofbiz.webapp.control.RequestHandlerException: Unknown request
> [InvoiceAcctgTransEntriesPdf]; this request does not exist or cannot be
> called directly.
> A grep through the full ofbiz repo yields no results for an implementation or
> freemarker template - only the link itself in accounting menus xml:
> git checkout release13.07
> find . -type f -exec grep -i InvoiceAcctgTransEntriesPdf {} \; -ls
>
> 528005 72 -rw-rw-r-- 1 xxx xxx 70103 Dec 17 07:05
> ./applications/accounting/widget/AccountingMenus.xml
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Closed] (OFBIZ-5907) Postgresql jdbc driver is causing exception. Mysql driver is working ok.
[ https://issues.apache.org/jira/browse/OFBIZ-5907?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Scott Gray closed OFBIZ-5907. - > Postgresql jdbc driver is causing exception. Mysql driver is working ok. > - > > Key: OFBIZ-5907 > URL: https://issues.apache.org/jira/browse/OFBIZ-5907 > Project: OFBiz > Issue Type: Bug > Components: framework >Affects Versions: Trunk > Environment: OS: > Ubuntu 14.04 > Java: > java version "1.7.0_71" > Java(TM) SE Runtime Environment (build 1.7.0_71-b14) > Java HotSpot(TM) 64-Bit Server VM (build 24.71-b01, mixed mode) >Reporter: Wai > > I've discovered an issue and I do not know if it lies in the entity engine or > the jdbc driver. > I have the following entity view. > title="View entity"> > > entity-name="UserLoginSecurityGroup" /> > > group-by="true" /> > > function="count-distinct" /> > rel-optional="true"> > > > rel-optional="true"> > > > > operator="equals" /> > > > When ofbiz is run using the latest mysql jdbc driver (v5.1.34), the proper > sql statement is generated and all runs well. But when the Postgresql jdbc > driver is used, it causes an exception. I have tried with the following > latest Postgresql drivers and they have all failed. > JDBC3 Postgresql Driver, Version 9.3-1102 > JDBC4 Postgresql Driver, Version 9.3-1102 > JDBC41 Postgresql Driver, Version 9.3-1102 > Mysql jdbc driver would generate the following sql statement: > SELECT SG.GROUP_ID, ULSG.USER_LOGIN_ID, COUNT(DISTINCT ULSG.USER_LOGIN_ID) > FROM SECURITY_GROUP SG LEFT OUTER JOIN USER_LOGIN_SECURITY_GROUP ULSG ON > SG.GROUP_ID = ULSG.GROUP_ID LEFT OUTER JOIN USER_LOGIN UL ON > ULSG.USER_LOGIN_ID = UL.USER_LOGIN_ID WHERE ((ULSG.THRU_DATE IS NULL)) GROUP > BY SG.GROUP_ID > Postgresql jdbc driver would give the following exception (Notice the > resulting sql statement is corrupted with 'public.' ???): > Failure in operation, rolling back transaction > org.ofbiz.entity.GenericDataSourceException: SQL Exception while executing > the following:SELECT SG.GROUP_ID, ULSG.USER_LOGIN_ID, COUNT(DISTINCT > ULSG.USER_LOGIN_ID) FROM (public.SECURITY_GROUP SG LEFT OUTER JOIN > public.USER_LOGIN_SECURITY_GROUP ULSG ON SG.GROUP_ID = ULSG.GROUP_ID) LEFT > OUTER JOIN public.USER_LOGIN UL ON ULSG.USER_LOGIN_ID = UL.USER_LOGIN_ID > WHERE ((ULSG.THRU_DATE IS NULL)) GROUP BY SG.GROUP_ID (ERROR: column > "ulsg.user_login_id" must appear in the GROUP BY clause or be used in an > aggregate function > Position: 21) > at > org.ofbiz.entity.jdbc.SQLProcessor.executeQuery(SQLProcessor.java:409) > ~[ofbiz-entity.jar:?] > at > org.ofbiz.entity.datasource.GenericDAO.selectListIteratorByCondition(GenericDAO.java:785) > ~[ofbiz-entity.jar:?] > at > org.ofbiz.entity.datasource.GenericHelperDAO.findListIteratorByCondition(GenericHelperDAO.java:140) > ~[ofbiz-entity.jar:?] > at org.ofbiz.entity.GenericDelegator.find(GenericDelegator.java:1774) > ~[ofbiz-entity.jar:?] > at > org.ofbiz.entity.util.EntityQuery.queryIterator(EntityQuery.java:392) > ~[ofbiz-entity.jar:?] > at org.ofbiz.entity.util.EntityQuery$queryIterator$1.call(Unknown > Source) ~[?:?] -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (OFBIZ-5907) Postgresql jdbc driver is causing exception. Mysql driver is working ok.
[ https://issues.apache.org/jira/browse/OFBIZ-5907?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Scott Gray resolved OFBIZ-5907. --- Resolution: Not A Problem > Postgresql jdbc driver is causing exception. Mysql driver is working ok. > - > > Key: OFBIZ-5907 > URL: https://issues.apache.org/jira/browse/OFBIZ-5907 > Project: OFBiz > Issue Type: Bug > Components: framework >Affects Versions: Trunk > Environment: OS: > Ubuntu 14.04 > Java: > java version "1.7.0_71" > Java(TM) SE Runtime Environment (build 1.7.0_71-b14) > Java HotSpot(TM) 64-Bit Server VM (build 24.71-b01, mixed mode) >Reporter: Wai > > I've discovered an issue and I do not know if it lies in the entity engine or > the jdbc driver. > I have the following entity view. > title="View entity"> > > entity-name="UserLoginSecurityGroup" /> > > group-by="true" /> > > function="count-distinct" /> > rel-optional="true"> > > > rel-optional="true"> > > > > operator="equals" /> > > > When ofbiz is run using the latest mysql jdbc driver (v5.1.34), the proper > sql statement is generated and all runs well. But when the Postgresql jdbc > driver is used, it causes an exception. I have tried with the following > latest Postgresql drivers and they have all failed. > JDBC3 Postgresql Driver, Version 9.3-1102 > JDBC4 Postgresql Driver, Version 9.3-1102 > JDBC41 Postgresql Driver, Version 9.3-1102 > Mysql jdbc driver would generate the following sql statement: > SELECT SG.GROUP_ID, ULSG.USER_LOGIN_ID, COUNT(DISTINCT ULSG.USER_LOGIN_ID) > FROM SECURITY_GROUP SG LEFT OUTER JOIN USER_LOGIN_SECURITY_GROUP ULSG ON > SG.GROUP_ID = ULSG.GROUP_ID LEFT OUTER JOIN USER_LOGIN UL ON > ULSG.USER_LOGIN_ID = UL.USER_LOGIN_ID WHERE ((ULSG.THRU_DATE IS NULL)) GROUP > BY SG.GROUP_ID > Postgresql jdbc driver would give the following exception (Notice the > resulting sql statement is corrupted with 'public.' ???): > Failure in operation, rolling back transaction > org.ofbiz.entity.GenericDataSourceException: SQL Exception while executing > the following:SELECT SG.GROUP_ID, ULSG.USER_LOGIN_ID, COUNT(DISTINCT > ULSG.USER_LOGIN_ID) FROM (public.SECURITY_GROUP SG LEFT OUTER JOIN > public.USER_LOGIN_SECURITY_GROUP ULSG ON SG.GROUP_ID = ULSG.GROUP_ID) LEFT > OUTER JOIN public.USER_LOGIN UL ON ULSG.USER_LOGIN_ID = UL.USER_LOGIN_ID > WHERE ((ULSG.THRU_DATE IS NULL)) GROUP BY SG.GROUP_ID (ERROR: column > "ulsg.user_login_id" must appear in the GROUP BY clause or be used in an > aggregate function > Position: 21) > at > org.ofbiz.entity.jdbc.SQLProcessor.executeQuery(SQLProcessor.java:409) > ~[ofbiz-entity.jar:?] > at > org.ofbiz.entity.datasource.GenericDAO.selectListIteratorByCondition(GenericDAO.java:785) > ~[ofbiz-entity.jar:?] > at > org.ofbiz.entity.datasource.GenericHelperDAO.findListIteratorByCondition(GenericHelperDAO.java:140) > ~[ofbiz-entity.jar:?] > at org.ofbiz.entity.GenericDelegator.find(GenericDelegator.java:1774) > ~[ofbiz-entity.jar:?] > at > org.ofbiz.entity.util.EntityQuery.queryIterator(EntityQuery.java:392) > ~[ofbiz-entity.jar:?] > at org.ofbiz.entity.util.EntityQuery$queryIterator$1.call(Unknown > Source) ~[?:?] -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (OFBIZ-6774) ACCTG TRANS ENTRIES PDF link on invoiceOverview does not work
[
https://issues.apache.org/jira/browse/OFBIZ-6774?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Scott Gray updated OFBIZ-6774:
--
Component/s: specialpurpose/birt
> ACCTG TRANS ENTRIES PDF link on invoiceOverview does not work
> -
>
> Key: OFBIZ-6774
> URL: https://issues.apache.org/jira/browse/OFBIZ-6774
> Project: OFBiz
> Issue Type: Bug
> Components: order, specialpurpose/birt
>Affects Versions: Release Branch 13.07
> Environment: Ubuntu linux 15.04, JVM 7u91-2.6.3-0ubuntu0.15.04.1
>Reporter: Morten Jensen
>Priority: Minor
>
> Whenever I click on the ACCTG TRANS ENTRIES PDF link in the invoice overview
> screen I get the following error:
> org.ofbiz.webapp.control.RequestHandlerException: Unknown request
> [InvoiceAcctgTransEntriesPdf]; this request does not exist or cannot be
> called directly.
> A grep through the full ofbiz repo yields no results for an implementation or
> freemarker template - only the link itself in accounting menus xml:
> git checkout release13.07
> find . -type f -exec grep -i InvoiceAcctgTransEntriesPdf {} \; -ls
>
> 528005 72 -rw-rw-r-- 1 xxx xxx 70103 Dec 17 07:05
> ./applications/accounting/widget/AccountingMenus.xml
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (OFBIZ-6111) Strange Behaviour of the eCommerce Login Link
[ https://issues.apache.org/jira/browse/OFBIZ-6111?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15076494#comment-15076494 ] Scott Gray commented on OFBIZ-6111: --- Looks like the issue is caused by a dropped session. A new session is created when the logout occurs and the user is redirected to the main page. Because the redirect switches the user from https to http, the JSESSIONID is included in the URL of the redirect and isn't set as a cookie (I'm not sure why). I think the session id inclusion in the URL is preventing the session id from being sent as a cookie in the subsequent response of the redirect. So after this point, when the user submits the add to cart form, there's no session id passed in the request via URL or by cookie and hence a new session is created. The "main" view was saved as the _SAVED_VIEW_NAME_ session attribute but that was lost when the additional session was created, so the request handler defaults back to the default view of "viewCart". Something like that anyway. It could possibly be a Tomcat bug given that any of the following would solve the problem: 1. Tomcat could set the session cookie during the redirect response 2. Tomcat could set the session cookie in the subsequent response Unless I'm missing something. > Strange Behaviour of the eCommerce Login Link > - > > Key: OFBIZ-6111 > URL: https://issues.apache.org/jira/browse/OFBIZ-6111 > Project: OFBiz > Issue Type: Bug > Components: specialpurpose/ecommerce >Affects Versions: Release Branch 12.04, Release Branch 13.07, Trunk >Reporter: Forrest Rae >Assignee: Arun Patidar >Priority: Trivial > Attachments: OFBIZ-6111.patch, OFBIZ-6111.patch > > > I've noticed some strange behaviour with the Login link in the eCommerce > application. If you're visit the Login link from "main", you're redirected > back to the Login view even after logging in: > 1) Visit http://demo-stable-ofbiz.apache.org/ecommerce/control/main > 2) Click "Login" in the upper left > 3) Login as "DemoCustomer" with a password of "ofbiz" > 4) Notice that you're at a new URL, logged in, but the login form is redrawn. > Compare this with how it's supposed to work: > 1) Logout > 2) Visit http://demo-stable-ofbiz.apache.org/ecommerce/tiny-gismo-GZ-1000-p > 3) Click "Login" in the upper left > 4) Login as "DemoCustomer" with a password of "ofbiz" > 5) Notice that you're at a new URL, but the product page is redrawn correctly. > It's just really strange behaviour, quite hard to track down, and I can't > really find a root cause. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (OFBIZ-6786) link does not invoke jquery dialog when clicked
[
https://issues.apache.org/jira/browse/OFBIZ-6786?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15076682#comment-15076682
]
Scott Gray commented on OFBIZ-6786:
---
This happens because the generated function names are invalid e.g. {code}
function Modal_fe352826-3a01-45f0-94b9-93fddd9bff00_data () {code}
MacroFormRenderer.makeHyperLinkByType is using a UUID random ID to generate
unique item names. It should use something else or otherwise strip the dashes
from the ID.
> link does not invoke jquery dialog when clicked
> ---
>
> Key: OFBIZ-6786
> URL: https://issues.apache.org/jira/browse/OFBIZ-6786
> Project: OFBiz
> Issue Type: Bug
> Components: framework
>Affects Versions: Trunk
>Reporter: Wai
>
> -use demo database.
> -go to
> http://demo-trunk-ofbiz.apache.org/example/control/authview/findExampleAjax
> -click on link cell.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (OFBIZ-6111) Strange Behaviour of the eCommerce Login Link
[
https://issues.apache.org/jira/browse/OFBIZ-6111?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15076677#comment-15076677
]
Scott Gray commented on OFBIZ-6111:
---
After a closer look this morning, it appears that the session is dropped
because it was created during an HTTPS request (logout) and is then passed to a
unsecure HTTP request in the URL. Tomcat uses the session for the unsecure
request but (correctly) it won't send it back as an unsecure session cookie.
IMO we shouldn't be passing a secure session ID to an unsecure request.
In RequestHandler.makeLink(HttpServletRequest, HttpServletResponse, String,
boolean, boolean, boolean) we have the following code:
{code}
// if this isn't a secure page, but we made a secure URL, make sure
we manually add the jsessionid since the response.encodeURL won't do that
if (!request.isSecure() && didFullSecure) {
forceManualJsessionid = true;
}
// if this is a secure page, but we made a standard URL, make sure
we manually add the jsessionid since the response.encodeURL won't do that
if (request.isSecure() && didFullStandard) {
forceManualJsessionid = true;
}
{code}
But I would argue that in both of the above cases, the reason that
response.encodeURL won't include the jsessionid is because it isn't safe to do
so from a security point of view. In both cases you've got the potential for
session hijacking because either a secure cookie id has been passed in plain
text or an unsecure session id will be used in place of a secure one. I think
we should remove the logic relating to the forceManualJsessionid variable.
> Strange Behaviour of the eCommerce Login Link
> -
>
> Key: OFBIZ-6111
> URL: https://issues.apache.org/jira/browse/OFBIZ-6111
> Project: OFBiz
> Issue Type: Bug
> Components: specialpurpose/ecommerce
>Affects Versions: Release Branch 12.04, Release Branch 13.07, Trunk
>Reporter: Forrest Rae
>Assignee: Arun Patidar
>Priority: Trivial
> Attachments: OFBIZ-6111.patch, OFBIZ-6111.patch
>
>
> I've noticed some strange behaviour with the Login link in the eCommerce
> application. If you're visit the Login link from "main", you're redirected
> back to the Login view even after logging in:
> 1) Visit http://demo-stable-ofbiz.apache.org/ecommerce/control/main
> 2) Click "Login" in the upper left
> 3) Login as "DemoCustomer" with a password of "ofbiz"
> 4) Notice that you're at a new URL, logged in, but the login form is redrawn.
> Compare this with how it's supposed to work:
> 1) Logout
> 2) Visit http://demo-stable-ofbiz.apache.org/ecommerce/tiny-gismo-GZ-1000-p
> 3) Click "Login" in the upper left
> 4) Login as "DemoCustomer" with a password of "ofbiz"
> 5) Notice that you're at a new URL, but the product page is redrawn correctly.
> It's just really strange behaviour, quite hard to track down, and I can't
> really find a root cause.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (OFBIZ-5608) Dates Displaying Incorrectly With Negative Offest Timezones.
[
https://issues.apache.org/jira/browse/OFBIZ-5608?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15076752#comment-15076752
]
Scott Gray commented on OFBIZ-5608:
---
I know this is a long ticket and I don't want to rehash all of this, but I am
confused. Under what circumstances would we ever use the following:
{code:xml}
{code}
I can't think of a date when that we'd ever want to apply timezone formatting
to.
> Dates Displaying Incorrectly With Negative Offest Timezones.
>
>
> Key: OFBIZ-5608
> URL: https://issues.apache.org/jira/browse/OFBIZ-5608
> Project: OFBiz
> Issue Type: Bug
> Components: ALL COMPONENTS
>Affects Versions: Release Branch 12.04, Release Branch 13.07, Trunk
>Reporter: Rupert Howell
>Assignee: Jacques Le Roux
>Priority: Minor
> Attachments: DateField_1.jpg, DateField_2.jpg, French calendar
> tootip.png, IgnoreTimeZone.patch, ObjectTypeTests.patch, dates.patch,
> dates_1589040.patch, en-GB calendar tootip.png, sqldate_scenarios.png
>
>
> Dates are displaying incorrectly when negative offset (relative to UTC) are
> applied by the users settings.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (OFBIZ-6743) Error on the Split Payment button from the Quick Finalize Order screen
[ https://issues.apache.org/jira/browse/OFBIZ-6743?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15076758#comment-15076758 ] Scott Gray commented on OFBIZ-6743: --- Looks like the view-map was moved to ecommerce in r544053. Probably because the view-map wasn't referenced in the controller.xml for ordermgr. It is actually used though as a view override in component://order/webapp/ordermgr/entry/checkoutoptions.ftl Just needs to be restored in the controller and have the screen moved back. > Error on the Split Payment button from the Quick Finalize Order screen > -- > > Key: OFBIZ-6743 > URL: https://issues.apache.org/jira/browse/OFBIZ-6743 > Project: OFBiz > Issue Type: Bug > Components: order >Affects Versions: Release Branch 12.04, Release Branch 13.07, Release > Branch 14.12, Trunk >Reporter: Jacques Le Roux > > Error in trunk: > ERROR rendering error page [/error/error.jsp], but here is the error text: > org.ofbiz.webapp.control.RequestHandlerException: No definition found for > view with name [checkoutpayment] > Error in stable and old: > org.ofbiz.webapp.control.RequestHandlerException: No definition found for > view with name [checkoutpayment] > This is the same kind of error you got with OFBIZ-6741 before it was fixed -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (OFBIZ-6697) CommunicationServices.createAttachmentContent duplicates attachments for existing CommunicationEvents
[ https://issues.apache.org/jira/browse/OFBIZ-6697?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15076753#comment-15076753 ] Scott Gray commented on OFBIZ-6697: --- There's no need to change the method signature since you're getting the delegator from the dispatcher anyway. And if the signature did need to change, the old should be deprecated rather than removed. Otherwise the patch looks fine to me, I haven't tested it though. > CommunicationServices.createAttachmentContent duplicates attachments for > existing CommunicationEvents > - > > Key: OFBIZ-6697 > URL: https://issues.apache.org/jira/browse/OFBIZ-6697 > Project: OFBiz > Issue Type: Bug > Components: party >Affects Versions: Trunk >Reporter: Gareth Carter >Assignee: Nicolas Malin >Priority: Minor > Attachments: FixDuplicateCommEventAttachments.patch > > > When sending an email from a CommunicationEvent that exists in the database > prior to calling sendMail/sendMailMultiPart, the seca > updateCommEventAfterEmail will call createAttachmentContent and store any > attachments into ImageDataResource and be referenced by the > CommunicationEvent even if the attachments already exist in the database (and > stored somewhere else). -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (OFBIZ-6781) Incorrect order adjustment after order item is cancelled
[ https://issues.apache.org/jira/browse/OFBIZ-6781?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15076462#comment-15076462 ] Scott Gray commented on OFBIZ-6781: --- Looks like a bug in the loadCartFromOrder service, it shouldn't be loading the order header level promo adjustments from the database. Was introduced in r745257 from ticket OFBIZ-1945. > Incorrect order adjustment after order item is cancelled > > > Key: OFBIZ-6781 > URL: https://issues.apache.org/jira/browse/OFBIZ-6781 > Project: OFBiz > Issue Type: Bug > Components: order >Affects Versions: Trunk >Reporter: Vyom Jain > > Steps to replicate (tested on trunk at r1721093) - > 1. Make sure promotion > https://localhost:8443/catalog/control/EditProductPromo?productPromoId=9011 > is enabled. > 2. Create a sales order after adding to cart 1 x GZ-1001 @ $25.99 & 1 x > GZ-1000 @ $15.99 > 3. order view screen shows Total Other Order Adjustments as -$4.2, which is > correct. > 4. Cancel 1 x GZ-1001 @ $25.99 > 5. Reload order view screen. > Observed - > 1. order view screen shows Total Other Order Adjustments as -($4.20 + $1.6) = > -$5.8 > Expected - > 1. order view screen should show Total Other Order Adjustments as -$1.6 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (OFBIZ-6784) JobSandbox : reload crashed job maybe duplicate pending service
[ https://issues.apache.org/jira/browse/OFBIZ-6784?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15076404#comment-15076404 ] Scott Gray commented on OFBIZ-6784: --- The new job created by the crashed job is set to run immediately, not after one hour. I disagree with this change. What if the job runs weekly/monthly/yearly instead of hourly? I think it is better to run a recurring job too often than not often enough. > JobSandbox : reload crashed job maybe duplicate pending service > --- > > Key: OFBIZ-6784 > URL: https://issues.apache.org/jira/browse/OFBIZ-6784 > Project: OFBiz > Issue Type: Bug > Components: framework >Affects Versions: Trunk >Reporter: Nicolas Malin >Assignee: Nicolas Malin > Labels: jobsandbox > Attachments: OFBIZ-6784.patch > > > When the JobPoller run reloadCrashedJobs() after an OFBiz restart, if you > have a large service that crash that already replenish the pool receive a new > run instant for it. > Example: If you have a service like loadExternalOrder that run each hours. > You stop your OFBiz during their activity and at restart you have : > * job1 loadExternalOrder RUNINNG > * job2 loadExternalOrder PENDING at t+1h (normal schedule) > * job1.1 loadExternalOrder PENDING at t+1h (crashed schedule) > I propose to exclude from the process reloadCrashedJobs() all jobs that have > already a new scheduled instance -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (OFBIZ-6782) Service parameter should be required.
[ https://issues.apache.org/jira/browse/OFBIZ-6782?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15076406#comment-15076406 ] Scott Gray commented on OFBIZ-6782: --- Are you sure you're using the 14.12 release? Because it appears to have been fixed already in that branch: Diff: http://svn.apache.org/viewvc/ofbiz/branches/release14.12/applications/accounting/src/org/ofbiz/accounting/tax/TaxAuthorityServices.java?r1=1511742=1534062 Commit: http://svn.apache.org/viewvc?view=revision=1534062 > Service parameter should be required. > - > > Key: OFBIZ-6782 > URL: https://issues.apache.org/jira/browse/OFBIZ-6782 > Project: OFBiz > Issue Type: Bug > Components: accounting >Affects Versions: Release Branch 14.12 >Reporter: Kulwant Singh > > There is no null check on one of parameters "itemShippingList" of calcTax > service implemented in TaxAuthorityServices.java by name of > rateProductTaxCalc. > Now this parameter should either be made required in service defination in > services_tax.xml or null check should be present just like the other > parameters like itemQuantity have. > because when i am trying to run this service with only passing required > parameters it is throwing null pointer exception. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (OFBIZ-6436) Different price Order vs. Invoice due rounding
[ https://issues.apache.org/jira/browse/OFBIZ-6436?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14568023#comment-14568023 ] Scott Gray commented on OFBIZ-6436: --- Order rounding and unit price rounding are not the same thing, please do not apply this patch. Typically order amounts are rounded as late as possible in order to gain the most accurate order total possible. I'm not sure why the invoice items are calculating to 2dp, they should be going to 3dp the same as order items and then being rounded for the invoice total only. This strategy increases the accuracy of invoice amounts when an order is broken into multiple invoices. Different price Order vs. Invoice due rounding -- Key: OFBIZ-6436 URL: https://issues.apache.org/jira/browse/OFBIZ-6436 Project: OFBiz Issue Type: Improvement Affects Versions: Release Branch 13.07, Release Branch 14.12, Trunk Reporter: Ingo Wolfmayr Assignee: Michael Brohl Attachments: priceservices.patch When creating an order with the following data, invoice and order calculates different prices due to different rounding strategies: Example: Net price: 8,70 Price Rule: 2 % Calc price: 8,526 Order quantity: 2 Rounding order: 2 dec Rounding invoice: 2 dec Both: ROUND_HALF_UP Calculation for order price: 8,526 * 2 = 17,052 -- Rouning = 17,05 (rounding takes place after multipying with the order quantity ) Calculation for invoice price: 8,53 * 2 = 17,06 (rounding takes place before multipying with the order quantity) Rounding takes place on different places and leads to (from my understanding) misscalculation. I create a patch that applies rounding on PriceCalculation level. Therefore: 1) get singe unit price and do all calculations on it (Price rules ...) 2) before forwarding the price, apply rounding (ORDER SETTINGS) on single unit price As the invoice calculation uses the unit price (if invoice is associate with order) from ORDER_ITEM it will calculate with the already rounded value. Result: Order Price = Invoice Price I would appreciate any thought on it. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (OFBIZ-5927) Issue reported while performing Refund Void (java.lang.ClassCastException: java.lang.String cannot be cast to java.math.BigDecimal)
[ https://issues.apache.org/jira/browse/OFBIZ-5927?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14363897#comment-14363897 ] Scott Gray commented on OFBIZ-5927: --- My contribution was the code review, I don't have time right now to do any more. You're more than welcome to commit the patch I provided. Issue reported while performing Refund Void (java.lang.ClassCastException: java.lang.String cannot be cast to java.math.BigDecimal) - Key: OFBIZ-5927 URL: https://issues.apache.org/jira/browse/OFBIZ-5927 Project: OFBiz Issue Type: Bug Affects Versions: Trunk, 12.04.05, 13.07.01 Reporter: Prateek Issue reported while performing Refund Void (java.lang.ClassCastException: java.lang.String cannot be cast to java.math.BigDecimal) Change needs to be done in AIMPaymentServices.java. Please look at the following small patch:- //BigDecimal amount = (BigDecimal) request.get(x_Amount); String newAmt = request.get(x_Amount).toString(); BigDecimal amount = new BigDecimal(newAmt); -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (OFBIZ-6150) Have 'Temporal Expression' Screen deliver the overview on opening screen
[ https://issues.apache.org/jira/browse/OFBIZ-6150?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14361236#comment-14361236 ] Scott Gray commented on OFBIZ-6150: --- Adrian is correct, the OFBiz default is to not perform an initial find before the user interacts with the search form. As he mentioned this default behavior is also configurable so I think we're fine to close this ticket as invalid. Have 'Temporal Expression' Screen deliver the overview on opening screen Key: OFBIZ-6150 URL: https://issues.apache.org/jira/browse/OFBIZ-6150 Project: OFBiz Issue Type: Improvement Components: framework Affects Versions: Trunk Reporter: Pierre Smits Priority: Minor Attachments: OFBIZ-6150-TempExprScreens-SEARCH.patch, tempExprForms.xml.0.patch Currently the Find Temporal Expressions screen doesn't show any data on opening the screen, which leads to a diminished UX. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (OFBIZ-6147) setInvoiceStatus causes incorrect header information when an error occurs
[ https://issues.apache.org/jira/browse/OFBIZ-6147?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14361288#comment-14361288 ] Scott Gray commented on OFBIZ-6147: --- This sounds like a duplicate of OFBIZ-1537 setInvoiceStatus causes incorrect header information when an error occurs - Key: OFBIZ-6147 URL: https://issues.apache.org/jira/browse/OFBIZ-6147 Project: OFBiz Issue Type: Bug Affects Versions: Trunk Reporter: Christian Carlow Priority: Minor When viewing an invoice at accounting/control/invoiceOverview, if a status change button is clicked and fails, the invoice header incorrectly displays the status as the one to which it failed to update and the description disappears. Its fairly minor but worth fixing eventually. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (OFBIZ-6106) Have the Quote Items overview show the quoteItemSeqId
[ https://issues.apache.org/jira/browse/OFBIZ-6106?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14361302#comment-14361302 ] Scott Gray commented on OFBIZ-6106: --- For what purpose? Have the Quote Items overview show the quoteItemSeqId - Key: OFBIZ-6106 URL: https://issues.apache.org/jira/browse/OFBIZ-6106 Project: OFBiz Issue Type: Improvement Components: order Affects Versions: Trunk Reporter: Pierre Smits Labels: quote Currently the overview of quote items doesn't show the quoteItemSeqId. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (OFBIZ-5959) Add lifespan fields to PartyRole
[ https://issues.apache.org/jira/browse/OFBIZ-5959?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14282260#comment-14282260 ] Scott Gray commented on OFBIZ-5959: --- Yeah maybe have a discussion before creating a huge number of tickets. PartyRelationship is intended for the type of use case you're looking at here. PartyRole very rarely makes sense to use for just about anything because it provides no context for the role. It's already been overused in OFBiz as a lazy way of saying the Party has a given role in relation to the company using OFBiz (i.e. an implied role). It is much better IMO to use context specific entities for defining roles such as PartyRelationship, OrderRole, AgreementRole, etc. I can't really even think of a reason why PartyRole exists as all. Add lifespan fields to PartyRole Key: OFBIZ-5959 URL: https://issues.apache.org/jira/browse/OFBIZ-5959 Project: OFBiz Issue Type: Improvement Components: party Affects Versions: Trunk Reporter: Pierre Smits Labels: role, roles Currently the assignments of roles to parties are boolean (there or not there). However, these role assignments also have a lifespan. This can be achieved by adding fromDate and thruDate fields. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (OFBIZ-5927) Issue reported while performing Refund Void (java.lang.ClassCastException: java.lang.String cannot be cast to java.math.BigDecimal)
[ https://issues.apache.org/jira/browse/OFBIZ-5927?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14256860#comment-14256860 ] Scott Gray commented on OFBIZ-5927: --- Reposting my comments here so that it's easier to follow: I know it looks like this makes sense at first glance but sometimes it's useful to look at the history of changes. It should be clear that something is amiss because of the useless try/catch block directly below your change. It points out that perhaps this code previously did something similar to what you're trying to do here. So I have a look and we find this commit: http://svn.apache.org/viewvc?view=revisionrevision=1303329 Maybe these changes warrant further investigation instead of committers switching it back and forth every few years. Because neither Jacques nor Hans have bothered to fully review the issue, you've both missed that the problem is that ccRelease(...) is passing a BigDecimal into the x_Amount map value while every other method is putting a String on that value. The getXAmount method need to be restored properly back to what it was before Hans' commit (i.e. actually use the try/catch block when creating the BigDecimal) and ccRelease(...) needs to convert the BigDecimal to a String before putting it in the map. Issue reported while performing Refund Void (java.lang.ClassCastException: java.lang.String cannot be cast to java.math.BigDecimal) - Key: OFBIZ-5927 URL: https://issues.apache.org/jira/browse/OFBIZ-5927 Project: OFBiz Issue Type: Bug Reporter: Prateek Ashtikar Fix For: Upcoming Branch, 12.04.06, 13.07.02 Issue reported while performing Refund Void (java.lang.ClassCastException: java.lang.String cannot be cast to java.math.BigDecimal) Change needs to be done in AIMPaymentServices.java. Please look at the following small patch:- //BigDecimal amount = (BigDecimal) request.get(x_Amount); String newAmt = request.get(x_Amount).toString(); BigDecimal amount = new BigDecimal(newAmt); -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (OFBIZ-5927) Issue reported while performing Refund Void (java.lang.ClassCastException: java.lang.String cannot be cast to java.math.BigDecimal)
[
https://issues.apache.org/jira/browse/OFBIZ-5927?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14257641#comment-14257641
]
Scott Gray commented on OFBIZ-5927:
---
Sorry if my comment was unclear, here is what I am saying should be done:
{code}
Index:
applications/accounting/src/org/ofbiz/accounting/thirdparty/authorizedotnet/AIMPaymentServices.java
===
---
applications/accounting/src/org/ofbiz/accounting/thirdparty/authorizedotnet/AIMPaymentServices.java
(revision 1647466)
+++
applications/accounting/src/org/ofbiz/accounting/thirdparty/authorizedotnet/AIMPaymentServices.java
(working copy)
@@ -253,7 +253,7 @@
return reply;
}
MapString, Object results = ServiceUtil.returnSuccess();
-context.put(x_Amount, context.get(releaseAmount)); // hack for
releaseAmount
+context.put(x_Amount, ((BigDecimal)
context.get(releaseAmount)).toPlainString()); // hack for releaseAmount
results.putAll(processReleaseTransResult(context, reply));
return results;
}
@@ -824,8 +824,8 @@
private static BigDecimal getXAmount(MapString, Object request) {
BigDecimal amt = BigDecimal.ZERO;
if (request.get(x_Amount) != null) {
-BigDecimal amount = (BigDecimal) request.get(x_Amount);
try {
+BigDecimal amount = new BigDecimal((String)
request.get(x_Amount));
amt = amount;
} catch (NumberFormatException e) {
Debug.logWarning(e, e.getMessage(), module);
{code}
The change in the first hunk is important otherwise we're fixing one issue but
creating another.
Issue reported while performing Refund Void (java.lang.ClassCastException:
java.lang.String cannot be cast to java.math.BigDecimal)
-
Key: OFBIZ-5927
URL: https://issues.apache.org/jira/browse/OFBIZ-5927
Project: OFBiz
Issue Type: Bug
Reporter: Prateek Ashtikar
Fix For: Upcoming Branch, 12.04.06, 13.07.02
Issue reported while performing Refund Void (java.lang.ClassCastException:
java.lang.String cannot be cast to java.math.BigDecimal)
Change needs to be done in AIMPaymentServices.java. Please look at the
following small patch:-
//BigDecimal amount = (BigDecimal) request.get(x_Amount);
String newAmt = request.get(x_Amount).toString();
BigDecimal amount = new BigDecimal(newAmt);
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (OFBIZ-5930) Data resouce caching issue while render data resource on multi tenant environment
[
https://issues.apache.org/jira/browse/OFBIZ-5930?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14258040#comment-14258040
]
Scott Gray commented on OFBIZ-5930:
---
Hi Deepak,
Before making this change, please investigate the possibility of using the
EntityObjectCache which can be accessed from the delegator using:
delegator.getCache().put(String, EntityCondition, String, T)
delegator.getCache().get(String, EntityCondition, String)
Data resouce caching issue while render data resource on multi tenant
environment
--
Key: OFBIZ-5930
URL: https://issues.apache.org/jira/browse/OFBIZ-5930
Project: OFBiz
Issue Type: Bug
Components: content
Affects Versions: Trunk
Reporter: Deepak Dixit
Attachments: OFBIZ-5930.patch
Need to fix the DataResouce caching issue while render the DataResouce on
multi tenant environment.
It might be possible that same data resource id exists for multiple tenant,
and as DataResouce caching does not used tenant specific caching so it may
lead to incorrect data rendering.
Here is the current code to get the DataResource Teamplate from cache
{code}
Template cachedTemplate = FreeMarkerWorker.getTemplate(DataResource: +
dataResourceId);
{code}
Need to add the delegator name as prefix to fix the issue.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (OFBIZ-5930) Data resouce caching issue while render data resource on multi tenant environment
[
https://issues.apache.org/jira/browse/OFBIZ-5930?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14258051#comment-14258051
]
Scott Gray commented on OFBIZ-5930:
---
Since you've already done the work, I think this approach is fine as a stop-gap
measure. But we definitely need to come up with a better approach for caching
data coming from different delegators (multi-tenant or otherwise). There are
numerous places in OFBiz where database derived objects are cached and will
have this same problem.
I'll keep thinking about this while I work on the ehcache integration.
Thoughts from others would be most welcome!
Data resouce caching issue while render data resource on multi tenant
environment
--
Key: OFBIZ-5930
URL: https://issues.apache.org/jira/browse/OFBIZ-5930
Project: OFBiz
Issue Type: Bug
Components: content
Affects Versions: Trunk
Reporter: Deepak Dixit
Attachments: OFBIZ-5930.patch
Need to fix the DataResouce caching issue while render the DataResouce on
multi tenant environment.
It might be possible that same data resource id exists for multiple tenant,
and as DataResouce caching does not used tenant specific caching so it may
lead to incorrect data rendering.
Here is the current code to get the DataResource Teamplate from cache
{code}
Template cachedTemplate = FreeMarkerWorker.getTemplate(DataResource: +
dataResourceId);
{code}
Need to add the delegator name as prefix to fix the issue.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (OFBIZ-5930) Data resouce caching issue while render data resource on multi tenant environment
[
https://issues.apache.org/jira/browse/OFBIZ-5930?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14258055#comment-14258055
]
Scott Gray commented on OFBIZ-5930:
---
It wouldn't you'd need to use a separate cache for database derived templates.
Either in DataResourceWorker or by refactoring FreeMarkerWorker to a bit more
delegator aware.
Data resouce caching issue while render data resource on multi tenant
environment
--
Key: OFBIZ-5930
URL: https://issues.apache.org/jira/browse/OFBIZ-5930
Project: OFBiz
Issue Type: Bug
Components: content
Affects Versions: Trunk
Reporter: Deepak Dixit
Attachments: OFBIZ-5930.patch
Need to fix the DataResouce caching issue while render the DataResouce on
multi tenant environment.
It might be possible that same data resource id exists for multiple tenant,
and as DataResouce caching does not used tenant specific caching so it may
lead to incorrect data rendering.
Here is the current code to get the DataResource Teamplate from cache
{code}
Template cachedTemplate = FreeMarkerWorker.getTemplate(DataResource: +
dataResourceId);
{code}
Need to add the delegator name as prefix to fix the issue.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (OFBIZ-5930) Data resouce caching issue while render data resource on multi tenant environment
[
https://issues.apache.org/jira/browse/OFBIZ-5930?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14258067#comment-14258067
]
Scott Gray commented on OFBIZ-5930:
---
Ideally the delegator would provide normal caches as well as GenericValue
specific caches. We'd just stop using UtilCache directly for creating database
derived object caches.
Data resouce caching issue while render data resource on multi tenant
environment
--
Key: OFBIZ-5930
URL: https://issues.apache.org/jira/browse/OFBIZ-5930
Project: OFBiz
Issue Type: Bug
Components: content
Affects Versions: Trunk
Reporter: Deepak Dixit
Attachments: OFBIZ-5930.patch
Need to fix the DataResouce caching issue while render the DataResouce on
multi tenant environment.
It might be possible that same data resource id exists for multiple tenant,
and as DataResouce caching does not used tenant specific caching so it may
lead to incorrect data rendering.
Here is the current code to get the DataResource Teamplate from cache
{code}
Template cachedTemplate = FreeMarkerWorker.getTemplate(DataResource: +
dataResourceId);
{code}
Need to add the delegator name as prefix to fix the issue.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (OFBIZ-5927) Issue reported while performing Refund Void (java.lang.ClassCastException: java.lang.String cannot be cast to java.math.BigDecimal)
[ https://issues.apache.org/jira/browse/OFBIZ-5927?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14258075#comment-14258075 ] Scott Gray commented on OFBIZ-5927: --- Were you performing auth releases against cancelled orders? Because prior to the additional change (first hunk) I've suggested above, it certainly looks to me like it would result in an error for that situation. Issue reported while performing Refund Void (java.lang.ClassCastException: java.lang.String cannot be cast to java.math.BigDecimal) - Key: OFBIZ-5927 URL: https://issues.apache.org/jira/browse/OFBIZ-5927 Project: OFBiz Issue Type: Bug Reporter: Prateek Ashtikar Fix For: Upcoming Branch, 12.04.06, 13.07.02 Issue reported while performing Refund Void (java.lang.ClassCastException: java.lang.String cannot be cast to java.math.BigDecimal) Change needs to be done in AIMPaymentServices.java. Please look at the following small patch:- //BigDecimal amount = (BigDecimal) request.get(x_Amount); String newAmt = request.get(x_Amount).toString(); BigDecimal amount = new BigDecimal(newAmt); -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (OFBIZ-5930) Data resouce caching issue while render data resource on multi tenant environment
[
https://issues.apache.org/jira/browse/OFBIZ-5930?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14258078#comment-14258078
]
Scott Gray commented on OFBIZ-5930:
---
Just to be clear(er), I'm basically suggesting the cache would come through the
delegator's Cache class which would transparently prepend the delegator name to
cache name, rather than having calling code everywhere appending them to the
cache keys. With a standard naming convention it might also help us hide
caches they shouldn't be able to see from tenants with access to webtools.
Data resouce caching issue while render data resource on multi tenant
environment
--
Key: OFBIZ-5930
URL: https://issues.apache.org/jira/browse/OFBIZ-5930
Project: OFBiz
Issue Type: Bug
Components: content
Affects Versions: Trunk
Reporter: Deepak Dixit
Attachments: OFBIZ-5930.patch
Need to fix the DataResouce caching issue while render the DataResouce on
multi tenant environment.
It might be possible that same data resource id exists for multiple tenant,
and as DataResouce caching does not used tenant specific caching so it may
lead to incorrect data rendering.
Here is the current code to get the DataResource Teamplate from cache
{code}
Template cachedTemplate = FreeMarkerWorker.getTemplate(DataResource: +
dataResourceId);
{code}
Need to add the delegator name as prefix to fix the issue.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (OFBIZ-5250) Support for assigning a sales representative to a custome/order
[
https://issues.apache.org/jira/browse/OFBIZ-5250?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14256166#comment-14256166
]
Scott Gray commented on OFBIZ-5250:
---
Regarding the new PartyRelatioshipType, I'm not sure it's needed. Why not use
the existing ACCOUNT PartyRelationshipType and use the roleTypeIdTo=SALES_REP
to differentiate roles within that relationship?
Support for assigning a sales representative to a custome/order
---
Key: OFBIZ-5250
URL: https://issues.apache.org/jira/browse/OFBIZ-5250
Project: OFBiz
Issue Type: New Feature
Components: order, party
Affects Versions: Trunk
Reporter: Christian Geisert
Assignee: Ashish Vijaywargiya
Attachments: ofbiz_sales_rep_order-20130628.diff
This change adds a new PartyRelationshipType SALES_REP:
{{PartyRelationshipType description= hasTable=N parentTypeId=
partyRelationshipName=Sales Representative
partyRelationshipTypeId=SALES_REP roleTypeIdValidFrom=
roleTypeIdValidTo=SALES_REP/}}
When creating an order the sales rep will be added as additional party role
to the shopping cart and then could be changed/removed on the Additional
Party Entry screen while finalizing the order.
You can use DemoCustCompany for testing (added as Demodata)
I'd like to have a review before committing.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (OFBIZ-5704) Extend lot entity to include party Id of manufacturer
[ https://issues.apache.org/jira/browse/OFBIZ-5704?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14256235#comment-14256235 ] Scott Gray commented on OFBIZ-5704: --- Perpetuating these personal arguments doesn't get us any closer to resolving this ticket. Let's try and focus on the design discussions please. Extend lot entity to include party Id of manufacturer - Key: OFBIZ-5704 URL: https://issues.apache.org/jira/browse/OFBIZ-5704 Project: OFBiz Issue Type: Improvement Components: manufacturing, product, workeffort Affects Versions: Release Branch 11.04, Release Branch 12.04, Release Branch 13.07, Trunk Reporter: Pierre Smits Attachments: OFBiz-5704-Product-EntityModel-Lot.patch, Screen Shot 2014-09-03 at 13.52.47.png Rationale Lot or batch management affects two places, namely the outbound process (and its functionalities) and inbound. It is possible that multiple parties have the same ID for the batch or the lot. Howver, in current feature set there is no discrimination between lots from supplier A, supplier B, or even the primary (internal) company in OFBiz. Therefore the entity 'Lot' should be extended with another key, namely that of the partyId of the manufacturer (or supplier). -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (OFBIZ-4098) Ability to plug a new Cache Implementation
[ https://issues.apache.org/jira/browse/OFBIZ-4098?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Scott Gray reassigned OFBIZ-4098: - Assignee: Scott Gray (was: Jacques Le Roux) Assigning to myself, I wish I had noticed this ticket sooner as I've already done quite a bit of work locally that is similar to this :-/ Ability to plug a new Cache Implementation -- Key: OFBIZ-4098 URL: https://issues.apache.org/jira/browse/OFBIZ-4098 Project: OFBiz Issue Type: New Feature Components: framework Affects Versions: Trunk Reporter: Philippe Mouawad Assignee: Scott Gray Attachments: ofbiz-4098.patch Original Estimate: 96h Remaining Estimate: 96h Hello, I would like to contribute a patch to enable switching from Ofbiz native Cache (today UtilCache) to another implementation like EhCache for example. To avoid big code impacts, UtilCache would stay the same and delegate to the real cache implementation this will impact less classes and big impacts would stay in UtilCache package. Ability to plug another implementation like EhCache for example would enable easily plugin with Terracota for example which on big Web Site gives much performance enhancements. Is the format to contribute this kind of evolution also a patch ? Thank you Regards Philippe http://www.ubik-ingenierie.com -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (OFBIZ-5919) Category not found for Category ID dropShip1-err
[ https://issues.apache.org/jira/browse/OFBIZ-5919?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14255272#comment-14255272 ] Scott Gray commented on OFBIZ-5919: --- What exactly is the issue Jacques? dropShip1-err doesn't exist... Category not found for Category ID dropShip1-err Key: OFBIZ-5919 URL: https://issues.apache.org/jira/browse/OFBIZ-5919 Project: OFBiz Issue Type: Bug Components: specialpurpose/ecommerce Affects Versions: Release Branch 12.04, Release Branch 13.07, Trunk Reporter: Jacques Le Roux To test: http://demo-trunk-ofbiz.apache.org/ecommerce/products/dropShip/dropShip1-err Doesn't work: Says catalog not found, but the logs show http status 200. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (OFBIZ-5704) Extend lot entity to include party Id of manufacturer
[ https://issues.apache.org/jira/browse/OFBIZ-5704?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14255301#comment-14255301 ] Scott Gray commented on OFBIZ-5704: --- Incoming/Outgoing inspections would more likely be associated to a Shipment since there's nothing about a lot/batch that says they move as one. Product packaging would form part of the production run and shipment packaging part of the shipment. Regulatory Inspection would again form part of the production run or shipment I would assume. Extend lot entity to include party Id of manufacturer - Key: OFBIZ-5704 URL: https://issues.apache.org/jira/browse/OFBIZ-5704 Project: OFBiz Issue Type: Improvement Components: manufacturing, product, workeffort Affects Versions: Release Branch 11.04, Release Branch 12.04, Release Branch 13.07, Trunk Reporter: Pierre Smits Attachments: OFBiz-5704-Product-EntityModel-Lot.patch, Screen Shot 2014-09-03 at 13.52.47.png Rationale Lot or batch management affects two places, namely the outbound process (and its functionalities) and inbound. It is possible that multiple parties have the same ID for the batch or the lot. Howver, in current feature set there is no discrimination between lots from supplier A, supplier B, or even the primary (internal) company in OFBiz. Therefore the entity 'Lot' should be extended with another key, namely that of the partyId of the manufacturer (or supplier). -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (OFBIZ-5919) CatalogUrlServlet should return a 404 HTTP status if the category or product does not exist
[ https://issues.apache.org/jira/browse/OFBIZ-5919?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14255302#comment-14255302 ] Scott Gray commented on OFBIZ-5919: --- Okay thanks I've changed the title to something a bit more useful. CatalogUrlServlet should return a 404 HTTP status if the category or product does not exist --- Key: OFBIZ-5919 URL: https://issues.apache.org/jira/browse/OFBIZ-5919 Project: OFBiz Issue Type: Bug Components: specialpurpose/ecommerce Affects Versions: Release Branch 12.04, Release Branch 13.07, Trunk Reporter: Jacques Le Roux To test: http://demo-trunk-ofbiz.apache.org/ecommerce/products/dropShip/dropShip1-err Doesn't work: Says catalog not found, but the logs show http status 200. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (OFBIZ-5919) CatalogUrlServlet should return a 404 HTTP status if the category or product does not exist
[ https://issues.apache.org/jira/browse/OFBIZ-5919?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Scott Gray updated OFBIZ-5919: -- Summary: CatalogUrlServlet should return a 404 HTTP status if the category or product does not exist (was: Category not found for Category ID dropShip1-err) CatalogUrlServlet should return a 404 HTTP status if the category or product does not exist --- Key: OFBIZ-5919 URL: https://issues.apache.org/jira/browse/OFBIZ-5919 Project: OFBiz Issue Type: Bug Components: specialpurpose/ecommerce Affects Versions: Release Branch 12.04, Release Branch 13.07, Trunk Reporter: Jacques Le Roux To test: http://demo-trunk-ofbiz.apache.org/ecommerce/products/dropShip/dropShip1-err Doesn't work: Says catalog not found, but the logs show http status 200. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (OFBIZ-5916) Tasks Report from Manufacturing Shipment Plans throws error due to due to missing EntityCondition import
[ https://issues.apache.org/jira/browse/OFBIZ-5916?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14255306#comment-14255306 ] Scott Gray commented on OFBIZ-5916: --- I'm a little confused here, your patch fix seems valid but not for the error you reported above. The issue in the error posted in the description is that 'records' variable doesn't exist when records.add(...) is called in ShipmentWorkEffortTasks.groovy. Did you upload the wrong patch for this ticket? Tasks Report from Manufacturing Shipment Plans throws error due to due to missing EntityCondition import Key: OFBIZ-5916 URL: https://issues.apache.org/jira/browse/OFBIZ-5916 Project: OFBiz Issue Type: Bug Components: manufacturing Affects Versions: Trunk Reporter: Christian Carlow Priority: Minor Attachments: OFBIZ-5916.patch This error occurs when clicking the Tasks Report button from the Manufacturing - Shipment Plans page once a production run has been created for a planned shipment: Error running script at location [component://manufacturing/webapp/manufacturing/WEB-INF/actions/reports/ShipmentWorkEffortTasks.groovy]: groovy.lang.MissingPropertyException: No such property: records for class: ShipmentWorkEffortTasks To reproduce: 1. Create a shipment with status Schedued and a planned item 2. Navigate to Manufacturing - Shipment Plans and click Create Production Runs for the shipment 3. Click the Tasks Report button that appears once Production Runs have been created -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (OFBIZ-5915) Error when viewing Shipment Plan from Manufacturing
[ https://issues.apache.org/jira/browse/OFBIZ-5915?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14255321#comment-14255321 ] Scott Gray commented on OFBIZ-5915: --- Note: this is no longer applicable to the trunk since the switch to EntityQuery. The other releases still need to be checked to see if they have the same problem though. Error when viewing Shipment Plan from Manufacturing --- Key: OFBIZ-5915 URL: https://issues.apache.org/jira/browse/OFBIZ-5915 Project: OFBiz Issue Type: Bug Components: manufacturing Affects Versions: Trunk Reporter: Christian Carlow Attachments: OFBIZ-5915.patch This error appears when clicking on a shipment plan from the Manufacturing Shipment Plans: Error running script at location [component://manufacturing/webapp/manufacturing/WEB-INF/actions/jobshopmgt/WorkWithShipmentPlans.groovy]: java.lang.ClassCastException: java.util.LinkedHashMap cannot be cast to java.lang.String The error is caused by an invalid call to delegator.findByAnd at line of 150 of WorkWithShipmentPlans.groovy. To reproduce: 1. Create an order for an item associated with a ship group 2. After order creation click New Shipment for the ship group 3. Change the shipment status to Scheduled' 4. Add a Shipment Plan 5. Navigate to Manufacturing - Shipment Plans 6. Click View for the shipment plan -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (OFBIZ-5704) Extend lot entity to include party Id of manufacturer
[ https://issues.apache.org/jira/browse/OFBIZ-5704?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14255325#comment-14255325 ] Scott Gray commented on OFBIZ-5704: --- It's not about ignoring your advice Adrian. It's more a case that to follow your advice as it stands currently would be to follow it blindly. For your use case you've given the absolute bare minimum required to form a single coherent sentence. Extend lot entity to include party Id of manufacturer - Key: OFBIZ-5704 URL: https://issues.apache.org/jira/browse/OFBIZ-5704 Project: OFBiz Issue Type: Improvement Components: manufacturing, product, workeffort Affects Versions: Release Branch 11.04, Release Branch 12.04, Release Branch 13.07, Trunk Reporter: Pierre Smits Attachments: OFBiz-5704-Product-EntityModel-Lot.patch, Screen Shot 2014-09-03 at 13.52.47.png Rationale Lot or batch management affects two places, namely the outbound process (and its functionalities) and inbound. It is possible that multiple parties have the same ID for the batch or the lot. Howver, in current feature set there is no discrimination between lots from supplier A, supplier B, or even the primary (internal) company in OFBiz. Therefore the entity 'Lot' should be extended with another key, namely that of the partyId of the manufacturer (or supplier). -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (OFBIZ-5704) Extend lot entity to include party Id of manufacturer
[ https://issues.apache.org/jira/browse/OFBIZ-5704?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14255365#comment-14255365 ] Scott Gray commented on OFBIZ-5704: --- Yes it is an established pattern for cases where a many-to-many relationship to Party is needed, but there's also plenty of examples where many-to-one is all that is needed so this pattern isn't followed (and some models use both approaches). When I read through this ticket I was ready to comment in favor of your suggestion the same as everyone else, but then I couldn't come up with an additional association to Party to use as an example of why your design was needed so I decided to discuss that. My understanding of lots/batches is that a reseller needs to track the lot id for product recalls and for product returns (determining if a lot has abnormal QC issues). Manufacturers using lots in OFBiz don't really need to track information using the Lot entity because the production run and inventory item models should capture everything that needs to be known about the lot. Getting mad about the discussion or resorting to ad hominem arguments doesn't do anything to further the issue. I thought it would be straightforward to get a use case that makes sense so that we could go with your approach and get on with life. I couldn't care less who is right and who is wrong, I just want our designs (particularly data model) to match known/likely use cases. Extend lot entity to include party Id of manufacturer - Key: OFBIZ-5704 URL: https://issues.apache.org/jira/browse/OFBIZ-5704 Project: OFBiz Issue Type: Improvement Components: manufacturing, product, workeffort Affects Versions: Release Branch 11.04, Release Branch 12.04, Release Branch 13.07, Trunk Reporter: Pierre Smits Attachments: OFBiz-5704-Product-EntityModel-Lot.patch, Screen Shot 2014-09-03 at 13.52.47.png Rationale Lot or batch management affects two places, namely the outbound process (and its functionalities) and inbound. It is possible that multiple parties have the same ID for the batch or the lot. Howver, in current feature set there is no discrimination between lots from supplier A, supplier B, or even the primary (internal) company in OFBiz. Therefore the entity 'Lot' should be extended with another key, namely that of the partyId of the manufacturer (or supplier). -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (OFBIZ-5035) Special characters (latin, accent ...) are in error from an input (search, contact us ...)
[ https://issues.apache.org/jira/browse/OFBIZ-5035?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Scott Gray updated OFBIZ-5035: -- Priority: Major (was: Minor) Special characters (latin, accent ...) are in error from an input (search, contact us ...) -- Key: OFBIZ-5035 URL: https://issues.apache.org/jira/browse/OFBIZ-5035 Project: OFBiz Issue Type: Bug Components: specialpurpose/ecommerce Affects Versions: Trunk Environment: trunk-r1384251 Reporter: Eric de Maulde When a user tapes a special character on a search field or a contact us field, OFBiz sends back a wrong character. Try on : http://demo-trunk.ofbiz.apache.org/ecommerce This error doesn't appear on old stable version : 10.04 09.04 http://demo-stable.ofbiz.apache.org/ecommerce http://demo-old.ofbiz.apache.org/ecommerce -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (OFBIZ-5035) Special characters (latin, accent ...) are in error from an input (search, contact us ...)
[ https://issues.apache.org/jira/browse/OFBIZ-5035?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14255508#comment-14255508 ] Scott Gray commented on OFBIZ-5035: --- It looks like this problem popped up because of the introduction of the CatalogUrlFilter and ContentUrlFilter. The filters access the parameter map before the code in the RequestHandler gets the opportunity to set the request's character encoding to UTF-8, once the parameters are parsed on first access setting the character encoding afterwards has no effect. Because these filters are mapped to all path requests they also affect the normal /control/ path, which wouldn't have had this issue prior to their introduction. We need to find somewhere very early in the request handling to set character encoding to UTF-8. We can either add tomcat's SetCharacterEncodingFilter to all of the web.xml files or we can add similar code to the ContextFilter and ensure it is always the first filter to run. Special characters (latin, accent ...) are in error from an input (search, contact us ...) -- Key: OFBIZ-5035 URL: https://issues.apache.org/jira/browse/OFBIZ-5035 Project: OFBiz Issue Type: Bug Components: specialpurpose/ecommerce Affects Versions: Trunk Environment: trunk-r1384251 Reporter: Eric de Maulde Priority: Minor When a user tapes a special character on a search field or a contact us field, OFBiz sends back a wrong character. Try on : http://demo-trunk.ofbiz.apache.org/ecommerce This error doesn't appear on old stable version : 10.04 09.04 http://demo-stable.ofbiz.apache.org/ecommerce http://demo-old.ofbiz.apache.org/ecommerce -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (OFBIZ-5869) correction to changeset r1626462 and r1626463
[ https://issues.apache.org/jira/browse/OFBIZ-5869?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14252853#comment-14252853 ] Scott Gray commented on OFBIZ-5869: --- Hi Leon, You are correct that EntityQuery.filterByDate(Timestamp) will not perform date filtering when the Timestamp is null. But none of the code that you changed uses that particular method. The code you changed uses a different code path and uses a default Timestamp of now. EntityQuery.filterByDate(String...) calls EntityQuery.filterByDate(Timestamp, String...) which doesn't exhibit the same behavior as the above. I see there are some inconsistencies in EntityQuery.filterByDate methods though, e.g. EntityQuery.filterByDate(Date) will throw an NPE if Date is null EntityQuery.filterByDate(Timestamp) will perform no filtering if Timestamp is null EntityQuery.filterByDate(Timestamp, String...) will default to now if Timestamp is null I'll have to have a think about which behavior makes the most sense. correction to changeset r1626462 and r1626463 Key: OFBIZ-5869 URL: https://issues.apache.org/jira/browse/OFBIZ-5869 Project: OFBiz Issue Type: Bug Components: ALL APPLICATIONS Affects Versions: Release Branch 13.07, Trunk Reporter: Leon Assignee: Jacques Le Roux Fix For: Upcoming Branch, 13.07.02 Attachments: OFBIZ-5869.patch There's error in this commit. e.g. – ListGenericValue allPCMPs = EntityUtil.filterByDate(delegator.findByAnd(PartyContactMechPurpose, pcmpFindMap, null, false), true); ++ allPCWPs = EntityUtil.filterByDate(allPCWPs, null, contactFromDate, contactThruDate, true); According to EntityUtil.filterByDate(List, EntityCondition, String, String ,Boolean), it filter nothing if condition parameter (the second) is null. see OFBIZ-5261. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (OFBIZ-5004) Warning in GenericEntity.get unnecessarily clutters logs
[
https://issues.apache.org/jira/browse/OFBIZ-5004?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14246209#comment-14246209
]
Scott Gray commented on OFBIZ-5004:
---
I'm not sure, a ClassCastException seems specifically for class casting issues
and I don't really think that fits here. If I wasn't aware of this discussion,
seeing a ClassCastException because a field I referenced didn't exist would
seem very strange.
I don't think we should be too concerned about throwing an
IllegalArgumentException, it doesn't need to be declared and would be less
surprising to see as an error given that it seems like the most appropriately
named exception available. Another interesting thing to keep in mind:
Javolution didn't allow null keys in its Maps and would throw a
NullPointerException if one was provided. I think our case is quite similar to
that one.
Warning in GenericEntity.get unnecessarily clutters logs
Key: OFBIZ-5004
URL: https://issues.apache.org/jira/browse/OFBIZ-5004
Project: OFBiz
Issue Type: Bug
Components: framework
Affects Versions: Trunk
Reporter: Christoph Neuroth
Assignee: Jacopo Cappellato
Attachments: iae.patch
This code in GenericEntity.java:
{code}Debug.logWarning(The field name (or key) [ + name + ] is not valid
for entity [ + this.getEntityName() + ], printing IllegalArgumentException
instead of throwing it because Map interface specification does not allow
throwing that exception., module);
{code}
is really annoying and IMHO it is wrong.
First, it does not print an exception, it only prints that string with no
stacktrace (I think that was changed at some point).
Second, IllegalArgument is a RuntimeException so the interface doesn't really
need to allow it to be thrown, right?
Personally, I think the warning is not even justified. We sometimes don't
know exactly what kind of entity we're dealing with and just check if it has
that field or not. With this code, to prevent excessive log clutter, we have
to wrap each call with a if (it.containsKey()). A java map will just return
null silently as well, and this behavior is documented in the Map interface.
If anyone is really worried about accessing fields wrong (your tests should
catch that error), there could be an extra method getOrThrow or something,
but get should just return the value or null.
Otherwise, at least throw the exception. Log warnings are usually found while
monitoring production logs, developers will find this much earlier otherwise.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (OFBIZ-5906) The delete action in entity-engine-xml definitions throw an error in tests
[
https://issues.apache.org/jira/browse/OFBIZ-5906?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14246331#comment-14246331
]
Scott Gray commented on OFBIZ-5906:
---
Having delete actions inside an xml assert test seems a bit strange, what would
you expect it to assert for those records?
The delete action in entity-engine-xml definitions throw an error in tests
--
Key: OFBIZ-5906
URL: https://issues.apache.org/jira/browse/OFBIZ-5906
Project: OFBiz
Issue Type: Bug
Components: framework
Affects Versions: Release Branch 12.04, Release Branch 13.07, Trunk
Reporter: Jacques Le Roux
Priority: Minor
While running a test with test data defined with a delete inside I got
thses errors:
{code}
2014-10-28 15:21:22,155 |main |GenericDelegator
|E| Error getting entity definition from model
org.ofbiz.entity.GenericModelException: Could not find definition for entity
name delete
at
org.ofbiz.entity.model.ModelReader.getModelEntity(ModelReader.java:489)
~[ofbiz-entity.jar:?]
at
org.ofbiz.entity.GenericDelegator.getModelEntity(GenericDelegator.java:405)
[ofbiz-entity.jar:?]
at
org.ofbiz.entity.GenericDelegator.makeValue(GenericDelegator.java:600)
[ofbiz-entity.jar:?]
at
org.ofbiz.entity.GenericDelegator.makeValue(GenericDelegator.java:2397)
[ofbiz-entity.jar:?]
at
org.ofbiz.entity.GenericDelegator.makeValues(GenericDelegator.java:2356)
[ofbiz-entity.jar:?]
at
org.ofbiz.entity.GenericDelegator.readXmlDocument(GenericDelegator.java:2327)
[ofbiz-entity.jar:?]
at
org.ofbiz.testtools.EntityXmlAssertTest.countTestCases(EntityXmlAssertTest.java:61)
[ofbiz-testtools.jar:?]
at junit.framework.TestResult.startTest(TestResult.java:150)
[junit-dep-4.10.jar:?]
at
org.ofbiz.testtools.EntityXmlAssertTest.run(EntityXmlAssertTest.java:71)
[ofbiz-testtools.jar:?]
at junit.framework.TestSuite.runTest(TestSuite.java:243)
[junit-dep-4.10.jar:?]
at junit.framework.TestSuite.run(TestSuite.java:238)
[junit-dep-4.10.jar:?]
at
org.ofbiz.testtools.TestRunContainer.start(TestRunContainer.java:147)
[ofbiz-testtools.jar:?]
at
org.ofbiz.base.container.ContainerLoader.start(ContainerLoader.java:237)
[ofbiz-base.jar:?]
at org.ofbiz.base.start.Start.startStartLoaders(Start.java:341)
[ofbiz.jar:?]
at org.ofbiz.base.start.Start.start(Start.java:367) [ofbiz.jar:?]
at org.ofbiz.base.start.Start.main(Start.java:135) [ofbiz.jar:?]
2014-10-28 15:21:22,156 |main |ServiceTest
|E| Error getting test case count
java.lang.IllegalArgumentException: [GenericDelegator.makeValue] could not
find entity for entityName: delete
at
org.ofbiz.entity.GenericDelegator.makeValue(GenericDelegator.java:602)
~[ofbiz-entity.jar:?]
at
org.ofbiz.entity.GenericDelegator.makeValue(GenericDelegator.java:2397)
~[ofbiz-entity.jar:?]
at
org.ofbiz.entity.GenericDelegator.makeValues(GenericDelegator.java:2356)
~[ofbiz-entity.jar:?]
at
org.ofbiz.entity.GenericDelegator.readXmlDocument(GenericDelegator.java:2327)
~[ofbiz-entity.jar:?]
at
org.ofbiz.testtools.EntityXmlAssertTest.countTestCases(EntityXmlAssertTest.java:61)
[ofbiz-testtools.jar:?]
at junit.framework.TestResult.startTest(TestResult.java:150)
[junit-dep-4.10.jar:?]
at
org.ofbiz.testtools.EntityXmlAssertTest.run(EntityXmlAssertTest.java:71)
[ofbiz-testtools.jar:?]
at junit.framework.TestSuite.runTest(TestSuite.java:243)
[junit-dep-4.10.jar:?]
at junit.framework.TestSuite.run(TestSuite.java:238)
[junit-dep-4.10.jar:?]
at
org.ofbiz.testtools.TestRunContainer.start(TestRunContainer.java:147)
[ofbiz-testtools.jar:?]
at
org.ofbiz.base.container.ContainerLoader.start(ContainerLoader.java:237)
[ofbiz-base.jar:?]
at org.ofbiz.base.start.Start.startStartLoaders(Start.java:341)
[ofbiz.jar:?]
at org.ofbiz.base.start.Start.start(Start.java:367) [ofbiz.jar:?]
at org.ofbiz.base.start.Start.main(Start.java:135) [ofbiz.jar:?]
{code}
This has no consequences AFAIK, but is a bit annoying...
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (OFBIZ-5906) The delete action in entity-engine-xml definitions throw an error in tests
[
https://issues.apache.org/jira/browse/OFBIZ-5906?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14246341#comment-14246341
]
Scott Gray commented on OFBIZ-5906:
---
Ah okay, I didn't realize the loading is done as a test as well.
The delete action in entity-engine-xml definitions throw an error in tests
--
Key: OFBIZ-5906
URL: https://issues.apache.org/jira/browse/OFBIZ-5906
Project: OFBiz
Issue Type: Bug
Components: framework
Affects Versions: Release Branch 12.04, Release Branch 13.07, Trunk
Reporter: Jacques Le Roux
Priority: Minor
While running a test with test data defined with a delete inside I got
thses errors:
{code}
2014-10-28 15:21:22,155 |main |GenericDelegator
|E| Error getting entity definition from model
org.ofbiz.entity.GenericModelException: Could not find definition for entity
name delete
at
org.ofbiz.entity.model.ModelReader.getModelEntity(ModelReader.java:489)
~[ofbiz-entity.jar:?]
at
org.ofbiz.entity.GenericDelegator.getModelEntity(GenericDelegator.java:405)
[ofbiz-entity.jar:?]
at
org.ofbiz.entity.GenericDelegator.makeValue(GenericDelegator.java:600)
[ofbiz-entity.jar:?]
at
org.ofbiz.entity.GenericDelegator.makeValue(GenericDelegator.java:2397)
[ofbiz-entity.jar:?]
at
org.ofbiz.entity.GenericDelegator.makeValues(GenericDelegator.java:2356)
[ofbiz-entity.jar:?]
at
org.ofbiz.entity.GenericDelegator.readXmlDocument(GenericDelegator.java:2327)
[ofbiz-entity.jar:?]
at
org.ofbiz.testtools.EntityXmlAssertTest.countTestCases(EntityXmlAssertTest.java:61)
[ofbiz-testtools.jar:?]
at junit.framework.TestResult.startTest(TestResult.java:150)
[junit-dep-4.10.jar:?]
at
org.ofbiz.testtools.EntityXmlAssertTest.run(EntityXmlAssertTest.java:71)
[ofbiz-testtools.jar:?]
at junit.framework.TestSuite.runTest(TestSuite.java:243)
[junit-dep-4.10.jar:?]
at junit.framework.TestSuite.run(TestSuite.java:238)
[junit-dep-4.10.jar:?]
at
org.ofbiz.testtools.TestRunContainer.start(TestRunContainer.java:147)
[ofbiz-testtools.jar:?]
at
org.ofbiz.base.container.ContainerLoader.start(ContainerLoader.java:237)
[ofbiz-base.jar:?]
at org.ofbiz.base.start.Start.startStartLoaders(Start.java:341)
[ofbiz.jar:?]
at org.ofbiz.base.start.Start.start(Start.java:367) [ofbiz.jar:?]
at org.ofbiz.base.start.Start.main(Start.java:135) [ofbiz.jar:?]
2014-10-28 15:21:22,156 |main |ServiceTest
|E| Error getting test case count
java.lang.IllegalArgumentException: [GenericDelegator.makeValue] could not
find entity for entityName: delete
at
org.ofbiz.entity.GenericDelegator.makeValue(GenericDelegator.java:602)
~[ofbiz-entity.jar:?]
at
org.ofbiz.entity.GenericDelegator.makeValue(GenericDelegator.java:2397)
~[ofbiz-entity.jar:?]
at
org.ofbiz.entity.GenericDelegator.makeValues(GenericDelegator.java:2356)
~[ofbiz-entity.jar:?]
at
org.ofbiz.entity.GenericDelegator.readXmlDocument(GenericDelegator.java:2327)
~[ofbiz-entity.jar:?]
at
org.ofbiz.testtools.EntityXmlAssertTest.countTestCases(EntityXmlAssertTest.java:61)
[ofbiz-testtools.jar:?]
at junit.framework.TestResult.startTest(TestResult.java:150)
[junit-dep-4.10.jar:?]
at
org.ofbiz.testtools.EntityXmlAssertTest.run(EntityXmlAssertTest.java:71)
[ofbiz-testtools.jar:?]
at junit.framework.TestSuite.runTest(TestSuite.java:243)
[junit-dep-4.10.jar:?]
at junit.framework.TestSuite.run(TestSuite.java:238)
[junit-dep-4.10.jar:?]
at
org.ofbiz.testtools.TestRunContainer.start(TestRunContainer.java:147)
[ofbiz-testtools.jar:?]
at
org.ofbiz.base.container.ContainerLoader.start(ContainerLoader.java:237)
[ofbiz-base.jar:?]
at org.ofbiz.base.start.Start.startStartLoaders(Start.java:341)
[ofbiz.jar:?]
at org.ofbiz.base.start.Start.start(Start.java:367) [ofbiz.jar:?]
at org.ofbiz.base.start.Start.main(Start.java:135) [ofbiz.jar:?]
{code}
This has no consequences AFAIK, but is a bit annoying...
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (OFBIZ-5895) Add a partyHelper method to get partyName history, giving a reference date.
[
https://issues.apache.org/jira/browse/OFBIZ-5895?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14232469#comment-14232469
]
Scott Gray commented on OFBIZ-5895:
---
Hi Gil,
We already have the service getPartyNameForDate which might do what you need
http://demo-trunk-ofbiz.apache.org/webtools/control/ServiceList?sel_service_name=getPartyNameForDate
Add a partyHelper method to get partyName history, giving a reference date.
---
Key: OFBIZ-5895
URL: https://issues.apache.org/jira/browse/OFBIZ-5895
Project: OFBiz
Issue Type: New Feature
Components: party
Affects Versions: Trunk
Reporter: Gil Portenseigne
Priority: Minor
Attachments: JIRA-5895.patch
Keeping the track of name change is good, but i haven't found a way to easily
show the name of a party in the past.
This new method might be used to display a party name, which has change in
time, giving a date of reference, for instance :
field name=partyNamedisplay description= ${groovy: return
org.ofbiz.party.party.PartyHelper.getPartyNameHistory(delegator, partyId,
false, actualStartDate);}//field
Will display the name of partyId in actualStartDate time
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (OFBIZ-5884) Have question of type 'Selected Option' to allow selection of multiple options in surveys
[ https://issues.apache.org/jira/browse/OFBIZ-5884?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14224223#comment-14224223 ] Scott Gray commented on OFBIZ-5884: --- Opening a new ticket to replace OFBIZ-5688 doesn't somehow make this ticket any different. If layout is your only concern then we could look at altering the templates/css that render/style the surveys but I don't see any benefit to redesigning the data model for a problem that is already solved. Have question of type 'Selected Option' to allow selection of multiple options in surveys - Key: OFBIZ-5884 URL: https://issues.apache.org/jira/browse/OFBIZ-5884 Project: OFBiz Issue Type: Improvement Components: content Affects Versions: Trunk Reporter: Pierre Smits Labels: questionnaire, survey Currently 'Select Option' only allows to select one option. This should also allow the selection of multiple options. Though there is the possibility to group multiple questions together by means of the SurveyMultiResp functionality, that might not always prove to be right the solution for survey creators. A simple 'multi-option' select question saves real estate. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (OFBIZ-5879) Sometimes, RMIDispatcher cannot be constructed
[
https://issues.apache.org/jira/browse/OFBIZ-5879?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14223790#comment-14223790
]
Scott Gray commented on OFBIZ-5879:
---
I'm willing to bet that NPE is caused because the key is null (which FastMap
doesn't allow) and if that's the case then it's an issue with the XML parser
rather than javolution and switching the implementation will merely hide the
problem. Just to be safe I'd suggest adding a null check on groupName until we
can be sure I'm wrong.
This reminds me of a similar issue we saw a while back where some service
engine map configs would randomly be set to null when the configuration was
cached as an XML document model.
Sometimes, RMIDispatcher cannot be constructed
--
Key: OFBIZ-5879
URL: https://issues.apache.org/jira/browse/OFBIZ-5879
Project: OFBiz
Issue Type: Bug
Components: framework
Affects Versions: Trunk
Reporter: Leon
Assignee: Adrian Crum
sometimes, the ofbiz instance startup failed because following error:
{quote}
java.lang.NullPointerException
at javolution.util.FastMap$Entry.access$302(FastMap.java:1530)
at javolution.util.FastMap.put(FastMap.java:490)
at javolution.util.FastMap.put(FastMap.java:453)
at
org.ofbiz.service.group.ServiceGroupReader.addGroupDefinitions(ServiceGroupReader.java:79)
at
org.ofbiz.service.group.ServiceGroupReader.readConfig(ServiceGroupReader.java:62)
at
org.ofbiz.service.ServiceDispatcher.init(ServiceDispatcher.java:104)
at
org.ofbiz.service.ServiceDispatcher.init(ServiceDispatcher.java:151)
at
org.ofbiz.service.ServiceDispatcher.getInstance(ServiceDispatcher.java:183)
at
org.ofbiz.service.ServiceDispatcher.getLocalDispatcher(ServiceDispatcher.java:162)
at
org.ofbiz.service.GenericDispatcherFactory.createLocalDispatcher(GenericDispatcherFactory.java:46)
at
org.ofbiz.service.ServiceContainer.getLocalDispatcher(ServiceContainer.java:90)
at
org.ofbiz.service.rmi.RmiServiceContainer.start(RmiServiceContainer.java:133)
at
org.ofbiz.base.container.ContainerLoader.start(ContainerLoader.java:237)
at org.ofbiz.base.start.Start.startStartLoaders(Start.java:341)
at org.ofbiz.base.start.Start.start(Start.java:367)
at org.ofbiz.base.start.Start.main(Start.java:135)
20141110104822705 |Thread-0 |ContainerLoader |I|
Shutting down containers
20141110104822705 |Thread-0 |ContainerLoader |I|
Stopping container birt-container
20141110104822706 |Thread-0 |ContainerLoader |I|
Stopped container birt-container
20141110104822706 |Thread-0 |ContainerLoader |I|
Stopping container catalina-container
20141110104822706 |Thread-0 |ContainerLoader |I|
Stopped container catalina-container
20141110104822706 |Thread-0 |ContainerLoader |I|
Stopping container rmi-dispatcher
java.lang.NullPointerException
at
org.ofbiz.service.rmi.RmiServiceContainer.stop(RmiServiceContainer.java:176)
at
org.ofbiz.base.container.ContainerLoader.unload(ContainerLoader.java:264)
at org.ofbiz.base.start.Start.shutdownServer(Start.java:317)
at org.ofbiz.base.start.Start$1.run(Start.java:231)
{quote}
Since it's hard to reproduce, and I'm not familiar with the logic behind it,
I'm unable to figure out what the root cause is.
Anyone can help?
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (OFBIZ-5347) Shipping costs not recalculated after changing sales order shipment method
[ https://issues.apache.org/jira/browse/OFBIZ-5347?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14223836#comment-14223836 ] Scott Gray commented on OFBIZ-5347: --- That sounds like a good approach to me Divesh Shipping costs not recalculated after changing sales order shipment method -- Key: OFBIZ-5347 URL: https://issues.apache.org/jira/browse/OFBIZ-5347 Project: OFBiz Issue Type: Bug Components: order Affects Versions: Trunk Reporter: Christian Carlow Sales order shipping costs are not recalculated when ship group shipment methods are changed. Its required that the order items be updated before the new shipment method costs are calculated and applied to the order. The same logic that calculates the new shipment method costs when order items are updated should be applied when the shipment method is updated. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (OFBIZ-5688) Question of type 'Selected Option' doesn't allow selection of multiple options
[ https://issues.apache.org/jira/browse/OFBIZ-5688?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Scott Gray closed OFBIZ-5688. - Resolution: Not a Problem Hi Pierre, All survey questions are single answer. You'll want to use the SurveyMultiResp entity to model multiple questions as though they were a single question, there's an example in the demo data. Question of type 'Selected Option' doesn't allow selection of multiple options -- Key: OFBIZ-5688 URL: https://issues.apache.org/jira/browse/OFBIZ-5688 Project: OFBiz Issue Type: Bug Components: content Affects Versions: Release Branch 11.04, Release Branch 12.04, Release Branch 13.07, Trunk Reporter: Pierre Smits When a question of a survey is of type SELECTED_OPTION it doesn't allow the selection of multiple options in a survey accessed through cmssite. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (OFBIZ-5846) Field definition problem, program should use purposeFromDate in stead of fromDate.
[ https://issues.apache.org/jira/browse/OFBIZ-5846?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14223885#comment-14223885 ] Scott Gray commented on OFBIZ-5846: --- Why has this been reopened? Field definition problem, program should use purposeFromDate in stead of fromDate. -- Key: OFBIZ-5846 URL: https://issues.apache.org/jira/browse/OFBIZ-5846 Project: OFBiz Issue Type: Bug Components: party Affects Versions: Trunk Reporter: Supachai Chaima-ngua Assignee: Jacques Le Roux Labels: partymgr Fix For: Upcoming Branch, 12.04.06, 13.07.02 Attachments: ofbizbug-deleltecontectmech.patch field definition problem, program should use purposeFromDate in stead of fromDate. deletePcmCtx.put(fromDate, tempVal.get(purposeFromDate)); -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (OFBIZ-5844) Convert java files to EntityQuery
[ https://issues.apache.org/jira/browse/OFBIZ-5844?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14197996#comment-14197996 ] Scott Gray commented on OFBIZ-5844: --- Hi Arun, So far I've been taking the approach of inlining everything into the query that can be e.g. any variables that are used only in the query preparation such as select field lists, where conditions and order by lists; as well as any post-processing that could be done within the query itself such as EntityUtil.getFirst() or EntityUtil.filterByDate(). Here's a few examples from the first few hunks of your patch (CommunicationEventServices.java): Line 307: SetString fieldsToSelect = UtilMisc.toSet(partyId, preferredContactMechId, fromDate, infoString); can be replaced inline by using EntityQuery.select(...): EntityQuery.use(delegator).select(partyId, preferredContactMechId, fromDate, infoString).from(...) Line 313: ListString orderBy = UtilMisc.toList(-fromDate); can be replaced by using EntityQuery.orderBy(-fromDate) Line 382: GenericValue contactListPartyStatus = EntityUtil.getFirst(contactListPartyStatuses); can be replaced by using EntityQuery.queryFirst() These are just a few examples of things to keep an eye out for. In general I like to get as much of the processing into the query chain as possible so that you can quickly and easily see exactly what data is being returned and worked with. Convert java files to EntityQuery - Key: OFBIZ-5844 URL: https://issues.apache.org/jira/browse/OFBIZ-5844 Project: OFBiz Issue Type: Improvement Components: ALL COMPONENTS Affects Versions: Trunk Reporter: Arun Patidar Priority: Minor Attachments: OFBIZ-5844-Party.patch Recently [~lektran] has been converted java files to use Entity Query methods in place of Entity Engine methods. Components that has been converted are as below: - content - humanres - manufacturing - ordermgr (partially converted) - Replaced findOne() method in all components And commit revisions are: r1635380, r1635381, r1635382 and r1635383 Remaining components to be convert are: - product - party - commonext - securityext - workeffort - ordermgr (remaining part) - specialpurpose -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (OFBIZ-5790) Json string parameters as a service input are not recognized by OFBiz ServiceEventHandler.
[
https://issues.apache.org/jira/browse/OFBIZ-5790?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14184425#comment-14184425
]
Scott Gray commented on OFBIZ-5790:
---
It does the conversion at the point of entry and exit based on the
content-type/accept http headers. My statement that you quoted above was in
reference to why I didn't see the need for a JSON type that you mentioned
previously.
I was simply saying that the number of likely places we'd want to convert
Objects to JSON strings and vice-versa is limited enough that we could consider
forgoing the extra code required to abstract it out and simply use the library
directly.
The issue with multiple exit points for JSON right now is because they aren't
using the json request chain from common-controller.xml (or whatever we decide
to replace it with). I'm sure we'd prefer these events to output a Map of data
than hard-coding a JSON response directly to the response stream. And if that
is the case, then it seems like the number of touch points on a JSON library
would be minimal.
Json string parameters as a service input are not recognized by OFBiz
ServiceEventHandler.
--
Key: OFBIZ-5790
URL: https://issues.apache.org/jira/browse/OFBIZ-5790
Project: OFBiz
Issue Type: Improvement
Affects Versions: Trunk
Reporter: Amardeep Singh Jhajj
Priority: Minor
Attachments: CommonEvents.java.patch, JSON.java.patch,
OFBIZ-5790.patch, jackson-annotations-2.4.0.jar, jackson-core-2.4.2.jar,
jackson-databind-2.4.2.jar
I was trying to pass the Json string as a input to a service, but is not
recognized by ServiceEventHandler.
Example Json String- {faciltyId: WebStoreWarehouse}
I worked on this issue and attached a patch here. Here I have used Jackson
Json library for parsing.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (OFBIZ-5790) Json string parameters as a service input are not recognized by OFBiz ServiceEventHandler.
[
https://issues.apache.org/jira/browse/OFBIZ-5790?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14184443#comment-14184443
]
Scott Gray commented on OFBIZ-5790:
---
Fair enough, I don't have any more to add. Thanks for taking the time to
discuss it.
Json string parameters as a service input are not recognized by OFBiz
ServiceEventHandler.
--
Key: OFBIZ-5790
URL: https://issues.apache.org/jira/browse/OFBIZ-5790
Project: OFBiz
Issue Type: Improvement
Affects Versions: Trunk
Reporter: Amardeep Singh Jhajj
Priority: Minor
Attachments: CommonEvents.java.patch, JSON.java.patch,
OFBIZ-5790.patch, jackson-annotations-2.4.0.jar, jackson-core-2.4.2.jar,
jackson-databind-2.4.2.jar
I was trying to pass the Json string as a input to a service, but is not
recognized by ServiceEventHandler.
Example Json String- {faciltyId: WebStoreWarehouse}
I worked on this issue and attached a patch here. Here I have used Jackson
Json library for parsing.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (OFBIZ-5790) Json string parameters as a service input are not recognized by OFBiz ServiceEventHandler.
[
https://issues.apache.org/jira/browse/OFBIZ-5790?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14184293#comment-14184293
]
Scott Gray commented on OFBIZ-5790:
---
Adrian, Jacopo, please don't think of my question as voicing a strong opinion,
it really was just a doubt/concern of something I was unsure about.
To be honest I don't see a need for an internal JSON type because I have no
idea what we'd do with it. That doesn't mean there isn't a need, I just don't
know what it is.
At the moment I can only visualize JSON as an external input/output format for
data that we already represent internally using Lists and Maps. I would never
be concerned about whether a string contains JSON or not because the framework
would have already converted it to a List/Map the moment it was received from
the external source. I wasn't picturing the use of static utility methods,
just direct access to whatever library we chose to include.
Either way though, I really don't mind what approach is taken, I was offering
some thoughts that came to mind.
Json string parameters as a service input are not recognized by OFBiz
ServiceEventHandler.
--
Key: OFBIZ-5790
URL: https://issues.apache.org/jira/browse/OFBIZ-5790
Project: OFBiz
Issue Type: Improvement
Affects Versions: Trunk
Reporter: Amardeep Singh Jhajj
Priority: Minor
Attachments: CommonEvents.java.patch, JSON.java.patch,
OFBIZ-5790.patch, jackson-annotations-2.4.0.jar, jackson-core-2.4.2.jar,
jackson-databind-2.4.2.jar
I was trying to pass the Json string as a input to a service, but is not
recognized by ServiceEventHandler.
Example Json String- {faciltyId: WebStoreWarehouse}
I worked on this issue and attached a patch here. Here I have used Jackson
Json library for parsing.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (OFBIZ-5790) Json string parameters as a service input are not recognized by OFBiz ServiceEventHandler.
[
https://issues.apache.org/jira/browse/OFBIZ-5790?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14183976#comment-14183976
]
Scott Gray commented on OFBIZ-5790:
---
Question: do we really need all of this abstraction? AFAIK the JSON format is
pretty straightforward and not something that's subject to constant change or
improvement. Can't we just pick the best library and stick with it? Is our
system internally using so much JSON that we need to abstract the library
usage? I mean, it's not XML.
Json string parameters as a service input are not recognized by OFBiz
ServiceEventHandler.
--
Key: OFBIZ-5790
URL: https://issues.apache.org/jira/browse/OFBIZ-5790
Project: OFBiz
Issue Type: Improvement
Affects Versions: Trunk
Reporter: Amardeep Singh Jhajj
Priority: Minor
Attachments: CommonEvents.java.patch, JSON.java.patch,
OFBIZ-5790.patch, jackson-annotations-2.4.0.jar, jackson-core-2.4.2.jar,
jackson-databind-2.4.2.jar
I was trying to pass the Json string as a input to a service, but is not
recognized by ServiceEventHandler.
Example Json String- {faciltyId: WebStoreWarehouse}
I worked on this issue and attached a patch here. Here I have used Jackson
Json library for parsing.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (OFBIZ-5790) Json string parameters as a service input are not recognized by OFBiz ServiceEventHandler.
[
https://issues.apache.org/jira/browse/OFBIZ-5790?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14180938#comment-14180938
]
Scott Gray commented on OFBIZ-5790:
---
#1 is certainly a bit of a kludge. I implemented so we could do away with a
worse kludge which was service-json, groovy-json, simple-json event handlers.
They were called something like that anyway. How about creating a new json
specific view handler instead of an using an event?
Json string parameters as a service input are not recognized by OFBiz
ServiceEventHandler.
--
Key: OFBIZ-5790
URL: https://issues.apache.org/jira/browse/OFBIZ-5790
Project: OFBiz
Issue Type: Improvement
Affects Versions: Trunk
Reporter: Amardeep Singh Jhajj
Priority: Minor
Attachments: CommonEvents.java.patch, OFBIZ-5790.patch,
jackson-annotations-2.4.0.jar, jackson-core-2.4.2.jar,
jackson-databind-2.4.2.jar
I was trying to pass the Json string as a input to a service, but is not
recognized by ServiceEventHandler.
Example Json String- {faciltyId: WebStoreWarehouse}
I worked on this issue and attached a patch here. Here I have used Jackson
Json library for parsing.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Resolved] (OFBIZ-4053) Implement an Entity Query Builder
[
https://issues.apache.org/jira/browse/OFBIZ-4053?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Scott Gray resolved OFBIZ-4053.
---
Resolution: Fixed
Fix Version/s: Upcoming Branch
Committed r1627940
Thanks to everyone who provided input here and on the dev mailing list.
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: Trunk
Reporter: Scott Gray
Assignee: Scott Gray
Fix For: Upcoming Branch
Attachments: builder.patch, builder.patch, 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 implementation so far that I'm not entirely happy
with:
- I'm not so sure that I like EntityBuilderUtil.list(delegator) in place of
something like EntityList.use(delegator). The latter requires less typing
and I think is more intuitive than typing EntityBuilderUtil because of its
similarities to the corresponding minilang method calls, I actually kept
having trouble remembering what it was called when converting some delegator
calls over. It also requires a little more typing (16-17 characters vs.
12-13), not a big deal but every little bit helps with what would be a very
commonly used class.
- I'm struggling to see the point of having the GenericQueryBuilder
interface, the two classes share very little in the way of API and its use
seems a little superfluous to me.
Opinions on the above points or anything else to do with the implementation
are most welcome. I'd like to get the API locked down (and hopefully some
javadocs in place) before committing.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (OFBIZ-4053) Implement an Entity Query Builder
[
https://issues.apache.org/jira/browse/OFBIZ-4053?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Scott Gray updated OFBIZ-4053:
--
Attachment: builder.patch
Updated patch with the latest and greatest:
- Single class for all queries
- queryList()/queryIterator()/queryOne()/queryFirst() for query execution
- select delegator via the use(delegator) method
Simple example:
{code}
ListGenericValue agreementItems =
EntityQuery.use(delegator).from(AgreementItemAndProductAppl)
.where(productId, productId, agreementItemTypeId,
AGREEMENT_COMMISSION)
.cache().filterByDate().queryList();
{code}
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: Trunk
Reporter: Scott Gray
Assignee: Scott Gray
Attachments: builder.patch, 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 implementation so far that I'm not entirely happy
with:
- I'm not so sure that I like EntityBuilderUtil.list(delegator) in place of
something like EntityList.use(delegator). The latter requires less typing
and I think is more intuitive than typing EntityBuilderUtil because of its
similarities to the corresponding minilang method calls, I actually kept
having trouble remembering what it was called when converting some delegator
calls over. It also requires a little more typing (16-17 characters vs.
12-13), not a big deal but every little bit helps with what would be a very
commonly used class.
- I'm struggling to see the point of having the GenericQueryBuilder
interface, the two classes share very little in the way of API and its use
seems a little superfluous to me.
Opinions on the above points or anything else to do with the implementation
are most welcome. I'd like to get the API locked down (and hopefully some
javadocs in place) before committing.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[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=14135257#comment-14135257
]
Scott Gray commented on OFBIZ-4053:
---
I'm in no rush so I'll wait a week or two before committing. In a few days
I'll post an additional patch showing a larger scale changeover to EntityQuery
within a few java files for comparison purposes.
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: Trunk
Reporter: Scott Gray
Assignee: Scott Gray
Attachments: builder.patch, 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 implementation so far that I'm not entirely happy
with:
- I'm not so sure that I like EntityBuilderUtil.list(delegator) in place of
something like EntityList.use(delegator). The latter requires less typing
and I think is more intuitive than typing EntityBuilderUtil because of its
similarities to the corresponding minilang method calls, I actually kept
having trouble remembering what it was called when converting some delegator
calls over. It also requires a little more typing (16-17 characters vs.
12-13), not a big deal but every little bit helps with what would be a very
commonly used class.
- I'm struggling to see the point of having the GenericQueryBuilder
interface, the two classes share very little in the way of API and its use
seems a little superfluous to me.
Opinions on the above points or anything else to do with the implementation
are most welcome. I'd like to get the API locked down (and hopefully some
javadocs in place) before committing.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (OFBIZ-4053) Implement an Entity Query Builder
[
https://issues.apache.org/jira/browse/OFBIZ-4053?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Scott Gray updated OFBIZ-4053:
--
Attachment: builder.patch
Great spotting Adrian and thanks for the review! Patch updated with the issue
fixed
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: Trunk
Reporter: Scott Gray
Assignee: Scott Gray
Attachments: builder.patch, builder.patch, 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 implementation so far that I'm not entirely happy
with:
- I'm not so sure that I like EntityBuilderUtil.list(delegator) in place of
something like EntityList.use(delegator). The latter requires less typing
and I think is more intuitive than typing EntityBuilderUtil because of its
similarities to the corresponding minilang method calls, I actually kept
having trouble remembering what it was called when converting some delegator
calls over. It also requires a little more typing (16-17 characters vs.
12-13), not a big deal but every little bit helps with what would be a very
commonly used class.
- I'm struggling to see the point of having the GenericQueryBuilder
interface, the two classes share very little in the way of API and its use
seems a little superfluous to me.
Opinions on the above points or anything else to do with the implementation
are most welcome. I'd like to get the API locked down (and hopefully some
javadocs in place) before committing.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[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=14050643#comment-14050643
]
Scott Gray commented on OFBIZ-4053:
---
Not really sure how any of this is relevant? The Query Builder is intended to
provide easier access to the Delegator and some of the EntityUtil methods. It
doesn't aim to fix anything or alter access to any functionality that already
exists.
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 implementation so far that I'm not entirely happy
with:
- I'm not so sure that I like EntityBuilderUtil.list(delegator) in place of
something like EntityList.use(delegator). The latter requires less typing
and I think is more intuitive than typing EntityBuilderUtil because of its
similarities to the corresponding minilang method calls, I actually kept
having trouble remembering what it was called when converting some delegator
calls over. It also requires a little more typing (16-17 characters vs.
12-13), not a big deal but every little bit helps with what would be a very
commonly used class.
- I'm struggling to see the point of having the GenericQueryBuilder
interface, the two classes share very little in the way of API and its use
seems a little superfluous to me.
Opinions on the above points or anything else to do with the implementation
are most welcome. I'd like to get the API locked down (and hopefully some
javadocs in place) before committing.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (OFBIZ-5626) No lock can be acquired after ofbiz application crashes.
[ https://issues.apache.org/jira/browse/OFBIZ-5626?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14021733#comment-14021733 ] Scott Gray commented on OFBIZ-5626: --- Either instanceId (which I'd already suggested above) or lockedByInstanceId would be fine by me. I agree runByInstanceId isn't ideal (but not necessarily a bad choice). I don't see why the instanceId needs to be part of the primary key though, the original intent of the table should be maintained where the intent is one row per service. No lock can be acquired after ofbiz application crashes. Key: OFBIZ-5626 URL: https://issues.apache.org/jira/browse/OFBIZ-5626 Project: OFBiz Issue Type: Bug Components: framework Affects Versions: SVN trunk Reporter: Leon Priority: Critical Attachments: OFBIZ-5626.patch We have a service which semaphore set to fail. Someday, while it was running, the whole ofbiz crashed. After the restart, the service is unable to run anymore since the lock file (database record in ServiceSemaphore entity) is already there. Is there any way to cleanup the unused lock files during ofbiz startup? How about the cluster environment? -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (OFBIZ-5626) No lock can be acquired after ofbiz application crashes.
[ https://issues.apache.org/jira/browse/OFBIZ-5626?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14025249#comment-14025249 ] Scott Gray commented on OFBIZ-5626: --- Thanks Leon, looks good to me. No lock can be acquired after ofbiz application crashes. Key: OFBIZ-5626 URL: https://issues.apache.org/jira/browse/OFBIZ-5626 Project: OFBiz Issue Type: Bug Components: framework Affects Versions: SVN trunk Reporter: Leon Priority: Critical Attachments: OFBIZ-5626.patch We have a service which semaphore set to fail. Someday, while it was running, the whole ofbiz crashed. After the restart, the service is unable to run anymore since the lock file (database record in ServiceSemaphore entity) is already there. Is there any way to cleanup the unused lock files during ofbiz startup? How about the cluster environment? -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (OFBIZ-5626) No lock can be acquired after ofbiz application crashes.
[ https://issues.apache.org/jira/browse/OFBIZ-5626?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14017638#comment-14017638 ] Scott Gray commented on OFBIZ-5626: --- Definitely not in DatabaseUtil, that's part of the entity component whereas this is a service component function. This should take a similar approach to JobManager.reloadCrashedJobs() which is called when the ServiceDispatcher is initialised (via JobPoller initialisation). I would add a protected method to ServiceDispatcher and call it from the constructor (before the call to runStartupServices()). No lock can be acquired after ofbiz application crashes. Key: OFBIZ-5626 URL: https://issues.apache.org/jira/browse/OFBIZ-5626 Project: OFBiz Issue Type: Bug Components: framework Affects Versions: SVN trunk Reporter: Leon Priority: Critical We have a service which semaphore set to fail. Someday, while it was running, the whole ofbiz crashed. After the restart, the service is unable to run anymore since the lock file (database record in ServiceSemaphore entity) is already there. Is there any way to cleanup the unused lock files during ofbiz startup? How about the cluster environment? -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (OFBIZ-5648) Extend primary keys
[
https://issues.apache.org/jira/browse/OFBIZ-5648?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14002017#comment-14002017
]
Scott Gray commented on OFBIZ-5648:
---
I agree with Adrian. When you get to the point of adding new fields to a pk
then it's no longer an extension, it's a redefinition and that isn't the
intention of the extend-entity feature.
Extend primary keys
---
Key: OFBIZ-5648
URL: https://issues.apache.org/jira/browse/OFBIZ-5648
Project: OFBiz
Issue Type: Bug
Components: framework
Affects Versions: Release Branch 11.04, SVN trunk, Release Branch 12.04,
Release Branch 13.07
Reporter: Jacques Le Roux
Assignee: Jacques Le Roux
Labels: entity, extend
Attachments: ModelEntity.java.patch, test.entity-extend.patch
At http://svn.apache.org/viewvc?view=revisionrevision=431009 David
Implemented extend-entity for entity definitions to support adding field,
relation and index elements to an entity; this is now also used to support
further separation of the framework from the applications
But primary keys were not taken into account
{code}
// this will always be true for now as extend-entity fielsd are always nonpks
{code}
It turned I needed to extend a PK and using the attached simple
ModelEntity.java.patch, it definitely works quite well.
I also attach a test.entity-extend.patch for testing with a localhost trunk
demo instance
# Apply the test.entity-extend.patch
# Get to
https://localhost:8443/webtools/control/FindGeneric?entityName=OrderHeader,
you will see the orderId extension has been taken into account in the DB:
orderId* String, VARCHAR(60). I also checked creating a
Postgres DB, the column is 60 chars wide.
# Get to
https://localhost:8443/webtools/control/ViewGeneric?entityName=OrderHeaderenableEdit=true,
you will see that you can't enter a PK longer than 20 chars
# Apply the ModelEntity.java.patch, clean-data load-demo, restart
# Get to
https://localhost:8443/webtools/control/ViewGeneric?entityName=OrderHeaderenableEdit=true,
you can enter a PK longer than 20 chars (up to 60) and create a new entity
Though I already use this change in a custom project, I will wait some time
before committing, thanks for your reviews
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (OFBIZ-5626) No lock can be acquired after ofbiz application crashes.
[
https://issues.apache.org/jira/browse/OFBIZ-5626?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13988826#comment-13988826
]
Scott Gray commented on OFBIZ-5626:
---
This is definitely a pain.
I'd suggest to:
- add an instanceId field to ServiceSemaphore which is populated by the
general.properties unique.instanceId value when a lock is acquired
- on startup an instance should check for any ServiceSemaphore rows that match
instanceId=${unique.instanceId} and delete them
No lock can be acquired after ofbiz application crashes.
Key: OFBIZ-5626
URL: https://issues.apache.org/jira/browse/OFBIZ-5626
Project: OFBiz
Issue Type: Bug
Components: framework
Affects Versions: SVN trunk
Reporter: Leon
Priority: Critical
We have a service which semaphore set to fail. Someday, while it was
running, the whole ofbiz crashed. After the restart, the service is unable to
run anymore since the lock file (database record in ServiceSemaphore entity)
is already there.
Is there any way to cleanup the unused lock files during ofbiz startup? How
about the cluster environment?
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (OFBIZ-5095) After adding reschedule order to shipping list, caused shippling listing page cannot show
[ https://issues.apache.org/jira/browse/OFBIZ-5095?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13945751#comment-13945751 ] Scott Gray commented on OFBIZ-5095: --- I'm unable to reproduce this in trunk After adding reschedule order to shipping list, caused shippling listing page cannot show - Key: OFBIZ-5095 URL: https://issues.apache.org/jira/browse/OFBIZ-5095 Project: OFBiz Issue Type: Bug Components: specialpurpose/ecommerce Affects Versions: SVN trunk Reporter: fanse Priority: Critical Step: 1.Create an order and checkout success 2.In Order history page, choose one order and show it's detail 3.At the head of Order Items table, click Send me this every month. Get: org.ofbiz.widget.screen.ScreenRenderException: Error rendering screen [component://ecommerce/widget/CommonScreens.xml#main-decorator]: org.ofbiz.entity.transaction.GenericTransactionException: The current transaction is marked for rollback, not beginning a new transaction and aborting current operation; the rollbackOnly was caused by: Error in simple-method [Create a ShoppingList Item [file:/E:/projects/ofbiz/source/underware/trunk/applications/order/script/org/ofbiz/order/shoppinglist/ShoppingListServices.xml#createShoppingListItem]]: (The current transaction is marked for rollback, not beginning a new transaction and aborting current operation; the rollbackOnly was caused by: Error in simple-method [Create a ShoppingList Item [file:/E:/projects/ofbiz/source/underware/trunk/applications/order/script/org/ofbiz/order/shoppinglist/ShoppingListServices.xml#createShoppingListItem]]: ) -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (OFBIZ-5476) Create component in OFBiz JIRA
[ https://issues.apache.org/jira/browse/OFBIZ-5476?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13874708#comment-13874708 ] Scott Gray commented on OFBIZ-5476: --- I'd prefer we didn't do anything that encourages Pierre to continue creating trivial tickets in JIRA. I wouldn't be surprised if he filed a ticket to go to the bathroom. Confluence and the mailing lists are a more suitable place to collaborate on design, once there's something tangible and actionable then file tickets and submit patches. What if your proposed design is rejected by the community? We don't want to have have to manage 50 tickets relating to a potentially flawed concept. Create component in OFBiz JIRA -- Key: OFBIZ-5476 URL: https://issues.apache.org/jira/browse/OFBIZ-5476 Project: OFBiz Issue Type: Sub-task Reporter: Pierre Smits Create a new component in JIRA to: 1. capture requirements (at first) 2. capture other issues pertaining bugs and improvements (a.o.) related to the Expense solution. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Commented] (OFBIZ-5448) Have Ivy download the activemq jar(s) for DCC
[ https://issues.apache.org/jira/browse/OFBIZ-5448?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13861414#comment-13861414 ] Scott Gray commented on OFBIZ-5448: --- Hi Jacques, what is DCC? Have Ivy download the activemq jar(s) for DCC - Key: OFBIZ-5448 URL: https://issues.apache.org/jira/browse/OFBIZ-5448 Project: OFBiz Issue Type: Improvement Components: framework Affects Versions: SVN trunk Reporter: Pierre Smits Assignee: Jacques Le Roux Priority: Minor Fix For: SVN trunk Attachments: OFBIZ-5448-BUILD-ivy-actvicemq.patch For a working DCC you'll need activemq jar(s). -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Commented] (OFBIZ-5448) Have Ivy download the activemq jar(s) for DCC
[ https://issues.apache.org/jira/browse/OFBIZ-5448?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13861475#comment-13861475 ] Scott Gray commented on OFBIZ-5448: --- Ah okay thanks, I hadn't seen that page Have Ivy download the activemq jar(s) for DCC - Key: OFBIZ-5448 URL: https://issues.apache.org/jira/browse/OFBIZ-5448 Project: OFBiz Issue Type: Improvement Components: framework Affects Versions: SVN trunk Reporter: Pierre Smits Assignee: Jacques Le Roux Priority: Minor Fix For: SVN trunk Attachments: OFBIZ-5448-BUILD-ivy-actvicemq.patch For a working DCC you'll need activemq jar(s). -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Closed] (OFBIZ-5358) Wrong to refer to fieldtypepostnew.xml in entityengine.xml
[ https://issues.apache.org/jira/browse/OFBIZ-5358?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Scott Gray closed OFBIZ-5358. - Resolution: Fixed It seems this has already been taken care of, closing the ticket. Wrong to refer to fieldtypepostnew.xml in entityengine.xml -- Key: OFBIZ-5358 URL: https://issues.apache.org/jira/browse/OFBIZ-5358 Project: OFBiz Issue Type: Bug Components: framework Affects Versions: SVN trunk Reporter: Wei Zhang Since fieldtypepostnew.xml has been deleted in revision 1530237, I don't think it should still refer to this file at line 105 in entityengine.xml -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (OFBIZ-5283) Inventory report shows different counts after a warehouse transfer.
[ https://issues.apache.org/jira/browse/OFBIZ-5283?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13731893#comment-13731893 ] Scott Gray commented on OFBIZ-5283: --- A lack of errors isn't the only indicator of a correct change however. While I'm not very familiar with the functionality involved, some questions need to be answered before moving further in order to properly understand the problem: - Why did the report previously use accountingQuantitySum? - What is the justification for changing the report to use quantityOnHandSum (other than that it appears to hold the correct value in this situation)? - Should accountingQuantitySum be altered as part of a transfer and would that fix the problem without any further changes? Inventory report shows different counts after a warehouse transfer. --- Key: OFBIZ-5283 URL: https://issues.apache.org/jira/browse/OFBIZ-5283 Project: OFBiz Issue Type: Bug Components: accounting Affects Versions: SVN trunk Reporter: Hans Bakker Priority: Critical Fix For: SVN trunk Attachments: accounting.diff A customer reported the following problem where the inventory report shows different counts after a warehouse transfer. Steps to replicate problem 1. Choose Facility - Web Store Warehouse 2. Select Inventory Items and filter by product id GZ-2644 3. You should see all the items for that product make a note of the Quantity on Hand 6. On any of the Product ID's GZ-2644 click Transfer(Right hand side of the screen) 7. Change the To Facility / Container to be My Retail Store 8. Transfer only quantity of 1 9. Click on Complete Requested Transfer 10. Select the item using the checkbox and click submit 11. Repeat steps 2 to 3 - Taking note of the Quantity on Hand which should have changed Next 1. Click on Accounting 2. Click on Organization GL Settings 3. Click Accounting for Your Company Name Here 4. Click Reports 5. Click Inventory Valuation 6. Select Web Store Warehouse and click submit 7. Note Quantities against GZ-2644 are the Accounting Quantity Total not the Quantity on Hand. - -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (OFBIZ-5277) UnitData.xml is missing some liquid volume measures
[ https://issues.apache.org/jira/browse/OFBIZ-5277?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13712173#comment-13712173 ] Scott Gray commented on OFBIZ-5277: --- M3-Liquid doesn't seem to be any sort of standard abbreviation, IMO it should just be m3. The abbreviation for Hectoliter is hL or hl. UnitData.xml is missing some liquid volume measures --- Key: OFBIZ-5277 URL: https://issues.apache.org/jira/browse/OFBIZ-5277 Project: OFBiz Issue Type: Bug Components: framework Affects Versions: SVN trunk Reporter: Pierre Smits Priority: Minor Fix For: SVN trunk Attachments: OFBIZ-5277-FRMWRK-UnitData.patch Following liquid volume measures are missing in data set UnitData.xml Hectoliters M3 -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (OFBIZ-4794) set different ports for testing in a CI environment (e.g. Jenkins)
[ https://issues.apache.org/jira/browse/OFBIZ-4794?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13694280#comment-13694280 ] Scott Gray commented on OFBIZ-4794: --- 1. I never suggested adding (yet another) ant target specifically for applying port offsets. You said you agree with that suggestion but I never made it. An ant target for applying patches (if one doesn't already exist) is a good idea though. 2. I meant as usual in that it is all too common for a committer to be given advice (from more than one reviewer) and then choose to ignore it. Also, suggesting you'll go against recommendations because no one is willing to help is ridiculous, it's basically trying to blackmail people into doing your work for you set different ports for testing in a CI environment (e.g. Jenkins) -- Key: OFBIZ-4794 URL: https://issues.apache.org/jira/browse/OFBIZ-4794 Project: OFBiz Issue Type: Improvement Components: framework Affects Versions: SVN trunk Reporter: Pierre Smits Assignee: Jacques Le Roux Fix For: SVN trunk Attachments: OFBIZ-4794 - test port.patch, OFBIZ-4794-test-ports.patch Original Estimate: 1h Remaining Estimate: 1h In order to run test targets in Jenkins we need to change ports for at least ajp, http and https in test-containers.xml as these ports are most likely to be already in use by the CI server. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (OFBIZ-4794) set different ports for testing in a CI environment (e.g. Jenkins)
[ https://issues.apache.org/jira/browse/OFBIZ-4794?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13692891#comment-13692891 ] Scott Gray commented on OFBIZ-4794: --- Haven't we made multiple changes in svn to our default configuration in the past to accommodate test and demo deployments? I'm suggesting that those changes and this one could be handled more appropriately by using patches and an ant target to apply them. If there are any more changes in the future (which I'm suggesting won't be easily handled by your approach) they will be easy to make with patches and will avoid over complicating our ant tasks with rarely-used parameter arguments. set different ports for testing in a CI environment (e.g. Jenkins) -- Key: OFBIZ-4794 URL: https://issues.apache.org/jira/browse/OFBIZ-4794 Project: OFBiz Issue Type: Improvement Components: framework Affects Versions: SVN trunk Reporter: Pierre Smits Assignee: Jacques Le Roux Fix For: SVN trunk Attachments: OFBIZ-4794 - test port.patch, OFBIZ-4794-test-ports.patch Original Estimate: 1h Remaining Estimate: 1h In order to run test targets in Jenkins we need to change ports for at least ajp, http and https in test-containers.xml as these ports are most likely to be already in use by the CI server. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (OFBIZ-4794) set different ports for testing in a CI environment (e.g. Jenkins)
[ https://issues.apache.org/jira/browse/OFBIZ-4794?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13692910#comment-13692910 ] Scott Gray commented on OFBIZ-4794: --- I can't recall what the changes were, but I recall tweaks over the years. I don't think running two or more instances on the same machine is such a common requirement that it should be a command line argument. When such adjustments are needed I don't think it's a big deal to find the configuration and change it, most devs know how to adjust the ports. The adjustment could also be environment specific depending on the app server being deployed with OFBiz (not necessarily embedded). I'm also not suggesting the use of patches as something for developers to be expected to use, I'm only suggesting them specifically for use within the Apache infrastructure. They don't even need to be kept in svn necessarily, the could just as easily reside in someone's apache home folder. That way no changes are needed within the project itself at all. The deployment environments within Apache infra would simply be no different to any other real world deployment. I doubt you foresaw this config change either until people started talking about problems with Jenkins so I'm not sure that your argument is valid. I don't see how the port number is any different from any other configuration in OFBiz, they could all arguably be accessible through the command line but where do you draw the line? And how easy will it be for people to adjust these configurations when we support setting them in multiple ways? I'm in favor of keeping OFBiz as simple as possible and covering the 90% of use cases while making the remainder easily solvable through normal configuration. I think this crosses a line of making things more complicated for a corner case instead of taking a more standard approach to solving a common deployment problem (the need to adjust the system configuration from their defaults). set different ports for testing in a CI environment (e.g. Jenkins) -- Key: OFBIZ-4794 URL: https://issues.apache.org/jira/browse/OFBIZ-4794 Project: OFBiz Issue Type: Improvement Components: framework Affects Versions: SVN trunk Reporter: Pierre Smits Assignee: Jacques Le Roux Fix For: SVN trunk Attachments: OFBIZ-4794 - test port.patch, OFBIZ-4794-test-ports.patch Original Estimate: 1h Remaining Estimate: 1h In order to run test targets in Jenkins we need to change ports for at least ajp, http and https in test-containers.xml as these ports are most likely to be already in use by the CI server. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (OFBIZ-4794) set different ports for testing in a CI environment (e.g. Jenkins)
[ https://issues.apache.org/jira/browse/OFBIZ-4794?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13693384#comment-13693384 ] Scott Gray commented on OFBIZ-4794: --- bq. Anyway, I can agree about providing an ant target to apply ports offset before running an instance (either in demo or test mode). This would be notably easier for instance than changing url.properties value in RequestHandler.getDefaultServerRootUrl() Please don't do that, it wasn't at all what I suggested. I give up though, do as you please (as usual). set different ports for testing in a CI environment (e.g. Jenkins) -- Key: OFBIZ-4794 URL: https://issues.apache.org/jira/browse/OFBIZ-4794 Project: OFBiz Issue Type: Improvement Components: framework Affects Versions: SVN trunk Reporter: Pierre Smits Assignee: Jacques Le Roux Fix For: SVN trunk Attachments: OFBIZ-4794 - test port.patch, OFBIZ-4794-test-ports.patch Original Estimate: 1h Remaining Estimate: 1h In order to run test targets in Jenkins we need to change ports for at least ajp, http and https in test-containers.xml as these ports are most likely to be already in use by the CI server. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (OFBIZ-4794) set different ports for testing in a CI environment (e.g. Jenkins)
[ https://issues.apache.org/jira/browse/OFBIZ-4794?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13692672#comment-13692672 ] Scott Gray commented on OFBIZ-4794: --- +1 for a patch (or patches), command line arguments might work for a while but as configuration differences grow things will be become messy. Easier is not necessarily better. set different ports for testing in a CI environment (e.g. Jenkins) -- Key: OFBIZ-4794 URL: https://issues.apache.org/jira/browse/OFBIZ-4794 Project: OFBiz Issue Type: Improvement Components: framework Affects Versions: SVN trunk Reporter: Pierre Smits Assignee: Jacques Le Roux Fix For: SVN trunk Attachments: OFBIZ-4794 - test port.patch, OFBIZ-4794-test-ports.patch Original Estimate: 1h Remaining Estimate: 1h In order to run test targets in Jenkins we need to change ports for at least ajp, http and https in test-containers.xml as these ports are most likely to be already in use by the CI server. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (OFBIZ-4949) Add a new attribute for entity-engine-xml tag, set-other-fields-to-null= true, if it exists at the beginning data file, all updates will set to null all fields not deta
[ https://issues.apache.org/jira/browse/OFBIZ-4949?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13500140#comment-13500140 ] Scott Gray commented on OFBIZ-4949: --- UEL could be a good idea but it's a separate feature IMO, we already have the ability to set a field null by supplying an empty attribute value as I mentioned above. Maybe the issue here is larger than we think and the forest isn't being seen for the trees. The current mode of operation for data files is to perform a create-or-update operation for each record present. What is essentially being asked for here is a new operation mode of create-or-replace. How about if we were to find a way to support any possible operation mode? This could also solve the recurring problems that seem to appear with seed-initial data where we would want a create only operation with no update if the value exists. Possible operations: - create - create-update - create-replace - delete? If we were to go this route we'd just need to decide how the operation should be set for a given file or record, options coming to mind: 1. At the reader in the entity-engine.xml or ofbiz-component.xml files 2. As an attribute of the entity-engine-xml element 3. As child element of the entity-engine-xml element 4. As an attribute of the record element itself I think I'd prefer #2 or #3, probably #3 Thoughts? Add a new attribute for entity-engine-xml tag, set-other-fields-to-null= true, if it exists at the beginning data file, all updates will set to null all fields not detailed in the file Key: OFBIZ-4949 URL: https://issues.apache.org/jira/browse/OFBIZ-4949 Project: OFBiz Issue Type: Sub-task Components: framework Affects Versions: SVN trunk Reporter: Olivier Heintz Priority: Minor Attachments: OFBIZ-4949-NMA.patch, OFBIZ-4949.patch, OFBIZ-4949.patch, OFBIZ-4949.patch This enhancement is useful when a entity is load by reader (ex: seed) and sometime, it could be modify in data file. If a field is change from a value to null, currently this modification will not be done in the next load. For portletWidget, entity PortalPortal have a lot of field with potential default value, so sometime, first release use some field and when it's reviewed and corrected, some field are changed to null to use the default value (to follow best practice). This enhancement will be very useful for portletData file. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (OFBIZ-4949) Add a new attribute for entity-engine-xml tag, nullify-absent-fields
[ https://issues.apache.org/jira/browse/OFBIZ-4949?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13500173#comment-13500173 ] Scott Gray commented on OFBIZ-4949: --- My main concern with #1 and #2 was decreased visibility to someone modifying the file which carries an increased risk of accidentally adding records under an inappropriate operation. #3 and #4 also carry the advantage of being able to perform multiple related operations within the same file. Add a new attribute for entity-engine-xml tag, nullify-absent-fields Key: OFBIZ-4949 URL: https://issues.apache.org/jira/browse/OFBIZ-4949 Project: OFBiz Issue Type: Sub-task Components: framework Affects Versions: SVN trunk Reporter: Olivier Heintz Priority: Minor Attachments: OFBIZ-4949-NMA.patch, OFBIZ-4949.patch, OFBIZ-4949.patch, OFBIZ-4949.patch This enhancement is useful when a entity is load by reader (ex: seed) and sometime, it could be modify in data file. If a field is change from a value to null, currently this modification will not be done in the next load. When you are first importing new data, quite naturally all fields other than those specified in the file will be null. If, however, you're updating existing data, you might want any field not specified in the file to retain its current value, or you might want the contents of the file to specify everything about a record, in other words take this data and null out the rest. The alternative to set-other-fields-to-null (or whatever else we might call it) would be a huge number of attribute= in the file. For portletWidget, entity PortalPortal have a lot of field with potential default value, so sometime, first release use some field and when it's reviewed and corrected, some field are changed to null to use the default value (to follow best practice). This enhancement will be very useful for portletData file. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (OFBIZ-4274) Implement a REST Servlet
[
https://issues.apache.org/jira/browse/OFBIZ-4274?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13497656#comment-13497656
]
Scott Gray commented on OFBIZ-4274:
---
I've only looked at rest-conf.xml at this stage but the following issues come
to mind:
1. No support for sub-resources e.g. GET: /parties/1/contactmechs/ While
this could also be possible using contactmechs?partyId=1, I don't think we
should restrict APIs to a non-hierarchical structure.
2. I think it might be better to structure the document by resource with child
elements for methods e.g.
{code:xml}
resource name=example
post
security https=true auth=true/
invoke-service name=createExample
!--
The servlet will convert trailing path elements into a List, so they can
be queried by code.
--
service-param name=exampleId value=${pathElements[0]}/
/invoke-service
response-hyperlink resource=exampleItem/
response-hyperlink url=http://www.mydomain.com/
/post
!-- Updates (or creates) an Example --
put
security https=true auth=true/
invoke-service name=updateExample
service-param name=exampleId value=${pathElements[0]}/
/invoke-service
response-hyperlink resource=exampleItem/
/put
/resource
{code}
3. I think we're also missing the distinction between collection and instance
methods whereby GET: /party/ and GET:/party/1 access different services and
return different results.
That's all that comes to mind right now.
Implement a REST Servlet
Key: OFBIZ-4274
URL: https://issues.apache.org/jira/browse/OFBIZ-4274
Project: OFBiz
Issue Type: New Feature
Components: framework
Reporter: Adrian Crum
Priority: Minor
Attachments: rest-conf.xml, RestExampleSchema.xsd,
RestXmlRepresentation.xml
Implement a REST servlet that will map REST requests to OFBiz services.
Details are in the comments.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (OFBIZ-5004) Warning in GenericEntity.get unnecessarily clutters logs
[
https://issues.apache.org/jira/browse/OFBIZ-5004?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13439413#comment-13439413
]
Scott Gray commented on OFBIZ-5004:
---
Hey Christoph,
Interesting point on the IllegalArgumentException, I missed your comment
initially and had always taken the code comment at face value without much
thought. I'd actually be in favor of throwing the exception when an invalid
field name is passed in.
While tests are great they aren't the answer here, the reality is that we have
the ability to build this protection into the framework and it should be taken
advantage of considering the 99% use-case is that the developer expects the
field they've passed in to exist on the entity.
For the record, I definitely look at the logs while developing.
Warning in GenericEntity.get unnecessarily clutters logs
Key: OFBIZ-5004
URL: https://issues.apache.org/jira/browse/OFBIZ-5004
Project: OFBiz
Issue Type: Bug
Components: framework
Affects Versions: SVN trunk
Reporter: Christoph Neuroth
This code in GenericEntity.java:
{code}Debug.logWarning(The field name (or key) [ + name + ] is not valid
for entity [ + this.getEntityName() + ], printing IllegalArgumentException
instead of throwing it because Map interface specification does not allow
throwing that exception., module);
{code}
is really annoying and IMHO it is wrong.
First, it does not print an exception, it only prints that string with no
stacktrace (I think that was changed at some point).
Second, IllegalArgument is a RuntimeException so the interface doesn't really
need to allow it to be thrown, right?
Personally, I think the warning is not even justified. We sometimes don't
know exactly what kind of entity we're dealing with and just check if it has
that field or not. With this code, to prevent excessive log clutter, we have
to wrap each call with a if (it.containsKey()). A java map will just return
null silently as well, and this behavior is documented in the Map interface.
If anyone is really worried about accessing fields wrong (your tests should
catch that error), there could be an extra method getOrThrow or something,
but get should just return the value or null.
Otherwise, at least throw the exception. Log warnings are usually found while
monitoring production logs, developers will find this much earlier otherwise.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (OFBIZ-5004) Warning in GenericEntity.get unnecessarily clutters logs
[
https://issues.apache.org/jira/browse/OFBIZ-5004?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13439208#comment-13439208
]
Scott Gray commented on OFBIZ-5004:
---
The warnings are not by any means pointless.
Reason to remove: I'm dealing with an unknown entity and the warnings fill my
logs
Solution: Use GenericEntity.getEntityName() or
(GenericEntity.getModelEntity().isField(String) *do not* use
GenericEntity.containsKey(String) because GenericEntity can carry a partially
populated value that will return false for valid fields. Doing a set or a get
without knowing that it is a valid operation for the given entity sounds like a
terrible practice to me.
Reason to keep: Typos are easy to make and there's no build-time protection
available, I've located issues in production numerous times because of this
logging and that's exactly why it exists, to warn developers when they do
something they shouldn't. The only reason it doesn't actually throw the
exception is because the Map spec doesn't allow it.
Please don't change this, the risks far outweigh the benefits here.
Warning in GenericEntity.get unnecessarily clutters logs
Key: OFBIZ-5004
URL: https://issues.apache.org/jira/browse/OFBIZ-5004
Project: OFBiz
Issue Type: Bug
Components: framework
Affects Versions: SVN trunk
Reporter: Christoph Neuroth
This code in GenericEntity.java:
{code}Debug.logWarning(The field name (or key) [ + name + ] is not valid
for entity [ + this.getEntityName() + ], printing IllegalArgumentException
instead of throwing it because Map interface specification does not allow
throwing that exception., module);
{code}
is really annoying and IMHO it is wrong.
First, it does not print an exception, it only prints that string with no
stacktrace (I think that was changed at some point).
Second, IllegalArgument is a RuntimeException so the interface doesn't really
need to allow it to be thrown, right?
Personally, I think the warning is not even justified. We sometimes don't
know exactly what kind of entity we're dealing with and just check if it has
that field or not. With this code, to prevent excessive log clutter, we have
to wrap each call with a if (it.containsKey()). A java map will just return
null silently as well, and this behavior is documented in the Map interface.
If anyone is really worried about accessing fields wrong (your tests should
catch that error), there could be an extra method getOrThrow or something,
but get should just return the value or null.
Otherwise, at least throw the exception. Log warnings are usually found while
monitoring production logs, developers will find this much earlier otherwise.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (OFBIZ-4958) Additional Validation for Password : Make password pattern driven
[ https://issues.apache.org/jira/browse/OFBIZ-4958?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13429979#comment-13429979 ] Scott Gray commented on OFBIZ-4958: --- Hi Sumit, I don't mind either way, either disable it by default or make the pattern less restrictive (probably only enforcing a minimum length). My only input into this issue is that I'd rather not see special characters and/or numbers be required by default. Thanks Additional Validation for Password : Make password pattern driven -- Key: OFBIZ-4958 URL: https://issues.apache.org/jira/browse/OFBIZ-4958 Project: OFBiz Issue Type: Sub-task Components: ALL COMPONENTS Affects Versions: SVN trunk Reporter: Sumit Pandit Assignee: Jacques Le Roux Fix For: SVN trunk Attachments: OFBIZ-4958.patch Providing an additional validation for password - Idea is to achieve following - * Insist user to provide a stronger login password for additional protection. * User's password need to match a pre-defined Pattern. * Password pattern can change any time. * Validation should applied for new user creation and update password processes. -- Thanks And Regards Sumit Pandit -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (OFBIZ-4958) Additional Validation for Password : Make password pattern driven
[ https://issues.apache.org/jira/browse/OFBIZ-4958?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13429106#comment-13429106 ] Scott Gray commented on OFBIZ-4958: --- Please keep the default to something less restrictive. I use pass phrases in place of passwords which are easier to remember and arguably more secure (http://en.wikipedia.org/wiki/Passphrase#Compared_to_passwords). Pass phrases become much harder to remember if you force them to contain numbers or special characters. Additional Validation for Password : Make password pattern driven -- Key: OFBIZ-4958 URL: https://issues.apache.org/jira/browse/OFBIZ-4958 Project: OFBiz Issue Type: Sub-task Components: ALL COMPONENTS Affects Versions: SVN trunk Reporter: Sumit Pandit Assignee: Jacques Le Roux Fix For: SVN trunk Attachments: OFBIZ-4958.patch Providing an additional validation for password - Idea is to achieve following - * Insist user to provide a stronger login password for additional protection. * User's password need to match a pre-defined Pattern. * Password pattern can change any time. * Validation should applied for new user creation and update password processes. -- Thanks And Regards Sumit Pandit -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (OFBIZ-4949) add a new attribute for for entity-engine-xml tag, put-other-field-to-null= true, if it exist at the beginning data file, all update will put to null all field not deta
[ https://issues.apache.org/jira/browse/OFBIZ-4949?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13407718#comment-13407718 ] Scott Gray commented on OFBIZ-4949: --- Currently if you set an attribute with an empty value e.g. firstName= then the field will be set to null, does this not suffice? add a new attribute for for entity-engine-xml tag, put-other-field-to-null= true, if it exist at the beginning data file, all update will put to null all field not detail in this file --- Key: OFBIZ-4949 URL: https://issues.apache.org/jira/browse/OFBIZ-4949 Project: OFBiz Issue Type: Sub-task Components: framework Affects Versions: SVN trunk Reporter: Olivier Heintz Priority: Minor Attachments: OFBIZ-4949.patch This enhancement is useful when a entity is load by reader (ex: seed) and sometime, it could be modify in data file. If a field is change from a value to null, currently this modification will not be done in the next load. For portletWidget, entity PortalPortal have a lot of field with potential default value, so sometime, first release use some field and when it's reviewed and corrected, some field are changed to null to use the default value (to follow best practice). This enhancement will be very useful for portletData file. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
