Re: Lose Weight Program for OFBiz - themes
Hi Mansour, From: Mansour Al Akeel mansour.alak...@gmail.com Jacques, We use RTL. May be you are right about the the ease of use to find an item, but the user who has permission to all these functionality is an admin, and normally, she is comfortable finding any item quickly. The rest of the uses don't have that much items and menus shown. This makes sense for a deployment, not OOTB. It's IMO easier to select Flat Grey, if you prefer, for your deployments and to keep Tomahawk as OOTB default for the reasons I explained and others I add below. I know, other themes may look better, or fancier, but most users use flat gray to base their work on and extend/customize it, because it's easier and cleaner. I am not sure if bigger organization prefer fancier look and feel over cleaner. And to be honest, I think flat gray looks more professional than others. Therefore, it give a positive first impression, when demonstrated. Additional themes may still exist beside FlatGray, but I recommend to make it the default one. What makes you think most users use flat gray to base their work ? Could you define easier and cleaner, and why Flat Grey is easier and cleaner (besides that it's the only one that is RTL which I understand for you is a must have) What makes you think Flat Grey looks more professionnal? For me Flat Gray has not enough contrast. In other words all looks grey/pale and it's difficult to spot things. With Tomahawk I quickly spot buttons, links, etc. because there is more contrast. Maybe it's If you read me, it's not about being fancier but ergonomic which is for me the only priority for the community to use OFBiz OOTB (contrary to deployments) Also I'd like to know why Flat Grey is the only Theme being marked as being Sight-Impaired Accessible? Adrian? I remember I began to add title=Skip navigation accesskey=2 (which is really only a small/poor beginnng) but that's for all themes. What is specific to Flat Grey? The only things I could concede: 1. Like 1 to 5% of the male population (women are rarely touched) I'm daltonian (kind of sight-impaired ;o) so my vision about contrast is maybe biased 2. Maybe, because it uses a blackboard background style rather than a white paper style, Tomahawk is more arduous for eyes on a long term (hours of work) Thanks for sharing your opinion :o) Jacques On Tue, Mar 20, 2012 at 6:10 PM, Jacques Le Roux jacques.le.r...@les7arts.com wrote: I see that most people prefer Flat Grey. Let me explain why I prefer Tomahawk. Did you ever wonder why the paper we write on has more than often a greater height than width, why newspaper have many columns, etc. Here is an answer http://graphicdesign.stackexchange.com/questions/3553/why-do-newspapers-use-multiple-columns OK, my argument: don't you feel a pain to find an application, a menu entry in Flat Grey? No? Then you are used to find it at some place and don't care anymore. Now just imagine the same for a new user... This is where Tomahawk is better. It's far easier to find an entry in 2 colums (applications in Tomahawk) than in 7 columns (applications in Flat Grey). Or an entry in an application (1 column for Tomahawk, up to 14 in Flat Grey). Just try it Another point: Product screens are awful in Flat Grey (to many buttons for menus, hard to spot). Though actually I believe Tomahawk would benefit from a third column, for instance for Product. This could be 2 twin columns if more than, say, 15 entries would show in a column. Like we have for Applications, though not sure how it's organized. I mean why some are in right column and other in left one? Also something wich could help spot entries quicker would be to allow sorting entries in menus by language. It's now only done based on English. OK, now there is the RTL feature. Who use it? Few I guess (http://en.wikipedia.org/wiki/Right-to-left http://en.wikipedia.org/wiki/Left-to-right#Directionality). Which does not diminish RTL importance, but ponders it in choice for a default theme. My 2 cts Jacques From: Ashish Vijaywargiya vijaywargiya.ash...@gmail.com My vote will be to keep two themes in the project. IMO Flatgrey theme is the best to keep as the default one for the project. -- Ashish On Tue, Mar 20, 2012 at 5:18 PM, Jacopo Cappellato jacopo.cappell...@hotwaxmedia.com wrote: I) $OFBIZ_HOME/themes/*: move a few of them to Attic and a few of them to Extras; keep just one (or two) Jacques proposed to keep Tomahawk (default) and Flat Grey. Olivier proposed to keep just one (Tomahawk, I guess). No other comments so far. What should be do with the remaining themes? Attic or Extras? Are there volunteers for Extras? I would suggest that, if we move them to Extras we create *one* project only (for all the themes) rather than one project for theme... but I would love to get your feedback on this. Jacopo
[jira] [Closed] (OFBIZ-4735) User behaviour issue on Lookup.
[ https://issues.apache.org/jira/browse/OFBIZ-4735?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jacques Le Roux closed OFBIZ-4735. -- User behaviour issue on Lookup. --- Key: OFBIZ-4735 URL: https://issues.apache.org/jira/browse/OFBIZ-4735 Project: OFBiz Issue Type: Bug Components: framework Reporter: Deepak Dixit Assignee: Ashish Vijaywargiya Priority: Minor Fix For: Release Branch 11.04, SVN trunk Attachments: OFBIZ-4735-11.04.patch, OFBIZ-4735.patch Currently if user perform search or use pagination in lookup and if matches found then list display but if no matches found then user didn't know that result will come or not, even no matches found. Change behaviour should be when user perform search or use pagination then spinner (ajax loader image) shows wchich tells user that search is in progress. If matches found or not found spinner disappears. Now user won't see any abnormal behaviour at ui. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (OFBIZ-1745) gift card processer error
[
https://issues.apache.org/jira/browse/OFBIZ-1745?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jacopo Cappellato resolved OFBIZ-1745.
--
Resolution: Won't Fix
The release branch 4.0 is no more actively maintained.
gift card processer error
-
Key: OFBIZ-1745
URL: https://issues.apache.org/jira/browse/OFBIZ-1745
Project: OFBiz
Issue Type: Bug
Components: accounting
Affects Versions: Release 4.0
Environment: windows
Reporter: bj_zhou
Fix For: Release Branch 4.0
2008-04-10 00:57:53,843 (http-0.0.0.0-8443-Processor3) [
ModelService.java:481:ERROR] [ModelService.validate] : {ofbGcProcessor} :
(IN) Required test error: org.ofbiz.service.ServiceValidationException: The
following required parameter is missing:: [IN]
[ofbGcProcessor.billToParty]The following required parameter is missing::
[IN] [ofbGcProcessor.giftCard]The following required parameter is missing::
[IN] [ofbGcProcessor.orderId]The following required parameter is missing::
[IN] [ofbGcProcessor.orderItems]
2008-04-10 00:57:53,843 (http-0.0.0.0-8443-Processor3) [
ServiceDispatcher.java:333:ERROR]
exception report
--
Incoming context (in runSync : ofbGcProcessor) does not match expected
requirements
Exception: org.ofbiz.service.ServiceValidationException
Message: The following required parameter is missing:: [IN]
[ofbGcProcessor.billToParty]The following required parameter is missing::
[IN] [ofbGcProcessor.giftCard]The following required parameter is missing::
[IN] [ofbGcProcessor.orderId]The following required parameter is missing::
[IN] [ofbGcProcessor.orderItems]
stack trace
---
org.ofbiz.service.ServiceValidationException: The following required
parameter is missing:: [IN] [ofbGcProcessor.billToParty]The following
required parameter is missing:: [IN] [ofbGcProcessor.giftCard]The following
required parameter is missing:: [IN] [ofbGcProcessor.orderId]The following
required parameter is missing:: [IN] [ofbGcProcessor.orderItems]
org.ofbiz.service.ModelService.validate(ModelService.java:523)
org.ofbiz.service.ModelService.validate(ModelService.java:478)
org.ofbiz.service.ServiceDispatcher.runSync(ServiceDispatcher.java:331)
org.ofbiz.service.ServiceDispatcher.runSync(ServiceDispatcher.java:214)
org.ofbiz.service.GenericDispatcher.runSync(GenericDispatcher.java:166)
org.ofbiz.accounting.payment.PaymentGatewayServices.capturePayment(PaymentGatewayServices.java:1541)
org.ofbiz.accounting.payment.PaymentGatewayServices.capturePayment(PaymentGatewayServices.java:1447)
org.ofbiz.accounting.payment.PaymentGatewayServices.captureOrderPayments(PaymentGatewayServices.java:1179)
sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
java.lang.reflect.Method.invoke(Method.java:585)
org.ofbiz.service.engine.StandardJavaEngine.serviceInvoker(StandardJavaEngine.java:94)
org.ofbiz.service.engine.StandardJavaEngine.runSync(StandardJavaEngine.java:56)
org.ofbiz.service.ServiceDispatcher.runSync(ServiceDispatcher.java:347)
org.ofbiz.service.ServiceDispatcher.runSync(ServiceDispatcher.java:214)
org.ofbiz.service.GenericDispatcher.runSync(GenericDispatcher.java:152)
org.ofbiz.accounting.payment.PaymentGatewayServices.capturePaymentsByInvoice(PaymentGatewayServices.java:986)
sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
java.lang.reflect.Method.invoke(Method.java:585)
org.ofbiz.service.engine.StandardJavaEngine.serviceInvoker(StandardJavaEngine.java:94)
org.ofbiz.service.engine.StandardJavaEngine.runSync(StandardJavaEngine.java:56)
org.ofbiz.service.ServiceDispatcher.runSync(ServiceDispatcher.java:347)
org.ofbiz.service.ServiceDispatcher.runSync(ServiceDispatcher.java:214)
org.ofbiz.service.GenericDispatcher.runSync(GenericDispatcher.java:152)
org.ofbiz.service.eca.ServiceEcaAction.runAction(ServiceEcaAction.java:113)
org.ofbiz.service.eca.ServiceEcaRule.eval(ServiceEcaRule.java:141)
org.ofbiz.service.eca.ServiceEcaUtil.evalRules(ServiceEcaUtil.java:158)
org.ofbiz.service.ServiceDispatcher.runSync(ServiceDispatcher.java:463)
org.ofbiz.service.ServiceDispatcher.runSync(ServiceDispatcher.java:214)
org.ofbiz.service.GenericDispatcher.runSync(GenericDispatcher.java:152)
org.ofbiz.order.order.OrderServices.checkDigitalItemFulfillment(OrderServices.java:2739)
[jira] [Resolved] (OFBIZ-4366) Accessing Ofbiz Entity UtilCache is time consuming
[ https://issues.apache.org/jira/browse/OFBIZ-4366?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jacopo Cappellato resolved OFBIZ-4366. -- Resolution: Won't Fix The release branch 4.0 is no more actively maintained. Accessing Ofbiz Entity UtilCache is time consuming -- Key: OFBIZ-4366 URL: https://issues.apache.org/jira/browse/OFBIZ-4366 Project: OFBiz Issue Type: Bug Components: framework Affects Versions: Release 4.0 Environment: Producttion Environment Issue. In one particular request, we are accessing UtilCache object 200 times via Generic Delegator, findByConditionCache and findCache methods to read entity values. Reporter: Arun Kumar Sri Assignee: Jacques Le Roux Labels: api-change Fix For: Release Branch 4.0 Original Estimate: 0.05h Remaining Estimate: 0.05h Its have been found that it is taking 3 to 4 seconds only for that. Is this some thing that how is built or ? -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (OFBIZ-3769) Entry of invoice in Trail balance after receiving PO
[ https://issues.apache.org/jira/browse/OFBIZ-3769?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jacopo Cappellato resolved OFBIZ-3769. -- Resolution: Won't Fix The release branch 4.0 is no more actively maintained. Entry of invoice in Trail balance after receiving PO Key: OFBIZ-3769 URL: https://issues.apache.org/jira/browse/OFBIZ-3769 Project: OFBiz Issue Type: New Feature Components: accounting Affects Versions: Release 4.0 Environment: windows xp Reporter: Anurag Fix For: Release Branch 4.0 Original Estimate: 48h Remaining Estimate: 48h I have a problem with ofbiz-4.0 for entry of invoice in Trail balance after receiving PO while it is working fine with ofbiz 9.0 after configure the financial account to party group but not with ofbiz-4.0 after making the same configuration . could any one tell me there is any other configuration also required in ofbiz-4.0. or can i implement any patch in ofbiz4.0 for solving this problem. Regards Anurag Walia -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (OFBIZ-2486) Next button/link on Physical Inventory Screen does not work
[ https://issues.apache.org/jira/browse/OFBIZ-2486?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jacopo Cappellato resolved OFBIZ-2486. -- Resolution: Won't Fix The release branch 4.0 is no more actively maintained. Next button/link on Physical Inventory Screen does not work --- Key: OFBIZ-2486 URL: https://issues.apache.org/jira/browse/OFBIZ-2486 Project: OFBiz Issue Type: Bug Components: product Affects Versions: Release 4.0 Environment: Sql Server 2005 Reporter: Brian Sanders Fix For: Release Branch 4.0 To reproduce (requires 100 inventory items, which should already be there): Goto Facility WebStoreWarehouse Physical Inventory Input % as the product id Scroll to the bottom and click Next The problem is that the facilityId is in the query string 2 times which yields the following query on SQL Server 2005: SELECT PR.FACILITY_ID, II.COMMENTS, PR.PRODUCT_ID, PR.PRODUCT_TYPE_ID, PR.PRIMARY_PRODUCT_CATEGORY_ID, PR.MANUFACTURER_PARTY_ID, PR.INTRODUCTION_DATE, PR.SUPPORT_DISCONTINUATION_DATE, PR.SALES_DISCONTINUATION_DATE, PR.SALES_DISC_WHEN_NOT_AVAIL, PR.INTERNAL_NAME, PR.BRAND_NAME, PR.COMMENTS, PR.PRODUCT_NAME, PR.DESCRIPTION, PR.LONG_DESCRIPTION, PR.PRICE_DETAIL_TEXT, PR.SMALL_IMAGE_URL, PR.MEDIUM_IMAGE_URL, PR.LARGE_IMAGE_URL, PR.DETAIL_IMAGE_URL, PR.DETAIL_SCREEN, PR.INVENTORY_MESSAGE, PR.REQUIRE_INVENTORY, PR.QUANTITY_UOM_ID, PR.QUANTITY_INCLUDED, PR.PIECES_INCLUDED, PR.REQUIRE_AMOUNT, PR.FIXED_AMOUNT, PR.AMOUNT_UOM_TYPE_ID, PR.WEIGHT_UOM_ID, PR.WEIGHT, PR.HEIGHT_UOM_ID, PR.PRODUCT_HEIGHT, PR.SHIPPING_HEIGHT, PR.WIDTH_UOM_ID, PR.PRODUCT_WIDTH, PR.SHIPPING_WIDTH, PR.DEPTH_UOM_ID, PR.PRODUCT_DEPTH, PR.SHIPPING_DEPTH, PR.PRODUCT_RATING, PR.RATING_TYPE_ENUM, PR.RETURNABLE, PR.TAXABLE, PR.TAX_CATEGORY, PR.TAX_VAT_CODE, PR.TAX_DUTY_CODE, PR.CHARGE_SHIPPING, PR.AUTO_CREATE_KEYWORDS, PR.INCLUDE_IN_PROMOTIONS, PR.IS_VIRTUAL, PR.IS_VARIANT, PR.ORIGIN_GEO_ID, PR.REQUIREMENT_METHOD_ENUM_ID, PR.BILL_OF_MATERIAL_LEVEL, PR.RESERV_MAX_PERSONS, PR.RESERV2ND_P_P_PERC, PR.RESERV_NTH_P_P_PERC, PR.CREATED_DATE, PR.CREATED_BY_USER_LOGIN, PR.LAST_MODIFIED_DATE, PR.LAST_MODIFIED_BY_USER_LOGIN, PR.IN_SHIPPING_BOX, II.INVENTORY_ITEM_ID, II.INVENTORY_ITEM_TYPE_ID, II.PARTY_ID, II.OWNER_PARTY_ID, II.STATUS_ID, II.DATETIME_RECEIVED, II.DATETIME_MANUFACTURED, II.EXPIRE_DATE, II.FACILITY_ID, II.CONTAINER_ID, II.LOT_ID, II.UOM_ID, II.BIN_NUMBER, II.LOCATION_SEQ_ID, II.QUANTITY_ON_HAND_TOTAL, II.AVAILABLE_TO_PROMISE_TOTAL, II.QUANTITY_ON_HAND, II.AVAILABLE_TO_PROMISE, II.SERIAL_NUMBER, II.SOFT_IDENTIFIER, II.ACTIVATION_NUMBER, II.ACTIVATION_VALID_THRU, II.UNIT_COST, II.CURRENCY_UOM_ID FROM dbo.PRODUCT PR INNER JOIN dbo.INVENTORY_ITEM II ON PR.PRODUCT_ID = II.PRODUCT_ID WHERE (II.FACILITY_ID = ( @P0, @P1 ) AND II.INVENTORY_ITEM_TYPE_ID = @P2 AND PR.PRODUCT_ID LIKE @P3) ORDER BY PR.PRODUCT_ID ASC II.FACILITY_ID = ( @P0, @P1 ) is not valid SQL syntax I tested for the bug in 9.04 and it is not there. If I modify the URL by removing the redundant facilityId, it works. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
Can we archive the Screen Widget Redesign version in Jira?
I am doing some cleanup in Jira versions and I would like to archive the Screen Widget Redesign version: there are currently 3 tasks there (all resolved); this change will not affect them (the only effect will be that the version will disappers from the valid values in the drop down when you create a new ticket). Can I proceed? Jacopo
[jira] [Updated] (OFBIZ-4738) Minor Refactoring in CategoryWorker - use delegator instead of request in getRelatedCategoriesRet
[ https://issues.apache.org/jira/browse/OFBIZ-4738?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Markus M. May updated OFBIZ-4738: - Attachment: OFBIZ-refactor_category_worker.patch Minor Refactoring in CategoryWorker - use delegator instead of request in getRelatedCategoriesRet - Key: OFBIZ-4738 URL: https://issues.apache.org/jira/browse/OFBIZ-4738 Project: OFBiz Issue Type: Improvement Components: product Affects Versions: SVN trunk Reporter: Markus M. May Priority: Trivial Fix For: SVN trunk Attachments: OFBIZ-refactor_category_worker.patch The method getRelatedCategoriesRet uses the request, the final called method could be called using the delegator directly easily. I have refactored the method accordingly. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: Lose Weight Program for OFBiz
Hi Jacopo, I have few questions on the proposed idea for Extras. -- Since the projects will be hosted as Apache OFBiz Extras and not officially under ASF, In future does this means these projects should strictly follow the ASF license? What if user group and/or the code maintainer of the project tries to change any such thing over time? -- Will all committers from OFBiz other than the maintainer still have a commit rights to Extras? I believe maintainer would be any existing committer(s) or new committer(s) assigned to the project(s) in Extras. -- Will the OFBiz community in general still be keeping track of development, discussions, future of these projects or any other activities? -- Is it necessary for Apache OFBiz Extras projects to follow the release policy similar to OFBiz? -- If no one come forward for a certain project under specialpurpose, it will be moved to Attic. What if, in future someone show interest in the project, will the project be moved Extras or not? Regards Vikas On Mar 18, 2012, at 2:40 PM, Jacopo Cappellato wrote: In the last period the OFBiz project has grown a lot in shape: the implicitly accepted (or tolerated) strategy operated by the active committers was that the more features you could add to the official repository the better was: you make happy the contributors, making them feel like they are a part of something, and each committer could manage the code implemented for his/her own projects directly in the OFBiz codebase. We operated under the concept that, since the code if free and the author (committer or not) is willing to contribute it, then no one should/could complain if it is added to the repository, if it doesn't cause immediate problems to others; all in all it is an additional feature that may be used by someone else in the future or if not would simply stay there without causing any harm. Following this strategy we got a lot of code like for example Webslinger, seleniumxml, debian packages, all sort of specialpurpose applications etc... Since there was not a central and agreed upon roadmap, no one could really state that a contribution was not a good fit for the project: each and every committer could add what, in his own personal vision, was good for the project. The wrong assumption is that, since the code if free then it doesn't harm to include it. This is completely *wrong*: the code is not *free* at all because as soon as you add it to the repository then you add a future cost to the community: you all know that in the software industry the cost to maintain a piece of code is by far greater than the cost to write it; and you *have* to maintain the code unless you want to have and distribute stale code. And this is exactly what we have now: * high costs to maintain the code (e.g. I recently spent a lot of hours to remove the Webslinger component) * stale/unused/half baked code that causes confusion and bad impression to user evaluating the quality of our product The message to all the committers is: when you add code to the repository, you are asking the community to take care of its maintenance costs forever. So please, add new code only when it is really beneficial to the project and to a large audience of committers and users. It is like feeding a wild animal at the zoo with chips: everyone knows it is bad for its health but when you are there it is so nice when it picks the food from your own hands and you cannot resist and have to feed it. OFBiz is now suffering from serious weight issues: the committers community is having an hard time to maintain the huge codebase, it is difficult to keep track of all the features in the system etc... I think it is important to start a new phase of the project and focus our energy in cleanup and consolidation of what we have. One step in this direction is for OFBiz to lose weight. In order to get the ball rolling and focus on some concrete tasks I am providing here some examples of stuff that I would like to see removed from the project. IMPORTANT: Please consider that the list is not based on what I think the perfect framework should be (so PLEASE do not reply stating what your ideal framework should have), but simply on the following considerations: * can the component be easily removed by the project? is it independent and can live outside as a plugin? * do we need all this custom code? can't we find a simpler, lighter and better way to implement this? * is this feature used by other code in the system? * is the feature functional? or is it largely incomplete? * is this an old component/code? * is this used by a lot of persons? (this is tricky to decide but you can get a feeling of it by reading the mailing lists, considering commit activity, the status of the feature etc...) DISCLAIMER: I know it will be a painful decision because each of us reading this will have a connection with
[jira] [Closed] (OFBIZ-1745) gift card processer error
[
https://issues.apache.org/jira/browse/OFBIZ-1745?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jacques Le Roux closed OFBIZ-1745.
--
gift card processer error
-
Key: OFBIZ-1745
URL: https://issues.apache.org/jira/browse/OFBIZ-1745
Project: OFBiz
Issue Type: Bug
Components: accounting
Affects Versions: Release 4.0
Environment: windows
Reporter: bj_zhou
Fix For: Release Branch 4.0
2008-04-10 00:57:53,843 (http-0.0.0.0-8443-Processor3) [
ModelService.java:481:ERROR] [ModelService.validate] : {ofbGcProcessor} :
(IN) Required test error: org.ofbiz.service.ServiceValidationException: The
following required parameter is missing:: [IN]
[ofbGcProcessor.billToParty]The following required parameter is missing::
[IN] [ofbGcProcessor.giftCard]The following required parameter is missing::
[IN] [ofbGcProcessor.orderId]The following required parameter is missing::
[IN] [ofbGcProcessor.orderItems]
2008-04-10 00:57:53,843 (http-0.0.0.0-8443-Processor3) [
ServiceDispatcher.java:333:ERROR]
exception report
--
Incoming context (in runSync : ofbGcProcessor) does not match expected
requirements
Exception: org.ofbiz.service.ServiceValidationException
Message: The following required parameter is missing:: [IN]
[ofbGcProcessor.billToParty]The following required parameter is missing::
[IN] [ofbGcProcessor.giftCard]The following required parameter is missing::
[IN] [ofbGcProcessor.orderId]The following required parameter is missing::
[IN] [ofbGcProcessor.orderItems]
stack trace
---
org.ofbiz.service.ServiceValidationException: The following required
parameter is missing:: [IN] [ofbGcProcessor.billToParty]The following
required parameter is missing:: [IN] [ofbGcProcessor.giftCard]The following
required parameter is missing:: [IN] [ofbGcProcessor.orderId]The following
required parameter is missing:: [IN] [ofbGcProcessor.orderItems]
org.ofbiz.service.ModelService.validate(ModelService.java:523)
org.ofbiz.service.ModelService.validate(ModelService.java:478)
org.ofbiz.service.ServiceDispatcher.runSync(ServiceDispatcher.java:331)
org.ofbiz.service.ServiceDispatcher.runSync(ServiceDispatcher.java:214)
org.ofbiz.service.GenericDispatcher.runSync(GenericDispatcher.java:166)
org.ofbiz.accounting.payment.PaymentGatewayServices.capturePayment(PaymentGatewayServices.java:1541)
org.ofbiz.accounting.payment.PaymentGatewayServices.capturePayment(PaymentGatewayServices.java:1447)
org.ofbiz.accounting.payment.PaymentGatewayServices.captureOrderPayments(PaymentGatewayServices.java:1179)
sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
java.lang.reflect.Method.invoke(Method.java:585)
org.ofbiz.service.engine.StandardJavaEngine.serviceInvoker(StandardJavaEngine.java:94)
org.ofbiz.service.engine.StandardJavaEngine.runSync(StandardJavaEngine.java:56)
org.ofbiz.service.ServiceDispatcher.runSync(ServiceDispatcher.java:347)
org.ofbiz.service.ServiceDispatcher.runSync(ServiceDispatcher.java:214)
org.ofbiz.service.GenericDispatcher.runSync(GenericDispatcher.java:152)
org.ofbiz.accounting.payment.PaymentGatewayServices.capturePaymentsByInvoice(PaymentGatewayServices.java:986)
sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
java.lang.reflect.Method.invoke(Method.java:585)
org.ofbiz.service.engine.StandardJavaEngine.serviceInvoker(StandardJavaEngine.java:94)
org.ofbiz.service.engine.StandardJavaEngine.runSync(StandardJavaEngine.java:56)
org.ofbiz.service.ServiceDispatcher.runSync(ServiceDispatcher.java:347)
org.ofbiz.service.ServiceDispatcher.runSync(ServiceDispatcher.java:214)
org.ofbiz.service.GenericDispatcher.runSync(GenericDispatcher.java:152)
org.ofbiz.service.eca.ServiceEcaAction.runAction(ServiceEcaAction.java:113)
org.ofbiz.service.eca.ServiceEcaRule.eval(ServiceEcaRule.java:141)
org.ofbiz.service.eca.ServiceEcaUtil.evalRules(ServiceEcaUtil.java:158)
org.ofbiz.service.ServiceDispatcher.runSync(ServiceDispatcher.java:463)
org.ofbiz.service.ServiceDispatcher.runSync(ServiceDispatcher.java:214)
org.ofbiz.service.GenericDispatcher.runSync(GenericDispatcher.java:152)
org.ofbiz.order.order.OrderServices.checkDigitalItemFulfillment(OrderServices.java:2739)
sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
[jira] [Closed] (OFBIZ-2486) Next button/link on Physical Inventory Screen does not work
[ https://issues.apache.org/jira/browse/OFBIZ-2486?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jacques Le Roux closed OFBIZ-2486. -- Next button/link on Physical Inventory Screen does not work --- Key: OFBIZ-2486 URL: https://issues.apache.org/jira/browse/OFBIZ-2486 Project: OFBiz Issue Type: Bug Components: product Affects Versions: Release 4.0 Environment: Sql Server 2005 Reporter: Brian Sanders Fix For: Release Branch 4.0 To reproduce (requires 100 inventory items, which should already be there): Goto Facility WebStoreWarehouse Physical Inventory Input % as the product id Scroll to the bottom and click Next The problem is that the facilityId is in the query string 2 times which yields the following query on SQL Server 2005: SELECT PR.FACILITY_ID, II.COMMENTS, PR.PRODUCT_ID, PR.PRODUCT_TYPE_ID, PR.PRIMARY_PRODUCT_CATEGORY_ID, PR.MANUFACTURER_PARTY_ID, PR.INTRODUCTION_DATE, PR.SUPPORT_DISCONTINUATION_DATE, PR.SALES_DISCONTINUATION_DATE, PR.SALES_DISC_WHEN_NOT_AVAIL, PR.INTERNAL_NAME, PR.BRAND_NAME, PR.COMMENTS, PR.PRODUCT_NAME, PR.DESCRIPTION, PR.LONG_DESCRIPTION, PR.PRICE_DETAIL_TEXT, PR.SMALL_IMAGE_URL, PR.MEDIUM_IMAGE_URL, PR.LARGE_IMAGE_URL, PR.DETAIL_IMAGE_URL, PR.DETAIL_SCREEN, PR.INVENTORY_MESSAGE, PR.REQUIRE_INVENTORY, PR.QUANTITY_UOM_ID, PR.QUANTITY_INCLUDED, PR.PIECES_INCLUDED, PR.REQUIRE_AMOUNT, PR.FIXED_AMOUNT, PR.AMOUNT_UOM_TYPE_ID, PR.WEIGHT_UOM_ID, PR.WEIGHT, PR.HEIGHT_UOM_ID, PR.PRODUCT_HEIGHT, PR.SHIPPING_HEIGHT, PR.WIDTH_UOM_ID, PR.PRODUCT_WIDTH, PR.SHIPPING_WIDTH, PR.DEPTH_UOM_ID, PR.PRODUCT_DEPTH, PR.SHIPPING_DEPTH, PR.PRODUCT_RATING, PR.RATING_TYPE_ENUM, PR.RETURNABLE, PR.TAXABLE, PR.TAX_CATEGORY, PR.TAX_VAT_CODE, PR.TAX_DUTY_CODE, PR.CHARGE_SHIPPING, PR.AUTO_CREATE_KEYWORDS, PR.INCLUDE_IN_PROMOTIONS, PR.IS_VIRTUAL, PR.IS_VARIANT, PR.ORIGIN_GEO_ID, PR.REQUIREMENT_METHOD_ENUM_ID, PR.BILL_OF_MATERIAL_LEVEL, PR.RESERV_MAX_PERSONS, PR.RESERV2ND_P_P_PERC, PR.RESERV_NTH_P_P_PERC, PR.CREATED_DATE, PR.CREATED_BY_USER_LOGIN, PR.LAST_MODIFIED_DATE, PR.LAST_MODIFIED_BY_USER_LOGIN, PR.IN_SHIPPING_BOX, II.INVENTORY_ITEM_ID, II.INVENTORY_ITEM_TYPE_ID, II.PARTY_ID, II.OWNER_PARTY_ID, II.STATUS_ID, II.DATETIME_RECEIVED, II.DATETIME_MANUFACTURED, II.EXPIRE_DATE, II.FACILITY_ID, II.CONTAINER_ID, II.LOT_ID, II.UOM_ID, II.BIN_NUMBER, II.LOCATION_SEQ_ID, II.QUANTITY_ON_HAND_TOTAL, II.AVAILABLE_TO_PROMISE_TOTAL, II.QUANTITY_ON_HAND, II.AVAILABLE_TO_PROMISE, II.SERIAL_NUMBER, II.SOFT_IDENTIFIER, II.ACTIVATION_NUMBER, II.ACTIVATION_VALID_THRU, II.UNIT_COST, II.CURRENCY_UOM_ID FROM dbo.PRODUCT PR INNER JOIN dbo.INVENTORY_ITEM II ON PR.PRODUCT_ID = II.PRODUCT_ID WHERE (II.FACILITY_ID = ( @P0, @P1 ) AND II.INVENTORY_ITEM_TYPE_ID = @P2 AND PR.PRODUCT_ID LIKE @P3) ORDER BY PR.PRODUCT_ID ASC II.FACILITY_ID = ( @P0, @P1 ) is not valid SQL syntax I tested for the bug in 9.04 and it is not there. If I modify the URL by removing the redundant facilityId, it works. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Closed] (OFBIZ-3769) Entry of invoice in Trail balance after receiving PO
[ https://issues.apache.org/jira/browse/OFBIZ-3769?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jacques Le Roux closed OFBIZ-3769. -- Entry of invoice in Trail balance after receiving PO Key: OFBIZ-3769 URL: https://issues.apache.org/jira/browse/OFBIZ-3769 Project: OFBiz Issue Type: New Feature Components: accounting Affects Versions: Release 4.0 Environment: windows xp Reporter: Anurag Fix For: Release Branch 4.0 Original Estimate: 48h Remaining Estimate: 48h I have a problem with ofbiz-4.0 for entry of invoice in Trail balance after receiving PO while it is working fine with ofbiz 9.0 after configure the financial account to party group but not with ofbiz-4.0 after making the same configuration . could any one tell me there is any other configuration also required in ofbiz-4.0. or can i implement any patch in ofbiz4.0 for solving this problem. Regards Anurag Walia -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Closed] (OFBIZ-4366) Accessing Ofbiz Entity UtilCache is time consuming
[ https://issues.apache.org/jira/browse/OFBIZ-4366?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jacques Le Roux closed OFBIZ-4366. -- Accessing Ofbiz Entity UtilCache is time consuming -- Key: OFBIZ-4366 URL: https://issues.apache.org/jira/browse/OFBIZ-4366 Project: OFBiz Issue Type: Bug Components: framework Affects Versions: Release 4.0 Environment: Producttion Environment Issue. In one particular request, we are accessing UtilCache object 200 times via Generic Delegator, findByConditionCache and findCache methods to read entity values. Reporter: Arun Kumar Sri Assignee: Jacques Le Roux Labels: api-change Fix For: Release Branch 4.0 Original Estimate: 0.05h Remaining Estimate: 0.05h Its have been found that it is taking 3 to 4 seconds only for that. Is this some thing that how is built or ? -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Closed] (OFBIZ-4734) User behaviour issue on auto-completer.
[ https://issues.apache.org/jira/browse/OFBIZ-4734?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jacques Le Roux closed OFBIZ-4734. -- User behaviour issue on auto-completer. --- Key: OFBIZ-4734 URL: https://issues.apache.org/jira/browse/OFBIZ-4734 Project: OFBiz Issue Type: Bug Reporter: Deepak Dixit Assignee: Ashish Vijaywargiya Priority: Minor Fix For: Release Branch 11.04, SVN trunk Attachments: OFBIZ-4734-Release11.04.patch, OFBIZ-4734-Trunk.patch Currently if user type in auto-completer text box and if matches found then list display as auto-completer result list but if no matches found then user didn't know that result will come or not, even no matches found. Change behaviour is when user type in text box then spinner (ajax loader image) shows wchich tells user that search is in progress. If matches found or not found spinner disapperars and reult/ no result message listed in auto-completer relsult list. Now user won't see any abnormal behaviour at ui. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: Lose Weight Program for OFBiz
Hi Vikas, I am sharing my ideas about this new process (they are also based on my reading of various documents provided by ASF): On Mar 21, 2012, at 8:58 AM, Vikas Mayur wrote: Hi Jacopo, I have few questions on the proposed idea for Extras. -- Since the projects will be hosted as Apache OFBiz Extras and not officially under ASF, In future does this means these projects should strictly follow the ASF license? What if user group and/or the code maintainer of the project tries to change any such thing over time? No, each project will be free to decide the license; of course the ASL2.0 will make it easier to contribute code with Apache OFBiz, but it will not be a requirement. -- Will all committers from OFBiz other than the maintainer still have a commit rights to Extras? I believe maintainer would be any existing committer(s) or new committer(s) assigned to the project(s) in Extras. Not necessarily: the maintainer could be also a non-committer and not all OFBiz committers will automatically get access to the project in Extras (you have to accept the agreement with Google etc...); this is definitely true for new projects that will start from scratch; for projects that will be contributed by the OFBiz community (by moving components out of OFBiz) we will ask to the maintainer to invite each OFBiz committer to become a committer: the ones that will accept will be setup there -- Will the OFBiz community in general still be keeping track of development, discussions, future of these projects or any other activities? I would like something like this: the OFBiz community could encourage (not oblige) the external project to send status updates to the OFBiz dev list from time to time to keep the community updated (every month/quarter or based on activity or milestones reached); I guess that the best mechanism will be refined over time with some experience -- Is it necessary for Apache OFBiz Extras projects to follow the release policy similar to OFBiz? No -- If no one come forward for a certain project under specialpurpose, it will be moved to Attic. What if, in future someone show interest in the project, will the project be moved Extras or not? Yes, we can resurrect all the code in our repository; the Attic page in Confluence will help to keep track of components that we remove. Regards, Jacopo Regards Vikas On Mar 18, 2012, at 2:40 PM, Jacopo Cappellato wrote: In the last period the OFBiz project has grown a lot in shape: the implicitly accepted (or tolerated) strategy operated by the active committers was that the more features you could add to the official repository the better was: you make happy the contributors, making them feel like they are a part of something, and each committer could manage the code implemented for his/her own projects directly in the OFBiz codebase. We operated under the concept that, since the code if free and the author (committer or not) is willing to contribute it, then no one should/could complain if it is added to the repository, if it doesn't cause immediate problems to others; all in all it is an additional feature that may be used by someone else in the future or if not would simply stay there without causing any harm. Following this strategy we got a lot of code like for example Webslinger, seleniumxml, debian packages, all sort of specialpurpose applications etc... Since there was not a central and agreed upon roadmap, no one could really state that a contribution was not a good fit for the project: each and every committer could add what, in his own personal vision, was good for the project. The wrong assumption is that, since the code if free then it doesn't harm to include it. This is completely *wrong*: the code is not *free* at all because as soon as you add it to the repository then you add a future cost to the community: you all know that in the software industry the cost to maintain a piece of code is by far greater than the cost to write it; and you *have* to maintain the code unless you want to have and distribute stale code. And this is exactly what we have now: * high costs to maintain the code (e.g. I recently spent a lot of hours to remove the Webslinger component) * stale/unused/half baked code that causes confusion and bad impression to user evaluating the quality of our product The message to all the committers is: when you add code to the repository, you are asking the community to take care of its maintenance costs forever. So please, add new code only when it is really beneficial to the project and to a large audience of committers and users. It is like feeding a wild animal at the zoo with chips: everyone knows it is bad for its health but when you are there it is so nice when it picks the food from your own hands and you cannot resist and have to feed it. OFBiz is now suffering from serious weight issues: the
Re: Lose Weight Program for OFBiz
Thanks Jacopo for your quick response. It clears my doubt. Regards Vikas On Mar 21, 2012, at 1:41 PM, Jacopo Cappellato wrote: Hi Vikas, I am sharing my ideas about this new process (they are also based on my reading of various documents provided by ASF): On Mar 21, 2012, at 8:58 AM, Vikas Mayur wrote: Hi Jacopo, I have few questions on the proposed idea for Extras. -- Since the projects will be hosted as Apache OFBiz Extras and not officially under ASF, In future does this means these projects should strictly follow the ASF license? What if user group and/or the code maintainer of the project tries to change any such thing over time? No, each project will be free to decide the license; of course the ASL2.0 will make it easier to contribute code with Apache OFBiz, but it will not be a requirement. -- Will all committers from OFBiz other than the maintainer still have a commit rights to Extras? I believe maintainer would be any existing committer(s) or new committer(s) assigned to the project(s) in Extras. Not necessarily: the maintainer could be also a non-committer and not all OFBiz committers will automatically get access to the project in Extras (you have to accept the agreement with Google etc...); this is definitely true for new projects that will start from scratch; for projects that will be contributed by the OFBiz community (by moving components out of OFBiz) we will ask to the maintainer to invite each OFBiz committer to become a committer: the ones that will accept will be setup there -- Will the OFBiz community in general still be keeping track of development, discussions, future of these projects or any other activities? I would like something like this: the OFBiz community could encourage (not oblige) the external project to send status updates to the OFBiz dev list from time to time to keep the community updated (every month/quarter or based on activity or milestones reached); I guess that the best mechanism will be refined over time with some experience -- Is it necessary for Apache OFBiz Extras projects to follow the release policy similar to OFBiz? No -- If no one come forward for a certain project under specialpurpose, it will be moved to Attic. What if, in future someone show interest in the project, will the project be moved Extras or not? Yes, we can resurrect all the code in our repository; the Attic page in Confluence will help to keep track of components that we remove. Regards, Jacopo Regards Vikas On Mar 18, 2012, at 2:40 PM, Jacopo Cappellato wrote: In the last period the OFBiz project has grown a lot in shape: the implicitly accepted (or tolerated) strategy operated by the active committers was that the more features you could add to the official repository the better was: you make happy the contributors, making them feel like they are a part of something, and each committer could manage the code implemented for his/her own projects directly in the OFBiz codebase. We operated under the concept that, since the code if free and the author (committer or not) is willing to contribute it, then no one should/could complain if it is added to the repository, if it doesn't cause immediate problems to others; all in all it is an additional feature that may be used by someone else in the future or if not would simply stay there without causing any harm. Following this strategy we got a lot of code like for example Webslinger, seleniumxml, debian packages, all sort of specialpurpose applications etc... Since there was not a central and agreed upon roadmap, no one could really state that a contribution was not a good fit for the project: each and every committer could add what, in his own personal vision, was good for the project. The wrong assumption is that, since the code if free then it doesn't harm to include it. This is completely *wrong*: the code is not *free* at all because as soon as you add it to the repository then you add a future cost to the community: you all know that in the software industry the cost to maintain a piece of code is by far greater than the cost to write it; and you *have* to maintain the code unless you want to have and distribute stale code. And this is exactly what we have now: * high costs to maintain the code (e.g. I recently spent a lot of hours to remove the Webslinger component) * stale/unused/half baked code that causes confusion and bad impression to user evaluating the quality of our product The message to all the committers is: when you add code to the repository, you are asking the community to take care of its maintenance costs forever. So please, add new code only when it is really beneficial to the project and to a large audience of committers and users. It is like feeding a wild animal at the zoo with chips: everyone knows it is bad for its health but when you
[jira] [Updated] (OFBIZ-4627) contribute Ofbiz Vietnamese tranlasting to community from HaNoi
[ https://issues.apache.org/jira/browse/OFBIZ-4627?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tri Duc Vo updated OFBIZ-4627: -- Attachment: ProductUiLabels.xml.patch ProductEntityLabels.xml.patch OrderUiLabels.xml.patch OrderEntityLabels.xml.patch MarketingUiLabels.xml.patch EcommerceUiLabels.xml.patch CommonUiLabels.xml.patch revision 1302146 Patch Files mr Jacques please revise for us Sorry I don't understand about Also when creating your patches create them from OFBiz root directory Thank you very much p/s: I don't know how to remove my older files contribute Ofbiz Vietnamese tranlasting to community from HaNoi --- Key: OFBIZ-4627 URL: https://issues.apache.org/jira/browse/OFBIZ-4627 Project: OFBiz Issue Type: Improvement Components: ALL APPLICATIONS Affects Versions: SVN trunk Reporter: Tri Duc Vo Assignee: Jacques Le Roux Labels: features Fix For: SVN trunk Attachments: CommonUiLabels.xml.patch, CommonUiLabels.xml.patch, EcommerceUiLabels.xml, EcommerceUiLabels.xml.patch, EcommerceUiLabels.xml.patch, MarketingUiLabels.xml.patch, MarketingUiLabels.xml.patch, OrderEntityLabels.xml.patch, OrderEntityLabels.xml.patch, OrderUiLabels.xml.patch, OrderUiLabels.xml.patch, ProductEntityLabels.xml.patch, ProductEntityLabels.xml.patch, ProductUiLabels.xml, ProductUiLabels.xml.patch, ProductUiLabels.xml.patch Original Estimate: 1,344h Remaining Estimate: 1,344h Dear Ofbiz community I'm Tri, from HaNoi, VietNam, and now our team build ERP based on Ofbiz opensource. Now we're completed translating 80% Ecommerce , 50% Catalog of Ofbiz. And we're going to complete 100% Vietnamese Ofbiz tranlasting and contribute them to community. We'll attach files soon Thank you -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (OFBIZ-4627) contribute Ofbiz Vietnamese tranlasting to community from HaNoi
[ https://issues.apache.org/jira/browse/OFBIZ-4627?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13234215#comment-13234215 ] Jacques Le Roux commented on OFBIZ-4627: Hi Tri, Those files looks good. I cursorily checked only.CommonUiLabels.xml.patch but from their sides I guess the others are good as well. But done from the OFBiz roo directory, it's the main OFBiz directory where you fine the LICENSE and APACHE2_HEADER files. Anyway not a big deal I will try to apply them as is and will let you know You don't have to remove the old files, as you can see they are now grayed, and it's good that you checked the grant license box. Thanks contribute Ofbiz Vietnamese tranlasting to community from HaNoi --- Key: OFBIZ-4627 URL: https://issues.apache.org/jira/browse/OFBIZ-4627 Project: OFBiz Issue Type: Improvement Components: ALL APPLICATIONS Affects Versions: SVN trunk Reporter: Tri Duc Vo Assignee: Jacques Le Roux Labels: features Fix For: SVN trunk Attachments: CommonUiLabels.xml.patch, CommonUiLabels.xml.patch, EcommerceUiLabels.xml, EcommerceUiLabels.xml.patch, EcommerceUiLabels.xml.patch, MarketingUiLabels.xml.patch, MarketingUiLabels.xml.patch, OrderEntityLabels.xml.patch, OrderEntityLabels.xml.patch, OrderUiLabels.xml.patch, OrderUiLabels.xml.patch, ProductEntityLabels.xml.patch, ProductEntityLabels.xml.patch, ProductUiLabels.xml, ProductUiLabels.xml.patch, ProductUiLabels.xml.patch Original Estimate: 1,344h Remaining Estimate: 1,344h Dear Ofbiz community I'm Tri, from HaNoi, VietNam, and now our team build ERP based on Ofbiz opensource. Now we're completed translating 80% Ecommerce , 50% Catalog of Ofbiz. And we're going to complete 100% Vietnamese Ofbiz tranlasting and contribute them to community. We'll attach files soon Thank you -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: Default package size assumed by fedex?
Hey Thanks for the reply Arun, Can you please help with a pivot to work-out which type of rate it is (list/discounted)? Also about dimensions, as the SOAP API is being used , I'd to use custom code to check Dimensions of RequestedPackage from the RateRequest and I got an NPE on 'getHeight()' method call, that clearly defines that the Dimensions for the Package are null. Also is there a way we define dimensions for a product and that are used by the service without any customization? Coz, observing the code I don't see anything like that happening somewhere. In all the rates are being calculated based on just weight and not dimensions. Regards Prince From: Arun Patidar arun.pati...@hotwaxmedia.com To: dev@ofbiz.apache.org Cc: Arun Patidar arun.pati...@hotwaxmedia.com Sent: Wednesday, March 21, 2012 11:14 AM Subject: Re: Default package size assumed by fedex? Fedex rates calculation requires weight and dimensions of packages only. Also Make sure that which type of rates you are getting, its a list rate or discounted rate of your account. Regards Arun Patidar Hotwax Media | www.hotwaxmedia.com On 20-Mar-2012, at 5:36 PM, Prince Sewani wrote: Hi All, I've a question, If the 'shipment.fedex.default.packagingType' is set to 'YOURPACKNG' , then what are the default dimensions assumed by Fedex for the package in which the product will be packed? I see a lot of difference in rates when I log-into Fedex a/c and give the zip codes, the difference in rate still lies whether I provide the dimensions of the package or not. Any pointers/clues will be of great help. Regards Prince
Re: Default package size assumed by fedex?
Hey Scott, Thanks for your reply, Does that means its the problem with API for the differences in the rates that I'm seeing? Regards Prince From: Scott. sc...@anglolimited.com To: dev@ofbiz.apache.org Sent: Tuesday, March 20, 2012 11:49 PM Subject: Re: Default package size assumed by fedex? We currently use the new FedEx Web Services API in our OFBiz installation. We'll try to create a patch and contribute it fairly soon. -- View this message in context: http://ofbiz.135035.n4.nabble.com/Default-package-size-assumed-by-fedex-tp4488552p4489853.html Sent from the OFBiz - Dev mailing list archive at Nabble.com.
Re: Lose Weight Program for OFBiz
Where are we going to show the list of addons for OFBiz? Will this only be limited to ones in Apache Extra's or for the people who prefer to do their source hosting on say github join in too? Thanks Sam On 21 Mar 2012, at 16:23, Vikas Mayur wrote: Thanks Jacopo for your quick response. It clears my doubt. Regards Vikas On Mar 21, 2012, at 1:41 PM, Jacopo Cappellato wrote: Hi Vikas, I am sharing my ideas about this new process (they are also based on my reading of various documents provided by ASF): On Mar 21, 2012, at 8:58 AM, Vikas Mayur wrote: Hi Jacopo, I have few questions on the proposed idea for Extras. -- Since the projects will be hosted as Apache OFBiz Extras and not officially under ASF, In future does this means these projects should strictly follow the ASF license? What if user group and/or the code maintainer of the project tries to change any such thing over time? No, each project will be free to decide the license; of course the ASL2.0 will make it easier to contribute code with Apache OFBiz, but it will not be a requirement. -- Will all committers from OFBiz other than the maintainer still have a commit rights to Extras? I believe maintainer would be any existing committer(s) or new committer(s) assigned to the project(s) in Extras. Not necessarily: the maintainer could be also a non-committer and not all OFBiz committers will automatically get access to the project in Extras (you have to accept the agreement with Google etc...); this is definitely true for new projects that will start from scratch; for projects that will be contributed by the OFBiz community (by moving components out of OFBiz) we will ask to the maintainer to invite each OFBiz committer to become a committer: the ones that will accept will be setup there -- Will the OFBiz community in general still be keeping track of development, discussions, future of these projects or any other activities? I would like something like this: the OFBiz community could encourage (not oblige) the external project to send status updates to the OFBiz dev list from time to time to keep the community updated (every month/quarter or based on activity or milestones reached); I guess that the best mechanism will be refined over time with some experience -- Is it necessary for Apache OFBiz Extras projects to follow the release policy similar to OFBiz? No -- If no one come forward for a certain project under specialpurpose, it will be moved to Attic. What if, in future someone show interest in the project, will the project be moved Extras or not? Yes, we can resurrect all the code in our repository; the Attic page in Confluence will help to keep track of components that we remove. Regards, Jacopo Regards Vikas On Mar 18, 2012, at 2:40 PM, Jacopo Cappellato wrote: In the last period the OFBiz project has grown a lot in shape: the implicitly accepted (or tolerated) strategy operated by the active committers was that the more features you could add to the official repository the better was: you make happy the contributors, making them feel like they are a part of something, and each committer could manage the code implemented for his/her own projects directly in the OFBiz codebase. We operated under the concept that, since the code if free and the author (committer or not) is willing to contribute it, then no one should/could complain if it is added to the repository, if it doesn't cause immediate problems to others; all in all it is an additional feature that may be used by someone else in the future or if not would simply stay there without causing any harm. Following this strategy we got a lot of code like for example Webslinger, seleniumxml, debian packages, all sort of specialpurpose applications etc... Since there was not a central and agreed upon roadmap, no one could really state that a contribution was not a good fit for the project: each and every committer could add what, in his own personal vision, was good for the project. The wrong assumption is that, since the code if free then it doesn't harm to include it. This is completely *wrong*: the code is not *free* at all because as soon as you add it to the repository then you add a future cost to the community: you all know that in the software industry the cost to maintain a piece of code is by far greater than the cost to write it; and you *have* to maintain the code unless you want to have and distribute stale code. And this is exactly what we have now: * high costs to maintain the code (e.g. I recently spent a lot of hours to remove the Webslinger component) * stale/unused/half baked code that causes confusion and bad impression to user evaluating the quality of our product The message to all the committers is: when you add code to the repository, you are asking the community to take care of its
[jira] [Updated] (OFBIZ-4627) contribute Ofbiz Vietnamese tranlasting to community from HaNoi
[ https://issues.apache.org/jira/browse/OFBIZ-4627?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tri Duc Vo updated OFBIZ-4627: -- Attachment: ProductUiLabels.xml.patch ProductEntityLabels.xml.patch OrderUiLabels.xml.patch OrderEntityLabels.xml.patch MarketingUiLabels.xml.patch EcommerceUiLabels.xml.patch CommonUiLabels.xml.patch Thank Jacques I found issue font breaking for Escape Sequence () in language key in ProductUiLabels.xml when using Tortoise patch , and attach new ProductUiLabels.xml.patch here. I have to fake and replace charactor.Example: +value xml:lang=zh_TW0 最小-gt; 到最大; 0 最大 -gt; 從最小起/value +value xml:lang=vi0 tối thiểu -gt; đến tối đa; 0 tối -gt; với ít nhất trở lên/value I created my patches from OFBiz root directory. I checked to license box, also. Please revise us Cheers contribute Ofbiz Vietnamese tranlasting to community from HaNoi --- Key: OFBIZ-4627 URL: https://issues.apache.org/jira/browse/OFBIZ-4627 Project: OFBiz Issue Type: Improvement Components: ALL APPLICATIONS Affects Versions: SVN trunk Reporter: Tri Duc Vo Assignee: Jacques Le Roux Labels: features Fix For: SVN trunk Attachments: CommonUiLabels.xml.patch, CommonUiLabels.xml.patch, CommonUiLabels.xml.patch, EcommerceUiLabels.xml, EcommerceUiLabels.xml.patch, EcommerceUiLabels.xml.patch, EcommerceUiLabels.xml.patch, MarketingUiLabels.xml.patch, MarketingUiLabels.xml.patch, MarketingUiLabels.xml.patch, OrderEntityLabels.xml.patch, OrderEntityLabels.xml.patch, OrderEntityLabels.xml.patch, OrderUiLabels.xml.patch, OrderUiLabels.xml.patch, OrderUiLabels.xml.patch, ProductEntityLabels.xml.patch, ProductEntityLabels.xml.patch, ProductEntityLabels.xml.patch, ProductUiLabels.xml, ProductUiLabels.xml.patch, ProductUiLabels.xml.patch, ProductUiLabels.xml.patch Original Estimate: 1,344h Remaining Estimate: 1,344h Dear Ofbiz community I'm Tri, from HaNoi, VietNam, and now our team build ERP based on Ofbiz opensource. Now we're completed translating 80% Ecommerce , 50% Catalog of Ofbiz. And we're going to complete 100% Vietnamese Ofbiz tranlasting and contribute them to community. We'll attach files soon Thank you -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: Default package size assumed by fedex?
Hey Jacques, Thanks for your response, I read that already, Its kinda goin that way with Almost everything these days , Firstly Amazon and now Fedex and may be other ones to come soon. Actually rather than buying those, we(The community) should also think of upgrading the existing solutions. Also the eBay ones are also not fully developed(Least to mention). Regards Prince From: Jacques Le Roux jacques.le.r...@les7arts.com To: dev@ofbiz.apache.org; Prince Sewani princesew...@ymail.com Sent: Tuesday, March 20, 2012 8:50 PM Subject: Re: Default package size assumed by fedex? Beware, see Si Chen last message on user ML On May 31, 2012, FedEx will be discontinuing its Ship Manager Direct API... Jacques From: Prince Sewani princesew...@ymail.com Hi All, I've a question, If the 'shipment.fedex.default.packagingType' is set to 'YOURPACKNG' , then what are the default dimensions assumed by Fedex for the package in which the product will be packed? I see a lot of difference in rates when I log-into Fedex a/c and give the zip codes, the difference in rate still lies whether I provide the dimensions of the package or not. Any pointers/clues will be of great help. Regards Prince
Re: Lose Weight Program for OFBiz
We will setup a page in the OFBiz website, for sure. The final decision on the projects that will appear there will be done by the OFBiz PMC but I guess that initially it will only contain projects in Apache Extras; there may be exceptions to to this rule, I guess. Jacopo On Mar 21, 2012, at 11:05 AM, Sam Hamilton wrote: Where are we going to show the list of addons for OFBiz? Will this only be limited to ones in Apache Extra's or for the people who prefer to do their source hosting on say github join in too? Thanks Sam On 21 Mar 2012, at 16:23, Vikas Mayur wrote: Thanks Jacopo for your quick response. It clears my doubt. Regards Vikas On Mar 21, 2012, at 1:41 PM, Jacopo Cappellato wrote: Hi Vikas, I am sharing my ideas about this new process (they are also based on my reading of various documents provided by ASF): On Mar 21, 2012, at 8:58 AM, Vikas Mayur wrote: Hi Jacopo, I have few questions on the proposed idea for Extras. -- Since the projects will be hosted as Apache OFBiz Extras and not officially under ASF, In future does this means these projects should strictly follow the ASF license? What if user group and/or the code maintainer of the project tries to change any such thing over time? No, each project will be free to decide the license; of course the ASL2.0 will make it easier to contribute code with Apache OFBiz, but it will not be a requirement. -- Will all committers from OFBiz other than the maintainer still have a commit rights to Extras? I believe maintainer would be any existing committer(s) or new committer(s) assigned to the project(s) in Extras. Not necessarily: the maintainer could be also a non-committer and not all OFBiz committers will automatically get access to the project in Extras (you have to accept the agreement with Google etc...); this is definitely true for new projects that will start from scratch; for projects that will be contributed by the OFBiz community (by moving components out of OFBiz) we will ask to the maintainer to invite each OFBiz committer to become a committer: the ones that will accept will be setup there -- Will the OFBiz community in general still be keeping track of development, discussions, future of these projects or any other activities? I would like something like this: the OFBiz community could encourage (not oblige) the external project to send status updates to the OFBiz dev list from time to time to keep the community updated (every month/quarter or based on activity or milestones reached); I guess that the best mechanism will be refined over time with some experience -- Is it necessary for Apache OFBiz Extras projects to follow the release policy similar to OFBiz? No -- If no one come forward for a certain project under specialpurpose, it will be moved to Attic. What if, in future someone show interest in the project, will the project be moved Extras or not? Yes, we can resurrect all the code in our repository; the Attic page in Confluence will help to keep track of components that we remove. Regards, Jacopo Regards Vikas On Mar 18, 2012, at 2:40 PM, Jacopo Cappellato wrote: In the last period the OFBiz project has grown a lot in shape: the implicitly accepted (or tolerated) strategy operated by the active committers was that the more features you could add to the official repository the better was: you make happy the contributors, making them feel like they are a part of something, and each committer could manage the code implemented for his/her own projects directly in the OFBiz codebase. We operated under the concept that, since the code if free and the author (committer or not) is willing to contribute it, then no one should/could complain if it is added to the repository, if it doesn't cause immediate problems to others; all in all it is an additional feature that may be used by someone else in the future or if not would simply stay there without causing any harm. Following this strategy we got a lot of code like for example Webslinger, seleniumxml, debian packages, all sort of specialpurpose applications etc... Since there was not a central and agreed upon roadmap, no one could really state that a contribution was not a good fit for the project: each and every committer could add what, in his own personal vision, was good for the project. The wrong assumption is that, since the code if free then it doesn't harm to include it. This is completely *wrong*: the code is not *free* at all because as soon as you add it to the repository then you add a future cost to the community: you all know that in the software industry the cost to maintain a piece of code is by far greater than the cost to write it; and you *have* to maintain the code unless you want to have and distribute stale code. And this is exactly what we have now: * high costs to maintain
Re: loop code simplification
Well I don't know why is it suggested so as in the mail by Paul,
But as I already mentioned :
- Forwarded Message -
From: Prince Sewani princesew...@ymail.com
To: dev@ofbiz.apache.org dev@ofbiz.apache.org
Sent: Tuesday, March 20, 2012 5:46 PM
Subject: Re: loop code simplification
Well If we're talking about the 'Enhanced For loop' in Java from 1.5 onwards
Then it goes something like this, you'll only get NPE if you haven't
initialized the collection,
otherwise if you've initialized the collection and there are no values in it
then
the for loop won't execute any iteration.
For example :
import java.util.ArrayList;
class Test{
static ArrayListStringt;
public static void main(String [] args){
System.out.println(before===);
for(String k : t){
System.out.println(+k);
}
System.out.println(after===);
}
}
The above program will generate an NPE when ran and the output will be :
before===
Exception in thread main java.lang.NullPointerException
at Test.main(Test.java:11)
but if I replace the ArrayList declaration with :
static ArrayListString t = new ArrayListString();
then the output will be :
before===
after===
Hope this helps.
Regards
Prince
Java does take care of it.
Regards
Prince
From: Jacques Le Roux jacques.le.r...@les7arts.com
To: dev@ofbiz.apache.org
Sent: Tuesday, March 20, 2012 8:36 PM
Subject: Re: loop code simplification
BTW, this shows how stupid is the for loop in Java implementation. The
suggested safeList() should be handled by the compiler IMO, I
see no gains to not have it in but to get NPEs. Did I miss something?
Jacques
From: Paul Foxworthy p...@cohsoft.com.au
Hi Erwan,
To be sure there is no Null Pointer Exception, yes, you need to test for
null first. One possibility is to just let the NPE happen.
The discussion at
http://stackoverflow.com/questions/2250031/null-check-in-an-enhanced-for-loop
suggests
for( Object o : safe( list ) ) {
// do whatever
}
Where safe would be:
public static List safe( List other ) {
return other == null ? Collections.EMPTY_LIST : other;
}
Cleaner code. I suspect the method would be inlined by most Java compilers.
Cheers
Paul Foxworthy
Erwan de FERRIERES-3 wrote
Hi,
I'm trying to remove a lot of iterators, and use the for-each syntax,
which exists since java 1.5.
During my journey, I found a lot of double tests for a while like this
one:
while (typePurposes != null typePurposes.hasNext()) {
(ContactMechWorker.java line 606)
Can it be simplified to for(GenericValue contactMechTypePurpose :
theList) ? Or should I keep it like it is ?
Regards,
--
Erwan de FERRIERES
www.nereide.biz
-
--
Coherent Software Australia Pty Ltd
http://www.cohsoft.com.au/
Bonsai ERP, the all-inclusive ERP system
http://www.bonsaierp.com.au/
--
View this message in context:
http://ofbiz.135035.n4.nabble.com/loop-code-simplification-tp4487741p4488324.html
Sent from the OFBiz - Dev mailing list archive at Nabble.com.
Re: Lose Weight Program for OFBiz - themes
I prefer to keep the Flat Grey and one other. Op 20 maart 2012 12:48 schreef Jacopo Cappellato jacopo.cappell...@hotwaxmedia.com het volgende: I) $OFBIZ_HOME/themes/*: move a few of them to Attic and a few of them to Extras; keep just one (or two) Jacques proposed to keep Tomahawk (default) and Flat Grey. Olivier proposed to keep just one (Tomahawk, I guess). No other comments so far. What should be do with the remaining themes? Attic or Extras? Are there volunteers for Extras? I would suggest that, if we move them to Extras we create *one* project only (for all the themes) rather than one project for theme... but I would love to get your feedback on this. Jacopo
Re: Lose Weight Program for OFBiz - example, exampleext
+1 on removal from core (framework), as it doesn't add any value in a framework. However, having it available as a separate downloadable application (to be used from hot-deploy or special purpose) would be beneficiary for newcomers in the development scene. Regards, Pierre Op 20 maart 2012 12:47 schreef Jacopo Cappellato jacopo.cappell...@hotwaxmedia.com het volgende: Q) framework/example and framework/exampleext: move to specialpurpose Adrian would like to keep Example in the framework but slim it down a lot to the essential (no form widgets examples, no Ajax examples, no content examples etc...). Adrian would you please confirm if in your vision the example application should document the layout of a typical OFBiz component only? If yes, we could use the output of the ant create-component task to document the best practice layout. Jacques, Olivier would like to keep also the examples for the various higher level features available to OFBiz applications. I think that from the discussion it could emerge the following solution to please everyone: * keep the example component in the framework but slim it down to the bare essential * move the exampleext component to specialpurpose and migrate to it all the extra features: this could also be used as a best practice guide on how to extend a component from hot-deploy/specialpurpose I still think that it would be nicer to not bundle the example component ootb to keep the framework cleaner: the example should be downloaded separately (when we will have clear separation between framework and the rest); this approach is similar to tomcat and its example applications. But I don't have a strong opinion on this. Jacopo
Re: bin folder for executable files/scripts
Well the 'bin' clashing with eclipse default is really a concern to being with, the learning curve is yet steep, and with to dos of IDE's as of now, everyone is pretty much acquainted. Also in-case we change it to 'bin' in the main folder, then there'll be an additional set of documentation required for that to help users on different Operating systems. Unless we go like opentaps (felt that on a few things) and then one is not really able to use it (Just a comment No offense). tools/bin sounds great, unless that also doesn't call of any other clash or so. Regards Prince From: Mansour Al Akeel mansour.alak...@gmail.com To: dev@ofbiz.apache.org Sent: Monday, March 19, 2012 4:13 PM Subject: Re: bin folder for executable files/scripts bin is good enough. On Mon, Mar 19, 2012 at 3:34 AM, Jacques Le Roux jacques.le.r...@les7arts.com wrote: Hi Jacopo, tools/bin sounds good to me Jacques From: Jacopo Cappellato jacopo.cappell...@hotwaxmedia.com Thanks everyone for the valuable comments! I am trying to finalize this thread: there seems to be consensus to move all the executable scripts into a folder to keep things organized. For the name of the folder: * some of you think that the bin (as I originally suggested) should be used because it is often used for this purpose * some of you are worried that this could interfere with some commonly used IDEs (e.g. Eclipse) that use the bin folder for output and need to be configured to use a different standard name After reviewing what we have now in OFBiz I am wondering if we could use the already existing tools folder; its current layout is: tools/api-java16 tools/src option a: add all the executables to tools/ folder directly option b: create a subfolder tools/bin and add all the executables there What do you think? Jacopo On Feb 29, 2012, at 5:45 PM, Jacques Le Roux wrote: Then we could recommend to name .bin for instance But I wonder if this will not be a source of problem for newbies... And also for Windows users, bin is not a standard name at all Jacques From: Adrian Crum adrian.c...@sandglass-software.com That's fine with me. We just need to update the Eclipse configuration files. -Adrian On 2/29/2012 3:20 PM, J. Eckard wrote: I think that eclipse / eclipse users should have to accommodate the directory structure of OFBiz, not the other way around. On Feb 29, 2012, at 9:58 AM, Jacopo Cappellato wrote: Thanks for the feedback! Any suggestion for the name of the folder? I was hoping to use a standard name, that is why I initially proposed the bin folder... but since that is not an option we will have to think to something else (unless we use the existing tools folder but I am not sure about the intended usage of that). Jacopo On Feb 27, 2012, at 8:45 PM, Jacques Le Roux wrote: +1 Jacques From: Adrian Crumadrian.c...@sandglass-software.com Sounds great, but don't use bin - that folder is created by Eclipse and it is in the SVN ignore list. -Adrian On 2/27/2012 7:10 PM, Jacopo Cappellato wrote: The number of executable files (*.sh and *bat) in the OFBiz home folder is rather big: what if we create a bin folder and we move all of them there? In this way users will have a place where they will find all the executable files only and the main folder will be cleaner. Jacopo
[jira] [Updated] (OFBIZ-4627) contribute Ofbiz Vietnamese tranlasting to community from HaNoi
[ https://issues.apache.org/jira/browse/OFBIZ-4627?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tri Duc Vo updated OFBIZ-4627: -- Attachment: ProductUiLabels.xml.patch ProductEntityLabels.xml.patch OrderUiLabels.xml.patch OrderEntityLabels.xml.patch MarketingUiLabels.xml.patch EcommerceUiLabels.xml.patch CommonUiLabels.xml.patch Check our latest files, man Patch for (revision 1303345) contribute Ofbiz Vietnamese tranlasting to community from HaNoi --- Key: OFBIZ-4627 URL: https://issues.apache.org/jira/browse/OFBIZ-4627 Project: OFBiz Issue Type: Improvement Components: ALL APPLICATIONS Affects Versions: SVN trunk Reporter: Tri Duc Vo Assignee: Jacques Le Roux Labels: features Fix For: SVN trunk Attachments: CommonUiLabels.xml.patch, CommonUiLabels.xml.patch, CommonUiLabels.xml.patch, CommonUiLabels.xml.patch, EcommerceUiLabels.xml, EcommerceUiLabels.xml.patch, EcommerceUiLabels.xml.patch, EcommerceUiLabels.xml.patch, EcommerceUiLabels.xml.patch, MarketingUiLabels.xml.patch, MarketingUiLabels.xml.patch, MarketingUiLabels.xml.patch, MarketingUiLabels.xml.patch, OrderEntityLabels.xml.patch, OrderEntityLabels.xml.patch, OrderEntityLabels.xml.patch, OrderEntityLabels.xml.patch, OrderUiLabels.xml.patch, OrderUiLabels.xml.patch, OrderUiLabels.xml.patch, OrderUiLabels.xml.patch, ProductEntityLabels.xml.patch, ProductEntityLabels.xml.patch, ProductEntityLabels.xml.patch, ProductEntityLabels.xml.patch, ProductUiLabels.xml, ProductUiLabels.xml.patch, ProductUiLabels.xml.patch, ProductUiLabels.xml.patch, ProductUiLabels.xml.patch Original Estimate: 1,344h Remaining Estimate: 1,344h Dear Ofbiz community I'm Tri, from HaNoi, VietNam, and now our team build ERP based on Ofbiz opensource. Now we're completed translating 80% Ecommerce , 50% Catalog of Ofbiz. And we're going to complete 100% Vietnamese Ofbiz tranlasting and contribute them to community. We'll attach files soon Thank you -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: Can we archive the Screen Widget Redesign version in Jira?
+1 Op 21 maart 2012 08:03 schreef Jacopo Cappellato jacopo.cappell...@hotwaxmedia.com het volgende: I am doing some cleanup in Jira versions and I would like to archive the Screen Widget Redesign version: there are currently 3 tasks there (all resolved); this change will not affect them (the only effect will be that the version will disappers from the valid values in the drop down when you create a new ticket). Can I proceed? Jacopo
Re: Lose Weight Program for OFBiz - ofbizwebsite
+1 Op 20 maart 2012 12:48 schreef Jacopo Cappellato jacopo.cappell...@hotwaxmedia.com het volgende: G) specialpurpose/ofbizwebsite: move to Attic Jacques and Olivier proposed to move it to Extras instead just in case someone will pick up the work and complete it in the future. I would like to mention that, if the original goal was to eat our own dog food and run the OFBiz site on it, then this could be in contrast with the ASF infrastructure offered to the projects. Jacopo
Re: Lose Weight Program for OFBiz JCR function
Re 1: keep in framework +1 Re 2: remove from upcoming release 12.04 +1, remove from all upcoming future releases until 3 is finished Re 3: draft up requirements for content framework replacement +1 Excellent roadmapping ;-) Regards, Pierre Op 20 maart 2012 11:48 schreef Jacopo Cappellato jacopo.cappell...@hotwaxmedia.com het volgende: Or alternatively we could: 1) keep it in framework 2) but remove it from the upcoming new release branch 12.04 3) and then, as a community, we could start the effort (i.e. top priority for upcoming contributions/commits) of defining the set of requirements needed by the applications to replace the existing Content framework, finalizing the architecture and start working all on the implementation and migration of existing applications: this would mean that the community will focus on this refactoring effort for a while (postponing any other new development to focus the energy) At least in this way we could experiment if the concept of a roadmap is a viable options and we will not keep and distribute a component under development waiting to see if and when something good will come out of it. Jacopo On Mar 20, 2012, at 11:32 AM, Jacopo Cappellato wrote: On Mar 20, 2012, at 10:15 AM, Olivier Heintz wrote: New thread for only JCR funstion Summary of initial discussion: Jacoppo: N) framework/jcr: move back into the Jackrabbit branch until the work is completed and can replace the existing content framework Hans: Also moving the JCR function out is not a good idea however when not improved in the next few months using the content manager, i would agree to a removal. Jacoppo Keep it mind we are preparing for the creation of the new release branch (12.04): this would mean that all the future releases for 12.04 will be bundled with an incomplete JCR/Jackrabbit integration that duplicates (but not replaces) the existing Component framework. This is alone a good reason for moving this work back to the development branch and will save a lot of future work in backporting features if security issues or bugs will be discovered. IMO, jcr will be a good enhancement in ofbiz, but currently we(the company I'm working for) are using content component in a lot of place, product, workeffort, project, party, custRequest, to manage files, so we area waiting the next step of the jcr OFBiz (content) integration. Meanwhile this second step, if jcr was a plugin, we will use it for some new customer project (and maybe contribute on ;-) but not use it for older customer which currently works with OFBiz solution to avoid using not completely implement feature. So IMO, jcr should move, branch or extra, but I prefer as a plugin to be able to used it easily. I didn't follow the details of the plans for JCR/Jackrabbit integration but as far as I understand it it is intended to be highly integrated with OFBiz (to replace Content Framework features): I am not sure how this is inline with Olivier's idea of a plugin, but it is an idea that can be explored. However, since we are still in this design phase I think it is a good idea to keep the component in the development branch in the meantime. Jacopo
Re: Lose Weight Program for OFBiz - ofbizwebsite
then this could be in contrast with the ASF infrastructure offered to the projects. - ??? try: http://demo-trunk.ofbiz.apache.org/ofbiz/ Regards, Hans On 03/20/2012 06:48 PM, Jacopo Cappellato wrote: G) specialpurpose/ofbizwebsite: move to Attic Jacques and Olivier proposed to move it to Extras instead just in case someone will pick up the work and complete it in the future. I would like to mention that, if the original goal was to eat our own dog food and run the OFBiz site on it, then this could be in contrast with the ASF infrastructure offered to the projects. Jacopo
Re: Lose Weight Program for OFBiz - guiapp and pos
A) removal of framework/guiapp out of framework: +1 B) move specialpurpose/pos to 'Extras' +1 I am not in favour of moving ProjectMgr out of specialpurpose to 'Extras' as the majority of my customers use this. However, if it goes to 'Extras' I would like to assist in maintaining it. Regards, Pierre Op 20 maart 2012 12:47 schreef Jacopo Cappellato jacopo.cappell...@hotwaxmedia.com het volgende: A) move framework/guiapp out of the framework; after all these years no code made advantage of it being part of the framework and it is only used by the specialpurpose/pos component (which was the component for which it was built for); so guiapp can go in the pos component B) specialpurpose/pos: move to Extras No one objected so far; Jacques offered his help for #A. Should we focus on #A for now (it is an actionable item) and then discuss #B also based on the outcome of similar discussions for other specialpurpose components?
Re: Lose Weight Program for OFBiz - debian, seleniumxml, workflow, shark, appserver, jetty
On all: +1 Regards, Pierre Op 20 maart 2012 12:48 schreef Jacopo Cappellato jacopo.cappell...@hotwaxmedia.com het volgende: C) $OFBIZ_HOME/debian: move to Attic D) the seleniumxml code in framework/testtools: move to Attic E) specialpurpose/workflow: move to Attic F) specialpurpose/shark: move to Attic J) framework/appserver: move to Extras K) framework/jetty: move to Extras (or Attic) The above are components/features that don't seem to be used/maintained by the community: some of them are very old (workflow, shark, appserver, jetty), some of them are experimental (shark, seleniumxml), some of them are very specialized (debian). I have proposed some of them for the Attic and some of them for the Extras but in theory all of them could go to Extras if we find at least one maintainer for each; if not, each of them could go to Attic. Any ideas? volunteers (OFBiz committers or not)? No one objected or commented on them so far (so I suspect that there could be a lazy consensus); for the seleniumxml code there was also a thread some weeks ago in the user list where there seemed to be a general consensus (also from the original contributors of the work) for the removal (apart from Hans who is using it, it doesn't seem to be used much by the community). Jacopo
Re: Lose Weight Program for OFBiz - what should go to specialpurpose
+ 1 on move of majority of apps in specialpurpose to 'Extras', excluding projectmgr as it displays how to use OFBiz in a different industry than ecommerce/webshop. Is it not so that OFBiz is versatile. ProjectMgr does deliver some of that versatility. Regards, Pierre Op 20 maart 2012 12:47 schreef Jacopo Cappellato jacopo.cappell...@hotwaxmedia.com het volgende: H) specialpurpose/*: move several (if not all, apart ecommerce) of the components to Extras (if there are persons interested to become committers/maintainers) or to Attic There seems to be a general agreement to slim down the number of applications in this group and move them to Extras (see exceptions below). I am summarizing here some notes but we should actually use this thread to continue the discussion about what should go to specialpurpose in general rather than focusing on the decision about removal of specific applications; we can then start a separate thread for each component. Adrian would like to keep one or two components to demonstrate the concept of reusing artifacts to create custom applications (Jacopo: can we use the exampleext component for this?) Hans would like to keep the ones that he considers feature complete like asset maintenance, LDAP, POS, e-commerce, cmssite, projectmgr and scrum. Jacopo: in my opinion even in the above list provided by Hans there are applications that are barely examples (cmssite) or are very specific implementation of very specific requirements (difficult to be used if your company doesn't have exactly these requirements): projectmgr and scrum; some of these components also extends (adding special purpose fields) the generic data model and this happens even if the user is not interested in evaluating the specialpurpose component. I also don't think that some of the components meet minimum quality requirements to be distributed with OFBiz: for example the scrum component uses a mechanism that is unique to demo its features (i.e. published a demo webapp with online instructions for demo data) that is not used by other applications (and this makes the suite of applications inconsistent); also, the component refers to resources that are owned by Hans' company. All in all, they seem very specific piece of codes that should better live as optional plugins downloaded separately. So in my opinion the concept of specialpurpose application is in general better suited for Apache Extras rather than for the OFBiz svn and releases.
Re: Lose Weight Program for OFBiz - documents
+1. This is an example of bloat. Keeping ill-maintained static documents in OFBiz (the suite) that are also available through the OFBiz website is not adding value. Regards, Pierre Op 20 maart 2012 12:48 schreef Jacopo Cappellato jacopo.cappell...@hotwaxmedia.com het volgende: O) framework/documents: move the content to Wiki and then move to Attic The broader topic is to move all the artifacts related to online help out of the framework; they should all live under applications.
[jira] [Commented] (OFBIZ-4627) contribute Ofbiz Vietnamese tranlasting to community from HaNoi
[ https://issues.apache.org/jira/browse/OFBIZ-4627?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13234277#comment-13234277 ] Paul Foxworthy commented on OFBIZ-4627: --- Hello Tri, Thank you very much for your contribution. What we mean by create patches from the root directory is described in https://cwiki.apache.org/confluence/display/OFBADMIN/OFBiz+Contributors+Best+Practices In particular this part: We prefer that you build your patch from the root as it's easier for commiters to merge your change. So please make your patch files from the OFBIZ_HOME directory (usually ofbiz/) and with relative file paths. Relative file paths means that in your patch file names should look like these : applications/party/widget/partymgr/PartyScreens.xml framework/webtools/config/WebtoolsErrorUiLabels.properties and should not have file names like: C:\myfiles\ofbiz\applications\party\widget\partymgr\PartyScreens.xml The idea behind this is that maintainers can apply a patch to several different parts of OFBiz without having to first navigate to the specific directory that contains the file to be patched. If every contributor makes it easier to apply patches, a committer is more likely to do so and put our hard work into the trunk revision of OFBiz. Your patches have just the file name without any path, so I presume you are creating them by doing a diff on the actual file that you've changed. Try doing a diff on the ofbiz directory instead, and see if you get relative paths in the patch file. This is really not very important, just making it a little easier for committers. I am sure the OFBiz community would prefer to have your patches even if the file name is not ideal. I really appreciate your efforts and I'm pleased to see Vietnamese support added to OFBiz. Cheers Paul Foxworthy contribute Ofbiz Vietnamese tranlasting to community from HaNoi --- Key: OFBIZ-4627 URL: https://issues.apache.org/jira/browse/OFBIZ-4627 Project: OFBiz Issue Type: Improvement Components: ALL APPLICATIONS Affects Versions: SVN trunk Reporter: Tri Duc Vo Assignee: Jacques Le Roux Labels: features Fix For: SVN trunk Attachments: CommonUiLabels.xml.patch, CommonUiLabels.xml.patch, CommonUiLabels.xml.patch, CommonUiLabels.xml.patch, EcommerceUiLabels.xml, EcommerceUiLabels.xml.patch, EcommerceUiLabels.xml.patch, EcommerceUiLabels.xml.patch, EcommerceUiLabels.xml.patch, MarketingUiLabels.xml.patch, MarketingUiLabels.xml.patch, MarketingUiLabels.xml.patch, MarketingUiLabels.xml.patch, OrderEntityLabels.xml.patch, OrderEntityLabels.xml.patch, OrderEntityLabels.xml.patch, OrderEntityLabels.xml.patch, OrderUiLabels.xml.patch, OrderUiLabels.xml.patch, OrderUiLabels.xml.patch, OrderUiLabels.xml.patch, ProductEntityLabels.xml.patch, ProductEntityLabels.xml.patch, ProductEntityLabels.xml.patch, ProductEntityLabels.xml.patch, ProductUiLabels.xml, ProductUiLabels.xml.patch, ProductUiLabels.xml.patch, ProductUiLabels.xml.patch, ProductUiLabels.xml.patch Original Estimate: 1,344h Remaining Estimate: 1,344h Dear Ofbiz community I'm Tri, from HaNoi, VietNam, and now our team build ERP based on Ofbiz opensource. Now we're completed translating 80% Ecommerce , 50% Catalog of Ofbiz. And we're going to complete 100% Vietnamese Ofbiz tranlasting and contribute them to community. We'll attach files soon Thank you -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: Lose Weight Program for OFBiz - documents
The idea behind this that documents in wiki are not according the version..(only the latest) This directory has it for the related version AND can be in different languages and formats: html, pdf do judge before you understand.. Regards, Hans On 03/21/2012 06:01 PM, Pierre Smits wrote: +1. This is an example of bloat. Keeping ill-maintained static documents in OFBiz (the suite) that are also available through the OFBiz website is not adding value. Regards, Pierre Op 20 maart 2012 12:48 schreef Jacopo Cappellato jacopo.cappell...@hotwaxmedia.com het volgende: O) framework/documents: move the content to Wiki and then move to Attic The broader topic is to move all the artifacts related to online help out of the framework; they should all live under applications.
Re: Lose Weight Program for OFBiz - Birt and BI
Currently, rptdesign is used in specialpurpose applications like ebaystore
and scrum, but also in core applications (accounting, order and product).
We have to provide reports in our applications, as it would be difficult to
maintain the concept of completeness of functionality without them.
Endusers requirements always dictate some kind of reports in applications.
I prefer to have a working solution ootb in OFBiz. Birt delivers that at
the moment.
Removing it creates another proposition issue (on top of all the others we
can think of why OFBiz is hard to sell).
Replacing it by something else would dictate roadmapping.
Regards,
Pierre
Op 20 maart 2012 12:47 schreef Jacopo Cappellato
jacopo.cappell...@hotwaxmedia.com het volgende:
L) framework/birt (and related dependencies/reports spread around): move
to Extras
M) framework/bi (and related dependencies - ecas/business rules and data
- spread around): move to Extras
This is an area where Hans and I are in disagreement and we didn't get
much feedback from others.
So I would like to explain here why I think we should move the Birt
component and the Birt reports out of the framework and consider them as
optional tools.
There are currently 18 reports in the applications implemented with Birt;
but they really seem experiments rather than something really usable; to
give you some examples:
* in most of them there is this code like this:
userLogin = null;
try {
userLogin =
delegator.findByPrimaryKey(UserLogin,UtilMisc.toMap(userLoginId,admin));
} catch(e) {
Debug.logError(e,);
}
* all the retrieval logic (scripts) is inlined with layout definition and
this is something we try to avoid in all the existing screens
* entity list iterators are not properly closed
* some of the widget based financial reports have been converted to Birt:
their layout is still very simple and comparable to the widget based
versions available before Birt; so the conversion to Birt added a
dependencies on this component without adding real value (the rptdesign
files mix together data preparation scripts and ui definitions and in order
to maintain them you have to use the Birt designer); also some of them are
now broken: Income Stetements, Balance Sheet etc... This is probably caused
by the recent refactoring of JSR-223 but the original widget based PDF are
still there and are working fine...
* building a report with this Birt integration still requires a lot of
development work (similar to the one required to create a screen); but then
the code in the rptdesign is very difficult to maintain without the editor
My questions are:
* do you really think that this way of integrating rptdesign reports is
the answer to fill the gap of a good reporting tool in OFBiz? Are you
actually using this integration for your reports?
* do we all agree to make this Birt integration the best practice
mechanism for all OFBiz reports?
* do you really think that we should replace all the existing widget
generated reports and FOP reports with rptdesign reports built using the
existing Birt integration under the framework?
If any of your answers will be no then in my opinion it would be much
better to:
1) make Birt integration an optional component, downloaded separately
2) move the existing rptdesign reports out of the applications and keep
them in the external Birt component
3) at this point users will have the option to use the Birt component or
not, but the ootb code will be clean and without dependencies on it; most
of all, we will not deliver reports that looks similar (ugly) but they are
implemented randomly with Birt or Widgets
4) start evaluating, as a community, what should be the best practices for
ootb reports: what is the tool we want, what are the minimal requirements
etc... and then work together to get it in place and then migrate all
existing reports to it in order to have a consistent system; if the
community will not be able to reach a consensus on this, then we should
leave the decision about the reporting tool to use to the end user
I think that the Birt integration is a nice optional component, and I see
that there may be interested parties, but in its current status it is not
something ready for becoming the primary reporting tool for the ootb
applications.
Jacopo
Re: Lose Weight Program for OFBiz - ofbizwebsite
Infra wouldn't be happy if we host the website in that demo instance; websites potentially have a lot of visits and that server is not intended for the load; this is similar to Confluence based pages: we will no more be allowed to use direct links to them from the website. Jacopo On Mar 21, 2012, at 11:46 AM, Hans Bakker wrote: then this could be in contrast with the ASF infrastructure offered to the projects. - ??? try: http://demo-trunk.ofbiz.apache.org/ofbiz/ Regards, Hans On 03/20/2012 06:48 PM, Jacopo Cappellato wrote: G) specialpurpose/ofbizwebsite: move to Attic Jacques and Olivier proposed to move it to Extras instead just in case someone will pick up the work and complete it in the future. I would like to mention that, if the original goal was to eat our own dog food and run the OFBiz site on it, then this could be in contrast with the ASF infrastructure offered to the projects. Jacopo
Re: Lose Weight Program for OFBiz - themes
Jacques, inline: On Wed, Mar 21, 2012 at 2:07 AM, Jacques Le Roux jacques.le.r...@les7arts.com wrote: Hi Mansour, From: Mansour Al Akeel mansour.alak...@gmail.com Jacques, We use RTL. May be you are right about the the ease of use to find an item, but the user who has permission to all these functionality is an admin, and normally, she is comfortable finding any item quickly. The rest of the uses don't have that much items and menus shown. This makes sense for a deployment, not OOTB. It's IMO easier to select Flat Grey, if you prefer, for your deployments and to keep Tomahawk as OOTB default for the reasons I explained and others I add below. Yes, this will work. So you are offering a fancier theme for the demo purposes, targeting new comers, and developers, can make a copy of FlatGray and customize it. Sound good. I know, other themes may look better, or fancier, but most users use flat gray to base their work on and extend/customize it, because it's easier and cleaner. I am not sure if bigger organization prefer fancier look and feel over cleaner. And to be honest, I think flat gray looks more professional than others. Therefore, it give a positive first impression, when demonstrated. Additional themes may still exist beside FlatGray, but I recommend to make it the default one. What makes you think most users use flat gray to base their work ? Sorry, I didn't express it properly. I meant most user based on my experience. I have two developers, I worked with, extend flat gray, and customize it as they need. This is not a number that can be a base for a statistical study, and generalize it. It's only my limited experience. Sorry for the confusion. Could you define easier and cleaner, and why Flat Grey is easier and cleaner (besides that it's the only one that is RTL which I understand for you is a must have) Cleaner and easier in terms of usage: The menu is at the top, showing all the available item, makes it easy to see what I need in case I navigated to the wrong section, or need another section. Nothing hidden. In fact even as a demo, it has some positive effect. and Cleaner and easier in terms of development: Flat Gray code is not cluttered. (that is how I feel). What makes you think Flat Grey looks more professionnal? For me Flat Gray has not enough contrast. In other words all looks grey/pale and it's difficult to spot things. I work more with enterprise portals than with ERPs. From what I have seen, portal severs default theme is mostly light, with darker high light. And I find FlatGray closer to them than Tomahawk theme is. For example: http://portals.apache.org/jetspeed-2/ and: http://www.liferay.com/products/liferay-portal/overview After all, It is not that hard for a developer to change the style of OFBiz themes to reflect the colors she likes. With Tomahawk I quickly spot buttons, links, etc. because there is more contrast. Maybe it's If you read me, it's not about being fancier but ergonomic which is for me the only priority for the community to use OFBiz OOTB (contrary to deployments) It's the opposite to me. I find it easier to spot things using FlatGray. But again not a big deal. Also I'd like to know why Flat Grey is the only Theme being marked as being Sight-Impaired Accessible? Adrian? I remember I began to add title=Skip navigation accesskey=2 (which is really only a small/poor beginnng) but that's for all themes. What is specific to Flat Grey? The only things I could concede: 1. Like 1 to 5% of the male population (women are rarely touched) I'm daltonian (kind of sight-impaired ;o) so my vision about contrast is maybe biased 2. Maybe, because it uses a blackboard background style rather than a white paper style, Tomahawk is more arduous for eyes on a long term (hours of work) Yes. I can see this, and I agree. Thanks for sharing your opinion :o) Jacques Finally, it's a personal preference. However, I like to keep FlatGray. Doesn't have to be the default, Unless demos in RTL needed. Thank you. On Tue, Mar 20, 2012 at 6:10 PM, Jacques Le Roux jacques.le.r...@les7arts.com wrote: I see that most people prefer Flat Grey. Let me explain why I prefer Tomahawk. Did you ever wonder why the paper we write on has more than often a greater height than width, why newspaper have many columns, etc. Here is an answer http://graphicdesign.stackexchange.com/questions/3553/why-do-newspapers-use-multiple-columns OK, my argument: don't you feel a pain to find an application, a menu entry in Flat Grey? No? Then you are used to find it at some place and don't care anymore. Now just imagine the same for a new user... This is where Tomahawk is better. It's far easier to find an entry in 2 colums (applications in Tomahawk) than in 7 columns (applications in Flat Grey). Or an entry in an application (1 column for Tomahawk, up to 14 in Flat Grey). Just try it Another point: Product screens are awful in
Re: Lose Weight Program for OFBiz - what should go to specialpurpose
I would recommend keeping partymgr and assetmaint. I am not sure if accounting depends on assetmain. On Wed, Mar 21, 2012 at 6:59 AM, Pierre Smits pierre.sm...@gmail.com wrote: + 1 on move of majority of apps in specialpurpose to 'Extras', excluding projectmgr as it displays how to use OFBiz in a different industry than ecommerce/webshop. Is it not so that OFBiz is versatile. ProjectMgr does deliver some of that versatility. Regards, Pierre Op 20 maart 2012 12:47 schreef Jacopo Cappellato jacopo.cappell...@hotwaxmedia.com het volgende: H) specialpurpose/*: move several (if not all, apart ecommerce) of the components to Extras (if there are persons interested to become committers/maintainers) or to Attic There seems to be a general agreement to slim down the number of applications in this group and move them to Extras (see exceptions below). I am summarizing here some notes but we should actually use this thread to continue the discussion about what should go to specialpurpose in general rather than focusing on the decision about removal of specific applications; we can then start a separate thread for each component. Adrian would like to keep one or two components to demonstrate the concept of reusing artifacts to create custom applications (Jacopo: can we use the exampleext component for this?) Hans would like to keep the ones that he considers feature complete like asset maintenance, LDAP, POS, e-commerce, cmssite, projectmgr and scrum. Jacopo: in my opinion even in the above list provided by Hans there are applications that are barely examples (cmssite) or are very specific implementation of very specific requirements (difficult to be used if your company doesn't have exactly these requirements): projectmgr and scrum; some of these components also extends (adding special purpose fields) the generic data model and this happens even if the user is not interested in evaluating the specialpurpose component. I also don't think that some of the components meet minimum quality requirements to be distributed with OFBiz: for example the scrum component uses a mechanism that is unique to demo its features (i.e. published a demo webapp with online instructions for demo data) that is not used by other applications (and this makes the suite of applications inconsistent); also, the component refers to resources that are owned by Hans' company. All in all, they seem very specific piece of codes that should better live as optional plugins downloaded separately. So in my opinion the concept of specialpurpose application is in general better suited for Apache Extras rather than for the OFBiz svn and releases.
Is ofbiz going the sugarcrm, magento route? (essential extra's are commercial?)
(I also copied the user list because users are heavily impacted here. Users please read the development forum at http://www.ofbiz.info) Hi Everybody interested in the future of ofbiz, - *i am very concerned with the current route which is proposed by Jacopo in the development mailing list: Lose Weight Program for OFBiz* Why? Have only a minimal core ERP with minimal functionality, anything extra is moved to either: 1. *Apache extras* (http://www.apache-extras.com) which is just a url link menu into Google projects This will not be maintained by the Apache OFBiz committers and only outside the Apache environment. 2. *attic* (abandoned=deleted) Pushing out complete components and functions like for example all components in the specialized directory such as e-commerce, project manager, asset manager and others and also Birt (Reporting) integration out of the OFBiz core system will actually mean: components will be abandoned even when stored in apache extra's and will be picked up by commercial companies like mine (Antwebsystems) and others and will promote them as commercial add-ons for a fee. [my Antwebsystems CEO hat on] Actually we (AntWebsystems) already started the process a couple of months ago, we have internal chat/live chat(see our website), twitter, sitemap, saas/tenant extension, shindig/igoogle integration, task manager and more because a number of committers objected that we added more functions, so we stopped contributing major functions. [my Apache PMC member hat on] This can now happen with anything that will be removed from the core system. There are many articles about the commercialization of open source products on the internet, examples are Sugercrm and Magento and OFBiz will be the next one: *In the future, a reasonable OFBiz system cannot be be run without commercial extra's! * Please keep this in mind if you react on the proposal Lose Weight Program for OFBiz: do not agree too easily. [my Antwebsystems CEO hat on] From a commercialization point of view please remove as much as possible. [my Apache PMC member hat on] Only remove the component/functions which are not maintained. Regards, Hans Bakker *Proud Apache OFBiz PMC member* and yes also CEO Antwebsystems Co.Ltd.
Re: Default package size assumed by fedex?
List rate means direct rates based on weight and dimensions of items and Account rates which based on discount provided on account. You can verify it from value of filed 'RateRequestTypes' in your rate request. You need some customization around it to get dimensions of package and products. You can assign defaultShipmentBoxTypeId to each product and get dimension of shipmentBox from there otherwise you can use product dimensions if exists. If you don't want to provide dimensions and shipment packages for each product then use default dimensions of default package along with total shippable weight. Regards Arun Patidar Hotwax Media | www.hotwaxmedia.com On 21-Mar-2012, at 3:22 PM, Prince Sewani wrote: Hey Thanks for the reply Arun, Can you please help with a pivot to work-out which type of rate it is (list/discounted)? Also about dimensions, as the SOAP API is being used , I'd to use custom code to check Dimensions of RequestedPackage from the RateRequest and I got an NPE on 'getHeight()' method call, that clearly defines that the Dimensions for the Package are null. Also is there a way we define dimensions for a product and that are used by the service without any customization? Coz, observing the code I don't see anything like that happening somewhere. In all the rates are being calculated based on just weight and not dimensions. Regards Prince From: Arun Patidar arun.pati...@hotwaxmedia.com To: dev@ofbiz.apache.org Cc: Arun Patidar arun.pati...@hotwaxmedia.com Sent: Wednesday, March 21, 2012 11:14 AM Subject: Re: Default package size assumed by fedex? Fedex rates calculation requires weight and dimensions of packages only. Also Make sure that which type of rates you are getting, its a list rate or discounted rate of your account. Regards Arun Patidar Hotwax Media | www.hotwaxmedia.com On 20-Mar-2012, at 5:36 PM, Prince Sewani wrote: Hi All, I've a question, If the 'shipment.fedex.default.packagingType' is set to 'YOURPACKNG' , then what are the default dimensions assumed by Fedex for the package in which the product will be packed? I see a lot of difference in rates when I log-into Fedex a/c and give the zip codes, the difference in rate still lies whether I provide the dimensions of the package or not. Any pointers/clues will be of great help. Regards Prince
Re: Lose Weight Program for OFBiz - ofbizwebsite
Hans, The problem is that it's completly outdated and nobody is able/want to maintain it Just compare with http://ofbiz.apache.org/ which follows ASF rules with for instance a TM on Logo, etc. Jacques From: Hans Bakker mailingl...@antwebsystems.com then this could be in contrast with the ASF infrastructure offered to the projects. - ??? try: http://demo-trunk.ofbiz.apache.org/ofbiz/ Regards, Hans On 03/20/2012 06:48 PM, Jacopo Cappellato wrote: G) specialpurpose/ofbizwebsite: move to Attic Jacques and Olivier proposed to move it to Extras instead just in case someone will pick up the work and complete it in the future. I would like to mention that, if the original goal was to eat our own dog food and run the OFBiz site on it, then this could be in contrast with the ASF infrastructure offered to the projects. Jacopo
Re: Default package size assumed by fedex?
Prince, It’s my understanding that FedEx is/has retired the Ship Manager API and the Ship Manager Direct solutions that are integrated into OFBiz and will require anyone using them to migrate to FedEx Web Services. I think that was what Jacques was trying to say originally. If you are making changes to the Ship Manager API or Ship Manager Direct, you are making changes to something that will no longer be supported. If this is incorrect or I misunderstood, let me know. -- View this message in context: http://ofbiz.135035.n4.nabble.com/Default-package-size-assumed-by-fedex-tp4488552p4492344.html Sent from the OFBiz - Dev mailing list archive at Nabble.com.
Re: Lose Weight Program for OFBiz - themes
From: Mansour Al Akeel mansour.alak...@gmail.com Jacques, inline: On Wed, Mar 21, 2012 at 2:07 AM, Jacques Le Roux jacques.le.r...@les7arts.com wrote: Hi Mansour, From: Mansour Al Akeel mansour.alak...@gmail.com Jacques, We use RTL. May be you are right about the the ease of use to find an item, but the user who has permission to all these functionality is an admin, and normally, she is comfortable finding any item quickly. The rest of the uses don't have that much items and menus shown. This makes sense for a deployment, not OOTB. It's IMO easier to select Flat Grey, if you prefer, for your deployments and to keep Tomahawk as OOTB default for the reasons I explained and others I add below. Yes, this will work. So you are offering a fancier theme for the demo purposes, targeting new comers, and developers, can make a copy of FlatGray and customize it. Sound good. I know, other themes may look better, or fancier, but most users use flat gray to base their work on and extend/customize it, because it's easier and cleaner. I am not sure if bigger organization prefer fancier look and feel over cleaner. And to be honest, I think flat gray looks more professional than others. Therefore, it give a positive first impression, when demonstrated. Additional themes may still exist beside FlatGray, but I recommend to make it the default one. What makes you think most users use flat gray to base their work ? Sorry, I didn't express it properly. I meant most user based on my experience. I have two developers, I worked with, extend flat gray, and customize it as they need. This is not a number that can be a base for a statistical study, and generalize it. It's only my limited experience. Sorry for the confusion. Could you define easier and cleaner, and why Flat Grey is easier and cleaner (besides that it's the only one that is RTL which I understand for you is a must have) Cleaner and easier in terms of usage: The menu is at the top, showing all the available item, makes it easy to see what I need in case I navigated to the wrong section, or need another section. Nothing hidden. In fact even as a demo, it has some positive effect. and Cleaner and easier in terms of development: Flat Gray code is not cluttered. (that is how I feel). What makes you think Flat Grey looks more professionnal? For me Flat Gray has not enough contrast. In other words all looks grey/pale and it's difficult to spot things. I work more with enterprise portals than with ERPs. From what I have seen, portal severs default theme is mostly light, with darker high light. And I find FlatGray closer to them than Tomahawk theme is. For example: http://portals.apache.org/jetspeed-2/ and: http://www.liferay.com/products/liferay-portal/overview After all, It is not that hard for a developer to change the style of OFBiz themes to reflect the colors she likes. With Tomahawk I quickly spot buttons, links, etc. because there is more contrast. Maybe it's If you read me, it's not about being fancier but ergonomic which is for me the only priority for the community to use OFBiz OOTB (contrary to deployments) It's the opposite to me. I find it easier to spot things using FlatGray. But again not a big deal. Also I'd like to know why Flat Grey is the only Theme being marked as being Sight-Impaired Accessible? Adrian? I remember I began to add title=Skip navigation accesskey=2 (which is really only a small/poor beginnng) but that's for all themes. What is specific to Flat Grey? The only things I could concede: 1. Like 1 to 5% of the male population (women are rarely touched) I'm daltonian (kind of sight-impaired ;o) so my vision about contrast is maybe biased 2. Maybe, because it uses a blackboard background style rather than a white paper style, Tomahawk is more arduous for eyes on a long term (hours of work) Yes. I can see this, and I agree. Thanks for sharing your opinion :o) Jacques Finally, it's a personal preference. However, I like to keep FlatGray. Doesn't have to be the default, Unless demos in RTL needed. That's an important point, and makes me need to consider indeed! I mean it's not obvious for new comers that only one theme is RTL able I think it should be default because of that, and keep Tomahawk as OOTB alternative Jacques Thank you. On Tue, Mar 20, 2012 at 6:10 PM, Jacques Le Roux jacques.le.r...@les7arts.com wrote: I see that most people prefer Flat Grey. Let me explain why I prefer Tomahawk. Did you ever wonder why the paper we write on has more than often a greater height than width, why newspaper have many columns, etc. Here is an answer http://graphicdesign.stackexchange.com/questions/3553/why-do-newspapers-use-multiple-columns OK, my argument: don't you feel a pain to find an application, a menu entry in Flat Grey? No? Then you are used to find it at some place and don't care anymore. Now just imagine the same for a new user... This is where Tomahawk is better. It's far
Re: Lose Weight Program for OFBiz - what should go to specialpurpose
partymgr is in application will not move, you meant ProjectMgr right? Jacques From: Mansour Al Akeel mansour.alak...@gmail.com I would recommend keeping partymgr and assetmaint. I am not sure if accounting depends on assetmain. On Wed, Mar 21, 2012 at 6:59 AM, Pierre Smits pierre.sm...@gmail.com wrote: + 1 on move of majority of apps in specialpurpose to 'Extras', excluding projectmgr as it displays how to use OFBiz in a different industry than ecommerce/webshop. Is it not so that OFBiz is versatile. ProjectMgr does deliver some of that versatility. Regards, Pierre Op 20 maart 2012 12:47 schreef Jacopo Cappellato jacopo.cappell...@hotwaxmedia.com het volgende: H) specialpurpose/*: move several (if not all, apart ecommerce) of the components to Extras (if there are persons interested to become committers/maintainers) or to Attic There seems to be a general agreement to slim down the number of applications in this group and move them to Extras (see exceptions below). I am summarizing here some notes but we should actually use this thread to continue the discussion about what should go to specialpurpose in general rather than focusing on the decision about removal of specific applications; we can then start a separate thread for each component. Adrian would like to keep one or two components to demonstrate the concept of reusing artifacts to create custom applications (Jacopo: can we use the exampleext component for this?) Hans would like to keep the ones that he considers feature complete like asset maintenance, LDAP, POS, e-commerce, cmssite, projectmgr and scrum. Jacopo: in my opinion even in the above list provided by Hans there are applications that are barely examples (cmssite) or are very specific implementation of very specific requirements (difficult to be used if your company doesn't have exactly these requirements): projectmgr and scrum; some of these components also extends (adding special purpose fields) the generic data model and this happens even if the user is not interested in evaluating the specialpurpose component. I also don't think that some of the components meet minimum quality requirements to be distributed with OFBiz: for example the scrum component uses a mechanism that is unique to demo its features (i.e. published a demo webapp with online instructions for demo data) that is not used by other applications (and this makes the suite of applications inconsistent); also, the component refers to resources that are owned by Hans' company. All in all, they seem very specific piece of codes that should better live as optional plugins downloaded separately. So in my opinion the concept of specialpurpose application is in general better suited for Apache Extras rather than for the OFBiz svn and releases.
Re: Lose Weight Program for OFBiz - ofbizwebsite
Jacques, sure at the time is was up-to-date and this was a proposal how we can use ofbiz for the website, however because of the strict apache rules it was not used...but can still be a template for any local ofbiz website. It remains weak: being an 'ofbiz' provider but not using it yourself. Regards, Hans On 03/21/2012 08:55 PM, Jacques Le Roux wrote: Hans, The problem is that it's completly outdated and nobody is able/want to maintain it Just compare with http://ofbiz.apache.org/ which follows ASF rules with for instance a TM on Logo, etc. Jacques From: Hans Bakker mailingl...@antwebsystems.com then this could be in contrast with the ASF infrastructure offered to the projects. - ??? try: http://demo-trunk.ofbiz.apache.org/ofbiz/ Regards, Hans On 03/20/2012 06:48 PM, Jacopo Cappellato wrote: G) specialpurpose/ofbizwebsite: move to Attic Jacques and Olivier proposed to move it to Extras instead just in case someone will pick up the work and complete it in the future. I would like to mention that, if the original goal was to eat our own dog food and run the OFBiz site on it, then this could be in contrast with the ASF infrastructure offered to the projects. Jacopo
Re: Lose Weight Program for OFBiz - documents
And there are parts in framework Jacques From: Hans Bakker mailingl...@antwebsystems.com The idea behind this that documents in wiki are not according the version..(only the latest) This directory has it for the related version AND can be in different languages and formats: html, pdf do judge before you understand.. Regards, Hans On 03/21/2012 06:01 PM, Pierre Smits wrote: +1. This is an example of bloat. Keeping ill-maintained static documents in OFBiz (the suite) that are also available through the OFBiz website is not adding value. Regards, Pierre Op 20 maart 2012 12:48 schreef Jacopo Cappellato jacopo.cappell...@hotwaxmedia.com het volgende: O) framework/documents: move the content to Wiki and then move to Attic The broader topic is to move all the artifacts related to online help out of the framework; they should all live under applications.
[jira] [Commented] (OFBIZ-4627) contribute Ofbiz Vietnamese tranlasting to community from HaNoi
[ https://issues.apache.org/jira/browse/OFBIZ-4627?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13234366#comment-13234366 ] Jacques Le Roux commented on OFBIZ-4627: Thanks Paul, Much appreciated :) ! contribute Ofbiz Vietnamese tranlasting to community from HaNoi --- Key: OFBIZ-4627 URL: https://issues.apache.org/jira/browse/OFBIZ-4627 Project: OFBiz Issue Type: Improvement Components: ALL APPLICATIONS Affects Versions: SVN trunk Reporter: Tri Duc Vo Assignee: Jacques Le Roux Labels: features Fix For: SVN trunk Attachments: CommonUiLabels.xml.patch, CommonUiLabels.xml.patch, CommonUiLabels.xml.patch, CommonUiLabels.xml.patch, EcommerceUiLabels.xml, EcommerceUiLabels.xml.patch, EcommerceUiLabels.xml.patch, EcommerceUiLabels.xml.patch, EcommerceUiLabels.xml.patch, MarketingUiLabels.xml.patch, MarketingUiLabels.xml.patch, MarketingUiLabels.xml.patch, MarketingUiLabels.xml.patch, OrderEntityLabels.xml.patch, OrderEntityLabels.xml.patch, OrderEntityLabels.xml.patch, OrderEntityLabels.xml.patch, OrderUiLabels.xml.patch, OrderUiLabels.xml.patch, OrderUiLabels.xml.patch, OrderUiLabels.xml.patch, ProductEntityLabels.xml.patch, ProductEntityLabels.xml.patch, ProductEntityLabels.xml.patch, ProductEntityLabels.xml.patch, ProductUiLabels.xml, ProductUiLabels.xml.patch, ProductUiLabels.xml.patch, ProductUiLabels.xml.patch, ProductUiLabels.xml.patch Original Estimate: 1,344h Remaining Estimate: 1,344h Dear Ofbiz community I'm Tri, from HaNoi, VietNam, and now our team build ERP based on Ofbiz opensource. Now we're completed translating 80% Ecommerce , 50% Catalog of Ofbiz. And we're going to complete 100% Vietnamese Ofbiz tranlasting and contribute them to community. We'll attach files soon Thank you -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: Lose Weight Program for OFBiz - ofbizwebsite
Hans, The OFBiz project can hardly be regarded as an OFBiz Provider. Look at the list of Providers on the site. Then look at the source of their websites and have a feel for how many (besides your company) use OFBiz as a WCM. There are several solutions in the field providing for website functionality. Some of which including a richer set of functionality and better user experience. Regards, Pierre Op 21 maart 2012 15:03 schreef Hans Bakker mailingl...@antwebsystems.comhet volgende: Jacques, sure at the time is was up-to-date and this was a proposal how we can use ofbiz for the website, however because of the strict apache rules it was not used...but can still be a template for any local ofbiz website. It remains weak: being an 'ofbiz' provider but not using it yourself. Regards, Hans On 03/21/2012 08:55 PM, Jacques Le Roux wrote: Hans, The problem is that it's completly outdated and nobody is able/want to maintain it Just compare with http://ofbiz.apache.org/ which follows ASF rules with for instance a TM on Logo, etc. Jacques From: Hans Bakker mailingl...@antwebsystems.com** then this could be in contrast with the ASF infrastructure offered to the projects. - ??? try: http://demo-trunk.ofbiz.**apache.org/ofbiz/http://demo-trunk.ofbiz.apache.org/ofbiz/ Regards, Hans On 03/20/2012 06:48 PM, Jacopo Cappellato wrote: G) specialpurpose/ofbizwebsite: move to Attic Jacques and Olivier proposed to move it to Extras instead just in case someone will pick up the work and complete it in the future. I would like to mention that, if the original goal was to eat our own dog food and run the OFBiz site on it, then this could be in contrast with the ASF infrastructure offered to the projects. Jacopo
Re: Default package size assumed by fedex?
Please no longer use dev ML for that and refer to this thread rather http://ofbiz.135035.n4.nabble.com/new-FedEx-Web-Services-Integration-Module-for-OFBiz-tt4487002.html Jacques -- View this message in context: http://ofbiz.135035.n4.nabble.com/Default-package-size-assumed-by-fedex-tp4488552p4492419.html Sent from the OFBiz - Dev mailing list archive at Nabble.com.
Re: Default package size assumed by fedex?
Hey Scott, I truly agree to what you said and I understood pretty well what Jacques was pointing to and I appreciate it, that's a wise advice. They're yet to retire the API, not much time though, What I'm wondering about is the cause that's creating the difference in rates when you're fetching through the SOAP API and when you work-it-out using the FedEx A/c from FedEx website. What exactly it is that could cause is the only thing I'm trying to figure out. Regards Prince From: Scott. sc...@anglolimited.com To: dev@ofbiz.apache.org Sent: Wednesday, March 21, 2012 7:27 PM Subject: Re: Default package size assumed by fedex? Prince, It’s my understanding that FedEx is/has retired the Ship Manager API and the Ship Manager Direct solutions that are integrated into OFBiz and will require anyone using them to migrate to FedEx Web Services. I think that was what Jacques was trying to say originally. If you are making changes to the Ship Manager API or Ship Manager Direct, you are making changes to something that will no longer be supported. If this is incorrect or I misunderstood, let me know. -- View this message in context: http://ofbiz.135035.n4.nabble.com/Default-package-size-assumed-by-fedex-tp4488552p4492344.html Sent from the OFBiz - Dev mailing list archive at Nabble.com.
Re: Is ofbiz going the sugarcrm, magento route? (essential extra's are commercial?)
As of now, anyone can disable components, and enable them as an extra commercial plugins. An if they are downloaded separately, it doesn't add to their commercial value. I am not sure if I missing something here. For example, at this point, anyone can disable Birt component, and say Hey, I can add for you a reporting tools for $ extra. The work involved will be just enabling it. IMHO there's no way to control the honesty of any commercial organization except competition and keeping it open source. Jacopo's proposal is good for the health of the product. I believe having a smaller code base will encourage users to contribute more, and enforce a little bit more control over what goes into the SVN. If there's unmaintained code, then it can be marked unmaintained by moving it out, and eventually, someone party will pick it and maintain it as an open source or commercial, depending on their business model. On Wed, Mar 21, 2012 at 9:00 AM, Hans Bakker h.bak...@antwebsystems.com wrote: (I also copied the user list because users are heavily impacted here. Users please read the development forum at http://www.ofbiz.info) Hi Everybody interested in the future of ofbiz, - *i am very concerned with the current route which is proposed by Jacopo in the development mailing list: Lose Weight Program for OFBiz* Why? Have only a minimal core ERP with minimal functionality, anything extra is moved to either: 1. *Apache extras* (http://www.apache-extras.com) which is just a url link menu into Google projects This will not be maintained by the Apache OFBiz committers and only outside the Apache environment. 2. *attic* (abandoned=deleted) Pushing out complete components and functions like for example all components in the specialized directory such as e-commerce, project manager, asset manager and others and also Birt (Reporting) integration out of the OFBiz core system will actually mean: components will be abandoned even when stored in apache extra's and will be picked up by commercial companies like mine (Antwebsystems) and others and will promote them as commercial add-ons for a fee. [my Antwebsystems CEO hat on] Actually we (AntWebsystems) already started the process a couple of months ago, we have internal chat/live chat(see our website), twitter, sitemap, saas/tenant extension, shindig/igoogle integration, task manager and more because a number of committers objected that we added more functions, so we stopped contributing major functions. [my Apache PMC member hat on] This can now happen with anything that will be removed from the core system. There are many articles about the commercialization of open source products on the internet, examples are Sugercrm and Magento and OFBiz will be the next one: *In the future, a reasonable OFBiz system cannot be be run without commercial extra's! * Please keep this in mind if you react on the proposal Lose Weight Program for OFBiz: do not agree too easily. [my Antwebsystems CEO hat on] From a commercialization point of view please remove as much as possible. [my Apache PMC member hat on] Only remove the component/functions which are not maintained. Regards, Hans Bakker *Proud Apache OFBiz PMC member* and yes also CEO Antwebsystems Co.Ltd.
Re: Default package size assumed by fedex?
Hey Arun, Thanks for your wonderful reply that captures all the customization stuff needed and also matches my plan that I had in mah mind go ahead with. It'll certainly need customizations to match-up with the ideal implementation, But all that made me post was the cause due which despite providing the same input in both the systems caused the rates to vary. For e.g. : 2 packages, total weight 59lbs. , from 45005 to 55303 for FedEx Ground fetches $31 in OFBiz and shows $41.95 in FedEx site, that's a huge difference. Regards Prince From: Arun Patidar arun.pati...@hotwaxmedia.com To: Prince Sewani princesew...@ymail.com Cc: Arun Patidar arun.pati...@hotwaxmedia.com; dev@ofbiz.apache.org dev@ofbiz.apache.org Sent: Wednesday, March 21, 2012 6:32 PM Subject: Re: Default package size assumed by fedex? List rate means direct rates based on weight and dimensions of items and Account rates which based on discount provided on account. You can verify it from value of filed 'RateRequestTypes' in your rate request. You need some customization around it to get dimensions of package and products. You can assign defaultShipmentBoxTypeId to each product and get dimension of shipmentBox from there otherwise you can use product dimensions if exists. If you don't want to provide dimensions and shipment packages for each product then use default dimensions of default package along with total shippable weight. Regards Arun Patidar Hotwax Media | www.hotwaxmedia.com On 21-Mar-2012, at 3:22 PM, Prince Sewani wrote: Hey Thanks for the reply Arun, Can you please help with a pivot to work-out which type of rate it is (list/discounted)? Also about dimensions, as the SOAP API is being used , I'd to use custom code to check Dimensions of RequestedPackage from the RateRequest and I got an NPE on 'getHeight()' method call, that clearly defines that the Dimensions for the Package are null. Also is there a way we define dimensions for a product and that are used by the service without any customization? Coz, observing the code I don't see anything like that happening somewhere. In all the rates are being calculated based on just weight and not dimensions. Regards Prince From: Arun Patidar arun.pati...@hotwaxmedia.com To: dev@ofbiz.apache.org Cc: Arun Patidar arun.pati...@hotwaxmedia.com Sent: Wednesday, March 21, 2012 11:14 AM Subject: Re: Default package size assumed by fedex? Fedex rates calculation requires weight and dimensions of packages only. Also Make sure that which type of rates you are getting, its a list rate or discounted rate of your account. Regards Arun Patidar Hotwax Media | www.hotwaxmedia.com On 20-Mar-2012, at 5:36 PM, Prince Sewani wrote: Hi All, I've a question, If the 'shipment.fedex.default.packagingType' is set to 'YOURPACKNG' , then what are the default dimensions assumed by Fedex for the package in which the product will be packed? I see a lot of difference in rates when I log-into Fedex a/c and give the zip codes, the difference in rate still lies whether I provide the dimensions of the package or not. Any pointers/clues will be of great help. Regards Prince
Re: Default package size assumed by fedex?
Hi Jacques, Surely, I got the pivots I was looking for. Thanks a lot for your guidance. :) Regards Prince From: Jacques Le Roux jacques.le.r...@les7arts.com To: dev@ofbiz.apache.org Sent: Wednesday, March 21, 2012 7:48 PM Subject: Re: Default package size assumed by fedex? Please no longer use dev ML for that and refer to this thread rather http://ofbiz.135035.n4.nabble.com/new-FedEx-Web-Services-Integration-Module-for-OFBiz-tt4487002.html Jacques -- View this message in context: http://ofbiz.135035.n4.nabble.com/Default-package-size-assumed-by-fedex-tp4488552p4492419.html Sent from the OFBiz - Dev mailing list archive at Nabble.com.
Re: Lose Weight Program for OFBiz - what should go to specialpurpose
Jacques, Yes. You are right. I meant projectmgr. :) I believe assetmaint and projectmgr are used more than others and good to keep them where they are. Thank you. On Wed, Mar 21, 2012 at 10:02 AM, Jacques Le Roux jacques.le.r...@les7arts.com wrote: partymgr is in application will not move, you meant ProjectMgr right? Jacques From: Mansour Al Akeel mansour.alak...@gmail.com I would recommend keeping partymgr and assetmaint. I am not sure if accounting depends on assetmain. On Wed, Mar 21, 2012 at 6:59 AM, Pierre Smits pierre.sm...@gmail.com wrote: + 1 on move of majority of apps in specialpurpose to 'Extras', excluding projectmgr as it displays how to use OFBiz in a different industry than ecommerce/webshop. Is it not so that OFBiz is versatile. ProjectMgr does deliver some of that versatility. Regards, Pierre Op 20 maart 2012 12:47 schreef Jacopo Cappellato jacopo.cappell...@hotwaxmedia.com het volgende: H) specialpurpose/*: move several (if not all, apart ecommerce) of the components to Extras (if there are persons interested to become committers/maintainers) or to Attic There seems to be a general agreement to slim down the number of applications in this group and move them to Extras (see exceptions below). I am summarizing here some notes but we should actually use this thread to continue the discussion about what should go to specialpurpose in general rather than focusing on the decision about removal of specific applications; we can then start a separate thread for each component. Adrian would like to keep one or two components to demonstrate the concept of reusing artifacts to create custom applications (Jacopo: can we use the exampleext component for this?) Hans would like to keep the ones that he considers feature complete like asset maintenance, LDAP, POS, e-commerce, cmssite, projectmgr and scrum. Jacopo: in my opinion even in the above list provided by Hans there are applications that are barely examples (cmssite) or are very specific implementation of very specific requirements (difficult to be used if your company doesn't have exactly these requirements): projectmgr and scrum; some of these components also extends (adding special purpose fields) the generic data model and this happens even if the user is not interested in evaluating the specialpurpose component. I also don't think that some of the components meet minimum quality requirements to be distributed with OFBiz: for example the scrum component uses a mechanism that is unique to demo its features (i.e. published a demo webapp with online instructions for demo data) that is not used by other applications (and this makes the suite of applications inconsistent); also, the component refers to resources that are owned by Hans' company. All in all, they seem very specific piece of codes that should better live as optional plugins downloaded separately. So in my opinion the concept of specialpurpose application is in general better suited for Apache Extras rather than for the OFBiz svn and releases.
Re: Lose Weight Program for OFBiz - what should go to specialpurpose
They are more generic sure, I wonder for the pos... Jacques From: Mansour Al Akeel mansour.alak...@gmail.com Jacques, Yes. You are right. I meant projectmgr. :) I believe assetmaint and projectmgr are used more than others and good to keep them where they are. Thank you. On Wed, Mar 21, 2012 at 10:02 AM, Jacques Le Roux jacques.le.r...@les7arts.com wrote: partymgr is in application will not move, you meant ProjectMgr right? Jacques From: Mansour Al Akeel mansour.alak...@gmail.com I would recommend keeping partymgr and assetmaint. I am not sure if accounting depends on assetmain. On Wed, Mar 21, 2012 at 6:59 AM, Pierre Smits pierre.sm...@gmail.com wrote: + 1 on move of majority of apps in specialpurpose to 'Extras', excluding projectmgr as it displays how to use OFBiz in a different industry than ecommerce/webshop. Is it not so that OFBiz is versatile. ProjectMgr does deliver some of that versatility. Regards, Pierre Op 20 maart 2012 12:47 schreef Jacopo Cappellato jacopo.cappell...@hotwaxmedia.com het volgende: H) specialpurpose/*: move several (if not all, apart ecommerce) of the components to Extras (if there are persons interested to become committers/maintainers) or to Attic There seems to be a general agreement to slim down the number of applications in this group and move them to Extras (see exceptions below). I am summarizing here some notes but we should actually use this thread to continue the discussion about what should go to specialpurpose in general rather than focusing on the decision about removal of specific applications; we can then start a separate thread for each component. Adrian would like to keep one or two components to demonstrate the concept of reusing artifacts to create custom applications (Jacopo: can we use the exampleext component for this?) Hans would like to keep the ones that he considers feature complete like asset maintenance, LDAP, POS, e-commerce, cmssite, projectmgr and scrum. Jacopo: in my opinion even in the above list provided by Hans there are applications that are barely examples (cmssite) or are very specific implementation of very specific requirements (difficult to be used if your company doesn't have exactly these requirements): projectmgr and scrum; some of these components also extends (adding special purpose fields) the generic data model and this happens even if the user is not interested in evaluating the specialpurpose component. I also don't think that some of the components meet minimum quality requirements to be distributed with OFBiz: for example the scrum component uses a mechanism that is unique to demo its features (i.e. published a demo webapp with online instructions for demo data) that is not used by other applications (and this makes the suite of applications inconsistent); also, the component refers to resources that are owned by Hans' company. All in all, they seem very specific piece of codes that should better live as optional plugins downloaded separately. So in my opinion the concept of specialpurpose application is in general better suited for Apache Extras rather than for the OFBiz svn and releases.
portlet development simplification enhancement
Description: Goals of this enhancement are : - simplification of portlet development by use of portlet Templates (PortletType), so most of the time, it's sufficient to define a form to have a portlet - default value of formName, menuName, ScreenName, ScriptName, Title, ... (name and location) based on component, subcomponent, webapp of the portlet - ajax call defined with xml syntax (new show-portlet on form and menu) - default parameters list in ajax link (show-portlet or on-event-update-area) Technical choices : - add some fields in PortalPortlet entity (add fieldDescription in entityLabel to have auto help) - add PortletType entity, which link id to a screenLocation#screenName for portlet Template - portlet template are based on screenlet - add portalPortletId and portletSeqId as optional attributes in include-portal-page - update include-portal-page java process to put in context some of PortalPortlet fields, to be usable by portlet templates. Value coming from entity or default value calculation. - add show-portlet as field type in Form with similar properties than hyperlink. Same for Menu. Sub Task of this Jira : 1) icon-purpose : same concept as uiLabel but for icons, a property file to address icons by a logical name 2) portlet-example : example portalPage with portlet using new functionality 3) portlet-help : help file on development using portlet 4) portletUilabel : add a portlet decorator by component to be sure that a portlet from a component can be used in an other component without label problem 5) Some generic PortletEditForm, usually needed 6) screenlet list navigation : solve two problems, first) screenlet navigation bar currently generate problem with listIterator, second) currenlty not working with ajax (on-event-update-area) 7) add field new-line in PortalColumn, to be able to have multiple line in PortalPage, ex: top of screen two column and bottom only one column, like in ProjectPage If you want more details : 0) install patch from Jira OFBIZ-4688 a) install the 4 first jiras, (compile and restart) (there is a patch with a merge of the four in the main Jira ;-) b) load data from Common and Example c) go to webtools and open PortalPagePortlet screen for portalPageId=, portalPortletId= portletSeqId= to read help on each PortalPortlet field d) go to example, and test ExampleMgmt PortalPage and ExampleRecap PortalPage e) open help on Example / development / Portal Page Type and Portlet usage The current Jira about it are the first release, si : 1) I leave the addon comment, because : - it's easier to see when something has been add, I will remove all, when it will be ready to be integrated - it's easier for me to make correction and evolution which will be ask by community 2) I have use example and example help, to show how it works, of course after OFBiz community decision about example and exampleext goals, I will move to the right place ;-)
[jira] [Created] (OFBIZ-4742) Portlet Widget
Portlet Widget -- Key: OFBIZ-4742 URL: https://issues.apache.org/jira/browse/OFBIZ-4742 Project: OFBiz Issue Type: Improvement Components: framework Affects Versions: SVN trunk Reporter: Olivier Heintz Description: Goals of this enhancement are : - simplification of portlet development by use of portlet Templates (PortletType), so most of the time, it's sufficient to define a form to have a portlet - default value of formName, menuName, ScreenName, ScriptName, Title, ... (name and location) based on component, subcomponent, webapp of the portlet - ajax call defined with xml syntax (new show-portlet on form and menu) - default parameters list in ajax link (show-portlet or on-event-update-area) -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: Lose Weight Program for OFBiz - what should go to specialpurpose
People are really worried on the idea of moving certain components from Ofbiz trunk to Ofbiz Extras. Why is it so? Moving a component from Ofbiz trunk to Ofbiz Extras does not mean that the component is not good and so we are throwing it out. Instead idea is to allow components to grow by giving them little more freedom. Like Jacopo mentioned in one of his responses, Projects from Ofbiz Extras can still post updates on Ofbiz lists. Finally if a Project in Extras is useful for business, people will keep improving it and community will grow. Thanks and Regards Anil Patel HotWax Media Inc On Mar 21, 2012, at 8:34 AM, Jacques Le Roux wrote: They are more generic sure, I wonder for the pos... Jacques From: Mansour Al Akeel mansour.alak...@gmail.com Jacques, Yes. You are right. I meant projectmgr. :) I believe assetmaint and projectmgr are used more than others and good to keep them where they are. Thank you. On Wed, Mar 21, 2012 at 10:02 AM, Jacques Le Roux jacques.le.r...@les7arts.com wrote: partymgr is in application will not move, you meant ProjectMgr right? Jacques From: Mansour Al Akeel mansour.alak...@gmail.com I would recommend keeping partymgr and assetmaint. I am not sure if accounting depends on assetmain. On Wed, Mar 21, 2012 at 6:59 AM, Pierre Smits pierre.sm...@gmail.com wrote: + 1 on move of majority of apps in specialpurpose to 'Extras', excluding projectmgr as it displays how to use OFBiz in a different industry than ecommerce/webshop. Is it not so that OFBiz is versatile. ProjectMgr does deliver some of that versatility. Regards, Pierre Op 20 maart 2012 12:47 schreef Jacopo Cappellato jacopo.cappell...@hotwaxmedia.com het volgende: H) specialpurpose/*: move several (if not all, apart ecommerce) of the components to Extras (if there are persons interested to become committers/maintainers) or to Attic There seems to be a general agreement to slim down the number of applications in this group and move them to Extras (see exceptions below). I am summarizing here some notes but we should actually use this thread to continue the discussion about what should go to specialpurpose in general rather than focusing on the decision about removal of specific applications; we can then start a separate thread for each component. Adrian would like to keep one or two components to demonstrate the concept of reusing artifacts to create custom applications (Jacopo: can we use the exampleext component for this?) Hans would like to keep the ones that he considers feature complete like asset maintenance, LDAP, POS, e-commerce, cmssite, projectmgr and scrum. Jacopo: in my opinion even in the above list provided by Hans there are applications that are barely examples (cmssite) or are very specific implementation of very specific requirements (difficult to be used if your company doesn't have exactly these requirements): projectmgr and scrum; some of these components also extends (adding special purpose fields) the generic data model and this happens even if the user is not interested in evaluating the specialpurpose component. I also don't think that some of the components meet minimum quality requirements to be distributed with OFBiz: for example the scrum component uses a mechanism that is unique to demo its features (i.e. published a demo webapp with online instructions for demo data) that is not used by other applications (and this makes the suite of applications inconsistent); also, the component refers to resources that are owned by Hans' company. All in all, they seem very specific piece of codes that should better live as optional plugins downloaded separately. So in my opinion the concept of specialpurpose application is in general better suited for Apache Extras rather than for the OFBiz svn and releases.
[jira] [Commented] (OFBIZ-4742) Portlet Widget
[ https://issues.apache.org/jira/browse/OFBIZ-4742?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13234389#comment-13234389 ] Olivier Heintz commented on OFBIZ-4742: --- Technical choices : - add some fields in PortalPortlet entity (add fieldDescription in entityLabel to have auto help) - add PortletType entity, which link id to a screenLocation#screenName for portlet Template - portlet template are based on screenlet - add portalPortletId and portletSeqId as optional attributes in include-portal-page - update include-portal-page java process to put in context some of PortalPortlet fields, to be usable by portlet templates. Value coming from entity or default value calculation. - add show-portlet as field type in Form with similar properties than hyperlink. Same for Menu. Sub Task of this Jira : 1) icon-purpose : same concept as uiLabel but for icons, a property file to address icons by a logical name 2) portlet-example : example portalPage with portlet using new functionality 3) portlet-help : help file on development using portlet 4) portletUilabel : add a portlet decorator by component to be sure that a portlet from a component can be used in an other component without label problem 5) Some generic PortletEditForm, usually needed 6) screenlet list navigation : solve two problems, first) screenlet navigation bar currently generate problem with listIterator, second) currenlty not working with ajax (on-event-update-area) 7) add field new-line in PortalColumn, to be able to have multiple line in PortalPage, ex: top of screen two column and bottom only one column, like in ProjectPage Portlet Widget -- Key: OFBIZ-4742 URL: https://issues.apache.org/jira/browse/OFBIZ-4742 Project: OFBiz Issue Type: Improvement Components: framework Affects Versions: SVN trunk Reporter: Olivier Heintz Description: Goals of this enhancement are : - simplification of portlet development by use of portlet Templates (PortletType), so most of the time, it's sufficient to define a form to have a portlet - default value of formName, menuName, ScreenName, ScriptName, Title, ... (name and location) based on component, subcomponent, webapp of the portlet - ajax call defined with xml syntax (new show-portlet on form and menu) - default parameters list in ajax link (show-portlet or on-event-update-area) -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (OFBIZ-4742) Portlet Widget
[ https://issues.apache.org/jira/browse/OFBIZ-4742?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Olivier Heintz updated OFBIZ-4742: -- Attachment: OFBIZ-4742.patch first release : I leave the addon comment, because : - it's easier to see when something has been add, I will remove all, when it will be ready to be integrated - it's easier for me to make correction and evolution which will be ask by community Portlet Widget -- Key: OFBIZ-4742 URL: https://issues.apache.org/jira/browse/OFBIZ-4742 Project: OFBiz Issue Type: Improvement Components: framework Affects Versions: SVN trunk Reporter: Olivier Heintz Attachments: OFBIZ-4742.patch Description: Goals of this enhancement are : - simplification of portlet development by use of portlet Templates (PortletType), so most of the time, it's sufficient to define a form to have a portlet - default value of formName, menuName, ScreenName, ScriptName, Title, ... (name and location) based on component, subcomponent, webapp of the portlet - ajax call defined with xml syntax (new show-portlet on form and menu) - default parameters list in ajax link (show-portlet or on-event-update-area) -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: Lose Weight Program for OFBiz - what should go to specialpurpose
Anil, I agree with you. Jacques, I don't use pos, but I think it's good idea to keep it where it's. I think it's more likely, it will be used more than what goes in Extra. It fits specialpurpose. On Wed, Mar 21, 2012 at 10:48 AM, Anil Patel anil.pa...@hotwaxmedia.com wrote: People are really worried on the idea of moving certain components from Ofbiz trunk to Ofbiz Extras. Why is it so? Moving a component from Ofbiz trunk to Ofbiz Extras does not mean that the component is not good and so we are throwing it out. Instead idea is to allow components to grow by giving them little more freedom. Like Jacopo mentioned in one of his responses, Projects from Ofbiz Extras can still post updates on Ofbiz lists. Finally if a Project in Extras is useful for business, people will keep improving it and community will grow. Thanks and Regards Anil Patel HotWax Media Inc On Mar 21, 2012, at 8:34 AM, Jacques Le Roux wrote: They are more generic sure, I wonder for the pos... Jacques From: Mansour Al Akeel mansour.alak...@gmail.com Jacques, Yes. You are right. I meant projectmgr. :) I believe assetmaint and projectmgr are used more than others and good to keep them where they are. Thank you. On Wed, Mar 21, 2012 at 10:02 AM, Jacques Le Roux jacques.le.r...@les7arts.com wrote: partymgr is in application will not move, you meant ProjectMgr right? Jacques From: Mansour Al Akeel mansour.alak...@gmail.com I would recommend keeping partymgr and assetmaint. I am not sure if accounting depends on assetmain. On Wed, Mar 21, 2012 at 6:59 AM, Pierre Smits pierre.sm...@gmail.com wrote: + 1 on move of majority of apps in specialpurpose to 'Extras', excluding projectmgr as it displays how to use OFBiz in a different industry than ecommerce/webshop. Is it not so that OFBiz is versatile. ProjectMgr does deliver some of that versatility. Regards, Pierre Op 20 maart 2012 12:47 schreef Jacopo Cappellato jacopo.cappell...@hotwaxmedia.com het volgende: H) specialpurpose/*: move several (if not all, apart ecommerce) of the components to Extras (if there are persons interested to become committers/maintainers) or to Attic There seems to be a general agreement to slim down the number of applications in this group and move them to Extras (see exceptions below). I am summarizing here some notes but we should actually use this thread to continue the discussion about what should go to specialpurpose in general rather than focusing on the decision about removal of specific applications; we can then start a separate thread for each component. Adrian would like to keep one or two components to demonstrate the concept of reusing artifacts to create custom applications (Jacopo: can we use the exampleext component for this?) Hans would like to keep the ones that he considers feature complete like asset maintenance, LDAP, POS, e-commerce, cmssite, projectmgr and scrum. Jacopo: in my opinion even in the above list provided by Hans there are applications that are barely examples (cmssite) or are very specific implementation of very specific requirements (difficult to be used if your company doesn't have exactly these requirements): projectmgr and scrum; some of these components also extends (adding special purpose fields) the generic data model and this happens even if the user is not interested in evaluating the specialpurpose component. I also don't think that some of the components meet minimum quality requirements to be distributed with OFBiz: for example the scrum component uses a mechanism that is unique to demo its features (i.e. published a demo webapp with online instructions for demo data) that is not used by other applications (and this makes the suite of applications inconsistent); also, the component refers to resources that are owned by Hans' company. All in all, they seem very specific piece of codes that should better live as optional plugins downloaded separately. So in my opinion the concept of specialpurpose application is in general better suited for Apache Extras rather than for the OFBiz svn and releases.
[jira] [Created] (OFBIZ-4743) icon-purpose : same concept as uiLabel but for icons, a property file to address icons by a logical name
icon-purpose : same concept as uiLabel but for icons, a property file to
address icons by a logical name
-
Key: OFBIZ-4743
URL: https://issues.apache.org/jira/browse/OFBIZ-4743
Project: OFBiz
Issue Type: Sub-task
Components: framework
Affects Versions: SVN trunk
Reporter: Olivier Heintz
copy from help:
Icons are useful to make the user interface nicer.
To ensure consistency in the application, a logical name was given to each icon
and it is advisable to use only one.
To be able to change icon sets based on themes, it is advisable not access
online the image file but to go through the appropriate properties files.
HowTo use of icons in a link (link or show-portlet).
An example of use of icon Details
{code}
show-portlet portlet-id=ShowExample
image-location=${iconsPurpose.Details}
image-title=${uiLabelMap.IconsTooltips_Details}
{code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (OFBIZ-4743) icon-purpose : same concept as uiLabel but for icons, a property file to address icons by a logical name
[
https://issues.apache.org/jira/browse/OFBIZ-4743?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Olivier Heintz updated OFBIZ-4743:
--
Attachment: OFBIZ-4743.patch
icon-purpose : same concept as uiLabel but for icons, a property file to
address icons by a logical name
-
Key: OFBIZ-4743
URL: https://issues.apache.org/jira/browse/OFBIZ-4743
Project: OFBiz
Issue Type: Sub-task
Components: framework
Affects Versions: SVN trunk
Reporter: Olivier Heintz
Attachments: OFBIZ-4743.patch
copy from help:
Icons are useful to make the user interface nicer.
To ensure consistency in the application, a logical name was given to each
icon and it is advisable to use only one.
To be able to change icon sets based on themes, it is advisable not access
online the image file but to go through the appropriate properties files.
HowTo use of icons in a link (link or show-portlet).
An example of use of icon Details
{code}
show-portlet portlet-id=ShowExample
image-location=${iconsPurpose.Details}
image-title=${uiLabelMap.IconsTooltips_Details}
{code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (OFBIZ-4744) ProductStoreCartAwareEvents: wrong check for website in setSessionProductStore
ProductStoreCartAwareEvents: wrong check for website in setSessionProductStore -- Key: OFBIZ-4744 URL: https://issues.apache.org/jira/browse/OFBIZ-4744 Project: OFBiz Issue Type: Bug Components: order, specialpurpose/ecommerce Affects Versions: SVN trunk Reporter: Michael Brohl Fix For: SVN trunk There's a duplicate check if the productStore is null instead of checking productStore and website in ProductStoreCartAwareEvents.setSessionProductStore. I will provide a patch. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (OFBIZ-4745) portlet-example : example portalPage with portlet using new functionality (portletType and showPortlet)
portlet-example : example portalPage with portlet using new functionality (portletType and showPortlet) --- Key: OFBIZ-4745 URL: https://issues.apache.org/jira/browse/OFBIZ-4745 Project: OFBiz Issue Type: Sub-task Components: framework Affects Versions: SVN trunk Reporter: Olivier Heintz A set of portalPortlet and portalPage to show what it's possible to do and how to do. For more detail look at the user help, strating from portalPage ExampleMgmt -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: Lose Weight Program for OFBiz - what should go to specialpurpose
Jacques, I don't use pos, but I think it's good idea to keep it where it's. I think it's more likely, it will be used more than what goes in Extra. It fits specialpurpose. Why do you think a component will be used more if its in specialpurpose section, instead of Extras. Personally think it opposite, If a business is interested in using POS, they will find be able to find it from Extras as well. Like any other Ofbiz application, The Users of POS application will will respond by saying UX sucks :). At that point Company who deployed the POS will be motivated to improve it. If POS is in Extras its will be much easy for new developer to become active committer. In some cases, contributor may want to change License on a components. Doing such thing will be possible for Ofbiz Extras. One of the reasons (I am sure there were many) why OpenTaps was started is License. I will personally like to have more freedom around UI toolset. Ofbiz Extras will make it possible. And if application is well accepted by users then it will get popular and community will grow. Regards Anil Patel On Wed, Mar 21, 2012 at 10:48 AM, Anil Patel anil.pa...@hotwaxmedia.com wrote: People are really worried on the idea of moving certain components from Ofbiz trunk to Ofbiz Extras. Why is it so? Moving a component from Ofbiz trunk to Ofbiz Extras does not mean that the component is not good and so we are throwing it out. Instead idea is to allow components to grow by giving them little more freedom. Like Jacopo mentioned in one of his responses, Projects from Ofbiz Extras can still post updates on Ofbiz lists. Finally if a Project in Extras is useful for business, people will keep improving it and community will grow. Thanks and Regards Anil Patel HotWax Media Inc On Mar 21, 2012, at 8:34 AM, Jacques Le Roux wrote: They are more generic sure, I wonder for the pos... Jacques From: Mansour Al Akeel mansour.alak...@gmail.com Jacques, Yes. You are right. I meant projectmgr. :) I believe assetmaint and projectmgr are used more than others and good to keep them where they are. Thank you. On Wed, Mar 21, 2012 at 10:02 AM, Jacques Le Roux jacques.le.r...@les7arts.com wrote: partymgr is in application will not move, you meant ProjectMgr right? Jacques From: Mansour Al Akeel mansour.alak...@gmail.com I would recommend keeping partymgr and assetmaint. I am not sure if accounting depends on assetmain. On Wed, Mar 21, 2012 at 6:59 AM, Pierre Smits pierre.sm...@gmail.com wrote: + 1 on move of majority of apps in specialpurpose to 'Extras', excluding projectmgr as it displays how to use OFBiz in a different industry than ecommerce/webshop. Is it not so that OFBiz is versatile. ProjectMgr does deliver some of that versatility. Regards, Pierre Op 20 maart 2012 12:47 schreef Jacopo Cappellato jacopo.cappell...@hotwaxmedia.com het volgende: H) specialpurpose/*: move several (if not all, apart ecommerce) of the components to Extras (if there are persons interested to become committers/maintainers) or to Attic There seems to be a general agreement to slim down the number of applications in this group and move them to Extras (see exceptions below). I am summarizing here some notes but we should actually use this thread to continue the discussion about what should go to specialpurpose in general rather than focusing on the decision about removal of specific applications; we can then start a separate thread for each component. Adrian would like to keep one or two components to demonstrate the concept of reusing artifacts to create custom applications (Jacopo: can we use the exampleext component for this?) Hans would like to keep the ones that he considers feature complete like asset maintenance, LDAP, POS, e-commerce, cmssite, projectmgr and scrum. Jacopo: in my opinion even in the above list provided by Hans there are applications that are barely examples (cmssite) or are very specific implementation of very specific requirements (difficult to be used if your company doesn't have exactly these requirements): projectmgr and scrum; some of these components also extends (adding special purpose fields) the generic data model and this happens even if the user is not interested in evaluating the specialpurpose component. I also don't think that some of the components meet minimum quality requirements to be distributed with OFBiz: for example the scrum component uses a mechanism that is unique to demo its features (i.e. published a demo webapp with online instructions for demo data) that is not used by other applications (and this makes the suite of applications inconsistent); also, the component refers to resources that are owned by Hans' company. All in all, they seem very specific piece of codes that should better live as optional plugins downloaded separately. So in my opinion the concept of
[jira] [Updated] (OFBIZ-4744) ProductStoreCartAwareEvents: wrong check for website in setSessionProductStore
[ https://issues.apache.org/jira/browse/OFBIZ-4744?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Brohl updated OFBIZ-4744: - Attachment: OFBIZ-4744_ProductStoreCartAwareEvents_wrong_check_for_website.patch The patch. ProductStoreCartAwareEvents: wrong check for website in setSessionProductStore -- Key: OFBIZ-4744 URL: https://issues.apache.org/jira/browse/OFBIZ-4744 Project: OFBiz Issue Type: Bug Components: order, specialpurpose/ecommerce Affects Versions: SVN trunk Reporter: Michael Brohl Fix For: SVN trunk Attachments: OFBIZ-4744_ProductStoreCartAwareEvents_wrong_check_for_website.patch Original Estimate: 5m Remaining Estimate: 5m There's a duplicate check if the productStore is null instead of checking productStore and website in ProductStoreCartAwareEvents.setSessionProductStore. I will provide a patch. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (OFBIZ-4745) portlet-example : example portalPage with portlet using new functionality (portletType and showPortlet)
[ https://issues.apache.org/jira/browse/OFBIZ-4745?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Olivier Heintz updated OFBIZ-4745: -- Attachment: OFBIZ-4745.patch to be usable, it's necessary to have installed Jira-4688, Jira-4742 and Jira-4743 portlet-example : example portalPage with portlet using new functionality (portletType and showPortlet) --- Key: OFBIZ-4745 URL: https://issues.apache.org/jira/browse/OFBIZ-4745 Project: OFBiz Issue Type: Sub-task Components: framework Affects Versions: SVN trunk Reporter: Olivier Heintz Attachments: OFBIZ-4745.patch A set of portalPortlet and portalPage to show what it's possible to do and how to do. For more detail look at the user help, strating from portalPage ExampleMgmt -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (OFBIZ-4746) portlet-help : help file on development using portlet
[ https://issues.apache.org/jira/browse/OFBIZ-4746?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Olivier Heintz updated OFBIZ-4746: -- Attachment: OFBIZ-4746.patch portlet-help : help file on development using portlet - Key: OFBIZ-4746 URL: https://issues.apache.org/jira/browse/OFBIZ-4746 Project: OFBiz Issue Type: Sub-task Components: framework Affects Versions: SVN trunk Reporter: Olivier Heintz Attachments: OFBIZ-4746.patch integrated user Help to explain 1) how to develop using portalPortlet and PortalPage 2) associated best practice English and French -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (OFBIZ-4746) portlet-help : help file on development using portlet
portlet-help : help file on development using portlet - Key: OFBIZ-4746 URL: https://issues.apache.org/jira/browse/OFBIZ-4746 Project: OFBiz Issue Type: Sub-task Components: framework Affects Versions: SVN trunk Reporter: Olivier Heintz Attachments: OFBIZ-4746.patch integrated user Help to explain 1) how to develop using portalPortlet and PortalPage 2) associated best practice English and French -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (OFBIZ-4742) Portlet Widget
[ https://issues.apache.org/jira/browse/OFBIZ-4742?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Olivier Heintz updated OFBIZ-4742: -- Attachment: OFBIZ-portletWidget_iconsPurpose_Example_Help.patch OFBIZ-portletWidget_iconsPurpose_Example_Help.patch is a merge of the 4 patch to avoid install problems. It's necessary to install JIRA-4688 to habe all working. Portlet Widget -- Key: OFBIZ-4742 URL: https://issues.apache.org/jira/browse/OFBIZ-4742 Project: OFBiz Issue Type: Improvement Components: framework Affects Versions: SVN trunk Reporter: Olivier Heintz Attachments: OFBIZ-4742.patch, OFBIZ-portletWidget_iconsPurpose_Example_Help.patch Description: Goals of this enhancement are : - simplification of portlet development by use of portlet Templates (PortletType), so most of the time, it's sufficient to define a form to have a portlet - default value of formName, menuName, ScreenName, ScriptName, Title, ... (name and location) based on component, subcomponent, webapp of the portlet - ajax call defined with xml syntax (new show-portlet on form and menu) - default parameters list in ajax link (show-portlet or on-event-update-area) -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (OFBIZ-4745) portlet-example : example portalPage with portlet using new functionality (portletType and showPortlet)
[ https://issues.apache.org/jira/browse/OFBIZ-4745?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13234427#comment-13234427 ] Olivier Heintz commented on OFBIZ-4745: --- I have use example and example help, to show how it works, of course after OFBiz community decision about example and exampleext goals, I will move to the right place ;-) portlet-example : example portalPage with portlet using new functionality (portletType and showPortlet) --- Key: OFBIZ-4745 URL: https://issues.apache.org/jira/browse/OFBIZ-4745 Project: OFBiz Issue Type: Sub-task Components: framework Affects Versions: SVN trunk Reporter: Olivier Heintz Attachments: OFBIZ-4745.patch A set of portalPortlet and portalPage to show what it's possible to do and how to do. For more detail look at the user help, strating from portalPage ExampleMgmt -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: Lose Weight Program for OFBiz - what should go to specialpurpose
Anil, I did not mean that putting a component under specialpurposes will make it used more by developers. I meant because it will be used more than other component, let's not move it. From Jacopo's first email about the Lose Weight : Legenda for what I propose for each piece of code: * Attic: remove from code base and document the removal for future reference in this page * Extras: identify a person interested in maintaining the code as a separate project hosted as an Apache Extra project (not officially under the ASF); add a link to it from the page that will contain OFBiz Extras He didn't mention anything about what type of applications should go/remain under specialpurposes. Since (I think), pos is used more than what went into Exta or Attic, I suggested keeping it where it's. The question is, will POS be maintained by ofbiz community or another party ? If it's will be separated from ofbiz, what about XUL integration code? should it remain part of the core ofbiz (framework), or moved to the component that needs it, and becomes the responsibility of the POS maintainer ? With regard to changing the License, I think it's possible on any part of Ofbiz and not only components under Extra. In all cases, users who uses POS more than I do, can give better suggestion. On Wed, Mar 21, 2012 at 11:16 AM, Anil Patel anil.pa...@hotwaxmedia.com wrote: Jacques, I don't use pos, but I think it's good idea to keep it where it's. I think it's more likely, it will be used more than what goes in Extra. It fits specialpurpose. Why do you think a component will be used more if its in specialpurpose section, instead of Extras. Personally think it opposite, If a business is interested in using POS, they will find be able to find it from Extras as well. Like any other Ofbiz application, The Users of POS application will will respond by saying UX sucks :). At that point Company who deployed the POS will be motivated to improve it. If POS is in Extras its will be much easy for new developer to become active committer. In some cases, contributor may want to change License on a components. Doing such thing will be possible for Ofbiz Extras. One of the reasons (I am sure there were many) why OpenTaps was started is License. I will personally like to have more freedom around UI toolset. Ofbiz Extras will make it possible. And if application is well accepted by users then it will get popular and community will grow. Regards Anil Patel On Wed, Mar 21, 2012 at 10:48 AM, Anil Patel anil.pa...@hotwaxmedia.com wrote: People are really worried on the idea of moving certain components from Ofbiz trunk to Ofbiz Extras. Why is it so? Moving a component from Ofbiz trunk to Ofbiz Extras does not mean that the component is not good and so we are throwing it out. Instead idea is to allow components to grow by giving them little more freedom. Like Jacopo mentioned in one of his responses, Projects from Ofbiz Extras can still post updates on Ofbiz lists. Finally if a Project in Extras is useful for business, people will keep improving it and community will grow. Thanks and Regards Anil Patel HotWax Media Inc On Mar 21, 2012, at 8:34 AM, Jacques Le Roux wrote: They are more generic sure, I wonder for the pos... Jacques From: Mansour Al Akeel mansour.alak...@gmail.com Jacques, Yes. You are right. I meant projectmgr. :) I believe assetmaint and projectmgr are used more than others and good to keep them where they are. Thank you. On Wed, Mar 21, 2012 at 10:02 AM, Jacques Le Roux jacques.le.r...@les7arts.com wrote: partymgr is in application will not move, you meant ProjectMgr right? Jacques From: Mansour Al Akeel mansour.alak...@gmail.com I would recommend keeping partymgr and assetmaint. I am not sure if accounting depends on assetmain. On Wed, Mar 21, 2012 at 6:59 AM, Pierre Smits pierre.sm...@gmail.com wrote: + 1 on move of majority of apps in specialpurpose to 'Extras', excluding projectmgr as it displays how to use OFBiz in a different industry than ecommerce/webshop. Is it not so that OFBiz is versatile. ProjectMgr does deliver some of that versatility. Regards, Pierre Op 20 maart 2012 12:47 schreef Jacopo Cappellato jacopo.cappell...@hotwaxmedia.com het volgende: H) specialpurpose/*: move several (if not all, apart ecommerce) of the components to Extras (if there are persons interested to become committers/maintainers) or to Attic There seems to be a general agreement to slim down the number of applications in this group and move them to Extras (see exceptions below). I am summarizing here some notes but we should actually use this thread to continue the discussion about what should go to specialpurpose in general rather than focusing on the decision about removal of specific applications; we can then start a separate thread for each component. Adrian would like to keep one or two components to demonstrate
Re: Is ofbiz going the sugarcrm, magento route? (essential extra's are commercial?)
I do not see any issues if the existing projects that are slated to be moved to Extras adhere to the ASF 2.0 license but as I see it further I don't see any issues either if the license of any project is changed in future. I think it would be good for the project overall and while its not necessary that there would be just one company/maintainer of the code for any particular project, I believe anyone (individual or company) can use the base project (project at the moment with ASF 2.0) and enhance it, form a community in itself. At a point of time there could be a number of different flavors of the same project with different user groups and maintainer (individual or company). Its like linux OS distributed in different flavors, right? The quality of these project will definitely improve with a stiff competition from similar projects and the end user eventually have more options to find a right project for himself. New projects of course can have ASF 2.0 or any other commercial license. On Mar 21, 2012, at 6:30 PM, Hans Bakker wrote: (I also copied the user list because users are heavily impacted here. Users please read the development forum at http://www.ofbiz.info) Hi Everybody interested in the future of ofbiz, - *i am very concerned with the current route which is proposed by Jacopo in the development mailing list: Lose Weight Program for OFBiz* Why? Have only a minimal core ERP with minimal functionality, anything extra is moved to either: 1. *Apache extras* (http://www.apache-extras.com) which is just a url link menu into Google projects This will not be maintained by the Apache OFBiz committers and only outside the Apache environment. 2. *attic* (abandoned=deleted) Pushing out complete components and functions like for example all components in the specialized directory such as e-commerce, project manager, asset manager and others and also Birt (Reporting) integration out of the OFBiz core system will actually mean: components will be abandoned even when stored in apache extra's and will be picked up by commercial companies like mine (Antwebsystems) and others and will promote them as commercial add-ons for a fee. As far I see the responses, devs are interested in keeping the e-commerce under the specialpurpose directory. Did I mis-read? [my Antwebsystems CEO hat on] Actually we (AntWebsystems) already started the process a couple of months ago, we have internal chat/live chat(see our website), twitter, sitemap, saas/tenant extension, shindig/igoogle integration, task manager and more because a number of committers objected that we added more functions, so we stopped contributing major functions. Not to mention that any such projects developed by AntWebsystems (I believe they are commercial right now) could be the next big projects in Extras and might attract a large number of users for contributions too. It may be easier for the customers to adopt to these projects if you decide to distribute it with ASF 2.0 :) [my Apache PMC member hat on] This can now happen with anything that will be removed from the core system. There are many articles about the commercialization of open source products on the internet, examples are Sugercrm and Magento and OFBiz will be the next one: *In the future, a reasonable OFBiz system cannot be be run without commercial extra's! * Please keep this in mind if you react on the proposal Lose Weight Program for OFBiz: do not agree too easily. I am sure that this will help in large adoption of the project OFBiz. Regards Vikas [my Antwebsystems CEO hat on] From a commercialization point of view please remove as much as possible. [my Apache PMC member hat on] Only remove the component/functions which are not maintained. Regards, Hans Bakker *Proud Apache OFBiz PMC member* and yes also CEO Antwebsystems Co.Ltd.
Re: Can we archive the Screen Widget Redesign version in Jira?
+1 Le 21/03/2012 11:38, Pierre Smits a écrit : +1 Op 21 maart 2012 08:03 schreef Jacopo Cappellato jacopo.cappell...@hotwaxmedia.com het volgende: I am doing some cleanup in Jira versions and I would like to archive the Screen Widget Redesign version: there are currently 3 tasks there (all resolved); this change will not affect them (the only effect will be that the version will disappers from the valid values in the drop down when you create a new ticket). Can I proceed? Jacopo
Re: Lose Weight Program for OFBiz JCR function
Le 21/03/2012 11:45, Pierre Smits a écrit : Re 1: keep in framework +1 Re 2: remove from upcoming release 12.04 +1, remove from all upcoming future releases until 3 is finished plugin could really be the solution, because most of contribution coming from customer project, and it's easier for a project leader on a customer project to decide to use (or not) a addon versus to use a part of branch. If necessary I would help in making the addon to help contributors which want to help to do the roadmap define in point 3. Re 3: draft up requirements for content framework replacement +1 +1 Excellent roadmapping ;-) Regards, Pierre Op 20 maart 2012 11:48 schreef Jacopo Cappellato jacopo.cappell...@hotwaxmedia.com het volgende: Or alternatively we could: 1) keep it in framework 2) but remove it from the upcoming new release branch 12.04 3) and then, as a community, we could start the effort (i.e. top priority for upcoming contributions/commits) of defining the set of requirements needed by the applications to replace the existing Content framework, finalizing the architecture and start working all on the implementation and migration of existing applications: this would mean that the community will focus on this refactoring effort for a while (postponing any other new development to focus the energy) At least in this way we could experiment if the concept of a roadmap is a viable options and we will not keep and distribute a component under development waiting to see if and when something good will come out of it. Jacopo On Mar 20, 2012, at 11:32 AM, Jacopo Cappellato wrote: On Mar 20, 2012, at 10:15 AM, Olivier Heintz wrote: New thread for only JCR funstion Summary of initial discussion: Jacoppo: N) framework/jcr: move back into the Jackrabbit branch until the work is completed and can replace the existing content framework Hans: Also moving the JCR function out is not a good idea however when not improved in the next few months using the content manager, i would agree to a removal. Jacoppo Keep it mind we are preparing for the creation of the new release branch (12.04): this would mean that all the future releases for 12.04 will be bundled with an incomplete JCR/Jackrabbit integration that duplicates (but not replaces) the existing Component framework. This is alone a good reason for moving this work back to the development branch and will save a lot of future work in backporting features if security issues or bugs will be discovered. IMO, jcr will be a good enhancement in ofbiz, but currently we(the company I'm working for) are using content component in a lot of place, product, workeffort, project, party, custRequest, to manage files, so we area waiting the next step of the jcr OFBiz (content) integration. Meanwhile this second step, if jcr was a plugin, we will use it for some new customer project (and maybe contribute on ;-) but not use it for older customer which currently works with OFBiz solution to avoid using not completely implement feature. So IMO, jcr should move, branch or extra, but I prefer as a plugin to be able to used it easily. I didn't follow the details of the plans for JCR/Jackrabbit integration but as far as I understand it it is intended to be highly integrated with OFBiz (to replace Content Framework features): I am not sure how this is inline with Olivier's idea of a plugin, but it is an idea that can be explored. However, since we are still in this design phase I think it is a good idea to keep the component in the development branch in the meantime. Jacopo
Re: Lose Weight Program for OFBiz
Le 20/03/2012 10:15, Jacopo Cappellato a écrit : Thanks to all of you for the great discussion and feedback: I really appreciate all the time and great ideas you have shared. There seems to be a general agreement (with exceptions) about the following points: * the size of OFBiz should be reduced * some components/features can go to Attic (i.e. removed) if properly documented (to give a chance in the future to resurrect them) * some components/features can go to Extras * the community should explore and enhance the plug-in approach, where we help to grow an ecosystem with new contributors of optional/external components that can be downloaded separately and deployed to OFBiz; Apache Extras seems a good candidate and valid initial approach (Hans disagrees on this); in the same time OFBiz structure should evolve in a direction that helps the plug-in approach (to be designed/discussed separately) in the plug-in approach don't forget Apache-OFBiz sub-project for plug-in done with all it's needed in Apache approach (best practice, user help, large community, ) I am starting separate threads to discuss specific topics/actionable items. Kind regards, Jacopo On Mar 18, 2012, at 10:10 AM, Jacopo Cappellato wrote: In the last period the OFBiz project has grown a lot in shape: the implicitly accepted (or tolerated) strategy operated by the active committers was that the more features you could add to the official repository the better was: you make happy the contributors, making them feel like they are a part of something, and each committer could manage the code implemented for his/her own projects directly in the OFBiz codebase. We operated under the concept that, since the code if free and the author (committer or not) is willing to contribute it, then no one should/could complain if it is added to the repository, if it doesn't cause immediate problems to others; all in all it is an additional feature that may be used by someone else in the future or if not would simply stay there without causing any harm. Following this strategy we got a lot of code like for example Webslinger, seleniumxml, debian packages, all sort of specialpurpose applications etc... Since there was not a central and agreed upon roadmap, no one could really state that a contribution was not a good fit for the project: each and every committer could add what, in his own personal vision, was good for the project. The wrong assumption is that, since the code if free then it doesn't harm to include it. This is completely *wrong*: the code is not *free* at all because as soon as you add it to the repository then you add a future cost to the community: you all know that in the software industry the cost to maintain a piece of code is by far greater than the cost to write it; and you *have* to maintain the code unless you want to have and distribute stale code. And this is exactly what we have now: * high costs to maintain the code (e.g. I recently spent a lot of hours to remove the Webslinger component) * stale/unused/half baked code that causes confusion and bad impression to user evaluating the quality of our product The message to all the committers is: when you add code to the repository, you are asking the community to take care of its maintenance costs forever. So please, add new code only when it is really beneficial to the project and to a large audience of committers and users. It is like feeding a wild animal at the zoo with chips: everyone knows it is bad for its health but when you are there it is so nice when it picks the food from your own hands and you cannot resist and have to feed it. OFBiz is now suffering from serious weight issues: the committers community is having an hard time to maintain the huge codebase, it is difficult to keep track of all the features in the system etc... I think it is important to start a new phase of the project and focus our energy in cleanup and consolidation of what we have. One step in this direction is for OFBiz to lose weight. In order to get the ball rolling and focus on some concrete tasks I am providing here some examples of stuff that I would like to see removed from the project. IMPORTANT: Please consider that the list is not based on what I think the perfect framework should be (so PLEASE do not reply stating what your ideal framework should have), but simply on the following considerations: * can the component be easily removed by the project? is it independent and can live outside as a plugin? * do we need all this custom code? can't we find a simpler, lighter and better way to implement this? * is this feature used by other code in the system? * is the feature functional? or is it largely incomplete? * is this an old component/code? * is this used by a lot of persons? (this is tricky to decide but you can get a feeling of it by reading the mailing lists, considering commit activity, the status of the feature etc...)
Re: Lose Weight Program for OFBiz - Birt and BI
Le 20/03/2012 15:31, adrian.c...@sandglass-software.com a écrit :
I like the idea of keeping reporting tools separate from OFBiz. In my
experience, IT departments are already using a reporting tool for
other applications and they would prefer to integrate that tool with
OFBiz, instead of learning/using a new tool that comes bundled with it.
It will be nice if there is a default solution in OFBiz kernel to
maximize ready-to-use report and for small company which have not yet a
real reporting tool.
-Adrian
Quoting Jacopo Cappellato jacopo.cappell...@hotwaxmedia.com:
L) framework/birt (and related dependencies/reports spread around):
move to Extras
M) framework/bi (and related dependencies - ecas/business rules and
data - spread around): move to Extras
This is an area where Hans and I are in disagreement and we didn't
get much feedback from others.
So I would like to explain here why I think we should move the Birt
component and the Birt reports out of the framework and consider them
as optional tools.
There are currently 18 reports in the applications implemented with
Birt; but they really seem experiments rather than something really
usable; to give you some examples:
* in most of them there is this code like this:
userLogin = null;
try {
userLogin =
delegator.findByPrimaryKey(UserLogin,UtilMisc.toMap(userLoginId,admin));
} catch(e) {
Debug.logError(e,);
}
* all the retrieval logic (scripts) is inlined with layout definition
and this is something we try to avoid in all the existing screens
* entity list iterators are not properly closed
* some of the widget based financial reports have been converted to
Birt: their layout is still very simple and comparable to the widget
based versions available before Birt; so the conversion to Birt added
a dependencies on this component without adding real value (the
rptdesign files mix together data preparation scripts and ui
definitions and in order to maintain them you have to use the Birt
designer); also some of them are now broken: Income Stetements,
Balance Sheet etc... This is probably caused by the recent
refactoring of JSR-223 but the original widget based PDF are still
there and are working fine...
* building a report with this Birt integration still requires a lot
of development work (similar to the one required to create a screen);
but then the code in the rptdesign is very difficult to maintain
without the editor
My questions are:
* do you really think that this way of integrating rptdesign reports
is the answer to fill the gap of a good reporting tool in OFBiz? Are
you actually using this integration for your reports?
* do we all agree to make this Birt integration the best practice
mechanism for all OFBiz reports?
* do you really think that we should replace all the existing widget
generated reports and FOP reports with rptdesign reports built using
the existing Birt integration under the framework?
If any of your answers will be no then in my opinion it would be
much better to:
1) make Birt integration an optional component, downloaded separately
2) move the existing rptdesign reports out of the applications and
keep them in the external Birt component
3) at this point users will have the option to use the Birt component
or not, but the ootb code will be clean and without dependencies on
it; most of all, we will not deliver reports that looks similar
(ugly) but they are implemented randomly with Birt or Widgets
4) start evaluating, as a community, what should be the best
practices for ootb reports: what is the tool we want, what are the
minimal requirements etc... and then work together to get it in place
and then migrate all existing reports to it in order to have a
consistent system; if the community will not be able to reach a
consensus on this, then we should leave the decision about the
reporting tool to use to the end user
I think that the Birt integration is a nice optional component, and I
see that there may be interested parties, but in its current status
it is not something ready for becoming the primary reporting tool for
the ootb applications.
Jacopo
Re: Lose Weight Program for OFBiz - Birt and BI
+1 birt to extra
and there will also a jasperReport in extras
Le 20/03/2012 15:34, Mansour Al Akeel a écrit :
+1 birt to Extra.
On Tue, Mar 20, 2012 at 10:31 AM,adrian.c...@sandglass-software.com wrote:
I like the idea of keeping reporting tools separate from OFBiz. In my
experience, IT departments are already using a reporting tool for other
applications and they would prefer to integrate that tool with OFBiz,
instead of learning/using a new tool that comes bundled with it.
-Adrian
Quoting Jacopo Cappellatojacopo.cappell...@hotwaxmedia.com:
L) framework/birt (and related dependencies/reports spread around): move
to Extras
M) framework/bi (and related dependencies - ecas/business rules and data
- spread around): move to Extras
This is an area where Hans and I are in disagreement and we didn't get
much feedback from others.
So I would like to explain here why I think we should move the Birt
component and the Birt reports out of the framework and consider them as
optional tools.
There are currently 18 reports in the applications implemented with Birt;
but they really seem experiments rather than something really usable; to
give you some examples:
* in most of them there is this code like this:
userLogin = null;
try {
userLogin =
delegator.findByPrimaryKey(UserLogin,UtilMisc.toMap(userLoginId,admin));
} catch(e) {
Debug.logError(e,);
}
* all the retrieval logic (scripts) is inlined with layout definition and
this is something we try to avoid in all the existing screens
* entity list iterators are not properly closed
* some of the widget based financial reports have been converted to Birt:
their layout is still very simple and comparable to the widget based
versions available before Birt; so the conversion to Birt added a
dependencies on this component without adding real value (the rptdesign
files mix together data preparation scripts and ui definitions and in order
to maintain them you have to use the Birt designer); also some of them are
now broken: Income Stetements, Balance Sheet etc... This is probably caused
by the recent refactoring of JSR-223 but the original widget based PDF are
still there and are working fine...
* building a report with this Birt integration still requires a lot of
development work (similar to the one required to create a screen); but then
the code in the rptdesign is very difficult to maintain without the editor
My questions are:
* do you really think that this way of integrating rptdesign reports is
the answer to fill the gap of a good reporting tool in OFBiz? Are you
actually using this integration for your reports?
* do we all agree to make this Birt integration the best practice
mechanism for all OFBiz reports?
* do you really think that we should replace all the existing widget
generated reports and FOP reports with rptdesign reports built using the
existing Birt integration under the framework?
If any of your answers will be no then in my opinion it would be much
better to:
1) make Birt integration an optional component, downloaded separately
2) move the existing rptdesign reports out of the applications and keep
them in the external Birt component
3) at this point users will have the option to use the Birt component or
not, but the ootb code will be clean and without dependencies on it; most of
all, we will not deliver reports that looks similar (ugly) but they are
implemented randomly with Birt or Widgets
4) start evaluating, as a community, what should be the best practices for
ootb reports: what is the tool we want, what are the minimal requirements
etc... and then work together to get it in place and then migrate all
existing reports to it in order to have a consistent system; if the
community will not be able to reach a consensus on this, then we should
leave the decision about the reporting tool to use to the end user
I think that the Birt integration is a nice optional component, and I see
that there may be interested parties, but in its current status it is not
something ready for becoming the primary reporting tool for the ootb
applications.
Jacopo
Re: Lose Weight Program for OFBiz - guiapp and pos
Le 20/03/2012 15:58, Jacques Le Roux a écrit : From: Jacopo Cappellato jacopo.cappell...@hotwaxmedia.com A) move framework/guiapp out of the framework; after all these years no code made advantage of it being part of the framework and it is only used by the specialpurpose/pos component (which was the component for which it was built for); so guiapp can go in the pos component B) specialpurpose/pos: move to Extras No one objected so far; Jacques offered his help for #A. Should we focus on #A for now (it is an actionable item) and then discuss #B also based on the outcome of similar discussions for other specialpurpose components? Yes, I know there are POS users out there. So I now wonder if we should not wait before moving it out of specialpurpose. When you think about it, it's the twin of eCommerce. With a bit more involvment though, mostly because of its relation with Entity Sync (maintenance) which is actually part of the framework (entityext component). IMO, pos is one of the perfect example which should go in a Apache-OFbiz-SubProject not out of Apache-Ofbiz, of course +1 to becoming a plug-in but one of the Apache-OFBiz official plug-in Jacques
Re: Lose Weight Program for OFBiz - guiapp and pos
Le 21/03/2012 11:50, Pierre Smits a écrit : A) removal of framework/guiapp out of framework: +1 B) move specialpurpose/pos to 'Extras' +1 I am not in favour of moving ProjectMgr out of specialpurpose to 'Extras' as the majority of my customers use this. However, if it goes to 'Extras' I would like to assist in maintaining it. +1 for ProjectMgr as a Apache-OFBiz plug-in, not out of Apache-OFBiz ps: most of our(the company I'm working for) future contribution will be complete Projectmgr migration to portlet ;-) Regards, Pierre Op 20 maart 2012 12:47 schreef Jacopo Cappellato jacopo.cappell...@hotwaxmedia.com het volgende: A) move framework/guiapp out of the framework; after all these years no code made advantage of it being part of the framework and it is only used by the specialpurpose/pos component (which was the component for which it was built for); so guiapp can go in the pos component B) specialpurpose/pos: move to Extras No one objected so far; Jacques offered his help for #A. Should we focus on #A for now (it is an actionable item) and then discuss #B also based on the outcome of similar discussions for other specialpurpose components?
Re: Lose Weight Program for OFBiz - guiapp and pos
Hi Olivier, I would love to exchange thoughts regarding migration to portlets. Regards, Pierre Sent from my iPhone On 21 mrt. 2012, at 17:26, Olivier Heintz holivier.lis...@nereide.biz wrote: Le 21/03/2012 11:50, Pierre Smits a écrit : A) removal of framework/guiapp out of framework: +1 B) move specialpurpose/pos to 'Extras' +1 I am not in favour of moving ProjectMgr out of specialpurpose to 'Extras' as the majority of my customers use this. However, if it goes to 'Extras' I would like to assist in maintaining it. +1 for ProjectMgr as a Apache-OFBiz plug-in, not out of Apache-OFBiz ps: most of our(the company I'm working for) future contribution will be complete Projectmgr migration to portlet ;-) Regards, Pierre Op 20 maart 2012 12:47 schreef Jacopo Cappellato jacopo.cappell...@hotwaxmedia.com het volgende: A) move framework/guiapp out of the framework; after all these years no code made advantage of it being part of the framework and it is only used by the specialpurpose/pos component (which was the component for which it was built for); so guiapp can go in the pos component B) specialpurpose/pos: move to Extras No one objected so far; Jacques offered his help for #A. Should we focus on #A for now (it is an actionable item) and then discuss #B also based on the outcome of similar discussions for other specialpurpose components?
Re: Lose Weight Program for OFBiz - guiapp and pos
On Mar 21, 2012, at 5:26 PM, Olivier Heintz wrote: +1 for ProjectMgr as a Apache-OFBiz plug-in, not out of Apache-OFBiz ps: most of our(the company I'm working for) future contribution will be complete Projectmgr migration to portlet ;-) Just to avoid any confusion: * with this +1 you are asking to keep projectmgr as it is now (specialpurpose) * we do not have official Apache subprojects in the small OFBiz community because they could be an overkill for what we do (subprojects needs PMC etc...) and we should be careful to even evaluate this path because it will add a lot of paperwork to our daily processes * transforming the architecture of the component(s) to enable plug-in can be discussed, even if in some ways they are already plugins; but I am wide open to discuss/evaluate your new proposals even if this discussion should be kept separate from the current thread Jacopo
Re: Lose Weight Program for OFBiz - guiapp and pos
As a next step, after all these threads about the slim down will settle down, we should probably, as a community, start to prepare the plan of action, aka roadmap (we could use Jira for it): add there all the actionable tasks coming out of this discussions; then, in these mailing lists we should also start to discuss, as a community, what are the other priorities/goals for the next few months of the project. We should probably start slowly with some cleanup tasks and refactoring of old code, bug fixes etc... but we could also come up with some more interesting priorities (like JCR or reporting tools): then, based on the priorities identified by the community we will start to explore how to design them; if an agreement is found we will add the tasks to the roadmap as well; then we will have a clear and shared plan of actions to keep us all busy for a while If migration to portlets will be a priority item is something that should be discussed with the community: the community is small and it should stay focused on a few key goals at the time; if the community will decide that the migration to portlets is something desirable then we will definitely explore this concept. Jacopo On Mar 21, 2012, at 5:33 PM, Pierre @GMail wrote: Hi Olivier, I would love to exchange thoughts regarding migration to portlets. Regards, Pierre Sent from my iPhone On 21 mrt. 2012, at 17:26, Olivier Heintz holivier.lis...@nereide.biz wrote: Le 21/03/2012 11:50, Pierre Smits a écrit : A) removal of framework/guiapp out of framework: +1 B) move specialpurpose/pos to 'Extras' +1 I am not in favour of moving ProjectMgr out of specialpurpose to 'Extras' as the majority of my customers use this. However, if it goes to 'Extras' I would like to assist in maintaining it. +1 for ProjectMgr as a Apache-OFBiz plug-in, not out of Apache-OFBiz ps: most of our(the company I'm working for) future contribution will be complete Projectmgr migration to portlet ;-) Regards, Pierre Op 20 maart 2012 12:47 schreef Jacopo Cappellato jacopo.cappell...@hotwaxmedia.com het volgende: A) move framework/guiapp out of the framework; after all these years no code made advantage of it being part of the framework and it is only used by the specialpurpose/pos component (which was the component for which it was built for); so guiapp can go in the pos component B) specialpurpose/pos: move to Extras No one objected so far; Jacques offered his help for #A. Should we focus on #A for now (it is an actionable item) and then discuss #B also based on the outcome of similar discussions for other specialpurpose components?
Re: Lose Weight Program for OFBiz - what should go to specialpurpose
Le 21/03/2012 16:16, Anil Patel a écrit : Jacques, I don't use pos, but I think it's good idea to keep it where it's. I think it's more likely, it will be used more than what goes in Extra. It fits specialpurpose. Why do you think a component will be used more if its in specialpurpose section, instead of Extras. Personally think it opposite, If a business is interested in using POS, they will find be able to find it from Extras as well. Like any other Ofbiz application, The Users of POS application will will respond by saying UX sucks :). At that point Company who deployed the POS will be motivated to improve it. If POS is in Extras its will be much easy for new developer to become active committer. In some cases, contributor may want to change License on a components. Doing such thing will be possible for Ofbiz Extras. As I said in a previous email, imo 1) it's very important for the end-user to be very clear especially for the license, 2) for visibility, we should not have too many project or 'repository, so in OFBiz-extras, we should have only a few project, not one per plug-in, but one per repository. example of repository - all plug-in with a Apache 2.0 license and hight quality level - all plug-in with a Apache 2.0 license, in development process - all plug-in with a Apache 2.0 license, with no more activity - all plug-in with a GPL license and hight quality level - all plug-in with a GPL license, in development process - all plug-in coming from a company or community with a associated license - ... One of the reasons (I am sure there were many) why OpenTaps was started is License. I will personally like to have more freedom around UI toolset. Ofbiz Extras will make it possible. And if application is well accepted by users then it will get popular and community will grow. of course, I agree, but only if maturity, support type (large community, commercial, ...) license constrain is readable. Regards Anil Patel On Wed, Mar 21, 2012 at 10:48 AM, Anil Patelanil.pa...@hotwaxmedia.com wrote: People are really worried on the idea of moving certain components from Ofbiz trunk to Ofbiz Extras. Why is it so? Moving a component from Ofbiz trunk to Ofbiz Extras does not mean that the component is not good and so we are throwing it out. Instead idea is to allow components to grow by giving them little more freedom. Like Jacopo mentioned in one of his responses, Projects from Ofbiz Extras can still post updates on Ofbiz lists. Finally if a Project in Extras is useful for business, people will keep improving it and community will grow. Thanks and Regards Anil Patel HotWax Media Inc On Mar 21, 2012, at 8:34 AM, Jacques Le Roux wrote: They are more generic sure, I wonder for the pos... Jacques From: Mansour Al Akeelmansour.alak...@gmail.com Jacques, Yes. You are right. I meant projectmgr. :) I believe assetmaint and projectmgr are used more than others and good to keep them where they are. Thank you. On Wed, Mar 21, 2012 at 10:02 AM, Jacques Le Roux jacques.le.r...@les7arts.com wrote: partymgr is in application will not move, you meant ProjectMgr right? Jacques From: Mansour Al Akeelmansour.alak...@gmail.com I would recommend keeping partymgr and assetmaint. I am not sure if accounting depends on assetmain. On Wed, Mar 21, 2012 at 6:59 AM, Pierre Smitspierre.sm...@gmail.com wrote: + 1 on move of majority of apps in specialpurpose to 'Extras', excluding projectmgr as it displays how to use OFBiz in a different industry than ecommerce/webshop. Is it not so that OFBiz is versatile. ProjectMgr does deliver some of that versatility. Regards, Pierre Op 20 maart 2012 12:47 schreef Jacopo Cappellato jacopo.cappell...@hotwaxmedia.com het volgende: H) specialpurpose/*: move several (if not all, apart ecommerce) of the components to Extras (if there are persons interested to become committers/maintainers) or to Attic There seems to be a general agreement to slim down the number of applications in this group and move them to Extras (see exceptions below). I am summarizing here some notes but we should actually use this thread to continue the discussion about what should go to specialpurpose in general rather than focusing on the decision about removal of specific applications; we can then start a separate thread for each component. Adrian would like to keep one or two components to demonstrate the concept of reusing artifacts to create custom applications (Jacopo: can we use the exampleext component for this?) Hans would like to keep the ones that he considers feature complete like asset maintenance, LDAP, POS, e-commerce, cmssite, projectmgr and scrum. Jacopo: in my opinion even in the above list provided by Hans there are applications that are barely examples (cmssite) or are very specific implementation of very specific requirements (difficult to be used if your company doesn't have exactly these requirements): projectmgr and scrum; some of these components also
Re: Lose Weight Program for OFBiz - guiapp and pos
Le 21/03/2012 17:40, Jacopo Cappellato a écrit : On Mar 21, 2012, at 5:26 PM, Olivier Heintz wrote: +1 for ProjectMgr as a Apache-OFBiz plug-in, not out of Apache-OFBiz ps: most of our(the company I'm working for) future contribution will be complete Projectmgr migration to portlet ;-) Just to avoid any confusion: * with this +1 you are asking to keep projectmgr as it is now (specialpurpose) no * we do not have official Apache subprojects in the small OFBiz community because they could be an overkill for what we do (subprojects needs PMC etc...) and we should be careful to even evaluate this path because it will add a lot of paperwork to our daily processes ok * transforming the architecture of the component(s) to enable plug-in can be discussed, even if in some ways they are already plugins; but I am wide open to discuss/evaluate your new proposals even if this discussion should be kept separate from the current thread I have started a dedicated thread about it 3 days ago (OFBiz Plugin Management, status and propositions) ;-) a plug-in repository is a directory, so it's possible to add it in svn repository in the same level that ofbiz, (if it's authorized by Apache rules) IMO it's important to say to the community that, for example projectmgr is still in the Apache-OFBiz project even if it's necessary to do something after downloading ofbiz to install more things Jacopo
Re: Lose Weight Program for OFBiz - example, exampleext
discussion on OFBiz Plugin Management, status and propositions should be on the corresponding thread Le 20/03/2012 16:59, Mansour Al Akeel a écrit : Ant+Ivy would fit easier with the structure of ofbiz components. If we want to move to maven, then a modification to org/ofbiz/base/location/FlexibleLocation.java has to be done to allow loading resource from a jar file. I am assuming with maven, you want to package the whole component in a jar file. I think this is good idea, and it will have to done for OSGI anyway. But for the moment, I think Ant+Ivy are more suitable. On Tue, Mar 20, 2012 at 11:38 AM, Jacques Le Roux jacques.le.r...@les7arts.com wrote: From: Nicolas Malinmalin.nico...@librenberry.net Le 20/03/2012 12:47, Jacopo Cappellato a écrit : Q) framework/example and framework/exampleext: move to specialpurpose Adrian would like to keep Example in the framework but slim it down a lot to the essential (no form widgets examples, no Ajax examples, no content examples etc...). Adrian would you please confirm if in your vision the example application should document the layout of a typical OFBiz component only? If yes, we could use the output of the ant create-component task to document the best practice layout. Jacques, Olivier would like to keep also the examples for the various higher level features available to OFBiz applications. I think that from the discussion it could emerge the following solution to please everyone: * keep the example component in the framework but slim it down to the bare essential * move the exampleext component to specialpurpose and migrate to it all the extra features: this could also be used as a best practice guide on how to extend a component from hot-deploy/specialpurpose I still think that it would be nicer to not bundle the example component ootb to keep the framework cleaner: the example should be downloaded separately (when we will have clear separation between framework and the rest); this approach is similar to tomcat and its example applications. But I don't have a strong opinion on this. Jacopo example and exampleext are they useful for production site ? if Apache OFBiz implement a plugin manager, why don't use ant (or other) to prepare OFBiz according to its use. If you want develop on OFBiz, when you download from svn run : ant run-install-dev (it's a example ;)) and ant use plugin manager to resolve all extras project that compose the official OFBiz developer package. Interesting, it's based on Ivy, right? Did you ever re-consider Maven (I know the historical ;o)? I guess ant+Ivy is more flexible? I prefer it too, but only crossed Maven during a Geronimo developement [my life] At this time, I comment all unneeded components as example on production site. It isn't a problem, just I don't find clean :) [/my life] Yes, I do the same, and certainly others as well... Jacques -- Nicolas MALIN Consultant Tél : 06.17.66.40.06 Site projet : http://www.neogia.org/ --- Société LibrenBerry Tél : 02.48.02.56.12 Site : http://www.librenberry.net/
Re: Lose Weight Program for OFBiz - example, exampleext
Le 20/03/2012 23:44, Jacques Le Roux a écrit : From: Mansour Al Akeel mansour.alak...@gmail.com Everyone has different preference about how would the basic component skeleton looks like (ie, with ajax, without, exta functionality ). Even if a basic example included with ofbiz distribution, in the future it will grow again with extra unneeded functionality, or it will be an on going discussion about what should go there. It's much easier to provide a very basic skeleton as a separate download, to serve as an example and a reference. There could be more than one example provided, each showing different capabilities and different techniques. This is better than creating one huge example to show everything, and better than showing only the basics without any additional tips (ie, ajax). +1 for additional download for a example (or exempleext) showing all the current development best practice. This component could be update by a other plug-in which install a extra functionality to showing how to use it. Those who are not satisfied with the examples as a skeleton, can maintain their own copy that will make him/her start a component quickly. Examples are not needed to run ofbiz. So they (examples and examplesext) could be in specialpurpose (+1) of even Extras (0) Jacques On Tue, Mar 20, 2012 at 4:33 PM, Erwan de FERRIERES erwan.de-ferrie...@nereide.fr wrote: Le 20/03/2012 12:47, Jacopo Cappellato a écrit : Q) framework/example and framework/exampleext: move to specialpurpose Adrian would like to keep Example in the framework but slim it down a lot to the essential (no form widgets examples, no Ajax examples, no content examples etc...). Adrian would you please confirm if in your vision the example application should document the layout of a typical OFBiz component only? If yes, we could use the output of the ant create-component task to document the best practice layout. Jacques, Olivier would like to keep also the examples for the various higher level features available to OFBiz applications. I think that from the discussion it could emerge the following solution to please everyone: * keep the example component in the framework but slim it down to the bare essential * move the exampleext component to specialpurpose and migrate to it all the extra features: this could also be used as a best practice guide on how to extend a component from hot-deploy/specialpurpose I still think that it would be nicer to not bundle the example component ootb to keep the framework cleaner: the example should be downloaded separately (when we will have clear separation between framework and the rest); this approach is similar to tomcat and its example applications. But I don't have a strong opinion on this. Jacopo create 2 components, one basic with simple CRUD and no ajax or whatever, and another one with more eye candy stuff (ajax, modal forms, etc...). Both components should be in specialpurpose/ I'm not in favor of moving them to extras, as when delivering an official release there should be a showcase included. And as Adrian said, when teaching people how to create apps with OFBiz, this could be really useful. And with JSR-223, there's a lot to add ! -- Erwan de FERRIERES www.nereide.biz
Re: Lose Weight Program for OFBiz - ofbizwebsite
Le 21/03/2012 15:03, Hans Bakker a écrit : Jacques, sure at the time is was up-to-date and this was a proposal how we can use ofbiz for the website, however because of the strict apache rules it was not used...but can still be a template for any local ofbiz website. It remains weak: being an 'ofbiz' provider but not using it yourself. imo it's a good cms ofbiz capability demonstration, so +1 for extras :-) Regards, Hans On 03/21/2012 08:55 PM, Jacques Le Roux wrote: Hans, The problem is that it's completly outdated and nobody is able/want to maintain it Just compare with http://ofbiz.apache.org/ which follows ASF rules with for instance a TM on Logo, etc. Jacques From: Hans Bakker mailingl...@antwebsystems.com then this could be in contrast with the ASF infrastructure offered to the projects. - ??? try: http://demo-trunk.ofbiz.apache.org/ofbiz/ Regards, Hans On 03/20/2012 06:48 PM, Jacopo Cappellato wrote: G) specialpurpose/ofbizwebsite: move to Attic Jacques and Olivier proposed to move it to Extras instead just in case someone will pick up the work and complete it in the future. I would like to mention that, if the original goal was to eat our own dog food and run the OFBiz site on it, then this could be in contrast with the ASF infrastructure offered to the projects. Jacopo
Re: Lose Weight Program for OFBiz - Birt and BI
From: Olivier Heintz holivier.lis...@nereide.biz
Le 20/03/2012 15:31, adrian.c...@sandglass-software.com a écrit :
I like the idea of keeping reporting tools separate from OFBiz. In my experience, IT departments are already using a reporting
tool for other applications and they would prefer to integrate that tool with OFBiz, instead of learning/using a new tool that
comes bundled with it.
It will be nice if there is a default solution in OFBiz kernel to maximize ready-to-use report and for small company which have
not yet a real reporting tool.
Then we have fo.ftl files and PDF rendering. Minimalistic but working.
Jacques
-Adrian
Quoting Jacopo Cappellato jacopo.cappell...@hotwaxmedia.com:
L) framework/birt (and related dependencies/reports spread around): move to
Extras
M) framework/bi (and related dependencies - ecas/business rules and data - spread
around): move to Extras
This is an area where Hans and I are in disagreement and we didn't get much
feedback from others.
So I would like to explain here why I think we should move the Birt component and the Birt reports out of the framework and
consider them as optional tools.
There are currently 18 reports in the applications implemented with Birt; but they really seem experiments rather than something
really usable; to give you some examples:
* in most of them there is this code like this:
userLogin = null;
try {
userLogin =
delegator.findByPrimaryKey(UserLogin,UtilMisc.toMap(userLoginId,admin));
} catch(e) {
Debug.logError(e,);
}
* all the retrieval logic (scripts) is inlined with layout definition and this is something we try to avoid in all the existing
screens
* entity list iterators are not properly closed
* some of the widget based financial reports have been converted to Birt: their layout is still very simple and comparable to
the widget based versions available before Birt; so the conversion to Birt added a dependencies on this component without adding
real value (the rptdesign files mix together data preparation scripts and ui definitions and in order to maintain them you have
to use the Birt designer); also some of them are now broken: Income Stetements, Balance Sheet etc... This is probably caused by
the recent refactoring of JSR-223 but the original widget based PDF are still there and are working fine...
* building a report with this Birt integration still requires a lot of development work (similar to the one required to create a
screen); but then the code in the rptdesign is very difficult to maintain without the editor
My questions are:
* do you really think that this way of integrating rptdesign reports is the answer to fill the gap of a good reporting tool in
OFBiz? Are you actually using this integration for your reports?
* do we all agree to make this Birt integration the best practice mechanism for
all OFBiz reports?
* do you really think that we should replace all the existing widget generated reports and FOP reports with rptdesign reports
built using the existing Birt integration under the framework?
If any of your answers will be no then in my opinion it would be much better
to:
1) make Birt integration an optional component, downloaded separately
2) move the existing rptdesign reports out of the applications and keep them in
the external Birt component
3) at this point users will have the option to use the Birt component or not, but the ootb code will be clean and without
dependencies on it; most of all, we will not deliver reports that looks similar (ugly) but they are implemented randomly with
Birt or Widgets
4) start evaluating, as a community, what should be the best practices for ootb reports: what is the tool we want, what are the
minimal requirements etc... and then work together to get it in place and then migrate all existing reports to it in order to
have a consistent system; if the community will not be able to reach a consensus on this, then we should leave the decision
about the reporting tool to use to the end user
I think that the Birt integration is a nice optional component, and I see that there may be interested parties, but in its
current status it is not something ready for becoming the primary reporting tool for the ootb applications.
Jacopo
Re: Lose Weight Program for OFBiz JCR function
From: Olivier Heintz holivier.lis...@nereide.biz Le 21/03/2012 11:45, Pierre Smits a écrit : Re 1: keep in framework +1 Re 2: remove from upcoming release 12.04 +1, remove from all upcoming future releases until 3 is finished plugin could really be the solution, because most of contribution coming from customer project, and it's easier for a project leader on a customer project to decide to use (or not) a addon versus to use a part of branch. I don't think JCR should be handled by a plugin. It should be part of core framework. And, while at it, I don't think it should replace all Content component (notably all its data model, and more anyway). It's just a better way to handle content repositories (JCR = Java Content Repository ;o): content should not go in DB We already discussed about reasons for that (versionning, webdav access, external HTML editors, etc.) Jacques If necessary I would help in making the addon to help contributors which want to help to do the roadmap define in point 3. Re 3: draft up requirements for content framework replacement +1 +1 Excellent roadmapping ;-) Regards, Pierre Op 20 maart 2012 11:48 schreef Jacopo Cappellato jacopo.cappell...@hotwaxmedia.com het volgende: Or alternatively we could: 1) keep it in framework 2) but remove it from the upcoming new release branch 12.04 3) and then, as a community, we could start the effort (i.e. top priority for upcoming contributions/commits) of defining the set of requirements needed by the applications to replace the existing Content framework, finalizing the architecture and start working all on the implementation and migration of existing applications: this would mean that the community will focus on this refactoring effort for a while (postponing any other new development to focus the energy) At least in this way we could experiment if the concept of a roadmap is a viable options and we will not keep and distribute a component under development waiting to see if and when something good will come out of it. Jacopo On Mar 20, 2012, at 11:32 AM, Jacopo Cappellato wrote: On Mar 20, 2012, at 10:15 AM, Olivier Heintz wrote: New thread for only JCR funstion Summary of initial discussion: Jacoppo: N) framework/jcr: move back into the Jackrabbit branch until the work is completed and can replace the existing content framework Hans: Also moving the JCR function out is not a good idea however when not improved in the next few months using the content manager, i would agree to a removal. Jacoppo Keep it mind we are preparing for the creation of the new release branch (12.04): this would mean that all the future releases for 12.04 will be bundled with an incomplete JCR/Jackrabbit integration that duplicates (but not replaces) the existing Component framework. This is alone a good reason for moving this work back to the development branch and will save a lot of future work in backporting features if security issues or bugs will be discovered. IMO, jcr will be a good enhancement in ofbiz, but currently we(the company I'm working for) are using content component in a lot of place, product, workeffort, project, party, custRequest, to manage files, so we area waiting the next step of the jcr OFBiz (content) integration. Meanwhile this second step, if jcr was a plugin, we will use it for some new customer project (and maybe contribute on ;-) but not use it for older customer which currently works with OFBiz solution to avoid using not completely implement feature. So IMO, jcr should move, branch or extra, but I prefer as a plugin to be able to used it easily. I didn't follow the details of the plans for JCR/Jackrabbit integration but as far as I understand it it is intended to be highly integrated with OFBiz (to replace Content Framework features): I am not sure how this is inline with Olivier's idea of a plugin, but it is an idea that can be explored. However, since we are still in this design phase I think it is a good idea to keep the component in the development branch in the meantime. Jacopo
Re: Lose Weight Program for OFBiz - guiapp and pos
From: Olivier Heintz holivier.lis...@nereide.biz Le 20/03/2012 15:58, Jacques Le Roux a écrit : From: Jacopo Cappellato jacopo.cappell...@hotwaxmedia.com A) move framework/guiapp out of the framework; after all these years no code made advantage of it being part of the framework and it is only used by the specialpurpose/pos component (which was the component for which it was built for); so guiapp can go in the pos component B) specialpurpose/pos: move to Extras No one objected so far; Jacques offered his help for #A. Should we focus on #A for now (it is an actionable item) and then discuss #B also based on the outcome of similar discussions for other specialpurpose components? Yes, I know there are POS users out there. So I now wonder if we should not wait before moving it out of specialpurpose. When you think about it, it's the twin of eCommerce. With a bit more involvment though, mostly because of its relation with Entity Sync (maintenance) which is actually part of the framework (entityext component). IMO, pos is one of the perfect example which should go in a Apache-OFbiz-SubProject not out of Apache-Ofbiz, of course +1 to becoming a plug-in but one of the Apache-OFBiz official plug-in What are exactly Apache-OFbiz-SubProject and Apache-OFBiz official plug-in in your mind? specialpurpose components? Jacques Jacques
Re: Lose Weight Program for OFBiz - what should go to specialpurpose
Hi Anil, From: Anil Patel anil.pa...@hotwaxmedia.com Jacques, I don't use pos, but I think it's good idea to keep it where it's. I think it's more likely, it will be used more than what goes in Extra. It fits specialpurpose. Why do you think a component will be used more if its in specialpurpose section, instead of Extras. I fear it will get less exposition and consequently less audience. Jacques Personally think it opposite, If a business is interested in using POS, they will find be able to find it from Extras as well. Like any other Ofbiz application, The Users of POS application will will respond by saying UX sucks :). At that point Company who deployed the POS will be motivated to improve it. If POS is in Extras its will be much easy for new developer to become active committer. In some cases, contributor may want to change License on a components. Doing such thing will be possible for Ofbiz Extras. One of the reasons (I am sure there were many) why OpenTaps was started is License. I will personally like to have more freedom around UI toolset. Ofbiz Extras will make it possible. And if application is well accepted by users then it will get popular and community will grow. Regards Anil Patel On Wed, Mar 21, 2012 at 10:48 AM, Anil Patel anil.pa...@hotwaxmedia.com wrote: People are really worried on the idea of moving certain components from Ofbiz trunk to Ofbiz Extras. Why is it so? Moving a component from Ofbiz trunk to Ofbiz Extras does not mean that the component is not good and so we are throwing it out. Instead idea is to allow components to grow by giving them little more freedom. Like Jacopo mentioned in one of his responses, Projects from Ofbiz Extras can still post updates on Ofbiz lists. Finally if a Project in Extras is useful for business, people will keep improving it and community will grow. Thanks and Regards Anil Patel HotWax Media Inc On Mar 21, 2012, at 8:34 AM, Jacques Le Roux wrote: They are more generic sure, I wonder for the pos... Jacques From: Mansour Al Akeel mansour.alak...@gmail.com Jacques, Yes. You are right. I meant projectmgr. :) I believe assetmaint and projectmgr are used more than others and good to keep them where they are. Thank you. On Wed, Mar 21, 2012 at 10:02 AM, Jacques Le Roux jacques.le.r...@les7arts.com wrote: partymgr is in application will not move, you meant ProjectMgr right? Jacques From: Mansour Al Akeel mansour.alak...@gmail.com I would recommend keeping partymgr and assetmaint. I am not sure if accounting depends on assetmain. On Wed, Mar 21, 2012 at 6:59 AM, Pierre Smits pierre.sm...@gmail.com wrote: + 1 on move of majority of apps in specialpurpose to 'Extras', excluding projectmgr as it displays how to use OFBiz in a different industry than ecommerce/webshop. Is it not so that OFBiz is versatile. ProjectMgr does deliver some of that versatility. Regards, Pierre Op 20 maart 2012 12:47 schreef Jacopo Cappellato jacopo.cappell...@hotwaxmedia.com het volgende: H) specialpurpose/*: move several (if not all, apart ecommerce) of the components to Extras (if there are persons interested to become committers/maintainers) or to Attic There seems to be a general agreement to slim down the number of applications in this group and move them to Extras (see exceptions below). I am summarizing here some notes but we should actually use this thread to continue the discussion about what should go to specialpurpose in general rather than focusing on the decision about removal of specific applications; we can then start a separate thread for each component. Adrian would like to keep one or two components to demonstrate the concept of reusing artifacts to create custom applications (Jacopo: can we use the exampleext component for this?) Hans would like to keep the ones that he considers feature complete like asset maintenance, LDAP, POS, e-commerce, cmssite, projectmgr and scrum. Jacopo: in my opinion even in the above list provided by Hans there are applications that are barely examples (cmssite) or are very specific implementation of very specific requirements (difficult to be used if your company doesn't have exactly these requirements): projectmgr and scrum; some of these components also extends (adding special purpose fields) the generic data model and this happens even if the user is not interested in evaluating the specialpurpose component. I also don't think that some of the components meet minimum quality requirements to be distributed with OFBiz: for example the scrum component uses a mechanism that is unique to demo its features (i.e. published a demo webapp with online instructions for demo data) that is not used by other applications (and this makes the suite of applications inconsistent); also, the component refers to resources that are owned by Hans' company. All in all, they seem very specific piece of codes that should better live as optional plugins downloaded separately. So in my
Re: Lose Weight Program for OFBiz - what should go to specialpurpose
From: Mansour Al Akeel mansour.alak...@gmail.com Anil, I did not mean that putting a component under specialpurposes will make it used more by developers. I meant because it will be used more than other component, let's not move it. From Jacopo's first email about the Lose Weight : Legenda for what I propose for each piece of code: * Attic: remove from code base and document the removal for future reference in this page * Extras: identify a person interested in maintaining the code as a separate project hosted as an Apache Extra project (not officially under the ASF); add a link to it from the page that will contain OFBiz Extras He didn't mention anything about what type of applications should go/remain under specialpurposes. Since (I think), pos is used more than what went into Exta or Attic, I suggested keeping it where it's. The question is, will POS be maintained by ofbiz community or another party ? If it's will be separated from ofbiz, what about XUL integration code? It's not XUL but XUI (which is a dead project, replaced by Aria which now smells* almost as much) http://xui.sourceforge.net/index.html http://www.formaria.org/ This does not prevent the POS to work well... Jacques PS: *smells like Frank Zappa said about Jazz: Jazz isn't dead. It just smells funny. http://www.goodreads.com/quotes/show/3092 Jazz has much evolved since...Not Aria... should it remain part of the core ofbiz (framework), or moved to the component that needs it, and becomes the responsibility of the POS maintainer ? With regard to changing the License, I think it's possible on any part of Ofbiz and not only components under Extra. In all cases, users who uses POS more than I do, can give better suggestion. On Wed, Mar 21, 2012 at 11:16 AM, Anil Patel anil.pa...@hotwaxmedia.com wrote: Jacques, I don't use pos, but I think it's good idea to keep it where it's. I think it's more likely, it will be used more than what goes in Extra. It fits specialpurpose. Why do you think a component will be used more if its in specialpurpose section, instead of Extras. Personally think it opposite, If a business is interested in using POS, they will find be able to find it from Extras as well. Like any other Ofbiz application, The Users of POS application will will respond by saying UX sucks :). At that point Company who deployed the POS will be motivated to improve it. If POS is in Extras its will be much easy for new developer to become active committer. In some cases, contributor may want to change License on a components. Doing such thing will be possible for Ofbiz Extras. One of the reasons (I am sure there were many) why OpenTaps was started is License. I will personally like to have more freedom around UI toolset. Ofbiz Extras will make it possible. And if application is well accepted by users then it will get popular and community will grow. Regards Anil Patel On Wed, Mar 21, 2012 at 10:48 AM, Anil Patel anil.pa...@hotwaxmedia.com wrote: People are really worried on the idea of moving certain components from Ofbiz trunk to Ofbiz Extras. Why is it so? Moving a component from Ofbiz trunk to Ofbiz Extras does not mean that the component is not good and so we are throwing it out. Instead idea is to allow components to grow by giving them little more freedom. Like Jacopo mentioned in one of his responses, Projects from Ofbiz Extras can still post updates on Ofbiz lists. Finally if a Project in Extras is useful for business, people will keep improving it and community will grow. Thanks and Regards Anil Patel HotWax Media Inc On Mar 21, 2012, at 8:34 AM, Jacques Le Roux wrote: They are more generic sure, I wonder for the pos... Jacques From: Mansour Al Akeel mansour.alak...@gmail.com Jacques, Yes. You are right. I meant projectmgr. :) I believe assetmaint and projectmgr are used more than others and good to keep them where they are. Thank you. On Wed, Mar 21, 2012 at 10:02 AM, Jacques Le Roux jacques.le.r...@les7arts.com wrote: partymgr is in application will not move, you meant ProjectMgr right? Jacques From: Mansour Al Akeel mansour.alak...@gmail.com I would recommend keeping partymgr and assetmaint. I am not sure if accounting depends on assetmain. On Wed, Mar 21, 2012 at 6:59 AM, Pierre Smits pierre.sm...@gmail.com wrote: + 1 on move of majority of apps in specialpurpose to 'Extras', excluding projectmgr as it displays how to use OFBiz in a different industry than ecommerce/webshop. Is it not so that OFBiz is versatile. ProjectMgr does deliver some of that versatility. Regards, Pierre Op 20 maart 2012 12:47 schreef Jacopo Cappellato jacopo.cappell...@hotwaxmedia.com het volgende: H) specialpurpose/*: move several (if not all, apart ecommerce) of the components to Extras (if there are persons interested to become committers/maintainers) or to Attic There seems to be a general agreement to slim down the number of applications in this group and move them to Extras (see
Re: Is ofbiz going the sugarcrm, magento route? (essential extra's are commercial?)
Le 21/03/2012 14:00, Hans Bakker a écrit : (I also copied the user list because users are heavily impacted here. Users please read the development forum at http://www.ofbiz.info) Hi Everybody interested in the future of ofbiz, - *i am very concerned with the current route which is proposed by Jacopo in the development mailing list: Lose Weight Program for OFBiz* Why? Have only a minimal core ERP with minimal functionality, anything extra is moved to either: 1. *Apache extras* (http://www.apache-extras.com) which is just a url link menu into Google projects This will not be maintained by the Apache OFBiz committers and only outside the Apache environment. 2. *attic* (abandoned=deleted) Pushing out complete components and functions like for example all components in the specialized directory such as e-commerce, project manager, asset manager and others and also Birt (Reporting) integration out of the OFBiz core system will actually mean: components will be abandoned even when stored in apache extra's and will be picked up by commercial companies like mine (Antwebsystems) and others and will promote them as commercial add-ons for a fee. [my Antwebsystems CEO hat on] Actually we (AntWebsystems) already started the process a couple of months ago, we have internal chat/live chat(see our website), twitter, sitemap, saas/tenant extension, shindig/igoogle integration, task manager and more because a number of committers objected that we added more functions, so we stopped contributing major functions. [my Apache PMC member hat on] This can now happen with anything that will be removed from the core system. There are many articles about the commercialization of open source products on the internet, examples are Sugercrm and Magento and OFBiz will be the next one: *In the future, a reasonable OFBiz system cannot be be run without commercial extra's! in my mind plug-in system is good to replace a plug-in we don't want * Please keep this in mind if you react on the proposal Lose Weight Program for OFBiz: do not agree too easily. I'm a GPL fan, so I will do all what is possible to be sure there will still a large community for a Free software ERP base on OFBiz I'm a modularity fan, so I don't like monolithic IMO The key point is how will be organize the OFBiz-extras and how it will be easy for a end user to download and install a solution (= OFBiz kernel + list of plug-in) [my Antwebsystems CEO hat on] From a commercialization point of view please remove as much as possible. [my Apache PMC member hat on] Only remove the component/functions which are not maintained. clarify what is maintained by whom, and who is using what and sometime the maturity level of a feature (dev, V0, stable , ...) Regards, Hans Bakker *Proud Apache OFBiz PMC member* and yes also CEO Antwebsystems Co.Ltd.
