[jira] Commented: (OFBIZ-3862) Ajax requests prevent externalLoginKey parameters from working correctly
[ https://issues.apache.org/jira/browse/OFBIZ-3862?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12892068#action_12892068 ] Scott Gray commented on OFBIZ-3862: --- To clarify, the problem only occurs if the ajax call results in a screen being rendered since it is the ScreenRenderer that causes a new key to be generated. > Ajax requests prevent externalLoginKey parameters from working correctly > > > Key: OFBIZ-3862 > URL: https://issues.apache.org/jira/browse/OFBIZ-3862 > Project: OFBiz > Issue Type: Bug > Components: framework >Affects Versions: SVN trunk >Reporter: Scott Gray > > A new external login key is generated for every request so if an ajax request > fires on a page then the externalLoginKey used in any links on the page is > invalidated. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Assigned: (OFBIZ-3840) Start button is not showing up when production run is confirmed
[ https://issues.apache.org/jira/browse/OFBIZ-3840?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Scott Gray reassigned OFBIZ-3840: - Assignee: Scott Gray > Start button is not showing up when production run is confirmed > --- > > Key: OFBIZ-3840 > URL: https://issues.apache.org/jira/browse/OFBIZ-3840 > Project: OFBiz > Issue Type: Bug > Components: manufacturing >Affects Versions: Release Branch 10.04, SVN trunk >Reporter: Jeremy Olmstead >Assignee: Scott Gray >Priority: Minor > Attachments: OFBIZ-3840_NoStartButton.patch > > > Steps to recreate the problem: > 1. Create a new production run for a product that has a routing associated > with it (i.e. PROD_MANUF). > 2. Click confirm. > I expected to see a start button for the lowest sequenced task. The start > button is not created. This does work in 9.04, but not 10.04 or the trunk. > It looks as though the ProductionRunServices.java method > changeProductionRunStatus was modified sometime after 9.04 to update each > production run task from PRUN_CREATED or PRUN_SCHEDULED to PRUN_DOC_PRINTED > where in 9.04 it was only updating the production run header. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (OFBIZ-3840) Start button is not showing up when production run is confirmed
[ https://issues.apache.org/jira/browse/OFBIZ-3840?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Scott Gray closed OFBIZ-3840. - Fix Version/s: Release Branch 10.04 SVN trunk Resolution: Fixed Thanks Jeremy, your patch is committed in: trunk - r965805 10.04 - r965809 > Start button is not showing up when production run is confirmed > --- > > Key: OFBIZ-3840 > URL: https://issues.apache.org/jira/browse/OFBIZ-3840 > Project: OFBiz > Issue Type: Bug > Components: manufacturing >Affects Versions: Release Branch 10.04, SVN trunk >Reporter: Jeremy Olmstead >Assignee: Scott Gray >Priority: Minor > Fix For: Release Branch 10.04, SVN trunk > > Attachments: OFBIZ-3840_NoStartButton.patch > > > Steps to recreate the problem: > 1. Create a new production run for a product that has a routing associated > with it (i.e. PROD_MANUF). > 2. Click confirm. > I expected to see a start button for the lowest sequenced task. The start > button is not created. This does work in 9.04, but not 10.04 or the trunk. > It looks as though the ProductionRunServices.java method > changeProductionRunStatus was modified sometime after 9.04 to update each > production run task from PRUN_CREATED or PRUN_SCHEDULED to PRUN_DOC_PRINTED > where in 9.04 it was only updating the production run header. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (OFBIZ-3859) Convert parameters before using entity-engine
[ https://issues.apache.org/jira/browse/OFBIZ-3859?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12890020#action_12890020 ] Scott Gray commented on OFBIZ-3859: --- Yeah you're right, I didn't look closely enough and made a few incorrect assumptions. The mismatch is no longer reported in GenericEntity.set() but it doesn't throw an exception and it has never performed an automatic type conversion in that method (for some reason I thought it did). > Convert parameters before using entity-engine > - > > Key: OFBIZ-3859 > URL: https://issues.apache.org/jira/browse/OFBIZ-3859 > Project: OFBiz > Issue Type: Bug > Components: manufacturing >Affects Versions: SVN trunk >Reporter: matthieu bollot > Attachments: ofbiz-3859.patch > > > Now, values need to be converted before using entity-engine. I'll provide a > patch corresponding to this selenium test : > http://selenium.neogia.org/ofbiz/tests/ManufacturingCreateCalendarAndWeek.html -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (OFBIZ-3765) Use CustomMethod for select order, quote and invoice hook to resolve id
[ https://issues.apache.org/jira/browse/OFBIZ-3765?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12889706#action_12889706 ] Scott Gray commented on OFBIZ-3765: --- Was this tested properly? Sales orders created with OOTB settings now take the form WSCO1 instead of WSCO1. > Use CustomMethod for select order, quote and invoice hook to resolve id > --- > > Key: OFBIZ-3765 > URL: https://issues.apache.org/jira/browse/OFBIZ-3765 > Project: OFBiz > Issue Type: Improvement > Components: accounting, order >Affects Versions: SVN trunk >Reporter: Nicolas Malin >Assignee: Erwan de FERRIERES > Fix For: SVN trunk > > Attachments: hookByPartyAcctgPreference.patch, OFBIZ-3765.patch > > > Currently the invoiceId resolve process is define on PartyAcctgPreference by > a enumeration. The service getNextInvoiceId analyse enumeration to active > code correponding to enumeration. > I propose pass enumeration to CustumMethod that permit to add more easier a > new resolve process. Just define a new CusthomMethod and associate to > PartyAcctgPreference. It's possible to add this by hot-deploy compenents > without change accounting code or add many unreadable function. > The patch contains : > * Entity modiication : pass enumeration to deprecated and add custumMethod > attribute/relation > * Add service enforced ans restart define previously by enumeration > * Implement getNextSeqId service by origin call service to permet analyse > and resolve new id by all information present in context > * Add error message if PartyAcctgPreference not define. > * Apply on invoice, quote an order > To test just ant clean-all && ant run-install and create quote, order and > invoice > Thanks to Leila Mekika for the help > Nicolas -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (OFBIZ-3862) Ajax requests prevent externalLoginKey parameters from working correctly
Ajax requests prevent externalLoginKey parameters from working correctly Key: OFBIZ-3862 URL: https://issues.apache.org/jira/browse/OFBIZ-3862 Project: OFBiz Issue Type: Bug Components: framework Affects Versions: SVN trunk Reporter: Scott Gray A new external login key is generated for every request so if an ajax request fires on a page then the externalLoginKey used in any links on the page is invalidated. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (OFBIZ-3838) Manufacturing Rules home lacks a find page.
[ https://issues.apache.org/jira/browse/OFBIZ-3838?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12889616#action_12889616 ] Scott Gray commented on OFBIZ-3838: --- Not everything has a find page especially when creating associated data and low volume data. Even if one would be useful, the lack of it isn't a bug. > Manufacturing Rules home lacks a find page. > --- > > Key: OFBIZ-3838 > URL: https://issues.apache.org/jira/browse/OFBIZ-3838 > Project: OFBiz > Issue Type: Bug > Components: manufacturing >Affects Versions: Release Branch 4.0, Release 4.0, Release Branch 09.04, > Release 09.04, Release Branch 10.04, SVN trunk >Reporter: BJ Freeman >Priority: Minor > Fix For: Release Branch 4.0, Release 4.0, Release Branch 09.04, > Release 09.04, Release Branch 10.04, SVN trunk > > Original Estimate: 24h > Remaining Estimate: 24h > > looks like there never was a find page. > to follow the standard model of landing on a find page one should be followed. > currently when you select Manufacturing rules from > https://demo-trunk.ofbiz.apache.org/manufacturing/control/FindBom > you go to > https://demo-trunk.ofbiz.apache.org/manufacturing/control/AddProductManufacturingRule > > if you go directly to the link you get a > The following required parameter is missing: > [addProductManufacturingRule.productIdIn] -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (OFBIZ-3834) factoids in ecommerce
[ https://issues.apache.org/jira/browse/OFBIZ-3834?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12889614#action_12889614 ] Scott Gray commented on OFBIZ-3834: --- Looks fine to me, can we close this? > factoids in ecommerce > - > > Key: OFBIZ-3834 > URL: https://issues.apache.org/jira/browse/OFBIZ-3834 > Project: OFBiz > Issue Type: Bug > Components: specialpurpose/ecommerce >Affects Versions: SVN trunk >Reporter: Erwan de FERRIERES > > go to http://demo-trunk.ofbiz.apache.org/ecommerce/ > screenlet at bottom right displays : > org.ofbiz.widget.screen.ScreenRenderException: Error rendering screen > [component://ecommerce/widget/ContentScreens.xml#factoids]: > java.lang.UnsupportedOperationException (null) > Spotted by Jacques > (http://ofbiz.135035.n4.nabble.com/Demo-trunk-needs-ant-clean-all-td2267769.html#a2268283) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (OFBIZ-3861) does not work
[ https://issues.apache.org/jira/browse/OFBIZ-3861?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Scott Gray closed OFBIZ-3861. - Fix Version/s: Release Branch 09.04 Release Branch 10.04 SVN trunk Resolution: Fixed Thanks Wai, fixed in commits: trunk - r965163 10.04 - r965164 9.04 - r965167 > does not work > > > Key: OFBIZ-3861 > URL: https://issues.apache.org/jira/browse/OFBIZ-3861 > Project: OFBiz > Issue Type: Bug > Components: framework >Affects Versions: SVN trunk >Reporter: Wai >Assignee: Scott Gray > Fix For: Release Branch 09.04, Release Branch 10.04, SVN trunk > > Attachments: RequestHandler.java.patch > > > specifying direct-request="false" in a request-map has no effect. A direct > request to the resource is not rejected by ofbiz -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Assigned: (OFBIZ-3861) does not work
[ https://issues.apache.org/jira/browse/OFBIZ-3861?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Scott Gray reassigned OFBIZ-3861: - Assignee: Scott Gray > does not work > > > Key: OFBIZ-3861 > URL: https://issues.apache.org/jira/browse/OFBIZ-3861 > Project: OFBiz > Issue Type: Bug > Components: framework >Affects Versions: SVN trunk >Reporter: Wai >Assignee: Scott Gray > Attachments: RequestHandler.java.patch > > > specifying direct-request="false" in a request-map has no effect. A direct > request to the resource is not rejected by ofbiz -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (OFBIZ-3847) Entity ECAs not triggered correctly when using Delegator.storeAll() method
[
https://issues.apache.org/jira/browse/OFBIZ-3847?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12888956#action_12888956
]
Scott Gray commented on OFBIZ-3847:
---
I think this points to a larger problem whereby there is no guarantee that any
entity ECA will receive a complete GenericValue representing the entire record.
For example GenericDelegator.removeByPrimaryKey() only passes the primary key
fields to the ECA rule runner and any ECAs that depend on other non-pk fields
won't be able to evaluate their condition properly.
I'm not sure what the full solution would look like, it would be good to get
some thoughts of others on this.
We could consider having EntityEcaCondition.eval() perform a db lookup if any
of the fields it needs to evaluate are missing. If they are missing it could
fully populate the entity with the missing fields so that a lookup is only
required at most once per delegator operation. If no ECA conditions require
any missing fields then the lookup wouldn't be performed, so the performance
penalty would only be incurred when necessary.
> Entity ECAs not triggered correctly when using Delegator.storeAll() method
> --
>
> Key: OFBIZ-3847
> URL: https://issues.apache.org/jira/browse/OFBIZ-3847
> Project: OFBiz
> Issue Type: Bug
> Components: framework
>Affects Versions: Release Branch 10.04
>Reporter: Martin Kreidenweis
> Attachments: GenericDelegator.java.diff
>
>
> The conditions don't work when updating (not creating) entities using the
> Delegator.storeAll() method. E.g. the following condition does not work:
> {code}
>
> value="N"/>
> value-attr="productInstance"/>
>
> {code}
> The indexProductKeywords service is called anyway when the product is updated
> and the autoCreateKeywords was "N" and stays "N". It works correctly for
> newly created products.
> The problem is in the method GenericDelegator.storeAll(), where unchanged
> field values are not passed down to the store() method. The store method
> calls the ECA engine, which does not receive the unchanged values at all and
> thus cannot evaluate the EECA conditions correctly.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (OFBIZ-3850) Exception on Add Credit Card page from Quick Checkout option
[ https://issues.apache.org/jira/browse/OFBIZ-3850?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12888938#action_12888938 ] Scott Gray commented on OFBIZ-3850: --- Hi Mukesh Please provide some steps to reproduce the issue Thanks Scott > Exception on Add Credit Card page from Quick Checkout option > - > > Key: OFBIZ-3850 > URL: https://issues.apache.org/jira/browse/OFBIZ-3850 > Project: OFBiz > Issue Type: Bug > Components: specialpurpose/ecommerce >Affects Versions: SVN trunk >Reporter: Mukesh Marathe > Attachments: OFBIZ-3850.patch > > > While creating the credit card for party by selecting Quick Finalize Order > option, it throwing an exception need to add some null checks. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (OFBIZ-3859) Convert parameters before using entity-engine
[ https://issues.apache.org/jira/browse/OFBIZ-3859?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12888932#action_12888932 ] Scott Gray commented on OFBIZ-3859: --- After looking at createCalendarExceptionDay, I see two problems: 1. The service definition types exceptionCapacity as a BigDecimal but the entity definition types it as a double, hence the mismatch 2. set-nonpk-fields ultimately just calls GenericEntity.set(String, Object), once upon a time this method would print (not throw) an exception if a mismatch occurred but would then convert it to the correct type but this doesn't appear to happen anymore. I would check the svn history and reinstate whatever logic was in place before the conversion framework took over. > Convert parameters before using entity-engine > - > > Key: OFBIZ-3859 > URL: https://issues.apache.org/jira/browse/OFBIZ-3859 > Project: OFBiz > Issue Type: Bug > Components: manufacturing >Affects Versions: SVN trunk >Reporter: matthieu bollot > Attachments: ofbiz-3859.patch > > > Now, values need to be converted before using entity-engine. I'll provide a > patch corresponding to this selenium test : > http://selenium.neogia.org/ofbiz/tests/ManufacturingCreateCalendarAndWeek.html -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (OFBIZ-3860) ofbizUrl not transform "&" correctly.
[ https://issues.apache.org/jira/browse/OFBIZ-3860?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Scott Gray closed OFBIZ-3860. - Resolution: Fixed Agreed, theres nothing worse than a bad fix. Anyways thanks Deepak, committed in: trunk - r963915 10.04 - r963917 > ofbizUrl not transform "&" correctly. > - > > Key: OFBIZ-3860 > URL: https://issues.apache.org/jira/browse/OFBIZ-3860 > Project: OFBiz > Issue Type: Bug > Components: order >Affects Versions: Release Branch 10.04, SVN trunk >Reporter: Deepak Dixit >Assignee: Scott Gray >Priority: Minor > Fix For: Release Branch 10.04, SVN trunk > > Attachments: OFBIZ-3860.patch, OFBIZ-3860.patch > > -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Assigned: (OFBIZ-3860) ofbizUrl not transform "&" correctly.
[ https://issues.apache.org/jira/browse/OFBIZ-3860?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Scott Gray reassigned OFBIZ-3860: - Assignee: Scott Gray > ofbizUrl not transform "&" correctly. > - > > Key: OFBIZ-3860 > URL: https://issues.apache.org/jira/browse/OFBIZ-3860 > Project: OFBiz > Issue Type: Bug > Components: order >Affects Versions: Release Branch 10.04, SVN trunk >Reporter: Deepak Dixit >Assignee: Scott Gray >Priority: Minor > Fix For: Release Branch 10.04, SVN trunk > > Attachments: OFBIZ-3860.patch, OFBIZ-3860.patch > > -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (OFBIZ-3860) ofbizUrl not transform "&" correctly.
[ https://issues.apache.org/jira/browse/OFBIZ-3860?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12888126#action_12888126 ] Scott Gray commented on OFBIZ-3860: --- Hans, here's the discussion from the user list if you want to understand the issue a little better: http://ofbiz.markmail.org/thread/7jo2k44nfbvcvhmy > ofbizUrl not transform "&" correctly. > - > > Key: OFBIZ-3860 > URL: https://issues.apache.org/jira/browse/OFBIZ-3860 > Project: OFBiz > Issue Type: Bug > Components: order >Affects Versions: Release Branch 10.04, SVN trunk >Reporter: Deepak Dixit >Assignee: Scott Gray >Priority: Minor > Fix For: Release Branch 10.04, SVN trunk > > Attachments: OFBIZ-3860.patch, OFBIZ-3860.patch > > -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (OFBIZ-3852) This is the main Jira for doing business plan jusing the Datamodel Book.
[ https://issues.apache.org/jira/browse/OFBIZ-3852?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12886973#action_12886973 ] Scott Gray commented on OFBIZ-3852: --- For a branch you first need people to collaborate with (and preferably a committer onboard) or it is pointless to even create one. Please don't go and start creating a ton of jira issues until you have put forward a proposal and gained some acceptance of it within the community. > This is the main Jira for doing business plan jusing the Datamodel Book. > -- > > Key: OFBIZ-3852 > URL: https://issues.apache.org/jira/browse/OFBIZ-3852 > Project: OFBiz > Issue Type: Improvement > Components: ALL APPLICATIONS >Affects Versions: SVN trunk >Reporter: BJ Freeman > Original Estimate: 6048h > Remaining Estimate: 6048h > > I have many subtask under this one related to > the goal is to allow a business to use the data-model to create a business > plan and have Ofbiz monitory it giving alarms with something is done outside > the business plan. > Hopefully i have broken down the subtask so they can be emplimented > individually and any upgrade paths are accomplished. > Along the way will add support for the model were there is non now. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (OFBIZ-3373) Adding menu merging feature
[ https://issues.apache.org/jira/browse/OFBIZ-3373?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Scott Gray updated OFBIZ-3373: -- Attachment: injections.patch Here's a somewhat hackish but working patch. Not intended for commit but useful for trying the injections stuff. > Adding menu merging feature > --- > > Key: OFBIZ-3373 > URL: https://issues.apache.org/jira/browse/OFBIZ-3373 > Project: OFBiz > Issue Type: Wish > Components: framework >Reporter: Bruno Busco >Priority: Minor > Attachments: googlebase-inject.patch, injections.patch, > injections.patch, links.jpg, partymenu.JPG > > > Hi devs, > while discussing in the ML about modules and framework separation I thought > to this new feature that I would like to discuss here with you. > We have now the possibility to extend a menu from one other. This is great in > order to have an high level of code reuse and great consistency all over > OFBiz. > I was thinking to a sort of "merges-to" property for the menu widget. > This would allow a new module to specify an already exixting menu name (in > the framework core or in a lower level module) that should be somewhat > changed by the actual menu. > For instance, in the attached image partymenu.jpg there is a a tipical use of > this feature: > in the party module there are lot of links that co to order application, > account etc. Those menu link could be used defining a simple menu (say it > partylinks_menu) in the party application that contains only party or > framework related links (i.e. profile); additional components like order or > accounting could define more menus that merges-to the partylinks_manu so that > when the menu is rendered IN THE PARTY APPLICATION the new menu items added > in the order and accounting applications are also rendered. > This would allow us to dramatically reduce the component dependence and help > us to have the framework-only distribution. > To eventually implement this I think there should be an entity that defines > such mergin menus and the menu rendered should lookup the entity to check if > one or more merges to the actually rendering menu is defined. > I would appreciate to hear from you if this idea can help. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (OFBIZ-3848) Add support for derived UOM conversion factors
Add support for derived UOM conversion factors -- Key: OFBIZ-3848 URL: https://issues.apache.org/jira/browse/OFBIZ-3848 Project: OFBiz Issue Type: Improvement Components: framework Reporter: Scott Gray Assignee: Scott Gray Priority: Minor Say we have 3 UOMs A, B and C, and we have UomConversion records for: A -> B B -> C currently the convertUom service in unable to directly convert from A -> C I propose we add support for automatically deriving conversion factors by walking the available conversion paths until an appropriate path is found. Comments are welcome, this is mainly just a TODO reminder for myself though. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (OFBIZ-3830) jQuery Calendar Implementation
[ https://issues.apache.org/jira/browse/OFBIZ-3830?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12884615#action_12884615 ] Scott Gray commented on OFBIZ-3830: --- Sounds great, I knew you were working on a branch but assumed you were just converting the code and not aware of the problem. Thanks! > jQuery Calendar Implementation > -- > > Key: OFBIZ-3830 > URL: https://issues.apache.org/jira/browse/OFBIZ-3830 > Project: OFBiz > Issue Type: Sub-task > Components: ALL APPLICATIONS >Affects Versions: jQuery >Reporter: Sascha Rodekamp >Assignee: Erwan de FERRIERES > Fix For: jQuery > > Attachments: cal.gif, images.zip, jquery.zip, > OFBIZ-3814_calendar_fix.patch, OFBIZ-3830_calendar_update.patch, > OFBIZ-3830_CalendarLanguageFix.patch > > > Hey, good morning, > here a few changes from the WE. I try to implement a new jQuery calendar. > It's not totally done, yet. I didn't touch the FTLs were the calenar is > called. But all calendar calls over the Macro renderer work. > I used the jQuery User Interface [http://jqueryui.com/] Calendar (so no > licence problems) furthermore i added a plugin for the data pickin (GLP/MIT > Licence too :-) [http://trentrichardson.com/examples/timepicker/]). The > jQuery UI have some interessting widgets!! > For commit please copy the folder from the jquery.zip in the images/jquery > folder. You should have images/jquery/ui and images/jquery/plugins. > Furthermore there are themes for the jQuery UI widgets. Which i have copied > in the Theme CSS of ofbiz. The images.zip contains images which are needed by > the jQuery widegts, i placed them in the image folder of each ofbiz Theme. > I think we have to decide if this is the right way to deal with th jQuery UI. > Cheers, hava good day > Sascha -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (OFBIZ-3830) jQuery Calendar Implementation
[ https://issues.apache.org/jira/browse/OFBIZ-3830?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12884610#action_12884610 ] Scott Gray commented on OFBIZ-3830: --- Hi Sascha Direct from my browser after visiting the demo trunk: Request URL:https://demo-trunk.ofbiz.apache.org/images/calendarDateSelect/locale/en_US.js Request Method:GET Status Code:404 Not Found Request Headers Accept:*/* Referer:https://demo-trunk.ofbiz.apache.org/webtools/control/main User-Agent:Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10_6_4; en-us) AppleWebKit/533.16 (KHTML, like Gecko) Version/5.0 Safari/533.16 Response Headers Connection:Keep-Alive Content-Length:1078 Content-Type:text/html;charset=utf-8 Date:Fri, 02 Jul 2010 08:43:37 GMT Keep-Alive:timeout=15, max=97 > jQuery Calendar Implementation > -- > > Key: OFBIZ-3830 > URL: https://issues.apache.org/jira/browse/OFBIZ-3830 > Project: OFBiz > Issue Type: Sub-task > Components: ALL APPLICATIONS >Affects Versions: jQuery >Reporter: Sascha Rodekamp >Assignee: Erwan de FERRIERES > Fix For: jQuery > > Attachments: cal.gif, images.zip, jquery.zip, > OFBIZ-3814_calendar_fix.patch, OFBIZ-3830_calendar_update.patch, > OFBIZ-3830_CalendarLanguageFix.patch > > > Hey, good morning, > here a few changes from the WE. I try to implement a new jQuery calendar. > It's not totally done, yet. I didn't touch the FTLs were the calenar is > called. But all calendar calls over the Macro renderer work. > I used the jQuery User Interface [http://jqueryui.com/] Calendar (so no > licence problems) furthermore i added a plugin for the data pickin (GLP/MIT > Licence too :-) [http://trentrichardson.com/examples/timepicker/]). The > jQuery UI have some interessting widgets!! > For commit please copy the folder from the jquery.zip in the images/jquery > folder. You should have images/jquery/ui and images/jquery/plugins. > Furthermore there are themes for the jQuery UI widgets. Which i have copied > in the Theme CSS of ofbiz. The images.zip contains images which are needed by > the jQuery widegts, i placed them in the image folder of each ofbiz Theme. > I think we have to decide if this is the right way to deal with th jQuery UI. > Cheers, hava good day > Sascha -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (OFBIZ-3647) Create dataResource from content
[ https://issues.apache.org/jira/browse/OFBIZ-3647?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12881617#action_12881617 ] Scott Gray commented on OFBIZ-3647: --- Hi Erwan, I'm sorry I should have unassigned myself from it, I originally took it on because I was working on content related stuff at the time. I haven't had a chance to review the latest patch, if you want to take it on then by all means please do so. Thanks Scott > Create dataResource from content > > > Key: OFBIZ-3647 > URL: https://issues.apache.org/jira/browse/OFBIZ-3647 > Project: OFBiz > Issue Type: Improvement > Components: content >Affects Versions: SVN trunk >Reporter: Nicolas Malin >Assignee: Scott Gray >Priority: Minor > Attachments: content.patch, OFBIZ-3647.patch > > > When you create a content, you need create a data resource and return to > content for create association. > If a content don't have a dataResource, I change buton : GoToDataResource by > Create a DataResource. When this lastest is created, she automaticly > associate to the content and retour to EditContent screen -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (OFBIZ-3828) Adding de UI Labels for Party
[ https://issues.apache.org/jira/browse/OFBIZ-3828?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12880738#action_12880738 ] Scott Gray commented on OFBIZ-3828: --- Jacques, I thought we were okay to back-port translations? > Adding de UI Labels for Party > - > > Key: OFBIZ-3828 > URL: https://issues.apache.org/jira/browse/OFBIZ-3828 > Project: OFBiz > Issue Type: Improvement > Components: party >Affects Versions: Release Branch 09.04, Release 09.04 > Environment: irrelevant. XML Configuration >Reporter: Carsten Schinzer >Priority: Minor > Fix For: Release Branch 09.04, Release 09.04 > > Original Estimate: 2h > Remaining Estimate: 2h > > Ca. 85 UI Lables were missing the German translation. > Iäve added them here -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (OFBIZ-3373) Adding menu merging feature
[ https://issues.apache.org/jira/browse/OFBIZ-3373?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12880620#action_12880620 ] Scott Gray commented on OFBIZ-3373: --- There are two problems: # There is a typo in the googlebase ofbiz-component file, three slashes instead of two for the google base controller location # Adam made a change to the way URLs are returned from a call to ConfigXMLReader.getControllerConfigUrl(...) in r948439 which means I can no longer use the absolute file path as the key for retrieving injections. I haven't figured out a way around it yet and won't have the time to look at it again for a while. > Adding menu merging feature > --- > > Key: OFBIZ-3373 > URL: https://issues.apache.org/jira/browse/OFBIZ-3373 > Project: OFBiz > Issue Type: Wish > Components: framework >Reporter: Bruno Busco >Priority: Minor > Attachments: googlebase-inject.patch, injections.patch, links.jpg, > partymenu.JPG > > > Hi devs, > while discussing in the ML about modules and framework separation I thought > to this new feature that I would like to discuss here with you. > We have now the possibility to extend a menu from one other. This is great in > order to have an high level of code reuse and great consistency all over > OFBiz. > I was thinking to a sort of "merges-to" property for the menu widget. > This would allow a new module to specify an already exixting menu name (in > the framework core or in a lower level module) that should be somewhat > changed by the actual menu. > For instance, in the attached image partymenu.jpg there is a a tipical use of > this feature: > in the party module there are lot of links that co to order application, > account etc. Those menu link could be used defining a simple menu (say it > partylinks_menu) in the party application that contains only party or > framework related links (i.e. profile); additional components like order or > accounting could define more menus that merges-to the partylinks_manu so that > when the menu is rendered IN THE PARTY APPLICATION the new menu items added > in the order and accounting applications are also rendered. > This would allow us to dramatically reduce the component dependence and help > us to have the framework-only distribution. > To eventually implement this I think there should be an entity that defines > such mergin menus and the menu rendered should lookup the entity to check if > one or more merges to the actually rendering menu is defined. > I would appreciate to hear from you if this idea can help. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (OFBIZ-3373) Adding menu merging feature
[ https://issues.apache.org/jira/browse/OFBIZ-3373?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12880571#action_12880571 ] Scott Gray commented on OFBIZ-3373: --- I'll try and find some time today to at least get it working again. That won't make it commit ready though, the roughness I originally mentioned will still be there. > Adding menu merging feature > --- > > Key: OFBIZ-3373 > URL: https://issues.apache.org/jira/browse/OFBIZ-3373 > Project: OFBiz > Issue Type: Wish > Components: framework >Reporter: Bruno Busco >Priority: Minor > Attachments: googlebase-inject.patch, injections.patch, links.jpg, > partymenu.JPG > > > Hi devs, > while discussing in the ML about modules and framework separation I thought > to this new feature that I would like to discuss here with you. > We have now the possibility to extend a menu from one other. This is great in > order to have an high level of code reuse and great consistency all over > OFBiz. > I was thinking to a sort of "merges-to" property for the menu widget. > This would allow a new module to specify an already exixting menu name (in > the framework core or in a lower level module) that should be somewhat > changed by the actual menu. > For instance, in the attached image partymenu.jpg there is a a tipical use of > this feature: > in the party module there are lot of links that co to order application, > account etc. Those menu link could be used defining a simple menu (say it > partylinks_menu) in the party application that contains only party or > framework related links (i.e. profile); additional components like order or > accounting could define more menus that merges-to the partylinks_manu so that > when the menu is rendered IN THE PARTY APPLICATION the new menu items added > in the order and accounting applications are also rendered. > This would allow us to dramatically reduce the component dependence and help > us to have the framework-only distribution. > To eventually implement this I think there should be an entity that defines > such mergin menus and the menu rendered should lookup the entity to check if > one or more merges to the actually rendering menu is defined. > I would appreciate to hear from you if this idea can help. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (OFBIZ-3563) Creating a category with an ID (manually or automatically) that matches an existing productID will show the unrelated product when enter into the category on the 'Browse
[ https://issues.apache.org/jira/browse/OFBIZ-3563?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12878382#action_12878382 ] Scott Gray commented on OFBIZ-3563: --- product ids are always prepended with a p_ when generated by the servlet so I'm not sure why the it is treating the last path element as a possible product id when p_ is missing from it. We should be able to fix this easily enough by always treating the last path element as a category id if it isn't prepended with p_ (let's hope no one ever creates a category starting with p_). If p_ is missing and the id doesn't resolve to a category then we could allow it through as a product id. An alternative solution could be to have two mount points for the servlet: products for products and categories for categories, that way there will never be any ambiguity. Examples: http://domain/ecommerce/products/productId http://domain/ecommerce/categories/categoryId For backwards SEO compatibility we could redirect any /products/categoryId urls to the new categories url. > Creating a category with an ID (manually or automatically) that matches an > existing productID will show the unrelated product when enter into the > category on the 'Browse category' of the Ecommerce application. > -- > > Key: OFBIZ-3563 > URL: https://issues.apache.org/jira/browse/OFBIZ-3563 > Project: OFBiz > Issue Type: Bug > Components: specialpurpose/ecommerce >Affects Versions: SVN trunk > Environment: Ubuntu 8.04 >Reporter: Jonatan Soto > > Steps to reproduce it: > - Create a new category and set the ID manually that corresponds with an > existing productID. > - Go to the Ecommerce app and enter in the category has been created. > - The product with the same ID will be show but it isn't really related to > this category. > As Jacques noted on the ML, it could be related to an URL improvement (SEO) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (OFBIZ-3798) Add generic service to call xml-rpc request
[ https://issues.apache.org/jira/browse/OFBIZ-3798?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12876604#action_12876604 ] Scott Gray commented on OFBIZ-3798: --- It might not hurt to take a look at the existing XmlRpcClient class in OFBiz and see if it helps with https configuration. > Add generic service to call xml-rpc request > --- > > Key: OFBIZ-3798 > URL: https://issues.apache.org/jira/browse/OFBIZ-3798 > Project: OFBiz > Issue Type: New Feature > Components: framework >Affects Versions: SVN trunk >Reporter: Nicolas Malin >Priority: Minor > Fix For: SVN trunk > > Attachments: xml-rpc.diff, XmlRpcEngine.patch > > > I add a generic service to call xml-rpc server. The goal is to have a > technical interface to make calls directly from mini-lang. > The first patch it's my draft. I don't know where I do the service > definition. I add a servicedef in framework/webapp, I move service on > framework/common ? any suggest are welcom ;) > Nicolas -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (OFBIZ-3537) Not all sales invoice item types are showing in listInvoiceItems screen
[ https://issues.apache.org/jira/browse/OFBIZ-3537?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Scott Gray updated OFBIZ-3537: -- Attachment: InvoiceItemType.txt Willem, I don't know if it's of any use to you but I'm attaching a tree of all of the InvoiceItemTypes which may help you see that some types aren't missing, they are just inconsistently named. > Not all sales invoice item types are showing in listInvoiceItems screen > --- > > Key: OFBIZ-3537 > URL: https://issues.apache.org/jira/browse/OFBIZ-3537 > Project: OFBiz > Issue Type: Bug > Components: accounting >Affects Versions: SVN trunk >Reporter: Willem Janssen > Fix For: SVN trunk > > Attachments: InvoiceItemType.txt, invoiceitemtypes.diff > > > Hello, > In the listInvoiceItems screen, in the 'Invoice Item Type' dropdown item > types are missing. > In the GetInvoiceItemTypes.groovy file the query on the InvoiceItemType > entity does not look for item types with: > - invoiceItemTypeId = SINVOICE_HEAD_ADJ > - parenttypeId = SINVOICE_HEAD_ADJ > - invoiceItemTypeId = SINVOICE_ITM_ADJ > - parenttypeId = SINVOICE_ITM_ADJ > and the invoice item types that are missing answer the above parameters. > The patch adds these parameters to the groovy file. > This seems to be a solutions that's not finished yet, because the splitting > of item types between Purchase and Sales invoice item types looks > uncompleted. On the one hand there is a parentItemType PINVOICE_ADJ, but > there's no SINVOICE_ADJ. Same goes for PINV_PROD_ITEM and no SINV_PROD_ITEM. > And there's a SINVOICE_HEAD_ADJ, but no PINVOICE_HEAD_ADJ. > If somebody can tell me which invoiceitemtypes should be grouped in which > parenttypes I'd be happy to make a patch for that... -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (OFBIZ-3373) Adding menu merging feature
[ https://issues.apache.org/jira/browse/OFBIZ-3373?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12876024#action_12876024 ] Scott Gray commented on OFBIZ-3373: --- Bruno, Hmm that is strange, I was sure it was all working at the time and I doubt anything has changed in the framework that would have caused it to stop working. I really don't have time to look into it right now but I'm sure whatever the problem is it could be solved with a minimal amount of debugging. The controller injections are much simpler than than the menu injections. When constructed the controller just asks the component config class for any injections and then loads them in, that's really all there is to it. > Adding menu merging feature > --- > > Key: OFBIZ-3373 > URL: https://issues.apache.org/jira/browse/OFBIZ-3373 > Project: OFBiz > Issue Type: Wish > Components: framework >Reporter: Bruno Busco >Priority: Minor > Attachments: googlebase-inject.patch, injections.patch, links.jpg, > partymenu.JPG > > > Hi devs, > while discussing in the ML about modules and framework separation I thought > to this new feature that I would like to discuss here with you. > We have now the possibility to extend a menu from one other. This is great in > order to have an high level of code reuse and great consistency all over > OFBiz. > I was thinking to a sort of "merges-to" property for the menu widget. > This would allow a new module to specify an already exixting menu name (in > the framework core or in a lower level module) that should be somewhat > changed by the actual menu. > For instance, in the attached image partymenu.jpg there is a a tipical use of > this feature: > in the party module there are lot of links that co to order application, > account etc. Those menu link could be used defining a simple menu (say it > partylinks_menu) in the party application that contains only party or > framework related links (i.e. profile); additional components like order or > accounting could define more menus that merges-to the partylinks_manu so that > when the menu is rendered IN THE PARTY APPLICATION the new menu items added > in the order and accounting applications are also rendered. > This would allow us to dramatically reduce the component dependence and help > us to have the framework-only distribution. > To eventually implement this I think there should be an entity that defines > such mergin menus and the menu rendered should lookup the entity to check if > one or more merges to the actually rendering menu is defined. > I would appreciate to hear from you if this idea can help. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (OFBIZ-3373) Adding menu merging feature
[ https://issues.apache.org/jira/browse/OFBIZ-3373?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12876021#action_12876021 ] Scott Gray commented on OFBIZ-3373: --- Sorry, in hindsight I probably shouldn't have bothered with the last point, it really makes no difference to me how we come to an inject menu model. > Adding menu merging feature > --- > > Key: OFBIZ-3373 > URL: https://issues.apache.org/jira/browse/OFBIZ-3373 > Project: OFBiz > Issue Type: Wish > Components: framework >Reporter: Bruno Busco >Priority: Minor > Attachments: googlebase-inject.patch, injections.patch, links.jpg, > partymenu.JPG > > > Hi devs, > while discussing in the ML about modules and framework separation I thought > to this new feature that I would like to discuss here with you. > We have now the possibility to extend a menu from one other. This is great in > order to have an high level of code reuse and great consistency all over > OFBiz. > I was thinking to a sort of "merges-to" property for the menu widget. > This would allow a new module to specify an already exixting menu name (in > the framework core or in a lower level module) that should be somewhat > changed by the actual menu. > For instance, in the attached image partymenu.jpg there is a a tipical use of > this feature: > in the party module there are lot of links that co to order application, > account etc. Those menu link could be used defining a simple menu (say it > partylinks_menu) in the party application that contains only party or > framework related links (i.e. profile); additional components like order or > accounting could define more menus that merges-to the partylinks_manu so that > when the menu is rendered IN THE PARTY APPLICATION the new menu items added > in the order and accounting applications are also rendered. > This would allow us to dramatically reduce the component dependence and help > us to have the framework-only distribution. > To eventually implement this I think there should be an entity that defines > such mergin menus and the menu rendered should lookup the entity to check if > one or more merges to the actually rendering menu is defined. > I would appreciate to hear from you if this idea can help. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (OFBIZ-3373) Adding menu merging feature
[ https://issues.apache.org/jira/browse/OFBIZ-3373?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12876020#action_12876020 ] Scott Gray commented on OFBIZ-3373: --- A few points: - I'm little vague on how immutability works but keep in mind that the model is modified during construction only. - I wrote this patch before that discussion was had. - I actually couldn't care less about how the functionality is implemented, it is the functionality itself that is important to me. - This patch is just a draft of the functionality that I envisaged, people are free to do with it as they please. The only thing I ask is that any changes to the actual plug-in behavior be discussed thoroughly. - If the base model is never actually used because the factory always returns the injected version then to be honest I don't see what benefits are gained by not touching it directly. > Adding menu merging feature > --- > > Key: OFBIZ-3373 > URL: https://issues.apache.org/jira/browse/OFBIZ-3373 > Project: OFBiz > Issue Type: Wish > Components: framework >Reporter: Bruno Busco >Priority: Minor > Attachments: googlebase-inject.patch, injections.patch, links.jpg, > partymenu.JPG > > > Hi devs, > while discussing in the ML about modules and framework separation I thought > to this new feature that I would like to discuss here with you. > We have now the possibility to extend a menu from one other. This is great in > order to have an high level of code reuse and great consistency all over > OFBiz. > I was thinking to a sort of "merges-to" property for the menu widget. > This would allow a new module to specify an already exixting menu name (in > the framework core or in a lower level module) that should be somewhat > changed by the actual menu. > For instance, in the attached image partymenu.jpg there is a a tipical use of > this feature: > in the party module there are lot of links that co to order application, > account etc. Those menu link could be used defining a simple menu (say it > partylinks_menu) in the party application that contains only party or > framework related links (i.e. profile); additional components like order or > accounting could define more menus that merges-to the partylinks_manu so that > when the menu is rendered IN THE PARTY APPLICATION the new menu items added > in the order and accounting applications are also rendered. > This would allow us to dramatically reduce the component dependence and help > us to have the framework-only distribution. > To eventually implement this I think there should be an entity that defines > such mergin menus and the menu rendered should lookup the entity to check if > one or more merges to the actually rendering menu is defined. > I would appreciate to hear from you if this idea can help. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (OFBIZ-3373) Adding menu merging feature
[ https://issues.apache.org/jira/browse/OFBIZ-3373?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12876017#action_12876017 ] Scott Gray commented on OFBIZ-3373: --- Adrian, I'm not entirely sure what you're suggesting, or more specifically, how it differs from what's in my patch. The patch does modify the menu model at run-time but that is on purpose, the idea being that these external add-ons transparently become an intrinsic part of the model being extended. In this way, even if you do have a hot-deploy order manager, the plug-in will still work so long as your custom application is extending the order manager's controller and reports menu. Unbeknownst to the hot-deploy app those order manager artifacts are actually composites of the base functionality plus any plugged in functionality. I actually think it's kinda cool. > Adding menu merging feature > --- > > Key: OFBIZ-3373 > URL: https://issues.apache.org/jira/browse/OFBIZ-3373 > Project: OFBiz > Issue Type: Wish > Components: framework >Reporter: Bruno Busco >Priority: Minor > Attachments: googlebase-inject.patch, injections.patch, links.jpg, > partymenu.JPG > > > Hi devs, > while discussing in the ML about modules and framework separation I thought > to this new feature that I would like to discuss here with you. > We have now the possibility to extend a menu from one other. This is great in > order to have an high level of code reuse and great consistency all over > OFBiz. > I was thinking to a sort of "merges-to" property for the menu widget. > This would allow a new module to specify an already exixting menu name (in > the framework core or in a lower level module) that should be somewhat > changed by the actual menu. > For instance, in the attached image partymenu.jpg there is a a tipical use of > this feature: > in the party module there are lot of links that co to order application, > account etc. Those menu link could be used defining a simple menu (say it > partylinks_menu) in the party application that contains only party or > framework related links (i.e. profile); additional components like order or > accounting could define more menus that merges-to the partylinks_manu so that > when the menu is rendered IN THE PARTY APPLICATION the new menu items added > in the order and accounting applications are also rendered. > This would allow us to dramatically reduce the component dependence and help > us to have the framework-only distribution. > To eventually implement this I think there should be an entity that defines > such mergin menus and the menu rendered should lookup the entity to check if > one or more merges to the actually rendering menu is defined. > I would appreciate to hear from you if this idea can help. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (OFBIZ-3373) Adding menu merging feature
[ https://issues.apache.org/jira/browse/OFBIZ-3373?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12876014#action_12876014 ] Scott Gray commented on OFBIZ-3373: --- We've had the ability to extend applications via new components for a long time. This doesn't take away from that. What it does provide is the ability to create new features for existing applications without needing to modify those applications directly. Personally I think this is sorely needed and clearly evidenced by some of the special purpose components that really don't fit well as their own webapp, e.g. googlebase (catalog), the ebays (catalog, ordermgr), oagis (ordermgr, catalog, facility). Say I've created a new set of reports for the order manager application, should I have a completely separate webapp just to deliver a few reports? Should I completely override the order manager in hot-deploy just to add a few apps? What if I want to distribute these reports for other people to use in their own applications, should I bundle up my customized hot-deploy order manager app and distribute that? What if the people I'm distributing to already have their own customized order manager app because they needed to add a couple of screens somewhere else, should they try and merge the two? With this approach you just drop in your plug-in component and boom, there the reports are in the existing application. The idea here is that you pick and choose from the available plug-ins in order to enhance the applications distributed with OFBiz to meet your needs. > Adding menu merging feature > --- > > Key: OFBIZ-3373 > URL: https://issues.apache.org/jira/browse/OFBIZ-3373 > Project: OFBiz > Issue Type: Wish > Components: framework >Reporter: Bruno Busco >Priority: Minor > Attachments: googlebase-inject.patch, injections.patch, links.jpg, > partymenu.JPG > > > Hi devs, > while discussing in the ML about modules and framework separation I thought > to this new feature that I would like to discuss here with you. > We have now the possibility to extend a menu from one other. This is great in > order to have an high level of code reuse and great consistency all over > OFBiz. > I was thinking to a sort of "merges-to" property for the menu widget. > This would allow a new module to specify an already exixting menu name (in > the framework core or in a lower level module) that should be somewhat > changed by the actual menu. > For instance, in the attached image partymenu.jpg there is a a tipical use of > this feature: > in the party module there are lot of links that co to order application, > account etc. Those menu link could be used defining a simple menu (say it > partylinks_menu) in the party application that contains only party or > framework related links (i.e. profile); additional components like order or > accounting could define more menus that merges-to the partylinks_manu so that > when the menu is rendered IN THE PARTY APPLICATION the new menu items added > in the order and accounting applications are also rendered. > This would allow us to dramatically reduce the component dependence and help > us to have the framework-only distribution. > To eventually implement this I think there should be an entity that defines > such mergin menus and the menu rendered should lookup the entity to check if > one or more merges to the actually rendering menu is defined. > I would appreciate to hear from you if this idea can help. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (OFBIZ-3373) Adding menu merging feature
[ https://issues.apache.org/jira/browse/OFBIZ-3373?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Scott Gray updated OFBIZ-3373: -- Attachment: googlebase-inject.patch Sorry I should have thought to include some sort of example. This is the best I have, a conversion of the google base component from a separate webapp to a plugin for the category webapp. Note that it is only an example and not intended to be committed (in it's current form at least) The most relevant changes in the patch are to the ofbiz-component file and also the introduction of the GoogleBaseInjectionMenus.xml file > Adding menu merging feature > --- > > Key: OFBIZ-3373 > URL: https://issues.apache.org/jira/browse/OFBIZ-3373 > Project: OFBiz > Issue Type: Wish > Components: framework >Reporter: Bruno Busco >Priority: Minor > Attachments: googlebase-inject.patch, injections.patch, links.jpg, > partymenu.JPG > > > Hi devs, > while discussing in the ML about modules and framework separation I thought > to this new feature that I would like to discuss here with you. > We have now the possibility to extend a menu from one other. This is great in > order to have an high level of code reuse and great consistency all over > OFBiz. > I was thinking to a sort of "merges-to" property for the menu widget. > This would allow a new module to specify an already exixting menu name (in > the framework core or in a lower level module) that should be somewhat > changed by the actual menu. > For instance, in the attached image partymenu.jpg there is a a tipical use of > this feature: > in the party module there are lot of links that co to order application, > account etc. Those menu link could be used defining a simple menu (say it > partylinks_menu) in the party application that contains only party or > framework related links (i.e. profile); additional components like order or > accounting could define more menus that merges-to the partylinks_manu so that > when the menu is rendered IN THE PARTY APPLICATION the new menu items added > in the order and accounting applications are also rendered. > This would allow us to dramatically reduce the component dependence and help > us to have the framework-only distribution. > To eventually implement this I think there should be an entity that defines > such mergin menus and the menu rendered should lookup the entity to check if > one or more merges to the actually rendering menu is defined. > I would appreciate to hear from you if this idea can help. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (OFBIZ-3807) Application name localizations should not be defined in the CommonUiLabels framework file
[ https://issues.apache.org/jira/browse/OFBIZ-3807?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12876002#action_12876002 ] Scott Gray commented on OFBIZ-3807: --- I've attached my patch to OFBIZ-3373 The patch would solve the problem described in this issue, although you'd have to have an action within each injected menu that loads the resource bundles necessary for the menu item labels. > Application name localizations should not be defined in the CommonUiLabels > framework file > - > > Key: OFBIZ-3807 > URL: https://issues.apache.org/jira/browse/OFBIZ-3807 > Project: OFBiz > Issue Type: Improvement > Components: ALL COMPONENTS >Affects Versions: SVN trunk >Reporter: Bruno Busco >Priority: Minor > > There is a weak dependence from the framework to ALL applications because the > application name localization for the application menu is defined in > CommonUiLabels.xml file. > Whenever a user wants to add an application and localize its name, a new > entry in CommonUiLabels.xml framework file needs to be created. > How could we have the application menu use the application specific labels > file to get the localitazion? > The injectable menu we are speaking about could be the solution. > A simple main menu could be defined in the framework with only the Webtools > and Example menu entries. > Every application could inject its own application menu entries. > An application could also inject menu entries in several different menus so > that, for example all application's administrations could be placed in one > unique high level "admin" menu entry. > This could also allow a party/content binding component to inject menu > entries into otherwise stand-alone party and content applications. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (OFBIZ-3373) Adding menu merging feature
[ https://issues.apache.org/jira/browse/OFBIZ-3373?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Scott Gray updated OFBIZ-3373: -- Attachment: injections.patch Attached patch adds support for injecting controller entries and menu items. It works well but the code is pretty rough. Hopefully someone can clean it up a bit, otherwise I'll get back to it when I have time. > Adding menu merging feature > --- > > Key: OFBIZ-3373 > URL: https://issues.apache.org/jira/browse/OFBIZ-3373 > Project: OFBiz > Issue Type: Wish > Components: framework >Reporter: Bruno Busco >Priority: Minor > Attachments: injections.patch, links.jpg, partymenu.JPG > > > Hi devs, > while discussing in the ML about modules and framework separation I thought > to this new feature that I would like to discuss here with you. > We have now the possibility to extend a menu from one other. This is great in > order to have an high level of code reuse and great consistency all over > OFBiz. > I was thinking to a sort of "merges-to" property for the menu widget. > This would allow a new module to specify an already exixting menu name (in > the framework core or in a lower level module) that should be somewhat > changed by the actual menu. > For instance, in the attached image partymenu.jpg there is a a tipical use of > this feature: > in the party module there are lot of links that co to order application, > account etc. Those menu link could be used defining a simple menu (say it > partylinks_menu) in the party application that contains only party or > framework related links (i.e. profile); additional components like order or > accounting could define more menus that merges-to the partylinks_manu so that > when the menu is rendered IN THE PARTY APPLICATION the new menu items added > in the order and accounting applications are also rendered. > This would allow us to dramatically reduce the component dependence and help > us to have the framework-only distribution. > To eventually implement this I think there should be an entity that defines > such mergin menus and the menu rendered should lookup the entity to check if > one or more merges to the actually rendering menu is defined. > I would appreciate to hear from you if this idea can help. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (OFBIZ-3807) Application name localizations should not be defined in the CommonUiLabels framework file
[ https://issues.apache.org/jira/browse/OFBIZ-3807?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12875826#action_12875826 ] Scott Gray commented on OFBIZ-3807: --- I have a nowhere near commit quality patch for controller and menu injection that I'll try and upload this weekend. It all works just fine but the code isn't great, just the results of a fairly quick hack session. I won't have time to work on it again in the immediate future so my hope is that the community will realize the potential of these features and continue the work I've started. > Application name localizations should not be defined in the CommonUiLabels > framework file > - > > Key: OFBIZ-3807 > URL: https://issues.apache.org/jira/browse/OFBIZ-3807 > Project: OFBiz > Issue Type: Improvement > Components: ALL COMPONENTS >Affects Versions: SVN trunk >Reporter: Bruno Busco >Priority: Minor > > There is a weak dependence from the framework to ALL applications because the > application name localization for the application menu is defined in > CommonUiLabels.xml file. > Whenever a user wants to add an application and localize its name, a new > entry in CommonUiLabels.xml framework file needs to be created. > How could we have the application menu use the application specific labels > file to get the localitazion? > The injectable menu we are speaking about could be the solution. > A simple main menu could be defined in the framework with only the Webtools > and Example menu entries. > Every application could inject its own application menu entries. > An application could also inject menu entries in several different menus so > that, for example all application's administrations could be placed in one > unique high level "admin" menu entry. > This could also allow a party/content binding component to inject menu > entries into otherwise stand-alone party and content applications. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (OFBIZ-3557) Enforced sequence does not work with concurrent access
[ https://issues.apache.org/jira/browse/OFBIZ-3557?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12870166#action_12870166 ] Scott Gray commented on OFBIZ-3557: --- http://svn.ofbiz.org/viewcvs that's the viewvc link for the old repo About the lack of synchronization, shouldn't be possible to issue a lock on the row retrieved from PartyAcctgPreference so that no other transactions can read from it until the current one is committed? > Enforced sequence does not work with concurrent access > -- > > Key: OFBIZ-3557 > URL: https://issues.apache.org/jira/browse/OFBIZ-3557 > Project: OFBiz > Issue Type: Bug > Components: framework >Affects Versions: Release Branch 09.04, SVN trunk >Reporter: Wickersheimer Jeremy > Attachments: OFBIZ-3557-1.patch > > > There is a fundamental issue with enforced sequences (for orders, invoices, > etc ..) and concurrency. > For example if two users are creating an order at the same time one of them > will see the creation fail with a PK error. The problem is that the > "getNextXXXId" rely on the party accounting preference entity, but there is > absolutely no guarantee that the last number in the sequence gets updated > before another service can read it. > This is at best very annoying when used only internally but may be > unpractical for e-commerce sites. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (OFBIZ-3699) ServiceDispatcher.checkAuth modifies the context if the invocation service has a permissionServiceName
[
https://issues.apache.org/jira/browse/OFBIZ-3699?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12865635#action_12865635
]
Scott Gray commented on OFBIZ-3699:
---
I had a go at fixing this over the weekend but the unit tests fail because we
already have code that is passing invalid parameters to service calls. What I
would like to do is fix the bug before any more damage is done and just disable
the offending unit tests until they can be corrected.
Committing the fix will most likely expose new bugs in the regular code but
there isn't really much we can do to avoid that IMO.
> ServiceDispatcher.checkAuth modifies the context if the invocation service
> has a permissionServiceName
> --
>
> Key: OFBIZ-3699
> URL: https://issues.apache.org/jira/browse/OFBIZ-3699
> Project: OFBiz
> Issue Type: Bug
> Components: framework
>Affects Versions: SVN trunk
>Reporter: Bob Morley
> Fix For: SVN trunk
>
>
> Created as a result of thread:
> http://n4.nabble.com/Magically-converted-types-from-simpleTypeConvert-td1838891.html
> The follow code in the ServiceDispatcher ...
> if (UtilValidate.isNotEmpty(origService.permissionServiceName)) {
> ...
> if (hasPermission.booleanValue()) {
> context.putAll(permResp);
> context = origService.makeValid(context,
> ModelService.IN_PARAM);
> ... causes the incoming context to be modified both by adding values from the
> results of the permission service but also by converting any datatypes to
> match those in the service definition. This hides any invalid service
> invocations (from a data type pov) and if the permisionServiceName is
> removed, the code would start failing with the incorrect data types.
> Suggest is to change this to something like ...
> Map permRespContext = ServiceUtil.setServiceFields(dctx,
> serviceName, permResp);
> context.putAll(permRespContext);
> The concern is that by doing this there may be some services that were
> relying on the data type conversion (because they were invalid requests)
> which would start to fail. Appropriate impact analysis of services that
> define "permissionServiceName" and appropriate resolutions need to be
> included with this change.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (OFBIZ-3740) Support for order by nulls first/last
[ https://issues.apache.org/jira/browse/OFBIZ-3740?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Scott Gray updated OFBIZ-3740: -- Issue Type: New Feature (was: Bug) > Support for order by nulls first/last > - > > Key: OFBIZ-3740 > URL: https://issues.apache.org/jira/browse/OFBIZ-3740 > Project: OFBiz > Issue Type: New Feature > Components: framework >Affects Versions: SVN trunk >Reporter: Bob Morley >Priority: Minor > Fix For: SVN trunk > > Attachments: OFBIZ-3740_SupportOrderByNulls.patch > > > This patch provides the fundamentals to resolve an issue where the sorting of > null values were inconsistent (sometimes sorting first and other times > sorting last). Specifically, this patch allows one to create an order-by > clause via any of the order-by elements of "-myField NULLS LAST" where this > text parses out the - (as descending) and the "nulls last". > Since not all databases support the "nulls" argument on an order by clause > (it was introduced as part of the OLAP support specification) , our > entity-engine.xml file allows each data source to indicate if it has this > support. If the support does not exist and nulls first/last is specified, > the sql that is generated uses native sql to simulate the nulls first/last > intent. At this time, the derby, postgres, and oracle databases are marked > to use the nulls first grammar. > Right now, if you do not specify "NULLS XXX" in the field-name for the > order-by it makes no change whatsever (naturally this assumption could be > changed to have a default). > It should be noted, that my intent here was ultimately to "properly" model > the order by into something whose xml representation could look something > like ... > -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (OFBIZ-3741) headerHead.ftl will never show the theme ico
[ https://issues.apache.org/jira/browse/OFBIZ-3741?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Scott Gray closed OFBIZ-3741. - Resolution: Fixed Thanks BJ, your patch has been applied in the following revisions: trunk - 942485 10.04 - 942486 09.04 - 942487 > headerHead.ftl will never show the theme ico > > > Key: OFBIZ-3741 > URL: https://issues.apache.org/jira/browse/OFBIZ-3741 > Project: OFBiz > Issue Type: Bug > Components: specialpurpose/ecommerce >Affects Versions: Release Branch 09.04, Release Branch 10.04, SVN trunk >Reporter: BJ Freeman >Assignee: Scott Gray >Priority: Minor > Fix For: Release Branch 09.04, Release Branch 10.04, SVN trunk > > Attachments: OFBIZ-3741-headerHead.ftl.patch > > > <#if layoutSettings.shortcutIcon?has_content> > <#assign shortcutIcon = layoutSettings.shortcutIcon/> > <#elseif layoutSettings.VT_SHORTCUT_ICON?has_content> > <#assign shortcutIcon = layoutSettings.VT_SHORTCUT_ICON.get(0)/> > > > since the layoutSettings.shortcutIcon (ofbiz.) is always present , > layoutSettings.VT_SHORTCUT_ICON will never be selected. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Assigned: (OFBIZ-3741) headerHead.ftl will never show the theme ico
[ https://issues.apache.org/jira/browse/OFBIZ-3741?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Scott Gray reassigned OFBIZ-3741: - Assignee: Scott Gray > headerHead.ftl will never show the theme ico > > > Key: OFBIZ-3741 > URL: https://issues.apache.org/jira/browse/OFBIZ-3741 > Project: OFBiz > Issue Type: Bug > Components: specialpurpose/ecommerce >Affects Versions: Release Branch 09.04, Release Branch 10.04, SVN trunk >Reporter: BJ Freeman >Assignee: Scott Gray >Priority: Minor > Fix For: Release Branch 09.04, Release Branch 10.04, SVN trunk > > Attachments: OFBIZ-3741-headerHead.ftl.patch > > > <#if layoutSettings.shortcutIcon?has_content> > <#assign shortcutIcon = layoutSettings.shortcutIcon/> > <#elseif layoutSettings.VT_SHORTCUT_ICON?has_content> > <#assign shortcutIcon = layoutSettings.VT_SHORTCUT_ICON.get(0)/> > > > since the layoutSettings.shortcutIcon (ofbiz.) is always present , > layoutSettings.VT_SHORTCUT_ICON will never be selected. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (OFBIZ-3742) Relation between ProductFeature and Uom-table missing
[ https://issues.apache.org/jira/browse/OFBIZ-3742?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Scott Gray closed OFBIZ-3742. - Resolution: Fixed Thanks Mirko, committed in r942363 > Relation between ProductFeature and Uom-table missing > - > > Key: OFBIZ-3742 > URL: https://issues.apache.org/jira/browse/OFBIZ-3742 > Project: OFBiz > Issue Type: Bug > Components: product >Affects Versions: SVN trunk >Reporter: Mirko Vogelsmeier >Assignee: Scott Gray >Priority: Minor > Fix For: SVN trunk > > Attachments: product-entitymodel.patch > > > A relation between ProductFeature and Uom (measurements) is missing -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Assigned: (OFBIZ-3742) Relation between ProductFeature and Uom-table missing
[ https://issues.apache.org/jira/browse/OFBIZ-3742?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Scott Gray reassigned OFBIZ-3742: - Assignee: Scott Gray > Relation between ProductFeature and Uom-table missing > - > > Key: OFBIZ-3742 > URL: https://issues.apache.org/jira/browse/OFBIZ-3742 > Project: OFBiz > Issue Type: Bug > Components: product >Affects Versions: SVN trunk >Reporter: Mirko Vogelsmeier >Assignee: Scott Gray >Priority: Minor > Fix For: SVN trunk > > Attachments: product-entitymodel.patch > > > A relation between ProductFeature and Uom (measurements) is missing -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (OFBIZ-3748) Remove test specific code in the GenericDelegator
[ https://issues.apache.org/jira/browse/OFBIZ-3748?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12863559#action_12863559 ] Scott Gray commented on OFBIZ-3748: --- Is it correct to have two separate Factory implementations? I thought it was the job of the factory to decide which delegator implementation to provide? About the "base delegator name", the question you aren't asking yourself is why was the delegator being cloned in the first place? I could have (and originally did) just turned on the test mode in the base delegator. Here's the original jira for reference: https://issues.apache.org/jira/browse/OFBIZ-2259 Although I would argue that it's impossible to run multiple test suites in parallel on the same database. I like the approach you've taken, but let's be clear, all we're really achieving here is a little cleaner code by moving some methods up one level. We're still intruding on the GenericDelegator implementation by forcing it to notify us of any changes. > Remove test specific code in the GenericDelegator > - > > Key: OFBIZ-3748 > URL: https://issues.apache.org/jira/browse/OFBIZ-3748 > Project: OFBiz > Issue Type: Bug > Components: framework >Affects Versions: SVN trunk >Reporter: Bob Morley > Attachments: OFBIZ-3748_TestGenericDelegator.patch > > > Adam -- This is the results from our conversation on consistent rolling back > of unit testers. We talked about moving the logic that is in the > GenericDelegator that is specific to testing into a sub-class. This patch is > NOT meant to be merged at this time, I wanted to put it up for review before > I continue down this path ... > Here are the key pieces: > - TestGenericDelegator - test version of a generic delegator that contains > the ability to record the list of database operations and then > programmatically roll them back in reverse order. This was from existing > code in GenericDelegator. > - TestDelegatorFactoryImpl - a new service implementation of DelegatoryFactor > that will construct instances of TestGenericDelegator. > Things to consider: > - Should rollback be on the Delegator interface? I sort of field it should > not be there; but I left it there for now with GenericDelegator reporting an > error if it is called. > - Since there are two implementations of the DelegatorFactory there needs to > be a way to determine which one to use; the way I have done this in the past > is through configuration. Usually something like ... > service.org.ofbiz.entity.DelegatorFactory=org.ofbiz.entity.DelegatorFactoryImpl > that could (for Ofbiz) be placed in the start.properties or test.properties > file. However, looking at the factory unit tester it looks like each factory > should be able to determine if it is applicable based on the incoming > parameters. As a result (until more discussion) I have made a choice based > on the delegator name -- I know this is clearly NOT the go forward method. > But would like some suggestions here ... was considering a new attribute on > the entityengine.xml delegator definition, but there should be some mechanism > to be able to provide control over which implementation is used I would think > ... > - I got an inkling that "base delegator name" may not be required anymore. > This is because I no longer create the standard delegator and then "clone" to > a test version. I simply instantiate the proper version right up front ... > Moreover, I let the delegator / dispatcher names be as they are (not adding a > random alpha-numeric suffix). Not sure about this, did not research further. > Go forward plan -- > - If there are agreement on these changes and a resolution for things to > consider point #2 above, I would then re-code my standalone rollback base > class for unit tests to leverage this functionality. This would ensure we > consistently rollback regardless of executing the test directly or through > the test infrastructure. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Reopened: (OFBIZ-3702) provide better user help
[ https://issues.apache.org/jira/browse/OFBIZ-3702?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Scott Gray reopened OFBIZ-3702: --- http://markmail.org/message/xpbtj6oxnnwaqplv > provide better user help > > > Key: OFBIZ-3702 > URL: https://issues.apache.org/jira/browse/OFBIZ-3702 > Project: OFBiz > Issue Type: Improvement >Affects Versions: Release Candidate Branch 10.04, SVN trunk >Reporter: chris snow >Assignee: Jacques Le Roux > Fix For: SVN trunk > > Attachments: entity_field_tooltip_screenshot.png, > fieldLabelTooltip.png, fieldLabelTooltip2.png, > fieldLabelTooltip2__DO_NOT_COMMIT.patch, > fieldLabelTooltip_DO_NOT_COMMIT.patch, fieldTooltipHelp3.patch, help.png, > product_entitymodel.patch, tooltip_help_DO_NOT_COMMIT.patch > > > Please see http://n4.nabble.com/Providing-users-with-help-td1840416.html -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (OFBIZ-3702) provide better user help
[ https://issues.apache.org/jira/browse/OFBIZ-3702?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12859052#action_12859052 ] Scott Gray commented on OFBIZ-3702: --- Hi Chris, sorry by user I meant developer-user rather than end user. As far as I can tell there is no way for the developer to switch this off and the only way to change the text displayed is by modifying the entity definition. > provide better user help > > > Key: OFBIZ-3702 > URL: https://issues.apache.org/jira/browse/OFBIZ-3702 > Project: OFBiz > Issue Type: Improvement >Affects Versions: Release Candidate Branch 10.04, SVN trunk >Reporter: chris snow > Attachments: entity_field_tooltip_screenshot.png, help.png, > product_entitymodel.patch, tooltip_help_DO_NOT_COMMIT.patch > > > Please see http://n4.nabble.com/Providing-users-with-help-td1840416.html -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (OFBIZ-3670) TestCase base classes providing ability to execute unit tests in Eclipse in "standalone" mode
[ https://issues.apache.org/jira/browse/OFBIZ-3670?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12859037#action_12859037 ] Scott Gray commented on OFBIZ-3670: --- I've tried this already :-) I extended the GenericDelegator but it didn't work because the ECAs would get in the way and result in changes being tracked in the wrong order. You are more than welcome to give it a go though, I didn't spend too much time on it and I'm sure there is a solution in there somewhere. As to how the existing system works, there isn't actually that much caching of the delegator or retrieving it by name, mostly just in the service dispatcher, job manager and eca handler. Aside from the job manager the others work fine with the current approach because you control their instantiation and can supply the delegator. > TestCase base classes providing ability to execute unit tests in Eclipse in > "standalone" mode > - > > Key: OFBIZ-3670 > URL: https://issues.apache.org/jira/browse/OFBIZ-3670 > Project: OFBiz > Issue Type: Improvement > Components: framework >Affects Versions: SVN trunk >Reporter: Bob Morley >Assignee: Scott Gray > Fix For: SVN trunk > > Attachments: OFBIZ-3670_StandaloneTestEnhancement.patch > > > This patch provides the framework that allows junit unit tests to be executed > directly in Eclipse (without having to invoke Start directly). It total it > contains: > - BaseTestCase - very top of the TestCase stack containing ofbiz specific > assertions > - StandaloneTestCase - determines if application has executed "Start"; if not > it will execute a scaled down "Start unittest" that is used in Eclipse > - RollbackTestCase - extends standalone and provides a transaction w/ > auto-rollback > - TestRunContainer - provides ability to disable dispatcher attributes via > configuration (used for unittest-containers.xml) > - GeoWorkerTest - unittester that provides "full" coverage of GeoWorker; can > be executed from Eclipse or from command-line as it is plugged into standard > testdef framework. Creates its own entities with transaction start/rollback > so it can be re-executed. > Would appreciate if this can be a priority so I can provide additional test > cases to boost our code coverage that will utilize these features. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (OFBIZ-3719) Include DOCTYPE at the begining of CMS driven html page.
[ https://issues.apache.org/jira/browse/OFBIZ-3719?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12858832#action_12858832 ] Scott Gray commented on OFBIZ-3719: --- Oh sorry yeah it sounds fine, at least until we can come up with something better. > Include DOCTYPE at the begining of CMS driven html page. > > > Key: OFBIZ-3719 > URL: https://issues.apache.org/jira/browse/OFBIZ-3719 > Project: OFBiz > Issue Type: Improvement > Components: specialpurpose/cmssite >Affects Versions: SVN trunk >Reporter: Deepak Dixit >Priority: Minor > Fix For: SVN trunk > > Attachments: OFBIZ-3719.patch > > > Include DOCTYPE at the begining of html pages, that are render through cms. > Currently DOCTYPE is included in HtmlHead.ftl for cms. > By doing so the DOCT YPE is always included on the top of the page before > rendering single HTML statement. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (OFBIZ-3663) Re-executing the tests cause unit test failures
[ https://issues.apache.org/jira/browse/OFBIZ-3663?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Scott Gray closed OFBIZ-3663. - Resolution: Fixed Thanks for the report Bob, fixed in r935869. Thanks for not taking my word on the cause as well, I'm a bit annoyed at myself for assuming and then putting up with that bug for so long because I thought it was too complicated to fix. While testing that I realized that entity ECA services weren't being rolled back (they used to work) which was also causing subsequent runs to fail, fixed that in r935870. > Re-executing the tests cause unit test failures > --- > > Key: OFBIZ-3663 > URL: https://issues.apache.org/jira/browse/OFBIZ-3663 > Project: OFBiz > Issue Type: Bug > Components: accounting >Affects Versions: SVN trunk >Reporter: Bob Morley >Assignee: Scott Gray > Fix For: SVN trunk > > > After a successful unit test run (from completely empty derby database) I > attempted a re-execution of the tests after some programming changes. A > number of tests started to fail (I think 4) which I believe were in the > Accounting area (but I could be wrong on that). Test execution ideally > should cause no state change to the database, but at a minimum should not > fail if executed more than one time. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Assigned: (OFBIZ-3663) Re-executing the tests cause unit test failures
[ https://issues.apache.org/jira/browse/OFBIZ-3663?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Scott Gray reassigned OFBIZ-3663: - Assignee: Scott Gray > Re-executing the tests cause unit test failures > --- > > Key: OFBIZ-3663 > URL: https://issues.apache.org/jira/browse/OFBIZ-3663 > Project: OFBiz > Issue Type: Bug > Components: accounting >Affects Versions: SVN trunk >Reporter: Bob Morley >Assignee: Scott Gray > Fix For: SVN trunk > > > After a successful unit test run (from completely empty derby database) I > attempted a re-execution of the tests after some programming changes. A > number of tests started to fail (I think 4) which I believe were in the > Accounting area (but I could be wrong on that). Test execution ideally > should cause no state change to the database, but at a minimum should not > fail if executed more than one time. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (OFBIZ-3670) TestCase base classes providing ability to execute unit tests in Eclipse in "standalone" mode
[ https://issues.apache.org/jira/browse/OFBIZ-3670?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12858809#action_12858809 ] Scott Gray commented on OFBIZ-3670: --- For #1, transaction rollbacks only work for simple use cases. It is not uncommon for OFBiz services to run in their own transaction which would suspend your transaction and then resume it once it is done, this is the reason for the system we have in place today. I don't want solutions that only work some of the time when we have one already that works (almost) all of the time. I'm going to make some changes to your patch that incorporates what you are trying to do into the existing test tools, I'll post it here when I'm done and we can discuss it further. > TestCase base classes providing ability to execute unit tests in Eclipse in > "standalone" mode > - > > Key: OFBIZ-3670 > URL: https://issues.apache.org/jira/browse/OFBIZ-3670 > Project: OFBiz > Issue Type: Improvement > Components: framework >Affects Versions: SVN trunk >Reporter: Bob Morley >Assignee: Scott Gray > Fix For: SVN trunk > > Attachments: OFBIZ-3670_StandaloneTestEnhancement.patch > > > This patch provides the framework that allows junit unit tests to be executed > directly in Eclipse (without having to invoke Start directly). It total it > contains: > - BaseTestCase - very top of the TestCase stack containing ofbiz specific > assertions > - StandaloneTestCase - determines if application has executed "Start"; if not > it will execute a scaled down "Start unittest" that is used in Eclipse > - RollbackTestCase - extends standalone and provides a transaction w/ > auto-rollback > - TestRunContainer - provides ability to disable dispatcher attributes via > configuration (used for unittest-containers.xml) > - GeoWorkerTest - unittester that provides "full" coverage of GeoWorker; can > be executed from Eclipse or from command-line as it is plugged into standard > testdef framework. Creates its own entities with transaction start/rollback > so it can be re-executed. > Would appreciate if this can be a priority so I can provide additional test > cases to boost our code coverage that will utilize these features. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Assigned: (OFBIZ-3670) TestCase base classes providing ability to execute unit tests in Eclipse in "standalone" mode
[ https://issues.apache.org/jira/browse/OFBIZ-3670?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Scott Gray reassigned OFBIZ-3670: - Assignee: Scott Gray > TestCase base classes providing ability to execute unit tests in Eclipse in > "standalone" mode > - > > Key: OFBIZ-3670 > URL: https://issues.apache.org/jira/browse/OFBIZ-3670 > Project: OFBiz > Issue Type: Improvement > Components: framework >Affects Versions: SVN trunk >Reporter: Bob Morley >Assignee: Scott Gray > Fix For: SVN trunk > > Attachments: OFBIZ-3670_StandaloneTestEnhancement.patch > > > This patch provides the framework that allows junit unit tests to be executed > directly in Eclipse (without having to invoke Start directly). It total it > contains: > - BaseTestCase - very top of the TestCase stack containing ofbiz specific > assertions > - StandaloneTestCase - determines if application has executed "Start"; if not > it will execute a scaled down "Start unittest" that is used in Eclipse > - RollbackTestCase - extends standalone and provides a transaction w/ > auto-rollback > - TestRunContainer - provides ability to disable dispatcher attributes via > configuration (used for unittest-containers.xml) > - GeoWorkerTest - unittester that provides "full" coverage of GeoWorker; can > be executed from Eclipse or from command-line as it is plugged into standard > testdef framework. Creates its own entities with transaction start/rollback > so it can be re-executed. > Would appreciate if this can be a priority so I can provide additional test > cases to boost our code coverage that will utilize these features. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (OFBIZ-3702) provide better user help
[ https://issues.apache.org/jira/browse/OFBIZ-3702?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12858789#action_12858789 ] Scott Gray commented on OFBIZ-3702: --- You need to go back to multiple lines when building the macro call, string concatenation is avoided for a reason. What would a user do if they wanted to remove or already this help field? Not criticizing, just putting it out there as a question. > provide better user help > > > Key: OFBIZ-3702 > URL: https://issues.apache.org/jira/browse/OFBIZ-3702 > Project: OFBiz > Issue Type: Improvement >Affects Versions: Release Candidate Branch 10.04, SVN trunk >Reporter: chris snow > Attachments: entity_field_tooltip_screenshot.png, help.png, > product_entitymodel.patch, tooltip_help_DO_NOT_COMMIT.patch > > > Please see http://n4.nabble.com/Providing-users-with-help-td1840416.html -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (OFBIZ-3663) Re-executing the tests cause unit test failures
[ https://issues.apache.org/jira/browse/OFBIZ-3663?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12858711#action_12858711 ] Scott Gray commented on OFBIZ-3663: --- Turns out you're right, the first thing the EntitySaxReader does is to clone the delegator which turns off the rollback feature. I've got a fix for that which I'll get tested and committed soonish. > Re-executing the tests cause unit test failures > --- > > Key: OFBIZ-3663 > URL: https://issues.apache.org/jira/browse/OFBIZ-3663 > Project: OFBiz > Issue Type: Bug > Components: accounting >Affects Versions: SVN trunk >Reporter: Bob Morley > Fix For: SVN trunk > > > After a successful unit test run (from completely empty derby database) I > attempted a re-execution of the tests after some programming changes. A > number of tests started to fail (I think 4) which I believe were in the > Accounting area (but I could be wrong on that). Test execution ideally > should cause no state change to the database, but at a minimum should not > fail if executed more than one time. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (OFBIZ-3719) Include DOCTYPE at the begining of CMS driven html page.
[ https://issues.apache.org/jira/browse/OFBIZ-3719?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12858467#action_12858467 ] Scott Gray commented on OFBIZ-3719: --- Hi Deepak, I'm not sure I understand the benefit, what good is it to render the doctype here when so much more is required of an html document such as html, head and body tags? > Include DOCTYPE at the begining of CMS driven html page. > > > Key: OFBIZ-3719 > URL: https://issues.apache.org/jira/browse/OFBIZ-3719 > Project: OFBiz > Issue Type: Improvement > Components: specialpurpose/cmssite >Affects Versions: SVN trunk >Reporter: Deepak Dixit >Priority: Minor > Fix For: SVN trunk > > Attachments: OFBIZ-3719.patch > > > Include DOCTYPE at the begining of html pages, that are render through cms. > Currently DOCTYPE is included in HtmlHead.ftl for cms. > By doing so the DOCT YPE is always included on the top of the page before > rendering single HTML statement. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (OFBIZ-3715) Error in screen Accounting->Organization GL Settings->GL Account Defaults->Sales Invoice / Purchase Invoice (groovy)
[ https://issues.apache.org/jira/browse/OFBIZ-3715?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Scott Gray closed OFBIZ-3715. - Resolution: Fixed Thanks Blas, fixed in r935434 > Error in screen Accounting->Organization GL Settings->GL Account > Defaults->Sales Invoice / Purchase Invoice (groovy) > > > Key: OFBIZ-3715 > URL: https://issues.apache.org/jira/browse/OFBIZ-3715 > Project: OFBiz > Issue Type: Bug > Components: accounting >Affects Versions: SVN trunk >Reporter: Blas Rodriguez Somoza >Assignee: Scott Gray >Priority: Minor > Fix For: SVN trunk > > > Error in screen Accounting->Organization GL Settings->GL Account > Defaults->Sales Invoice / Purchase Invoice > org.ofbiz.widget.screen.ScreenRenderException: Error rendering screen > [component://common/widget/CommonScreens.xml#GlobalDecorator]: > java.lang.IllegalArgumentException: Error running Groovy script at location > [component://accounting/webapp/accounting/WEB-INF/actions/admin/ListInvoiceItemTypesGlAccount.groovy]: > org.ofbiz.base.util.GeneralException: Error loading Groovy script at > [component://accounting/webapp/accounting/WEB-INF/actions/admin/ListInvoiceItemTypesGlAccount.groovy]: > (startup failed: > component://accounting/webapp/accounting/WEB-INF/actions/admin/ListInvoiceItemTypesGlAccount.groovy: > 32: unable to resolve class EntityExpressionBuilder > @ line 32, column 12. > exprBldr = new EntityExpressionBuilder(); > ^ > 1 error > ) (Error running Groovy script at location > [component://accounting/webapp/accounting/WEB-INF/actions/admin/ListInvoiceItemTypesGlAccount.groovy]: > org.ofbiz.base.util.GeneralException: Error loading Groovy script at > [component://accounting/webapp/accounting/WEB-INF/actions/admin/ListInvoiceItemTypesGlAccount.groovy]: > (startup failed: > component://accounting/webapp/accounting/WEB-INF/actions/admin/ListInvoiceItemTypesGlAccount.groovy: > 32: unable to resolve class EntityExpressionBuilder > @ line 32, column 12. > exprBldr = new EntityExpressionBuilder(); > ^ > 1 error > )) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Assigned: (OFBIZ-3715) Error in screen Accounting->Organization GL Settings->GL Account Defaults->Sales Invoice / Purchase Invoice (groovy)
[ https://issues.apache.org/jira/browse/OFBIZ-3715?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Scott Gray reassigned OFBIZ-3715: - Assignee: Scott Gray > Error in screen Accounting->Organization GL Settings->GL Account > Defaults->Sales Invoice / Purchase Invoice (groovy) > > > Key: OFBIZ-3715 > URL: https://issues.apache.org/jira/browse/OFBIZ-3715 > Project: OFBiz > Issue Type: Bug > Components: accounting >Affects Versions: SVN trunk >Reporter: Blas Rodriguez Somoza >Assignee: Scott Gray >Priority: Minor > Fix For: SVN trunk > > > Error in screen Accounting->Organization GL Settings->GL Account > Defaults->Sales Invoice / Purchase Invoice > org.ofbiz.widget.screen.ScreenRenderException: Error rendering screen > [component://common/widget/CommonScreens.xml#GlobalDecorator]: > java.lang.IllegalArgumentException: Error running Groovy script at location > [component://accounting/webapp/accounting/WEB-INF/actions/admin/ListInvoiceItemTypesGlAccount.groovy]: > org.ofbiz.base.util.GeneralException: Error loading Groovy script at > [component://accounting/webapp/accounting/WEB-INF/actions/admin/ListInvoiceItemTypesGlAccount.groovy]: > (startup failed: > component://accounting/webapp/accounting/WEB-INF/actions/admin/ListInvoiceItemTypesGlAccount.groovy: > 32: unable to resolve class EntityExpressionBuilder > @ line 32, column 12. > exprBldr = new EntityExpressionBuilder(); > ^ > 1 error > ) (Error running Groovy script at location > [component://accounting/webapp/accounting/WEB-INF/actions/admin/ListInvoiceItemTypesGlAccount.groovy]: > org.ofbiz.base.util.GeneralException: Error loading Groovy script at > [component://accounting/webapp/accounting/WEB-INF/actions/admin/ListInvoiceItemTypesGlAccount.groovy]: > (startup failed: > component://accounting/webapp/accounting/WEB-INF/actions/admin/ListInvoiceItemTypesGlAccount.groovy: > 32: unable to resolve class EntityExpressionBuilder > @ line 32, column 12. > exprBldr = new EntityExpressionBuilder(); > ^ > 1 error > )) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (OFBIZ-3713) Error in screens Accounting/AP/AR->Invoices->Invoice(in process)->Applications (groovy)
[ https://issues.apache.org/jira/browse/OFBIZ-3713?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Scott Gray closed OFBIZ-3713. - Resolution: Fixed Thanks Blas, fixed in r935432 > Error in screens Accounting/AP/AR->Invoices->Invoice(in > process)->Applications (groovy) > --- > > Key: OFBIZ-3713 > URL: https://issues.apache.org/jira/browse/OFBIZ-3713 > Project: OFBiz > Issue Type: Bug > Components: accounting >Affects Versions: SVN trunk >Reporter: Blas Rodriguez Somoza >Assignee: Scott Gray >Priority: Minor > Fix For: SVN trunk > > > Error in screens Accounting/AP/AR->Invoices->Invoice(in process)->Applications > org.ofbiz.widget.screen.ScreenRenderException: Error rendering screen > [component://accounting/widget/InvoiceScreens.xml#EditInvoiceApplications]: > groovy.lang.MissingPropertyException: No such property: exprBuilder for > class: ListNotAppliedPayments (No such property: exprBuilder for class: > ListNotAppliedPayments) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Assigned: (OFBIZ-3713) Error in screens Accounting/AP/AR->Invoices->Invoice(in process)->Applications (groovy)
[ https://issues.apache.org/jira/browse/OFBIZ-3713?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Scott Gray reassigned OFBIZ-3713: - Assignee: Scott Gray > Error in screens Accounting/AP/AR->Invoices->Invoice(in > process)->Applications (groovy) > --- > > Key: OFBIZ-3713 > URL: https://issues.apache.org/jira/browse/OFBIZ-3713 > Project: OFBiz > Issue Type: Bug > Components: accounting >Affects Versions: SVN trunk >Reporter: Blas Rodriguez Somoza >Assignee: Scott Gray >Priority: Minor > Fix For: SVN trunk > > > Error in screens Accounting/AP/AR->Invoices->Invoice(in process)->Applications > org.ofbiz.widget.screen.ScreenRenderException: Error rendering screen > [component://accounting/widget/InvoiceScreens.xml#EditInvoiceApplications]: > groovy.lang.MissingPropertyException: No such property: exprBuilder for > class: ListNotAppliedPayments (No such property: exprBuilder for class: > ListNotAppliedPayments) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (OFBIZ-3712) Error in screen Accounting->Invoices->Items (recent commit)
[ https://issues.apache.org/jira/browse/OFBIZ-3712?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Scott Gray closed OFBIZ-3712. - Resolution: Fixed Thanks Blas, fixed in r935403 > Error in screen Accounting->Invoices->Items (recent commit) > --- > > Key: OFBIZ-3712 > URL: https://issues.apache.org/jira/browse/OFBIZ-3712 > Project: OFBiz > Issue Type: Bug > Components: accounting >Affects Versions: SVN trunk >Reporter: Blas Rodriguez Somoza >Priority: Minor > Fix For: SVN trunk > > > Error in screen Accounting->Invoices->Items > org.ofbiz.widget.screen.ScreenRenderException: Error rendering screen > [component://accounting/widget/InvoiceScreens.xml#EditInvoiceItems]: > org.ofbiz.base.util.GeneralException: Error running Groovy script at location > [component://accounting/webapp/accounting/WEB-INF/actions/invoice/GetInvoiceItemTypes.groovy] > (Error loading Groovy script at > [component://accounting/webapp/accounting/WEB-INF/actions/invoice/GetInvoiceItemTypes.groovy]: > (startup failed: > component://accounting/webapp/accounting/WEB-INF/actions/invoice/GetInvoiceItemTypes.groovy: > 29: unable to resolve class EntityConditionBuilder > @ line 29, column 13. > exprBldr = new EntityConditionBuilder(); > ^ > 1 error > )) (Error running Groovy script at location > [component://accounting/webapp/accounting/WEB-INF/actions/invoice/GetInvoiceItemTypes.groovy] > (Error loading Groovy script at > [component://accounting/webapp/accounting/WEB-INF/actions/invoice/GetInvoiceItemTypes.groovy]: > (startup failed: > component://accounting/webapp/accounting/WEB-INF/actions/invoice/GetInvoiceItemTypes.groovy: > 29: unable to resolve class EntityConditionBuilder > @ line 29, column 13. > exprBldr = new EntityConditionBuilder(); > ^ > 1 error > ))) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (OFBIZ-3711) Error in screen AP->Invoice Overview (recent commit)
[ https://issues.apache.org/jira/browse/OFBIZ-3711?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Scott Gray closed OFBIZ-3711. - Resolution: Fixed Thanks Blas, fixed in r935402 > Error in screen AP->Invoice Overview (recent commit) > > > Key: OFBIZ-3711 > URL: https://issues.apache.org/jira/browse/OFBIZ-3711 > Project: OFBiz > Issue Type: Bug > Components: accounting >Affects Versions: SVN trunk >Reporter: Blas Rodriguez Somoza >Assignee: Scott Gray >Priority: Minor > Fix For: SVN trunk > > > Error in screen AP->Invoice overview (for example with invoiceId=8005 of > Ofbiz demo) > org.ofbiz.widget.screen.ScreenRenderException: Error rendering screen > [component://accounting/widget/InvoiceScreens.xml#invoiceOverview]: > java.util.NoSuchElementException: Cannot access first() element from an empty > List (Cannot access first() element from an empty List) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (OFBIZ-3710) Error in screens AP->Reports and AR->Reports (recent commit)
[ https://issues.apache.org/jira/browse/OFBIZ-3710?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Scott Gray closed OFBIZ-3710. - Resolution: Fixed Thanks Blas, fixed in r935401 > Error in screens AP->Reports and AR->Reports (recent commit) > > > Key: OFBIZ-3710 > URL: https://issues.apache.org/jira/browse/OFBIZ-3710 > Project: OFBiz > Issue Type: Bug > Components: accounting >Affects Versions: SVN trunk >Reporter: Blas Rodriguez Somoza >Assignee: Scott Gray >Priority: Minor > Fix For: SVN trunk > > > Error in screens AP->Reports > org.ofbiz.widget.screen.ScreenRenderException: Error rendering screen > [component://accounting/widget/ap/InvoiceScreens.xml#ListReports]: > groovy.lang.MissingPropertyException: No such property: statusId for class: > InvoiceReport (No such property: statusId for class: InvoiceReport) > And AR->Reports > org.ofbiz.widget.screen.ScreenRenderException: Error rendering screen > [component://accounting/widget/ar/InvoiceScreens.xml#ListReports]: > groovy.lang.MissingPropertyException: No such property: statusId for class: > InvoiceReport (No such property: statusId for class: InvoiceReport) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Assigned: (OFBIZ-3711) Error in screen AP->Invoice Overview (recent commit)
[ https://issues.apache.org/jira/browse/OFBIZ-3711?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Scott Gray reassigned OFBIZ-3711: - Assignee: Scott Gray > Error in screen AP->Invoice Overview (recent commit) > > > Key: OFBIZ-3711 > URL: https://issues.apache.org/jira/browse/OFBIZ-3711 > Project: OFBiz > Issue Type: Bug > Components: accounting >Affects Versions: SVN trunk >Reporter: Blas Rodriguez Somoza >Assignee: Scott Gray >Priority: Minor > Fix For: SVN trunk > > > Error in screen AP->Invoice overview (for example with invoiceId=8005 of > Ofbiz demo) > org.ofbiz.widget.screen.ScreenRenderException: Error rendering screen > [component://accounting/widget/InvoiceScreens.xml#invoiceOverview]: > java.util.NoSuchElementException: Cannot access first() element from an empty > List (Cannot access first() element from an empty List) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Assigned: (OFBIZ-3710) Error in screens AP->Reports and AR->Reports (recent commit)
[ https://issues.apache.org/jira/browse/OFBIZ-3710?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Scott Gray reassigned OFBIZ-3710: - Assignee: Scott Gray > Error in screens AP->Reports and AR->Reports (recent commit) > > > Key: OFBIZ-3710 > URL: https://issues.apache.org/jira/browse/OFBIZ-3710 > Project: OFBiz > Issue Type: Bug > Components: accounting >Affects Versions: SVN trunk >Reporter: Blas Rodriguez Somoza >Assignee: Scott Gray >Priority: Minor > Fix For: SVN trunk > > > Error in screens AP->Reports > org.ofbiz.widget.screen.ScreenRenderException: Error rendering screen > [component://accounting/widget/ap/InvoiceScreens.xml#ListReports]: > groovy.lang.MissingPropertyException: No such property: statusId for class: > InvoiceReport (No such property: statusId for class: InvoiceReport) > And AR->Reports > org.ofbiz.widget.screen.ScreenRenderException: Error rendering screen > [component://accounting/widget/ar/InvoiceScreens.xml#ListReports]: > groovy.lang.MissingPropertyException: No such property: statusId for class: > InvoiceReport (No such property: statusId for class: InvoiceReport) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (OFBIZ-1968) Enrich Groovy integration with Ofbiz framework
[
https://issues.apache.org/jira/browse/OFBIZ-1968?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12858261#action_12858261
]
Scott Gray commented on OFBIZ-1968:
---
Here's an example I can actually get to work for building entity expressions:
{code}
entityCondition = expression.AND() {
equals (productId: 12345),
in (productId: [1, 2, 3, 4]),
like (productId: "1234%"),
OR() {
equals (productId: "54321"),
between (productId: [0, 1, 2, 3, 4, 5])
}
}
{code}
Any thoughts?
> Enrich Groovy integration with Ofbiz framework
> --
>
> Key: OFBIZ-1968
> URL: https://issues.apache.org/jira/browse/OFBIZ-1968
> Project: OFBiz
> Issue Type: Improvement
> Components: framework
>Reporter: Anil K Patel
>Priority: Minor
>
> Enrich Groovy integration with Ofbiz framework in order to bring goodies of
> Minilang to Groovy scripts. Start with simple things like use
> findByPrimaryKey in groovy scripts without having to prefix it with delegator
> and then automatically find values for primary key fields from environment if
> they are not explicitly passed in the call. Later other similar goodies of
> minilang can be added.
> Use Groovy to add DSL where possible.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
https://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (OFBIZ-1968) Enrich Groovy integration with Ofbiz framework
[
https://issues.apache.org/jira/browse/OFBIZ-1968?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12858252#action_12858252
]
Scott Gray commented on OFBIZ-1968:
---
Here's an example of using groovy's Categories with existing util classes:
{code}
import org.ofbiz.entity.util.EntityUtil;
taxInfos = delegator.findByAnd("PartyTaxAuthInfo", [partyId :
billingParty.partyId, taxAuthGeoId : taxRate.taxAuthGeoId, taxAuthPartyId :
taxRate.taxAuthPartyId])
use (EntityUtil) {
// Equivalent to EntityUtil.filterByDate(taxInfos);
dateFilteredTaxInfos = taxInfos.filterByDate();
}
{code}
> Enrich Groovy integration with Ofbiz framework
> --
>
> Key: OFBIZ-1968
> URL: https://issues.apache.org/jira/browse/OFBIZ-1968
> Project: OFBiz
> Issue Type: Improvement
> Components: framework
>Reporter: Anil K Patel
>Priority: Minor
>
> Enrich Groovy integration with Ofbiz framework in order to bring goodies of
> Minilang to Groovy scripts. Start with simple things like use
> findByPrimaryKey in groovy scripts without having to prefix it with delegator
> and then automatically find values for primary key fields from environment if
> they are not explicitly passed in the call. Later other similar goodies of
> minilang can be added.
> Use Groovy to add DSL where possible.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
https://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (OFBIZ-3636) Order Manager: the Add Gift Certificate button in 3rd screen of order creation does not work
[ https://issues.apache.org/jira/browse/OFBIZ-3636?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12858111#action_12858111 ] Scott Gray commented on OFBIZ-3636: --- Talk to Hans, I'm pretty sure I complained at the time. > Order Manager: the Add Gift Certificate button in 3rd screen of order > creation does not work > - > > Key: OFBIZ-3636 > URL: https://issues.apache.org/jira/browse/OFBIZ-3636 > Project: OFBiz > Issue Type: Bug > Components: order >Affects Versions: SVN trunk >Reporter: Jacques Le Roux > Fix For: SVN trunk > > > https://demo-trunk.ofbiz.apache.org/ordermgr/control/AddGiftCertificate > It does not work or I don't know how it works. Anyway if something special is > needed it should no be available in any cases as it's now. This feature does > not exist in R9.04 -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (OFBIZ-3523) Send a Confirmation email content doesn't generate correct URL
[ https://issues.apache.org/jira/browse/OFBIZ-3523?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Scott Gray closed OFBIZ-3523. - Assignee: Scott Gray (was: Ashish Vijaywargiya) Resolution: Fixed Sorry Ashish, I didn't realize this was assigned to you until just now :-) Anyways fixed in r935146 > Send a Confirmation email content doesn't generate correct URL > --- > > Key: OFBIZ-3523 > URL: https://issues.apache.org/jira/browse/OFBIZ-3523 > Project: OFBiz > Issue Type: Bug > Components: order >Affects Versions: SVN trunk >Reporter: Ashish Vijaywargiya >Assignee: Scott Gray > Fix For: SVN trunk > > Attachments: Order_Confirmation.png > > > Steps to reproduce: > 1) Place a sales order. > 2) Edit that Order. > 3) There is a link next to the email address "Send Confirmation Email". > 4) Clink on the "Send" button. > 5) The generated email doesn't contain correct URL. > 6) Image attached for ready reference (Refer status bar in the attached > image). -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (OFBIZ-3576) Error in Creating new Content - CMS.
[ https://issues.apache.org/jira/browse/OFBIZ-3576?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Scott Gray closed OFBIZ-3576. - Resolution: Fixed Somebody fixed it because it works now > Error in Creating new Content - CMS. > - > > Key: OFBIZ-3576 > URL: https://issues.apache.org/jira/browse/OFBIZ-3576 > Project: OFBiz > Issue Type: Bug > Components: content >Affects Versions: SVN trunk >Reporter: Sumit Pandit > Fix For: SVN trunk > > > At https://demo-trunk.ofbiz.apache.org:8443/content/control/CMSContentFind > when click on 'Create new' getting error at next page. > org.ofbiz.widget.screen.ScreenRenderException: Error rendering screen > [component://content/widget/cms/CMSScreens.xml#EditAddContent]: > org.ofbiz.base.util.GeneralException: Error running Groovy script at location > [component://content/webapp/content/WEB-INF/actions/cms/CmsEditAddPrep.groovy] > (Could not find SimpleMapProcessor XML document in resource: > org/ofbiz/content/ContentManagementMapProcessors.xml) (Error running Groovy > script at location > [component://content/webapp/content/WEB-INF/actions/cms/CmsEditAddPrep.groovy] > (Could not find SimpleMapProcessor XML document in resource: > org/ofbiz/content/ContentManagementMapProcessors.xml)) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (OFBIZ-3636) Order Manager: the Add Gift Certificate button in 3rd screen of order creation does not work
[ https://issues.apache.org/jira/browse/OFBIZ-3636?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12858106#action_12858106 ] Scott Gray commented on OFBIZ-3636: --- Yeah those extra (and unnecessary IMO) ProductStores are a real PITA > Order Manager: the Add Gift Certificate button in 3rd screen of order > creation does not work > - > > Key: OFBIZ-3636 > URL: https://issues.apache.org/jira/browse/OFBIZ-3636 > Project: OFBiz > Issue Type: Bug > Components: order >Affects Versions: SVN trunk >Reporter: Jacques Le Roux > Fix For: SVN trunk > > > https://demo-trunk.ofbiz.apache.org/ordermgr/control/AddGiftCertificate > It does not work or I don't know how it works. Anyway if something special is > needed it should no be available in any cases as it's now. This feature does > not exist in R9.04 -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (OFBIZ-3636) Order Manager: the Add Gift Certificate button in 3rd screen of order creation does not work
[ https://issues.apache.org/jira/browse/OFBIZ-3636?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12858100#action_12858100 ] Scott Gray commented on OFBIZ-3636: --- Works for me, what's the problem exactly? > Order Manager: the Add Gift Certificate button in 3rd screen of order > creation does not work > - > > Key: OFBIZ-3636 > URL: https://issues.apache.org/jira/browse/OFBIZ-3636 > Project: OFBiz > Issue Type: Bug > Components: order >Affects Versions: SVN trunk >Reporter: Jacques Le Roux > Fix For: SVN trunk > > > https://demo-trunk.ofbiz.apache.org/ordermgr/control/AddGiftCertificate > It does not work or I don't know how it works. Anyway if something special is > needed it should no be available in any cases as it's now. This feature does > not exist in R9.04 -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (OFBIZ-3636) Order Manager: the Add Gift Certificate button in 3rd screen of order creation does not work
[ https://issues.apache.org/jira/browse/OFBIZ-3636?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Scott Gray updated OFBIZ-3636: -- Summary: Order Manager: the Add Gift Certificate button in 3rd screen of order creation does not work (was: Order Manager: the Add Gift Certificate button in 3d screen of order creation does not work) > Order Manager: the Add Gift Certificate button in 3rd screen of order > creation does not work > - > > Key: OFBIZ-3636 > URL: https://issues.apache.org/jira/browse/OFBIZ-3636 > Project: OFBiz > Issue Type: Bug > Components: order >Affects Versions: SVN trunk >Reporter: Jacques Le Roux > Fix For: SVN trunk > > > https://demo-trunk.ofbiz.apache.org/ordermgr/control/AddGiftCertificate > It does not work or I don't know how it works. Anyway if something special is > needed it should no be available in any cases as it's now. This feature does > not exist in R9.04 -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (OFBIZ-3646) Change log level on never-cache related messages from "warn" to "info"
[ https://issues.apache.org/jira/browse/OFBIZ-3646?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12858097#action_12858097 ] Scott Gray commented on OFBIZ-3646: --- I'm not sure, I'm guessing it's logged as a warning because you may be expecting the value to cache but it isn't going to happen. Warnings are about logging potential mistakes that don't actually result in an error. Why not just not use the cache when you shouldn't be? > Change log level on never-cache related messages from "warn" to "info" > -- > > Key: OFBIZ-3646 > URL: https://issues.apache.org/jira/browse/OFBIZ-3646 > Project: OFBiz > Issue Type: Bug > Components: framework >Affects Versions: SVN trunk >Reporter: Bob Morley > Fix For: SVN trunk > > Attachments: OFBIZ-3646_ChangeLogLevelForNeverCacheMessages.patch > > > When you use caching there are a number of warning messages that are produced > indicating that various entity instances will not be cached (because the > entity is configured not to cache). Changing these from "warn" to "info" > which better reflects what they are and reduces warn threshold log noise. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (OFBIZ-3663) Re-executing the tests cause unit test failures
[ https://issues.apache.org/jira/browse/OFBIZ-3663?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12858095#action_12858095 ] Scott Gray commented on OFBIZ-3663: --- This is a known problem that I haven't gotten around to dealing with yet. The problem is that (persisted?) async services can't be rolled back because the JobManager uses the original delegator instead of the temporary test delegator. I'll have another look when I get a chance, I'm hoping that the changes that David made for multi-tenanting may actually make fixing this problem easier. > Re-executing the tests cause unit test failures > --- > > Key: OFBIZ-3663 > URL: https://issues.apache.org/jira/browse/OFBIZ-3663 > Project: OFBiz > Issue Type: Bug > Components: accounting >Affects Versions: SVN trunk >Reporter: Bob Morley > Fix For: SVN trunk > > > After a successful unit test run (from completely empty derby database) I > attempted a re-execution of the tests after some programming changes. A > number of tests started to fail (I think 4) which I believe were in the > Accounting area (but I could be wrong on that). Test execution ideally > should cause no state change to the database, but at a minimum should not > fail if executed more than one time. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (OFBIZ-3670) TestCase base classes providing ability to execute unit tests in Eclipse in "standalone" mode
[ https://issues.apache.org/jira/browse/OFBIZ-3670?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12858093#action_12858093 ] Scott Gray commented on OFBIZ-3670: --- Hi Bob, I don't really like this approach for a couple of reasons: 1. We already have a rollback system in place 2. OFBiz allows unit tests to depend on each other within a suite which your approach won't allow because of each unit test doing a rollback 3. If this is committed then we'll end up with two different approaches to testing and it will be more complicated for people to write new tests Why not just improve the TestRunContainer to allow it to start OFBiz and pass in arguments of what tests to run? > TestCase base classes providing ability to execute unit tests in Eclipse in > "standalone" mode > - > > Key: OFBIZ-3670 > URL: https://issues.apache.org/jira/browse/OFBIZ-3670 > Project: OFBiz > Issue Type: Improvement > Components: framework >Affects Versions: SVN trunk >Reporter: Bob Morley > Fix For: SVN trunk > > Attachments: OFBIZ-3670_StandaloneTestEnhancement.patch > > > This patch provides the framework that allows junit unit tests to be executed > directly in Eclipse (without having to invoke Start directly). It total it > contains: > - BaseTestCase - very top of the TestCase stack containing ofbiz specific > assertions > - StandaloneTestCase - determines if application has executed "Start"; if not > it will execute a scaled down "Start unittest" that is used in Eclipse > - RollbackTestCase - extends standalone and provides a transaction w/ > auto-rollback > - TestRunContainer - provides ability to disable dispatcher attributes via > configuration (used for unittest-containers.xml) > - GeoWorkerTest - unittester that provides "full" coverage of GeoWorker; can > be executed from Eclipse or from command-line as it is plugged into standard > testdef framework. Creates its own entities with transaction start/rollback > so it can be re-executed. > Would appreciate if this can be a priority so I can provide additional test > cases to boost our code coverage that will utilize these features. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (OFBIZ-3696) order Requirment
[ https://issues.apache.org/jira/browse/OFBIZ-3696?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12858091#action_12858091 ] Scott Gray commented on OFBIZ-3696: --- The system attempts to create a production run when an internal requirement is approved but I'm guessing you have supplied a productId so it fails. The error message could definitely be improved. > order Requirment > > > Key: OFBIZ-3696 > URL: https://issues.apache.org/jira/browse/OFBIZ-3696 > Project: OFBiz > Issue Type: Bug > Components: order >Affects Versions: Release Branch 4.0 > Environment: win xp , jdk 1.5.13 >Reporter: Anurag > > Hi all, > I have a problem with order->requirement. > After creating a requirement of type INTERNAL REQUIREMENT. > approve requirement giving an error like > The Following Errors Occurred: > Error calling event: org.ofbiz.webapp.event.EventHandlerException: Commit > multi-service global transaction failed > while other type PRODUCT REQUIREMENT working fine > Regard > Anurag Walia -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (OFBIZ-3638) Assigning a resource to a task is not reflected in the resource's tasks view.
[ https://issues.apache.org/jira/browse/OFBIZ-3638?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Scott Gray updated OFBIZ-3638: -- Priority: Major (was: Critical) > Assigning a resource to a task is not reflected in the resource's tasks view. > - > > Key: OFBIZ-3638 > URL: https://issues.apache.org/jira/browse/OFBIZ-3638 > Project: OFBiz > Issue Type: Bug > Components: specialpurpose/projectmgr >Affects Versions: SVN trunk > Environment: Windows 7 >Reporter: Peter Radkov > > Steps to reproduce the bug: > 1) Create a Project, a Phase and a Task (say "Observe the Bug"). > 2) Select the "Observe the Bug" task, go to its [Resources] sub-tab and > assign a resource (Say "Tester") to it. > 3) Now go to the resource "Tester" that you just assigned (from the Project's > application main menu select [Resoruces] and then select "Tester" from the > list). > 4) Click on the "Tester"'s [Tasks] sub-tab and observe that the task "Observe > the Bug" is NOT listed. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (OFBIZ-3705) nightly build task for testers.
[ https://issues.apache.org/jira/browse/OFBIZ-3705?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12857707#action_12857707 ] Scott Gray commented on OFBIZ-3705: --- I propose to close this as "won't fix", a continuous integration deployment can be done in many ways and I don't think that we really achieve anything here other than having more code to manage. > nightly build task for testers. > --- > > Key: OFBIZ-3705 > URL: https://issues.apache.org/jira/browse/OFBIZ-3705 > Project: OFBiz > Issue Type: New Feature >Affects Versions: SVN trunk > Environment: trunknightly build on a linux machine. >Reporter: BJ Freeman >Priority: Minor > Attachments: nightlybuild.sh, nightlybuild.xml > > > the will download > http://ci.apache.org/projects/ofbiz/snapshots/ofbiz-trunk-current.zip > into the ofbiz home directory > optinally stop the running application (has to be modified buy user- is > commented out) > clean the logs > unzip the downloaded file. > optionally copies saved backup of entityengine.xml (has to be modified buy > user- is commented out) > optionally copies save back of framework/base/config/ofbiz-containers.xml > (has to be modified buy user- is commented out) > deletes the download zip file > optionally changes the ownership (has to be modified buy user- is commented > out) > optionally copies the ofbiz.jar to the user name (has to be modified buy > user- is commented out) > optionally starts ofbiz (has to be modified buy user- is commented out) > I also include a sh file -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (OFBIZ-3703) updatePartyContactMech service creates new record while contactMechId is unchange.
[ https://issues.apache.org/jira/browse/OFBIZ-3703?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12857269#action_12857269 ] Scott Gray commented on OFBIZ-3703: --- Hi Arun, why not just move the store and create down to the existing if block directly below your new one? (it has the same condition) > updatePartyContactMech service creates new record while contactMechId is > unchange. > -- > > Key: OFBIZ-3703 > URL: https://issues.apache.org/jira/browse/OFBIZ-3703 > Project: OFBiz > Issue Type: Bug > Components: party, specialpurpose/ecommerce >Affects Versions: SVN trunk >Reporter: Arun Patidar >Priority: Minor > Fix For: SVN trunk > > Attachments: OFBIZ-3703.patch > > > updatePartyContactMech service should not expire old record and create new > record when contactMechId is unchange. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (OFBIZ-3695) open symphony work flow in ofbiz
[ https://issues.apache.org/jira/browse/OFBIZ-3695?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Scott Gray closed OFBIZ-3695. - Resolution: Invalid Please use the user mailing list for such questions > open symphony work flow in ofbiz > - > > Key: OFBIZ-3695 > URL: https://issues.apache.org/jira/browse/OFBIZ-3695 > Project: OFBiz > Issue Type: New Feature > Components: humanres >Affects Versions: Release Branch 4.0 >Reporter: Anurag > > I want to implement work flow open symphony for humanres. > if u have any idea to configure this with ofbiz then please suggest me how to > configure it. > Thanks in advance > Regards > Anurag Walia -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (OFBIZ-3659) Download cobertura code coverage jar so it can be used to compile and execute tests with
[ https://issues.apache.org/jira/browse/OFBIZ-3659?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12854815#action_12854815 ] Scott Gray commented on OFBIZ-3659: --- Okay, I still think it should be it's own manual step though and not automated. The new targets created in the patch look good to me, I just don't want them called from any processing targets. > Download cobertura code coverage jar so it can be used to compile and execute > tests with > > > Key: OFBIZ-3659 > URL: https://issues.apache.org/jira/browse/OFBIZ-3659 > Project: OFBiz > Issue Type: New Feature > Components: framework >Affects Versions: SVN trunk >Reporter: Bob Morley >Priority: Minor > Fix For: SVN trunk > > Attachments: OFBIZ-3659_AutomateDownloadOfCobertura.patch > > > Framework executed around allowing use of cobertura to create code coverage > metrics as part of the Ofbiz build process. Licensing restricts distribution > of cobertura with Ofbiz, so we have taken the approach to attempt to download > it before doing our build so it is available for any container that wants > instrumentation turned on (currently only test-container). Net result is > when we run our tests we will now get very nice code coverage metrics being > generated. > There is an existing target to generate the cobertura report (html) which is > not automatically being executed. Once we get more reasonable code coverage > via unit testing we can automatically generate this and expose it as > appropriate. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (OFBIZ-3659) Download cobertura code coverage jar so it can be used to compile and execute tests with
[ https://issues.apache.org/jira/browse/OFBIZ-3659?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12854811#action_12854811 ] Scott Gray commented on OFBIZ-3659: --- Adrian, You obviously haven't looked at the patch so I guess we're talking about different things. In the patch Compiling OFBiz == Downloading code metrics tools. > Download cobertura code coverage jar so it can be used to compile and execute > tests with > > > Key: OFBIZ-3659 > URL: https://issues.apache.org/jira/browse/OFBIZ-3659 > Project: OFBiz > Issue Type: New Feature > Components: framework >Affects Versions: SVN trunk >Reporter: Bob Morley >Priority: Minor > Fix For: SVN trunk > > Attachments: OFBIZ-3659_AutomateDownloadOfCobertura.patch > > > Framework executed around allowing use of cobertura to create code coverage > metrics as part of the Ofbiz build process. Licensing restricts distribution > of cobertura with Ofbiz, so we have taken the approach to attempt to download > it before doing our build so it is available for any container that wants > instrumentation turned on (currently only test-container). Net result is > when we run our tests we will now get very nice code coverage metrics being > generated. > There is an existing target to generate the cobertura report (html) which is > not automatically being executed. Once we get more reasonable code coverage > via unit testing we can automatically generate this and expose it as > appropriate. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (OFBIZ-3659) Download cobertura code coverage jar so it can be used to compile and execute tests with
[ https://issues.apache.org/jira/browse/OFBIZ-3659?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12854807#action_12854807 ] Scott Gray commented on OFBIZ-3659: --- Bob: Buildbot can run any number of tasks in sequence, currently I think it does: svn co ... ant run-install ant run-tests ant docs-all then some other stuff for the nightly builds > Download cobertura code coverage jar so it can be used to compile and execute > tests with > > > Key: OFBIZ-3659 > URL: https://issues.apache.org/jira/browse/OFBIZ-3659 > Project: OFBiz > Issue Type: New Feature > Components: framework >Affects Versions: SVN trunk >Reporter: Bob Morley >Priority: Minor > Fix For: SVN trunk > > Attachments: OFBIZ-3659_AutomateDownloadOfCobertura.patch > > > Framework executed around allowing use of cobertura to create code coverage > metrics as part of the Ofbiz build process. Licensing restricts distribution > of cobertura with Ofbiz, so we have taken the approach to attempt to download > it before doing our build so it is available for any container that wants > instrumentation turned on (currently only test-container). Net result is > when we run our tests we will now get very nice code coverage metrics being > generated. > There is an existing target to generate the cobertura report (html) which is > not automatically being executed. Once we get more reasonable code coverage > via unit testing we can automatically generate this and expose it as > appropriate. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (OFBIZ-3659) Download cobertura code coverage jar so it can be used to compile and execute tests with
[ https://issues.apache.org/jira/browse/OFBIZ-3659?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12854806#action_12854806 ] Scott Gray commented on OFBIZ-3659: --- Adrian - Just because it's a "local" copy doesn't mean you're not going to distribute it and if you don't know that the metrics library is there then how would you know to exclude it? Example: Someone may decide to distribute a precompiled version of OFBiz for the convenience of the community. > Download cobertura code coverage jar so it can be used to compile and execute > tests with > > > Key: OFBIZ-3659 > URL: https://issues.apache.org/jira/browse/OFBIZ-3659 > Project: OFBiz > Issue Type: New Feature > Components: framework >Affects Versions: SVN trunk >Reporter: Bob Morley >Priority: Minor > Fix For: SVN trunk > > Attachments: OFBIZ-3659_AutomateDownloadOfCobertura.patch > > > Framework executed around allowing use of cobertura to create code coverage > metrics as part of the Ofbiz build process. Licensing restricts distribution > of cobertura with Ofbiz, so we have taken the approach to attempt to download > it before doing our build so it is available for any container that wants > instrumentation turned on (currently only test-container). Net result is > when we run our tests we will now get very nice code coverage metrics being > generated. > There is an existing target to generate the cobertura report (html) which is > not automatically being executed. Once we get more reasonable code coverage > via unit testing we can automatically generate this and expose it as > appropriate. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (OFBIZ-3659) Download cobertura code coverage jar so it can be used to compile and execute tests with
[ https://issues.apache.org/jira/browse/OFBIZ-3659?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12854797#action_12854797 ] Scott Gray commented on OFBIZ-3659: --- It just seems to me that downloading an incompatibly licensed jar is something that the user should do knowingly and not have it be some sort of transparent process. Download OFBiz: Apache licensed distribution Run tests: No longer an Apache licensed distribution but the user doesn't know that > Download cobertura code coverage jar so it can be used to compile and execute > tests with > > > Key: OFBIZ-3659 > URL: https://issues.apache.org/jira/browse/OFBIZ-3659 > Project: OFBiz > Issue Type: New Feature > Components: framework >Affects Versions: SVN trunk >Reporter: Bob Morley >Priority: Minor > Fix For: SVN trunk > > Attachments: OFBIZ-3659_AutomateDownloadOfCobertura.patch > > > Framework executed around allowing use of cobertura to create code coverage > metrics as part of the Ofbiz build process. Licensing restricts distribution > of cobertura with Ofbiz, so we have taken the approach to attempt to download > it before doing our build so it is available for any container that wants > instrumentation turned on (currently only test-container). Net result is > when we run our tests we will now get very nice code coverage metrics being > generated. > There is an existing target to generate the cobertura report (html) which is > not automatically being executed. Once we get more reasonable code coverage > via unit testing we can automatically generate this and expose it as > appropriate. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (OFBIZ-3659) Download cobertura code coverage jar so it can be used to compile and execute tests with
[ https://issues.apache.org/jira/browse/OFBIZ-3659?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12854791#action_12854791 ] Scott Gray commented on OFBIZ-3659: --- My only concern is that an automatic and transparent download may not constitute an optional dependency (since the user isn't really given an option). > Download cobertura code coverage jar so it can be used to compile and execute > tests with > > > Key: OFBIZ-3659 > URL: https://issues.apache.org/jira/browse/OFBIZ-3659 > Project: OFBiz > Issue Type: Bug > Components: framework >Affects Versions: SVN trunk >Reporter: Bob Morley > Fix For: SVN trunk > > Attachments: OFBIZ-3659_AutomateDownloadOfCobertura.patch > > > Framework executed around allowing use of cobertura to create code coverage > metrics as part of the Ofbiz build process. Licensing restricts distribution > of cobertura with Ofbiz, so we have taken the approach to attempt to download > it before doing our build so it is available for any container that wants > instrumentation turned on (currently only test-container). Net result is > when we run our tests we will now get very nice code coverage metrics being > generated. > There is an existing target to generate the cobertura report (html) which is > not automatically being executed. Once we get more reasonable code coverage > via unit testing we can automatically generate this and expose it as > appropriate. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (OFBIZ-3633) Minimum order quantity
[ https://issues.apache.org/jira/browse/OFBIZ-3633?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12854338#action_12854338 ] Scott Gray commented on OFBIZ-3633: --- Currently ProductPrice is used for selling goods and SupplierProduct is used for purchasing goods, I don't like the idea of blurring the lines between the two unnecessarily. Using that entity just because it happens to have a minimum quantity field on it seems like a bit of a stretch to me. > Minimum order quantity > -- > > Key: OFBIZ-3633 > URL: https://issues.apache.org/jira/browse/OFBIZ-3633 > Project: OFBiz > Issue Type: New Feature > Components: order, specialpurpose/ecommerce >Reporter: Rishi Solanki > Fix For: SVN trunk > > Attachments: OFBIZ-3633.patch, OFBIZ-3633.patch > > > It will work as follows; > We will set the special type price as 'MINIMUM_ORDER_PRICE' for a Product in > ProductPrice entity. On the basis of it we will get the minimum order > quantity of the product on the basis of this price and sale price. > Will get the minimum order quantity for product by division. For example we > have selling price of product P1 is $10.00 and its MINIMUM_ORDER_PRICE is > $100.00 then minimum order quantity for the product will be --> 100/10 ==> 10. > To achieve the above ; > write a getMinimumOrderQuantity() method in ShoppingCart.java which takes the > itemBasePrice and productId as in parameter, and call it where we add, update > the cart items and change the quantity to minmumOrderQuantity if it is less > then minimum. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (OFBIZ-3633) Minimum order quantity
[
https://issues.apache.org/jira/browse/OFBIZ-3633?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12854324#action_12854324
]
Scott Gray commented on OFBIZ-3633:
---
Hi Rishi,
{quote}
1) Achieve this ProductPrice entity patch is attached with Jira.
{quote}
The attached patch doesn't seem to make any changes to the ProductPrice entity?
At this stage I'm in favor of one simply because it doesn't change the entity
model and still achieves (in theory) the current requirements. If we go for a
different approach furhter down the track at least we won't have to deal with
deprecating any entity fields.
I don't see how SupplierProduct could be used without it being fairly messy.
> Minimum order quantity
> --
>
> Key: OFBIZ-3633
> URL: https://issues.apache.org/jira/browse/OFBIZ-3633
> Project: OFBiz
> Issue Type: New Feature
> Components: order, specialpurpose/ecommerce
>Reporter: Rishi Solanki
> Fix For: SVN trunk
>
> Attachments: OFBIZ-3633.patch, OFBIZ-3633.patch
>
>
> It will work as follows;
> We will set the special type price as 'MINIMUM_ORDER_PRICE' for a Product in
> ProductPrice entity. On the basis of it we will get the minimum order
> quantity of the product on the basis of this price and sale price.
> Will get the minimum order quantity for product by division. For example we
> have selling price of product P1 is $10.00 and its MINIMUM_ORDER_PRICE is
> $100.00 then minimum order quantity for the product will be --> 100/10 ==> 10.
> To achieve the above ;
> write a getMinimumOrderQuantity() method in ShoppingCart.java which takes the
> itemBasePrice and productId as in parameter, and call it where we add, update
> the cart items and change the quantity to minmumOrderQuantity if it is less
> then minimum.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (OFBIZ-3647) Create dataResource from content
[ https://issues.apache.org/jira/browse/OFBIZ-3647?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12854036#action_12854036 ] Scott Gray commented on OFBIZ-3647: --- Hi Nicolas, Thanks for the patch, here is my review: # createDataResourceAndGiveType has the following problems: ## It is unnecessary, I can't see any reason why you have switched from using the event that was already there ## The description is wrong ## I don't like using the service response code to return values, this is what events are for ## In the implementation there is no need to do an entity-one because createDataResource returns the GenericValue # createDataResourceAndAssocToContent ## the "template" service attribute should be a boolean or at the very least a char or Character and why not make the name more verbose like useTemplateDataResourceId? ## please correct the indentation of the if-compare + else elements ## use the updateContent service, you should almost never persist an entity directly > Create dataResource from content > > > Key: OFBIZ-3647 > URL: https://issues.apache.org/jira/browse/OFBIZ-3647 > Project: OFBiz > Issue Type: Improvement > Components: content >Affects Versions: SVN trunk >Reporter: nicolas malin >Assignee: Scott Gray >Priority: Minor > Attachments: content.patch > > > When you create a content, you need create a data resource and return to > content for create association. > If a content don't have a dataResource, I change buton : GoToDataResource by > Create a DataResource. When this lastest is created, she automaticly > associate to the content and retour to EditContent screen -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Assigned: (OFBIZ-3647) Create dataResource from content
[ https://issues.apache.org/jira/browse/OFBIZ-3647?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Scott Gray reassigned OFBIZ-3647: - Assignee: Scott Gray > Create dataResource from content > > > Key: OFBIZ-3647 > URL: https://issues.apache.org/jira/browse/OFBIZ-3647 > Project: OFBiz > Issue Type: Improvement > Components: content >Affects Versions: SVN trunk >Reporter: nicolas malin >Assignee: Scott Gray >Priority: Minor > Attachments: content.patch > > > When you create a content, you need create a data resource and return to > content for create association. > If a content don't have a dataResource, I change buton : GoToDataResource by > Create a DataResource. When this lastest is created, she automaticly > associate to the content and retour to EditContent screen -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (OFBIZ-3503) Content has a dependency on Person
[ https://issues.apache.org/jira/browse/OFBIZ-3503?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12854005#action_12854005 ] Scott Gray commented on OFBIZ-3503: --- I would like to close this as Invalid, the WebSiteRole entity is intrinsically tied to the Party component and I can't see what this patch would achieve. > Content has a dependency on Person > -- > > Key: OFBIZ-3503 > URL: https://issues.apache.org/jira/browse/OFBIZ-3503 > Project: OFBiz > Issue Type: Sub-task > Components: content >Affects Versions: SVN trunk >Reporter: chris snow > Attachments: entitymodel.xml.patch > > > The entity WebSiteRole in the content component has a dependency on Person. > Can this be removed? -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (OFBIZ-3558) Out of memory when importing large files /framework/datafile
[
https://issues.apache.org/jira/browse/OFBIZ-3558?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Scott Gray updated OFBIZ-3558:
--
Priority: Major (was: Blocker)
> Out of memory when importing large files /framework/datafile
> -
>
> Key: OFBIZ-3558
> URL: https://issues.apache.org/jira/browse/OFBIZ-3558
> Project: OFBiz
> Issue Type: Bug
> Components: framework
>Affects Versions: Release Branch 9.04, Release Candidate Branch 10.04, SVN
> trunk
>Reporter: BJ Freeman
> Fix For: Release Branch 9.04, Release Candidate Branch 10.04, SVN
> trunk
>
> Attachments: Copy of dobraimportTemplate.xml
>
>
> importing a tab delimited file 8megs(discontinued products) in size
> to me this is poor design since most file are even bigger when importing
> inventory from suppliers.
> javax.servlet.ServletException: Servlet execution threw an exception
> org.ofbiz.webapp.control.ContextFilter.doFilter(ContextFilter.java:259)
> root cause
> java.lang.OutOfMemoryError: Java heap space
> java.util.Arrays.copyOfRange(Unknown Source)
> java.lang.String.(Unknown Source)
> java.lang.StringBuffer.toString(Unknown Source)
> java.io.StringWriter.toString(Unknown Source)
> org.apache.log4j.spi.LocationInfo.(LocationInfo.java:114)
>
> org.apache.log4j.spi.LoggingEvent.getLocationInformation(LoggingEvent.java:247)
> org.apache.log4j.AsyncAppender.append(AsyncAppender.java:160)
> org.apache.log4j.AppenderSkeleton.doAppend(AppenderSkeleton.java:251)
>
> org.apache.log4j.helpers.AppenderAttachableImpl.appendLoopOnAppenders(AppenderAttachableImpl.java:66)
> org.apache.log4j.Category.callAppenders(Category.java:206)
> org.apache.log4j.Category.forcedLog(Category.java:391)
> org.apache.log4j.Category.log(Category.java:856)
> org.ofbiz.base.util.Debug.log(Debug.java:166)
> org.ofbiz.base.util.Debug.log(Debug.java:149)
> org.ofbiz.base.util.Debug.logInfo(Debug.java:258)
> org.ofbiz.datafile.RecordIterator.getNextLine(RecordIterator.java:117)
> org.ofbiz.datafile.RecordIterator.next(RecordIterator.java:163)
> org.ofbiz.datafile.DataFile.readDataFile(DataFile.java:126)
> org.ofbiz.datafile.DataFile.readFile(DataFile.java:63)
> sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
> sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
> java.lang.reflect.Method.invoke(Unknown Source)
> org.codehaus.groovy.reflection.CachedMethod.invoke(CachedMethod.java:86)
> groovy.lang.MetaMethod.doMethodInvoke(MetaMethod.java:230)
> groovy.lang.MetaClassImpl.invokeStaticMethod(MetaClassImpl.java:1105)
>
> org.codehaus.groovy.runtime.InvokerHelper.invokeMethod(InvokerHelper.java:749)
>
> org.codehaus.groovy.runtime.ScriptBytecodeAdapter.invokeMethodN(ScriptBytecodeAdapter.java:170)
> viewdatafile.run(viewdatafile.groovy:65)
> org.ofbiz.base.util.GroovyUtil.runScriptAtLocation(GroovyUtil.java:117)
>
> org.ofbiz.widget.screen.ModelScreenAction$Script.runAction(ModelScreenAction.java:408)
>
> org.ofbiz.widget.screen.ModelScreenAction.runSubActions(ModelScreenAction.java:118)
> this is a typical record
> {code}
> 2010-03-15 16:56:15,421 (http-0.0.0.0-8443-1) [ RecordIterator.java:117:INFO
> ] br.readLine()="569 0.00 Britney 5473236 23320:302273:P "14K Yellow Gold
> Kansas City Chief's
> Enamel Helment Pendant" "Reflecting the flawless elegance from a long-gone
> age of gentility, this luminescent pendant blends the sublime majestic
> aesthetics of the past with the
> impeccable advanced metallurgical technology of the modern day. This 14k
> yellow gold pendant makes a great addition to any jewelry collection and can
> be worn on many
> occasions. The total metal weight of this pendant is 2.30 grams. This pendant
> is part of our sports pendants collection of jewelry. This pendant has a
> length of 21 mm, a width of
> 21.25 mm." new Britney Britney 0 "2009-11-06 16:41:38" 5910653 23320:302273:P
> 23320:302273:P "14K Yellow Gold Kansas City Chief's Enamel Helment Pendant" 0
> 0 0.00
> 181.94 176.72 599.98 10 in-stock 0 "2009-11-06 15:02:07" "Catalog||Apparel,
> shoes & jewelry||Jewelry & watches||Pendants" http://images.doba.com/products
> /569/images_inventory_23320.jpg 250 250"
> {code}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (OFBIZ-3634) ProductPromoWorker PROMO_GWP hard-codes a required inventory check
[ https://issues.apache.org/jira/browse/OFBIZ-3634?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12853269#action_12853269 ] Scott Gray commented on OFBIZ-3634: --- Here's my understanding of what the new condition does: Get all productIds attached to the condition and for each one get the sum of the quantity in the cart plus the condition's condValue and check that at least that amount is available in inventory, if there is not enough inventory for all of the condition products then the condition will not be satisfied. For virtual products your condition probably isn't handling them correctly, if a virtual product is included in the condition then any variants in the cart will contribute to the quantityNeeded but the problem is that isStoreInventoryAvailable always returns "N" for virtual products. Even if the above is fixed, it gets more complicated when you get to the gift with purchase action because it won't know what variant products to make available. The current process is that the variants are gathered up and inventory checked (excluded if it fails), the first variant is grabbed from the set and added to the cart but the other options are made available to the shopper so they can select a different variant if desired. The problem here is that if a virtual was put into your condition then the action won't know about it and won't know whether it should be doing an inventory check on the variant or allowing it to be back ordered. The only solution I can think of at the moment is to: - Have the condition check each variant for quantityNeeded instead of checking the virtual, do not return false unless ALL of the variants fail the test (i.e. only one variant need pass the condition) - On the GWP action, during optionProductIds iteration do the following: -- if the option is a variant product then it will need to lookup the PPIP_PRODUCT_INV (if there is one) and handle the following scenarios: --- If the variant was in the condition then leave it in the set and continue --- If the variant's virtual was in the condition then run the condition inventory check against the variant and remove it if it fails Additionally it looks like there is a bug in GWP action where if getPromoRuleActionProductIds returns any virtual products then currently they are excluded because the inventory check always fails and I'm not sure what will happen when the inventory check is removed. Ideally they would be handled in the same way as when a virtual is explicitly set on the ProductPromoAction.productId field. > ProductPromoWorker PROMO_GWP hard-codes a required inventory check > -- > > Key: OFBIZ-3634 > URL: https://issues.apache.org/jira/browse/OFBIZ-3634 > Project: OFBiz > Issue Type: Bug > Components: order >Reporter: Adam Heath > Attachments: PROMO_GWP_inventory_check.patch > > > PROMO_GWP processing always requires the gifted item to have available > inventory. There is no way to have that configurable, no way to have the > free item get backordered. > The attached patch removes the inventory check on *real* products, and > instead created a new condition, PPIP_PRODUCT_INV, so that *any* promo can > pass/fail based on an inventory check. > I did not commit this patch, because the full fix would need to handle > virtual products as well. I don't understand how PROMO_GWP works with > virtual products when doing inventory, so I need help with that. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (OFBIZ-3546) FreeMarkerViewHandler should load templates via the FreeMarkerWorker
[
https://issues.apache.org/jira/browse/OFBIZ-3546?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12853262#action_12853262
]
Scott Gray commented on OFBIZ-3546:
---
{quote}
A better solution would be to switch those screens to screen widgets.
{quote}
Not really, the FreeMarkerViewHandler is an alternative to screen rendering, so
we can't really say that the best solution is to use a different view handler.
> FreeMarkerViewHandler should load templates via the FreeMarkerWorker
>
>
> Key: OFBIZ-3546
> URL: https://issues.apache.org/jira/browse/OFBIZ-3546
> Project: OFBiz
> Issue Type: Bug
> Components: framework
>Reporter: Bruno Busco
>
> This bug has been introduced in r920115.
> A temporary fix is in r920589: Fix a problem reported by Hans Bakker,
> FreeMarker templates loaded using the Configuration object don't have access
> to the component:// notation reader and this causes them to fail because all
> templates now attempt to retrieve the html form macro library using that
> notation. This is a quick fix but we should really fix the
> FreeMarkerViewHandler to load templates via the FreeMarkerWorker.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (OFBIZ-3630) Fix .classpath for hamcrest.jar inclusion
[ https://issues.apache.org/jira/browse/OFBIZ-3630?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12851993#action_12851993 ] Scott Gray commented on OFBIZ-3630: --- Standard Jira issue navigation only displays issues with an unresolved status by default, so resolving the issue does a lot to hide it from committers. > Fix .classpath for hamcrest.jar inclusion > - > > Key: OFBIZ-3630 > URL: https://issues.apache.org/jira/browse/OFBIZ-3630 > Project: OFBiz > Issue Type: Bug > Components: ALL COMPONENTS >Affects Versions: SVN trunk >Reporter: Bob Morley > Fix For: SVN trunk > > Attachments: OFBIZ-3630_AddHamcrestToClasspath.patch > > > It appears that the hamcrest.jar has been added to help in some of the cache > related unit tests. This just adds it to the .classpath so that the project > can compile in Eclipse. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (OFBIZ-3564) accounting has dependency on projectmgr
[ https://issues.apache.org/jira/browse/OFBIZ-3564?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12847069#action_12847069 ] Scott Gray commented on OFBIZ-3564: --- Same problem exists in: applications/humanres/widget/CommonScreens.xml > accounting has dependency on projectmgr > --- > > Key: OFBIZ-3564 > URL: https://issues.apache.org/jira/browse/OFBIZ-3564 > Project: OFBiz > Issue Type: Bug > Components: accounting >Affects Versions: SVN trunk >Reporter: Adam Heath > > applications/accounting/widget/InvoiceScreens.xml references > ProjectMgrUiLabels, which only exists in specialpurpose. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (OFBIZ-3562) Tomahawk theme makes some webtools entity data unreadable
Tomahawk theme makes some webtools entity data unreadable - Key: OFBIZ-3562 URL: https://issues.apache.org/jira/browse/OFBIZ-3562 Project: OFBiz Issue Type: Bug Components: framework, themes Affects Versions: SVN trunk Reporter: Scott Gray Navigate to webtools -> Entity Data Maintenance -> OrderHeader -> All Scroll down to the list of data and note that on the darker rows the data is invisible where the table overflows the screen width due to black text appearing on a black background. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (OFBIZ-3533) Associate Image functionality with ProductPromo using content driven
[ https://issues.apache.org/jira/browse/OFBIZ-3533?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12843199#action_12843199 ] Scott Gray commented on OFBIZ-3533: --- Few comments: - The entity packages should probably be org.ofbiz.product.promo instead of org.ofbiz.product.product - I'm not sure about re-using the ProductContentType entity for representing productPromoContentTypeIds, does anyone have an opinion on this? - What is the reason for calling updateContent within the ProductPromoContent CrUD services? Maybe the answer is obvious but I'm not fresh enough on the content stuff to know. Thanks Scott > Associate Image functionality with ProductPromo using content driven > > > Key: OFBIZ-3533 > URL: https://issues.apache.org/jira/browse/OFBIZ-3533 > Project: OFBiz > Issue Type: Improvement > Components: product >Affects Versions: SVN trunk >Reporter: Amit Sharma >Assignee: Ashish Vijaywargiya >Priority: Minor > Fix For: SVN trunk > > Attachments: OFBIZ-3533.patch, OFBIZ-3533.patch > > > Associate Image functionality with ProductPromo using content driven. > Following work will be covered: - > # Add new entity "ProductPromoContent" entity having composite primary key: > ## productPromoId > ## contentId > ## productPromoContentTypeId > ## fromDate > # CRUD services for ProductPromoContent Entity. > # Create wrapper ProductPromoContentWrapper > # Add content tab at catalog -> promo > # List and edit form for associating images to specific productPromoId. > # Implement service addImageForProductPromo. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (OFBIZ-3519) Slightly modified Visual Theme Resource Enums for better readability
[ https://issues.apache.org/jira/browse/OFBIZ-3519?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12842924#action_12842924 ] Scott Gray commented on OFBIZ-3519: --- Well we've had a couple of suggestions: - Support both the new IDs and the old (me) - Increase the field length to allow for more verbose names (Adrian) - Do nothing (Jacques, Hans) - Provide a migration service (Jacques) > Slightly modified Visual Theme Resource Enums for better readability > > > Key: OFBIZ-3519 > URL: https://issues.apache.org/jira/browse/OFBIZ-3519 > Project: OFBiz > Issue Type: Improvement > Components: ALL COMPONENTS >Reporter: Vikas Mayur >Priority: Minor > Fix For: SVN trunk > > Attachments: enum.patch > > > Minor enhancement to the visual theme resource enumId so that a more verbose > name of the resource or template file can be specified. > The suffix STYLESHEET and JAVASCRIPT in the enum impose a restriction on > specifying a meaningful name of the enumId field which is max 20 chars in > size. > The suffix in the enum contains following changes. > 1. STYLESHEET is replaced with CSS > 2. JAVASCRIPT is replaced with JS > 3. LOC is completely removed from TMPLT, since it is anyway specify a > template location. > With all above points the total char size of the enum decreased and it gives > an opportunity to specify better names and hence more readability. > For example VT_HDR_TMPLT_LOC becomes VT_HEADER_TMPLT -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
