[jira] [Commented] (OFBIZ-6144) FindShipment.groovy error due to null findShipmentExprs
[ https://issues.apache.org/jira/browse/OFBIZ-6144?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14357114#comment-14357114 ] Christian Carlow commented on OFBIZ-6144: - FindShipment.groovy used to have a check to make sure findShipmentExprs existed before performing the query at line 135. FindShipment.groovy error due to null findShipmentExprs --- Key: OFBIZ-6144 URL: https://issues.apache.org/jira/browse/OFBIZ-6144 Project: OFBiz Issue Type: Bug Components: product Affects Versions: Trunk Reporter: Christian Carlow The error below occurs when findShipmentExprs is null in FindShipment.groovy which prevents the page from even displaying. IMO the FindShipment.groovy and FindShipment.ftl should be replaced with form widgets. ERROR rendering error page [/error/error.jsp], but here is the error text: org.ofbiz.widget.renderer.ScreenRenderException: Error rendering screen [component://product/widget/facility/ShipmentScreens.xml#FindShipment]: java.lang.IllegalArgumentException: Error running script at location [component://product/webapp/facility/WEB-INF/actions/shipment/FindShipment.groovy]: groovy.lang.GroovyRuntimeException: Ambiguous method overloading for method org.ofbiz.entity.util.EntityQuery#where. Cannot resolve which method to invoke for [null] due to overlapping prototypes between: [interface java.util.List] [interface java.util.Map] (Error running script at location [component://product/webapp/facility/WEB-INF/actions/shipment/FindShipment.groovy]: groovy.lang.GroovyRuntimeException: Ambiguous method overloading for method org.ofbiz.entity.util.EntityQuery#where. Cannot resolve which method to invoke for [null] due to overlapping prototypes between: [interface java.util.List] [interface java.util.Map]) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
Re: OFBiz integration for Magento eCommerce
Le 11/03/2015 12:19, Jacopo Cappellato a écrit : On Mar 10, 2015, at 10:45 PM, Pierre Smitspierre.sm...@gmail.com wrote: Apart from that, might I suggest another approach: in stead of committing the solution straight away into the special purpose stack, why don't you create the umbrella issue and attach the patch to it Yes, this is exactly what I was planning to do, I will ask Arun Patidar to prepare a patch and submit it to a Jira ticket. I was not seeking for approval to commit before a community review, but instead I was offering to the community an opportunity to get a new contribution and I was checking for its interest in it. Is it a big stuff? Anyway this is completely external I guess, so indeed it should have no implications on current state. Jacques Regards, Jacopo
[jira] [Assigned] (OFBIZ-6143) Incorporate the readme for the projectmgr component
[ https://issues.apache.org/jira/browse/OFBIZ-6143?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pierre Smits reassigned OFBIZ-6143: --- Assignee: Pierre Smits Incorporate the readme for the projectmgr component --- Key: OFBIZ-6143 URL: https://issues.apache.org/jira/browse/OFBIZ-6143 Project: OFBiz Issue Type: Improvement Components: specialpurpose/projectmgr Affects Versions: Trunk Reporter: Pierre Smits Assignee: Pierre Smits -- This message was sent by Atlassian JIRA (v6.3.4#6332)
Re: OFBiz integration for Magento eCommerce
On Feb 27, 2015, at 9:49 AM, Jacques Le Roux jacques.le.r...@les7arts.com wrote: That's quite an interesting proposition. I guess HotWax Systems already used it in production? Jacques We have implemented this as a product, not for a customer project and we will present it in an upcoming Magento conference. Jacopo Le 27/02/2015 09:17, Jacopo Cappellato a écrit : Hi all, in the last year, the research and development lab of HotWax Systems has implemented a series of components and tools for OFBiz. Some of them are ready-to-be-used applications and, in my opinion, would be a good fit for OFBiz. After discussing the topic internally, we believe that the community could benefit from them and at the same time help to further improve them. Accordingly, I would like to start by exploring with you the opportunity to include in OFBiz our integration with Magento eCommerce platform. Magento eCommerce (http://magento.com/products/overview) is a popular solution for merchants; it is an open source product (but the company is owned by eBay). In terms of features it competes with the OFBiz ecommerce component, but it is easier to setup and with a shorter go to market. For these reasons it is a good fit for small-medium merchants that need an ecommerce store with no backend capabilities and it has a very large users base. We realized that there could be a rather large group of merchants, already using Magento for online sales, that may be interested in integrating it with a powerful ERP system for the backend tasks (order fulfillment, accounting etc...). The integration component we have implemented has a nice user interface to import categories, products, orders from Magento eCommerce and then synch held/cancelled orders; there are screens to manage shipment options and product store settings. You can find some screenshot here: http://people.apache.org/~jacopoc/magento-integration-2.png http://people.apache.org/~jacopoc/magento-integration-3.png http://people.apache.org/~jacopoc/magento-integration-4.png http://people.apache.org/~jacopoc/magento-integration-5.png Arun Patidar led the effort and is happy to provide additional details so please feel free to ask any questions. In my opinion this product could be integrated as a specialpurpose component, but I am open to suggestions. What do you think? Jacopo
[jira] [Updated] (OFBIZ-6144) FindShipment.groovy error due to null findShipmentExprs
[ https://issues.apache.org/jira/browse/OFBIZ-6144?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christian Carlow updated OFBIZ-6144: Attachment: OFBIZ-6144.patch This patch replaces FindShipment.groovy and FindShipment.ftl with form widgets. The two files can probably be removed once this patch is applied. FindShipment.groovy error due to null findShipmentExprs --- Key: OFBIZ-6144 URL: https://issues.apache.org/jira/browse/OFBIZ-6144 Project: OFBiz Issue Type: Bug Components: product Affects Versions: Trunk Reporter: Christian Carlow Attachments: OFBIZ-6144.patch The error below occurs when findShipmentExprs is null in FindShipment.groovy which prevents the page from even displaying. IMO the FindShipment.groovy and FindShipment.ftl should be replaced with form widgets. ERROR rendering error page [/error/error.jsp], but here is the error text: org.ofbiz.widget.renderer.ScreenRenderException: Error rendering screen [component://product/widget/facility/ShipmentScreens.xml#FindShipment]: java.lang.IllegalArgumentException: Error running script at location [component://product/webapp/facility/WEB-INF/actions/shipment/FindShipment.groovy]: groovy.lang.GroovyRuntimeException: Ambiguous method overloading for method org.ofbiz.entity.util.EntityQuery#where. Cannot resolve which method to invoke for [null] due to overlapping prototypes between: [interface java.util.List] [interface java.util.Map] (Error running script at location [component://product/webapp/facility/WEB-INF/actions/shipment/FindShipment.groovy]: groovy.lang.GroovyRuntimeException: Ambiguous method overloading for method org.ofbiz.entity.util.EntityQuery#where. Cannot resolve which method to invoke for [null] due to overlapping prototypes between: [interface java.util.List] [interface java.util.Map]) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
Why are committers accounts never terminated?
Hi Infra Team and All, I have a question I wonder for some time and recently discussed in our OFBiz PMC ML. Committers come and go. When a PMC member resign, because s/he clearly wants to stop helping on the project and want to be completely disconnect from it, her/his committer account remains active. I wonder if this is not an useless security hole. Same for no longer active committers. The difference with an active committer is s/he will never know since s/he is possibly no longer monitoring things. A credential can be abused by an external person, that can be the beginning of much troubles we can not all imagine (hackers do)... With security holes you never know, until it bites you, so I really wonder why a committer account can not be terminated? Thanks Jacques
[jira] [Commented] (OFBIZ-5573) Implementation of VENDOR MANAGEMENT software in Ofbiz in ecommerce component
[ https://issues.apache.org/jira/browse/OFBIZ-5573?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14357171#comment-14357171 ] Ravi Shekhar commented on OFBIZ-5573: - Is there any interest or approach decided for the marketplace implemetation? Is this issue going anywhere? Implementation of VENDOR MANAGEMENT software in Ofbiz in ecommerce component - Key: OFBIZ-5573 URL: https://issues.apache.org/jira/browse/OFBIZ-5573 Project: OFBiz Issue Type: Improvement Components: specialpurpose/ecommerce Environment: Software platform, Ecommerce component, Party Component, Catalog Component Reporter: Heidi Dehaes Priority: Trivial Attachments: vendor_spec-1.pdf, vendor_spec.doc, vendor_spec.doc, vendor_specifications_17_Oktober_2014-2B.doc, vendor_specifications_17_Oktober_2014.doc, vendor_specifications_17_Oktober_2014.doc, vendor_specifications_2_july_2014.doc Wants to initiate the development of a VENDOR ENVIRONMENT AND MANAGEMENT for ofbiz in the ecommerce component as exists also in the Amazon ecommerce websites. An external vendor must be able to put products and sell the products on the ecommerce platform of the owner. Involved: - ioannis ntantis giannis...@gmail.com - Heidi Eric info.ola...@gmail.com Requirements: - ... to be added. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (OFBIZ-5522) Introduce websocket usage
[ https://issues.apache.org/jira/browse/OFBIZ-5522?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14358488#comment-14358488 ] Neeraj kumar commented on OFBIZ-5522: - Always decide on a efficient moreover to well-known getting along with going company. Visit for Best info: Packers and Movers Pune @ http://packersmoverspune.top3rd.in/ Packers and Movers Hyderabad @ http://www.expert5th.in/packers-and-movers-hyderabad/ Packers and Movers Mumbai @ http://www.expert5th.in/packers-and-movers-mumbai/ Packers and Movers Mumbai @ http://www.local5th.in/packers-and-movers-mumbai/ Packers and Movers Chennai @ http://www.expert5th.in/packers-and-movers-chennai/ Introduce websocket usage - Key: OFBIZ-5522 URL: https://issues.apache.org/jira/browse/OFBIZ-5522 Project: OFBiz Issue Type: Task Components: framework Affects Versions: Trunk Reporter: Jacques Le Roux Priority: Minor After a discussion with Ean, was suggested (draft here): You need a service that lets you subscribe a widget to an entity and then propagate change events to the widget as the entity is modified. A generic mechanism like that could eventually expand to be a general purpose data bound widgets system that mostly looks like the existing system but magically reflects updates. Could be used with/for * The entity cache and webforms to automatically update views when data changes. * Replaces the current system notes * Create a dashboard type pages (to be discussed futher) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (OFBIZ-5522) Introduce websocket usage
[ https://issues.apache.org/jira/browse/OFBIZ-5522?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14358516#comment-14358516 ] Neeraj kumar commented on OFBIZ-5522: - These functions appear simple but in real they are frustrating and topsy-turvy one. But selecting an outstanding Packers Moving organizations Organization can create your career trouble-free. Packers and Movers Pune @ http://packersmoverspune.top3rd.in/ Introduce websocket usage - Key: OFBIZ-5522 URL: https://issues.apache.org/jira/browse/OFBIZ-5522 Project: OFBiz Issue Type: Task Components: framework Affects Versions: Trunk Reporter: Jacques Le Roux Priority: Minor After a discussion with Ean, was suggested (draft here): You need a service that lets you subscribe a widget to an entity and then propagate change events to the widget as the entity is modified. A generic mechanism like that could eventually expand to be a general purpose data bound widgets system that mostly looks like the existing system but magically reflects updates. Could be used with/for * The entity cache and webforms to automatically update views when data changes. * Replaces the current system notes * Create a dashboard type pages (to be discussed futher) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
Welcome to Deepak Dixit as new committer!
The OFBiz PMC has invited Deepak Dixit to become a new committer and he has accepted the new role. Deepak, thank you for your continued commitment and valuable contributions. Welcome onboard! Jacopo
[jira] [Commented] (OFBIZ-5522) Introduce websocket usage
[ https://issues.apache.org/jira/browse/OFBIZ-5522?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14358520#comment-14358520 ] Neeraj kumar commented on OFBIZ-5522: - Packing and shifting of useful products is a maddening and uninteresting process. Several projects like overall look, working, unloading and transportation have to be done. Packers and Movers Mumbai @ http://www.expert5th.in/packers-and-movers-mumbai/ Introduce websocket usage - Key: OFBIZ-5522 URL: https://issues.apache.org/jira/browse/OFBIZ-5522 Project: OFBiz Issue Type: Task Components: framework Affects Versions: Trunk Reporter: Jacques Le Roux Priority: Minor After a discussion with Ean, was suggested (draft here): You need a service that lets you subscribe a widget to an entity and then propagate change events to the widget as the entity is modified. A generic mechanism like that could eventually expand to be a general purpose data bound widgets system that mostly looks like the existing system but magically reflects updates. Could be used with/for * The entity cache and webforms to automatically update views when data changes. * Replaces the current system notes * Create a dashboard type pages (to be discussed futher) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
Re: Welcome to Deepak Dixit as new committer!
Congratulations and welcome Deepak! On 12.3.2015 12:25, Gavin Mabie wrote: Congratulations Deepak On Thu, Mar 12, 2015 at 1:19 PM, Jacopo Cappellato jacopo.cappell...@hotwaxsystems.com wrote: The OFBiz PMC has invited Deepak Dixit to become a new committer and he has accepted the new role. Deepak, thank you for your continued commitment and valuable contributions. Welcome onboard! Jacopo
Re: Why are committers accounts never terminated?
Ron, I suspect the ASF has the tools/solutions regarding those processes to the PMC. Best regards, Pierre Smits *ORRTIZ.COM http://www.orrtiz.com* Services Solutions for Cloud- Based Manufacturing, Professional Services and Retail Trade http://www.orrtiz.com On Thu, Mar 12, 2015 at 2:26 PM, Ron Wheeler rwhee...@artifact-software.com wrote: I thought that we were talking about removing accounts not erasing past contributors from all history of the project. Is there some great difficulty to adding a committer with the right privs? How much karma is encapsulated in the actual account? Getting rid of unused accounts seems to be a common recommendation for improving security. Having an up-to-date list of voters would probably help to clarify the results of votes for releases, etc. Turning 20% of the eligible voters into 80% by cleaning the enumeration list, makes it easier to explain why a release vote was accepted. Ron On 12/03/2015 9:15 AM, Jake Farrell wrote: Hi Pierre merit and karma are earned and should not be taken away. If we where to remove karma for services and then someone came back how would we track what their previous permissions had been, this would leave no guarantee that they would have the same permissions they had when they initially stepped away for whatever reason. -Jake On Thu, Mar 12, 2015 at 9:09 AM, Pierre Smits pierre.sm...@gmail.com wrote: I apparently only replied to Jaques. See that message below. Pierre Smits *ORRTIZ.COM http://www.orrtiz.com* Services Solutions for Cloud- Based Manufacturing, Professional Services and Retail Trade http://www.orrtiz.com -- Forwarded message -- From: Pierre Smits pierre.sm...@gmail.com Date: Thu, Mar 12, 2015 at 1:15 PM Subject: Re: Why are committers accounts never terminated? To: Jacques Le Roux jacques.le.r...@les7arts.com When committers resign on their own accord (for whatever reason) their permissions for the tools of the project (JIRA, CONFLUENCE, SVN, etc) should be revoked. When they want to be active again, this can easily be facilitated. Best regards, Pierre Smits *ORRTIZ.COM http://www.orrtiz.com* Services Solutions for Cloud- Based Manufacturing, Professional Services and Retail Trade http://www.orrtiz.com On Thu, Mar 12, 2015 at 1:11 PM, Jacques Le Roux jacques.le.r...@les7arts.com wrote: Thanks Mark, It's quite clear Jacques Le 12/03/2015 11:59, Mark Thomas a écrit : On 12/03/2015 09:50, Jacques Le Roux wrote: Hi Infra Team and All, I have a question I wonder for some time and recently discussed in our OFBiz PMC ML. Committers come and go. When a PMC member resign, because s/he clearly wants to stop helping on the project and want to be completely disconnect from it, her/his committer account remains active. I wonder if this is not an useless security hole. Same for no longer active committers. The difference with an active committer is s/he will never know since s/he is possibly no longer monitoring things. A credential can be abused by an external person, that can be the beginning of much troubles we can not all imagine (hackers do)... With security holes you never know, until it bites you, so I really wonder why a committer account can not be terminated? A committer account on its own can do very little in the way of harm. It can (if you know which hoops to jump through) get shell access to people.a.o and it can send e-mail from an @apache.org e-mail address. people.a.o is locked down (and infra has additional monitoring in place) so the risk here is sufficiently small infra is happy with it. It terms of sending e-mail via an @apache.org e-mail address, if it is abusive (i.e. spammy) then we do rely on folks reporting it to us. The PMC is responsible for granting (and revoking) commit access. There is nothing (of a technical nature - you'll have to answer to the board and your community for the social aspects) stopping you removing inactive committers from the appropriate LDAP group(s). I'd add that the PMC is responsible for reviewing all the commits made to the PMC's repositories. You are expected to spot if a long inactive committer suddenly starts making changes or an account you don't recognise makes changes. Likewise, active committers are expected to spot changes in their name they did not make. More generally, if infra has a security concern we shut stuff down and/or lock accounts first and ask questions later. Any security concerns should be reported immediately to r...@apache.org Finally, infra periodically enforces password resets for all committers. This has the helpful side-effect of effectively locking unused committer accounts. Mark -- Ron Wheeler President Artifact Software Inc email: rwhee...@artifact-software.com skype: ronaldmwheeler phone: 866-970-2435, ext 102
Re: Welcome to Deepak Dixit as new committer!
Congrats Deepak! Adrian Crum Sandglass Software www.sandglass-software.com On 3/12/2015 11:19 AM, Jacopo Cappellato wrote: The OFBiz PMC has invited Deepak Dixit to become a new committer and he has accepted the new role. Deepak, thank you for your continued commitment and valuable contributions. Welcome onboard! Jacopo
Upcoming releases according to our tentative schedule
Hi all, according to our tentative schedule published here: http://ofbiz.apache.org/download.html there are two upcoming releases: * March - Apache OFBiz 13.07.02 * April - Apache OFBiz 12.04.06 (the last release in the 12.04 series) I think that the two branches are in good shape and I could start the preparation of 13.07.02 now. After that we will prepare the 12.04.06 ones to be published in April. What do you think? Jacopo
Re: Why are committers accounts never terminated?
We're not even talking about removing accounts. That is at ASF level. But we're talking about revoking permissions. Best regards, Pierre Smits *ORRTIZ.COM http://www.orrtiz.com* Services Solutions for Cloud- Based Manufacturing, Professional Services and Retail Trade http://www.orrtiz.com On Thu, Mar 12, 2015 at 2:26 PM, Ron Wheeler rwhee...@artifact-software.com wrote: I thought that we were talking about removing accounts not erasing past contributors from all history of the project. Is there some great difficulty to adding a committer with the right privs? How much karma is encapsulated in the actual account? Getting rid of unused accounts seems to be a common recommendation for improving security. Having an up-to-date list of voters would probably help to clarify the results of votes for releases, etc. Turning 20% of the eligible voters into 80% by cleaning the enumeration list, makes it easier to explain why a release vote was accepted. Ron On 12/03/2015 9:15 AM, Jake Farrell wrote: Hi Pierre merit and karma are earned and should not be taken away. If we where to remove karma for services and then someone came back how would we track what their previous permissions had been, this would leave no guarantee that they would have the same permissions they had when they initially stepped away for whatever reason. -Jake On Thu, Mar 12, 2015 at 9:09 AM, Pierre Smits pierre.sm...@gmail.com wrote: I apparently only replied to Jaques. See that message below. Pierre Smits *ORRTIZ.COM http://www.orrtiz.com* Services Solutions for Cloud- Based Manufacturing, Professional Services and Retail Trade http://www.orrtiz.com -- Forwarded message -- From: Pierre Smits pierre.sm...@gmail.com Date: Thu, Mar 12, 2015 at 1:15 PM Subject: Re: Why are committers accounts never terminated? To: Jacques Le Roux jacques.le.r...@les7arts.com When committers resign on their own accord (for whatever reason) their permissions for the tools of the project (JIRA, CONFLUENCE, SVN, etc) should be revoked. When they want to be active again, this can easily be facilitated. Best regards, Pierre Smits *ORRTIZ.COM http://www.orrtiz.com* Services Solutions for Cloud- Based Manufacturing, Professional Services and Retail Trade http://www.orrtiz.com On Thu, Mar 12, 2015 at 1:11 PM, Jacques Le Roux jacques.le.r...@les7arts.com wrote: Thanks Mark, It's quite clear Jacques Le 12/03/2015 11:59, Mark Thomas a écrit : On 12/03/2015 09:50, Jacques Le Roux wrote: Hi Infra Team and All, I have a question I wonder for some time and recently discussed in our OFBiz PMC ML. Committers come and go. When a PMC member resign, because s/he clearly wants to stop helping on the project and want to be completely disconnect from it, her/his committer account remains active. I wonder if this is not an useless security hole. Same for no longer active committers. The difference with an active committer is s/he will never know since s/he is possibly no longer monitoring things. A credential can be abused by an external person, that can be the beginning of much troubles we can not all imagine (hackers do)... With security holes you never know, until it bites you, so I really wonder why a committer account can not be terminated? A committer account on its own can do very little in the way of harm. It can (if you know which hoops to jump through) get shell access to people.a.o and it can send e-mail from an @apache.org e-mail address. people.a.o is locked down (and infra has additional monitoring in place) so the risk here is sufficiently small infra is happy with it. It terms of sending e-mail via an @apache.org e-mail address, if it is abusive (i.e. spammy) then we do rely on folks reporting it to us. The PMC is responsible for granting (and revoking) commit access. There is nothing (of a technical nature - you'll have to answer to the board and your community for the social aspects) stopping you removing inactive committers from the appropriate LDAP group(s). I'd add that the PMC is responsible for reviewing all the commits made to the PMC's repositories. You are expected to spot if a long inactive committer suddenly starts making changes or an account you don't recognise makes changes. Likewise, active committers are expected to spot changes in their name they did not make. More generally, if infra has a security concern we shut stuff down and/or lock accounts first and ask questions later. Any security concerns should be reported immediately to r...@apache.org Finally, infra periodically enforces password resets for all committers. This has the helpful side-effect of effectively locking unused committer accounts. Mark -- Ron Wheeler President Artifact Software Inc email: rwhee...@artifact-software.com skype: ronaldmwheeler phone: 866-970-2435, ext 102
Re: Why are committers accounts never terminated?
I'm with Pierre on this one. The ATS PMC has, as an example, several members and committers who no longer read or reply to emails. We honestly have no idea if they are even in control of their accounts. Cheers, -- Leif On Mar 12, 2015, at 7:21 AM, Pierre Smits pierre.sm...@gmail.com wrote: Hi Jake, I am not talking about removing merit and karma. Such is persisted in many ways, think web pages, wiki pages, etc. I am talking about revoking permissions at tools levels. That doesn't mean deleting committers identities within the ASF. Ensuring that committers get the same permissions back (or not) is up to the PMC of a project to decide. Best regards, Pierre Smits *ORRTIZ.COM http://www.orrtiz.com* Services Solutions for Cloud- Based Manufacturing, Professional Services and Retail Trade http://www.orrtiz.com On Thu, Mar 12, 2015 at 2:15 PM, Jake Farrell jfarr...@apache.org wrote: Hi Pierre merit and karma are earned and should not be taken away. If we where to remove karma for services and then someone came back how would we track what their previous permissions had been, this would leave no guarantee that they would have the same permissions they had when they initially stepped away for whatever reason. -Jake On Thu, Mar 12, 2015 at 9:09 AM, Pierre Smits pierre.sm...@gmail.com wrote: I apparently only replied to Jaques. See that message below. Pierre Smits *ORRTIZ.COM http://www.orrtiz.com* Services Solutions for Cloud- Based Manufacturing, Professional Services and Retail Trade http://www.orrtiz.com -- Forwarded message -- From: Pierre Smits pierre.sm...@gmail.com Date: Thu, Mar 12, 2015 at 1:15 PM Subject: Re: Why are committers accounts never terminated? To: Jacques Le Roux jacques.le.r...@les7arts.com When committers resign on their own accord (for whatever reason) their permissions for the tools of the project (JIRA, CONFLUENCE, SVN, etc) should be revoked. When they want to be active again, this can easily be facilitated. Best regards, Pierre Smits *ORRTIZ.COM http://www.orrtiz.com* Services Solutions for Cloud- Based Manufacturing, Professional Services and Retail Trade http://www.orrtiz.com On Thu, Mar 12, 2015 at 1:11 PM, Jacques Le Roux jacques.le.r...@les7arts.com wrote: Thanks Mark, It's quite clear Jacques Le 12/03/2015 11:59, Mark Thomas a écrit : On 12/03/2015 09:50, Jacques Le Roux wrote: Hi Infra Team and All, I have a question I wonder for some time and recently discussed in our OFBiz PMC ML. Committers come and go. When a PMC member resign, because s/he clearly wants to stop helping on the project and want to be completely disconnect from it, her/his committer account remains active. I wonder if this is not an useless security hole. Same for no longer active committers. The difference with an active committer is s/he will never know since s/he is possibly no longer monitoring things. A credential can be abused by an external person, that can be the beginning of much troubles we can not all imagine (hackers do)... With security holes you never know, until it bites you, so I really wonder why a committer account can not be terminated? A committer account on its own can do very little in the way of harm. It can (if you know which hoops to jump through) get shell access to people.a.o and it can send e-mail from an @apache.org e-mail address. people.a.o is locked down (and infra has additional monitoring in place) so the risk here is sufficiently small infra is happy with it. It terms of sending e-mail via an @apache.org e-mail address, if it is abusive (i.e. spammy) then we do rely on folks reporting it to us. The PMC is responsible for granting (and revoking) commit access. There is nothing (of a technical nature - you'll have to answer to the board and your community for the social aspects) stopping you removing inactive committers from the appropriate LDAP group(s). I'd add that the PMC is responsible for reviewing all the commits made to the PMC's repositories. You are expected to spot if a long inactive committer suddenly starts making changes or an account you don't recognise makes changes. Likewise, active committers are expected to spot changes in their name they did not make. More generally, if infra has a security concern we shut stuff down and/or lock accounts first and ask questions later. Any security concerns should be reported immediately to r...@apache.org Finally, infra periodically enforces password resets for all committers. This has the helpful side-effect of effectively locking unused committer accounts. Mark
Re: Why are committers accounts never terminated?
I thought that we were talking about removing accounts not erasing past contributors from all history of the project. Is there some great difficulty to adding a committer with the right privs? How much karma is encapsulated in the actual account? Getting rid of unused accounts seems to be a common recommendation for improving security. Having an up-to-date list of voters would probably help to clarify the results of votes for releases, etc. Turning 20% of the eligible voters into 80% by cleaning the enumeration list, makes it easier to explain why a release vote was accepted. Ron On 12/03/2015 9:15 AM, Jake Farrell wrote: Hi Pierre merit and karma are earned and should not be taken away. If we where to remove karma for services and then someone came back how would we track what their previous permissions had been, this would leave no guarantee that they would have the same permissions they had when they initially stepped away for whatever reason. -Jake On Thu, Mar 12, 2015 at 9:09 AM, Pierre Smits pierre.sm...@gmail.com wrote: I apparently only replied to Jaques. See that message below. Pierre Smits *ORRTIZ.COM http://www.orrtiz.com* Services Solutions for Cloud- Based Manufacturing, Professional Services and Retail Trade http://www.orrtiz.com -- Forwarded message -- From: Pierre Smits pierre.sm...@gmail.com Date: Thu, Mar 12, 2015 at 1:15 PM Subject: Re: Why are committers accounts never terminated? To: Jacques Le Roux jacques.le.r...@les7arts.com When committers resign on their own accord (for whatever reason) their permissions for the tools of the project (JIRA, CONFLUENCE, SVN, etc) should be revoked. When they want to be active again, this can easily be facilitated. Best regards, Pierre Smits *ORRTIZ.COM http://www.orrtiz.com* Services Solutions for Cloud- Based Manufacturing, Professional Services and Retail Trade http://www.orrtiz.com On Thu, Mar 12, 2015 at 1:11 PM, Jacques Le Roux jacques.le.r...@les7arts.com wrote: Thanks Mark, It's quite clear Jacques Le 12/03/2015 11:59, Mark Thomas a écrit : On 12/03/2015 09:50, Jacques Le Roux wrote: Hi Infra Team and All, I have a question I wonder for some time and recently discussed in our OFBiz PMC ML. Committers come and go. When a PMC member resign, because s/he clearly wants to stop helping on the project and want to be completely disconnect from it, her/his committer account remains active. I wonder if this is not an useless security hole. Same for no longer active committers. The difference with an active committer is s/he will never know since s/he is possibly no longer monitoring things. A credential can be abused by an external person, that can be the beginning of much troubles we can not all imagine (hackers do)... With security holes you never know, until it bites you, so I really wonder why a committer account can not be terminated? A committer account on its own can do very little in the way of harm. It can (if you know which hoops to jump through) get shell access to people.a.o and it can send e-mail from an @apache.org e-mail address. people.a.o is locked down (and infra has additional monitoring in place) so the risk here is sufficiently small infra is happy with it. It terms of sending e-mail via an @apache.org e-mail address, if it is abusive (i.e. spammy) then we do rely on folks reporting it to us. The PMC is responsible for granting (and revoking) commit access. There is nothing (of a technical nature - you'll have to answer to the board and your community for the social aspects) stopping you removing inactive committers from the appropriate LDAP group(s). I'd add that the PMC is responsible for reviewing all the commits made to the PMC's repositories. You are expected to spot if a long inactive committer suddenly starts making changes or an account you don't recognise makes changes. Likewise, active committers are expected to spot changes in their name they did not make. More generally, if infra has a security concern we shut stuff down and/or lock accounts first and ask questions later. Any security concerns should be reported immediately to r...@apache.org Finally, infra periodically enforces password resets for all committers. This has the helpful side-effect of effectively locking unused committer accounts. Mark -- Ron Wheeler President Artifact Software Inc email: rwhee...@artifact-software.com skype: ronaldmwheeler phone: 866-970-2435, ext 102
Re: Welcome to Deepak Dixit as new committer!
This is how Deepak looks like today with a very pleasant smile. :-) http://www.hotwaxsystems.com/Deepak-Dixit-1.jpg http://www.hotwaxsystems.com/Deepak-Dixit-2.jpg Many Congratulations Deepak!! -- Kind Regards Ashish Vijaywargiya HotWax Systems - est. 1997 On Thu, Mar 12, 2015 at 4:49 PM, Jacopo Cappellato jacopo.cappell...@hotwaxsystems.com wrote: The OFBiz PMC has invited Deepak Dixit to become a new committer and he has accepted the new role. Deepak, thank you for your continued commitment and valuable contributions. Welcome onboard! Jacopo
Re: Upcoming releases according to our tentative schedule
Some of the Commons libraries have new releases that include bug fixes, so it would be nice to get those in. I am aware of Validator and DHCP. Adrian Crum Sandglass Software www.sandglass-software.com On 3/12/2015 2:31 PM, Jacopo Cappellato wrote: Hi all, according to our tentative schedule published here: http://ofbiz.apache.org/download.html there are two upcoming releases: * March - Apache OFBiz 13.07.02 * April - Apache OFBiz 12.04.06 (the last release in the 12.04 series) I think that the two branches are in good shape and I could start the preparation of 13.07.02 now. After that we will prepare the 12.04.06 ones to be published in April. What do you think? Jacopo
Re: Why are committers accounts never terminated?
Hi Pierre merit and karma are earned and should not be taken away. If we where to remove karma for services and then someone came back how would we track what their previous permissions had been, this would leave no guarantee that they would have the same permissions they had when they initially stepped away for whatever reason. -Jake On Thu, Mar 12, 2015 at 9:09 AM, Pierre Smits pierre.sm...@gmail.com wrote: I apparently only replied to Jaques. See that message below. Pierre Smits *ORRTIZ.COM http://www.orrtiz.com* Services Solutions for Cloud- Based Manufacturing, Professional Services and Retail Trade http://www.orrtiz.com -- Forwarded message -- From: Pierre Smits pierre.sm...@gmail.com Date: Thu, Mar 12, 2015 at 1:15 PM Subject: Re: Why are committers accounts never terminated? To: Jacques Le Roux jacques.le.r...@les7arts.com When committers resign on their own accord (for whatever reason) their permissions for the tools of the project (JIRA, CONFLUENCE, SVN, etc) should be revoked. When they want to be active again, this can easily be facilitated. Best regards, Pierre Smits *ORRTIZ.COM http://www.orrtiz.com* Services Solutions for Cloud- Based Manufacturing, Professional Services and Retail Trade http://www.orrtiz.com On Thu, Mar 12, 2015 at 1:11 PM, Jacques Le Roux jacques.le.r...@les7arts.com wrote: Thanks Mark, It's quite clear Jacques Le 12/03/2015 11:59, Mark Thomas a écrit : On 12/03/2015 09:50, Jacques Le Roux wrote: Hi Infra Team and All, I have a question I wonder for some time and recently discussed in our OFBiz PMC ML. Committers come and go. When a PMC member resign, because s/he clearly wants to stop helping on the project and want to be completely disconnect from it, her/his committer account remains active. I wonder if this is not an useless security hole. Same for no longer active committers. The difference with an active committer is s/he will never know since s/he is possibly no longer monitoring things. A credential can be abused by an external person, that can be the beginning of much troubles we can not all imagine (hackers do)... With security holes you never know, until it bites you, so I really wonder why a committer account can not be terminated? A committer account on its own can do very little in the way of harm. It can (if you know which hoops to jump through) get shell access to people.a.o and it can send e-mail from an @apache.org e-mail address. people.a.o is locked down (and infra has additional monitoring in place) so the risk here is sufficiently small infra is happy with it. It terms of sending e-mail via an @apache.org e-mail address, if it is abusive (i.e. spammy) then we do rely on folks reporting it to us. The PMC is responsible for granting (and revoking) commit access. There is nothing (of a technical nature - you'll have to answer to the board and your community for the social aspects) stopping you removing inactive committers from the appropriate LDAP group(s). I'd add that the PMC is responsible for reviewing all the commits made to the PMC's repositories. You are expected to spot if a long inactive committer suddenly starts making changes or an account you don't recognise makes changes. Likewise, active committers are expected to spot changes in their name they did not make. More generally, if infra has a security concern we shut stuff down and/or lock accounts first and ask questions later. Any security concerns should be reported immediately to r...@apache.org Finally, infra periodically enforces password resets for all committers. This has the helpful side-effect of effectively locking unused committer accounts. Mark
Re: Welcome to Deepak Dixit as new committer!
Many Congratulations Deepak!!! Thanks Regards --- Arun Patidar Manager,Enterprise Software Development HotWax Media www.hotwaxsystems.com On Thursday 12 March 2015 04:49 PM, Jacopo Cappellato wrote: The OFBiz PMC has invited Deepak Dixit to become a new committer and he has accepted the new role. Deepak, thank you for your continued commitment and valuable contributions. Welcome onboard! Jacopo
Fwd: Why are committers accounts never terminated?
This bounced. Pierre Smits *ORRTIZ.COM http://www.orrtiz.com* Services Solutions for Cloud- Based Manufacturing, Professional Services and Retail Trade http://www.orrtiz.com -- Forwarded message -- From: Pierre Smits pierre.sm...@gmail.com Date: Thu, Mar 12, 2015 at 2:21 PM Subject: Re: Why are committers accounts never terminated? To: jfarr...@apache.org Cc: Mark Thomas ma...@apache.org, infrastruct...@apache.org infrastruct...@apache.org, dev@ofbiz.apache.org dev@ofbiz.apache.org, d...@community.apache.org d...@community.apache.org Hi Jake, I am not talking about removing merit and karma. Such is persisted in many ways, think web pages, wiki pages, etc. I am talking about revoking permissions at tools levels. That doesn't mean deleting committers identities within the ASF. Ensuring that committers get the same permissions back (or not) is up to the PMC of a project to decide. Best regards, Pierre Smits *ORRTIZ.COM http://www.orrtiz.com* Services Solutions for Cloud- Based Manufacturing, Professional Services and Retail Trade http://www.orrtiz.com On Thu, Mar 12, 2015 at 2:15 PM, Jake Farrell jfarr...@apache.org wrote: Hi Pierre merit and karma are earned and should not be taken away. If we where to remove karma for services and then someone came back how would we track what their previous permissions had been, this would leave no guarantee that they would have the same permissions they had when they initially stepped away for whatever reason. -Jake On Thu, Mar 12, 2015 at 9:09 AM, Pierre Smits pierre.sm...@gmail.com wrote: I apparently only replied to Jaques. See that message below. Pierre Smits *ORRTIZ.COM http://www.orrtiz.com* Services Solutions for Cloud- Based Manufacturing, Professional Services and Retail Trade http://www.orrtiz.com -- Forwarded message -- From: Pierre Smits pierre.sm...@gmail.com Date: Thu, Mar 12, 2015 at 1:15 PM Subject: Re: Why are committers accounts never terminated? To: Jacques Le Roux jacques.le.r...@les7arts.com When committers resign on their own accord (for whatever reason) their permissions for the tools of the project (JIRA, CONFLUENCE, SVN, etc) should be revoked. When they want to be active again, this can easily be facilitated. Best regards, Pierre Smits *ORRTIZ.COM http://www.orrtiz.com* Services Solutions for Cloud- Based Manufacturing, Professional Services and Retail Trade http://www.orrtiz.com On Thu, Mar 12, 2015 at 1:11 PM, Jacques Le Roux jacques.le.r...@les7arts.com wrote: Thanks Mark, It's quite clear Jacques Le 12/03/2015 11:59, Mark Thomas a écrit : On 12/03/2015 09:50, Jacques Le Roux wrote: Hi Infra Team and All, I have a question I wonder for some time and recently discussed in our OFBiz PMC ML. Committers come and go. When a PMC member resign, because s/he clearly wants to stop helping on the project and want to be completely disconnect from it, her/his committer account remains active. I wonder if this is not an useless security hole. Same for no longer active committers. The difference with an active committer is s/he will never know since s/he is possibly no longer monitoring things. A credential can be abused by an external person, that can be the beginning of much troubles we can not all imagine (hackers do)... With security holes you never know, until it bites you, so I really wonder why a committer account can not be terminated? A committer account on its own can do very little in the way of harm. It can (if you know which hoops to jump through) get shell access to people.a.o and it can send e-mail from an @apache.org e-mail address. people.a.o is locked down (and infra has additional monitoring in place) so the risk here is sufficiently small infra is happy with it. It terms of sending e-mail via an @apache.org e-mail address, if it is abusive (i.e. spammy) then we do rely on folks reporting it to us. The PMC is responsible for granting (and revoking) commit access. There is nothing (of a technical nature - you'll have to answer to the board and your community for the social aspects) stopping you removing inactive committers from the appropriate LDAP group(s). I'd add that the PMC is responsible for reviewing all the commits made to the PMC's repositories. You are expected to spot if a long inactive committer suddenly starts making changes or an account you don't recognise makes changes. Likewise, active committers are expected to spot changes in their name they did not make. More generally, if infra has a security concern we shut stuff down and/or lock accounts first and ask questions later. Any security concerns should be reported immediately to r...@apache.org Finally, infra periodically enforces password resets for all committers. This has the helpful side-effect of effectively locking unused committer accounts. Mark
[jira] [Created] (OFBIZ-6145) Purchase return shipment issuance greater than ATP error
Christian Carlow created OFBIZ-6145: --- Summary: Purchase return shipment issuance greater than ATP error Key: OFBIZ-6145 URL: https://issues.apache.org/jira/browse/OFBIZ-6145 Project: OFBiz Issue Type: Bug Components: product Affects Versions: Trunk Reporter: Christian Carlow This error occurred when issuing received purchase order inventory to a return shipment: Not issuing Order Item Ship Group Inventory Reservation to shipment 10096 because the quantity to issue 1 is greater than the quantity left to issue for order order item inventoryItem IssuanceServices.xml issueInventoryItemToShipment service checks that the inventoryItem ATP is greater than the return quantity submitted which fails when sales backorder qty of the product is greater than the purchase receipt qty. To reproduce: 1. Create a sales order for 100 of a product 2. Create a purchase order for 10 of the same product 3. Receive the purchase order inventory 4. Create a purchase order return then accept it 5. Click the Create Return Shipment button that appears once the return is accepted 6. Update the shipment to create and navigate to the shipment order items page 7. Issue qty of the inventory item received for purchase order to get the error -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (OFBIZ-6142) returnItems.ftl freemarker null error when returnPrice or returnQuantity is null
[ https://issues.apache.org/jira/browse/OFBIZ-6142?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christian Carlow updated OFBIZ-6142: Attachment: OFBIZ-6142.patch Updated patch again to prevent OrderView.groovy getReturnableItems error which prevents page from displaying when returnQuantity gets set to blank due to getReturnableQuantity in OrderReturnServices.java. returnItems.ftl freemarker null error when returnPrice or returnQuantity is null - Key: OFBIZ-6142 URL: https://issues.apache.org/jira/browse/OFBIZ-6142 Project: OFBiz Issue Type: Bug Components: order Affects Versions: Trunk Reporter: Christian Carlow Priority: Minor Attachments: OFBIZ-6142.patch This error message: FreeMarker template error: The following has evaluated to null or missing: == null [in template component://order/webapp/ordermgr/return/returnItems.ftl at line 155, column 48] -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (OFBIZ-6142) returnItems.ftl freemarker null error when returnPrice or returnQuantity is null
[ https://issues.apache.org/jira/browse/OFBIZ-6142?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christian Carlow updated OFBIZ-6142: Attachment: (was: OFBIZ-6142.patch) returnItems.ftl freemarker null error when returnPrice or returnQuantity is null - Key: OFBIZ-6142 URL: https://issues.apache.org/jira/browse/OFBIZ-6142 Project: OFBiz Issue Type: Bug Components: order Affects Versions: Trunk Reporter: Christian Carlow Priority: Minor This error message: FreeMarker template error: The following has evaluated to null or missing: == null [in template component://order/webapp/ordermgr/return/returnItems.ftl at line 155, column 48] -- This message was sent by Atlassian JIRA (v6.3.4#6332)
Re: Upcoming releases according to our tentative schedule
This is a good point, thanks Adrian. Did you mean DBCP? Jacopo On Mar 12, 2015, at 3:41 PM, Adrian Crum adrian.c...@sandglass-software.com wrote: Some of the Commons libraries have new releases that include bug fixes, so it would be nice to get those in. I am aware of Validator and DHCP. Adrian Crum Sandglass Software www.sandglass-software.com On 3/12/2015 2:31 PM, Jacopo Cappellato wrote: Hi all, according to our tentative schedule published here: http://ofbiz.apache.org/download.html there are two upcoming releases: * March - Apache OFBiz 13.07.02 * April - Apache OFBiz 12.04.06 (the last release in the 12.04 series) I think that the two branches are in good shape and I could start the preparation of 13.07.02 now. After that we will prepare the 12.04.06 ones to be published in April. What do you think? Jacopo
[jira] [Created] (OFBIZ-6146) LookupInventoryItem not functional
Christian Carlow created OFBIZ-6146: --- Summary: LookupInventoryItem not functional Key: OFBIZ-6146 URL: https://issues.apache.org/jira/browse/OFBIZ-6146 Project: OFBiz Issue Type: Bug Components: product Reporter: Christian Carlow LookupInventoryItem is not functional. The dropdown results are not implemented and the popup is implemented by LookupInventoryItems.ftl which lacks search options leading to empty results. This was encountered for OFBIZ-6145 for purchase return issuance which employs the lookup. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (OFBIZ-6146) LookupInventoryItem not functional
[ https://issues.apache.org/jira/browse/OFBIZ-6146?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christian Carlow updated OFBIZ-6146: Description: LookupInventoryItem is not functional. The dropdown results are not implemented and the popup is implemented by LookupInventoryItems.ftl which lacks search options leading to empty results. This was encountered for OFBIZ-6145 for purchase return issuance which employs the lookup. It should be implemented based on the existing lookups which use form widgets rather than FTL files. was: LookupInventoryItem is not functional. The dropdown results are not implemented and the popup is implemented by LookupInventoryItems.ftl which lacks search options leading to empty results. This was encountered for OFBIZ-6145 for purchase return issuance which employs the lookup. LookupInventoryItem not functional -- Key: OFBIZ-6146 URL: https://issues.apache.org/jira/browse/OFBIZ-6146 Project: OFBiz Issue Type: Bug Components: product Reporter: Christian Carlow LookupInventoryItem is not functional. The dropdown results are not implemented and the popup is implemented by LookupInventoryItems.ftl which lacks search options leading to empty results. This was encountered for OFBIZ-6145 for purchase return issuance which employs the lookup. It should be implemented based on the existing lookups which use form widgets rather than FTL files. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (OFBIZ-6146) LookupInventoryItem not functional
[ https://issues.apache.org/jira/browse/OFBIZ-6146?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14359076#comment-14359076 ] Christian Carlow commented on OFBIZ-6146: - LookupInventoryItems.ftl is no longer used and can probably be removed. LookupInventoryItems.groovy is also no longer used but did contain logic to look for the orderId which may still need to be integrated in the functionality. LookupInventoryItem not functional -- Key: OFBIZ-6146 URL: https://issues.apache.org/jira/browse/OFBIZ-6146 Project: OFBiz Issue Type: Bug Components: product Reporter: Christian Carlow Attachments: OFBIZ-6146.patch LookupInventoryItem is not functional. The dropdown results are not implemented and the popup is implemented by LookupInventoryItems.ftl which lacks search options leading to empty results. This was encountered for OFBIZ-6145 for purchase return issuance which employs the lookup. It should be implemented based on the existing lookups which use form widgets rather than FTL files. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (OFBIZ-6146) LookupInventoryItem not functional
[ https://issues.apache.org/jira/browse/OFBIZ-6146?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christian Carlow updated OFBIZ-6146: Attachment: OFBIZ-6146.patch This is a starting point for the InventoryItem lookup functionality. Additional fields may need to be added to be considered complete. LookupInventoryItem not functional -- Key: OFBIZ-6146 URL: https://issues.apache.org/jira/browse/OFBIZ-6146 Project: OFBiz Issue Type: Bug Components: product Reporter: Christian Carlow Attachments: OFBIZ-6146.patch LookupInventoryItem is not functional. The dropdown results are not implemented and the popup is implemented by LookupInventoryItems.ftl which lacks search options leading to empty results. This was encountered for OFBIZ-6145 for purchase return issuance which employs the lookup. It should be implemented based on the existing lookups which use form widgets rather than FTL files. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
Re: Welcome to Deepak Dixit as new committer!
Hi Deepak, many congratulations! Very nice pics!! Anahita 2015-03-12 15:23 GMT+01:00 Ashish Vijaywargiya ashish.vijaywarg...@hotwaxsystems.com: This is how Deepak looks like today with a very pleasant smile. :-) http://www.hotwaxsystems.com/Deepak-Dixit-1.jpg http://www.hotwaxsystems.com/Deepak-Dixit-2.jpg Many Congratulations Deepak!! -- Kind Regards Ashish Vijaywargiya HotWax Systems - est. 1997 On Thu, Mar 12, 2015 at 4:49 PM, Jacopo Cappellato jacopo.cappell...@hotwaxsystems.com wrote: The OFBiz PMC has invited Deepak Dixit to become a new committer and he has accepted the new role. Deepak, thank you for your continued commitment and valuable contributions. Welcome onboard! Jacopo
[jira] [Updated] (OFBIZ-6145) Purchase return shipment issuance greater than ATP error
[ https://issues.apache.org/jira/browse/OFBIZ-6145?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christian Carlow updated OFBIZ-6145: Attachment: OFBIZ-6145.patch This patch replaces the inventoryItem availableToPromiseTotal check with quantityOnHandTotal. Once the issuance succeeds the availableToPromiseTotal is correctly deducted but the corresponding inventoryItemShipGrpInvRes.quantityNotAvailable is not deducted so extra logic is probably needed for that. InventoryItem.accountingQuantityTotal is also not updated which might be needed also. Purchase return shipment issuance greater than ATP error Key: OFBIZ-6145 URL: https://issues.apache.org/jira/browse/OFBIZ-6145 Project: OFBiz Issue Type: Bug Components: product Affects Versions: Trunk Reporter: Christian Carlow Attachments: OFBIZ-6145.patch This error occurred when issuing received purchase order inventory to a return shipment: Not issuing Order Item Ship Group Inventory Reservation to shipment 10096 because the quantity to issue 1 is greater than the quantity left to issue for order order item inventoryItem IssuanceServices.xml issueInventoryItemToShipment service checks that the inventoryItem ATP is greater than the return quantity submitted which fails when sales backorder qty of the product is greater than the purchase receipt qty. To reproduce: 1. Create a sales order for 100 of a product 2. Create a purchase order for 10 of the same product 3. Receive the purchase order inventory 4. Create a purchase order return then accept it 5. Click the Create Return Shipment button that appears once the return is accepted 6. Update the shipment to create and navigate to the shipment order items page 7. Issue qty of the inventory item received for purchase order to get the error -- This message was sent by Atlassian JIRA (v6.3.4#6332)
Re: Upcoming releases according to our tentative schedule
lol - yes, thanks for the clarification. Adrian Crum Sandglass Software www.sandglass-software.com On 3/12/2015 3:03 PM, Jacopo Cappellato wrote: This is a good point, thanks Adrian. Did you mean DBCP? Jacopo On Mar 12, 2015, at 3:41 PM, Adrian Crum adrian.c...@sandglass-software.com wrote: Some of the Commons libraries have new releases that include bug fixes, so it would be nice to get those in. I am aware of Validator and DHCP. Adrian Crum Sandglass Software www.sandglass-software.com On 3/12/2015 2:31 PM, Jacopo Cappellato wrote: Hi all, according to our tentative schedule published here: http://ofbiz.apache.org/download.html there are two upcoming releases: * March - Apache OFBiz 13.07.02 * April - Apache OFBiz 12.04.06 (the last release in the 12.04 series) I think that the two branches are in good shape and I could start the preparation of 13.07.02 now. After that we will prepare the 12.04.06 ones to be published in April. What do you think? Jacopo
[jira] [Created] (OFBIZ-6147) setInvoiceStatus causes incorrect header information when an error occurs
Christian Carlow created OFBIZ-6147: --- Summary: setInvoiceStatus causes incorrect header information when an error occurs Key: OFBIZ-6147 URL: https://issues.apache.org/jira/browse/OFBIZ-6147 Project: OFBiz Issue Type: Bug Affects Versions: Trunk Reporter: Christian Carlow Priority: Minor When viewing an invoice at accounting/control/invoiceOverview, if a status change button is clicked and fails, the invoice header incorrectly displays the status as the one to which it failed to update and the description disappears. Its fairly minor but worth fixing eventually. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
Re: Why are committers accounts never terminated?
On 12/03/2015 09:50, Jacques Le Roux wrote: Hi Infra Team and All, I have a question I wonder for some time and recently discussed in our OFBiz PMC ML. Committers come and go. When a PMC member resign, because s/he clearly wants to stop helping on the project and want to be completely disconnect from it, her/his committer account remains active. I wonder if this is not an useless security hole. Same for no longer active committers. The difference with an active committer is s/he will never know since s/he is possibly no longer monitoring things. A credential can be abused by an external person, that can be the beginning of much troubles we can not all imagine (hackers do)... With security holes you never know, until it bites you, so I really wonder why a committer account can not be terminated? A committer account on its own can do very little in the way of harm. It can (if you know which hoops to jump through) get shell access to people.a.o and it can send e-mail from an @apache.org e-mail address. people.a.o is locked down (and infra has additional monitoring in place) so the risk here is sufficiently small infra is happy with it. It terms of sending e-mail via an @apache.org e-mail address, if it is abusive (i.e. spammy) then we do rely on folks reporting it to us. The PMC is responsible for granting (and revoking) commit access. There is nothing (of a technical nature - you'll have to answer to the board and your community for the social aspects) stopping you removing inactive committers from the appropriate LDAP group(s). I'd add that the PMC is responsible for reviewing all the commits made to the PMC's repositories. You are expected to spot if a long inactive committer suddenly starts making changes or an account you don't recognise makes changes. Likewise, active committers are expected to spot changes in their name they did not make. More generally, if infra has a security concern we shut stuff down and/or lock accounts first and ask questions later. Any security concerns should be reported immediately to r...@apache.org Finally, infra periodically enforces password resets for all committers. This has the helpful side-effect of effectively locking unused committer accounts. Mark
Re: jira spam
Le 24/02/2015 09:34, Jacques Le Roux a écrit : Thanks Hans, I have removed the comment. Please infra team could you remove the top3rdjaiho Jira user? Thanks! Jacques Le 24/02/2015 08:44, Hans Bakker a écrit : https://issues.apache.org/jira/browse/OFBIZ-5522?focusedCommentId=14334519page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14334519 S/he (or more surely it, a bot) did it again, 1 hour ago in the same OFBIZ-5522. I guess it's a bot, because it does not make sense for a human to make several same comments, even for a spammer And last time it was also on this issue. So could be based on websocket word? Nobody knows about a Jira spammer bot? In any case, please infra team could you remove the ns5219139 Jira user? I will then remove the comments, in case they help investigating before Thanks! Jacques
Re: Why are committers accounts never terminated?
Thanks Mark, It's quite clear Jacques Le 12/03/2015 11:59, Mark Thomas a écrit : On 12/03/2015 09:50, Jacques Le Roux wrote: Hi Infra Team and All, I have a question I wonder for some time and recently discussed in our OFBiz PMC ML. Committers come and go. When a PMC member resign, because s/he clearly wants to stop helping on the project and want to be completely disconnect from it, her/his committer account remains active. I wonder if this is not an useless security hole. Same for no longer active committers. The difference with an active committer is s/he will never know since s/he is possibly no longer monitoring things. A credential can be abused by an external person, that can be the beginning of much troubles we can not all imagine (hackers do)... With security holes you never know, until it bites you, so I really wonder why a committer account can not be terminated? A committer account on its own can do very little in the way of harm. It can (if you know which hoops to jump through) get shell access to people.a.o and it can send e-mail from an @apache.org e-mail address. people.a.o is locked down (and infra has additional monitoring in place) so the risk here is sufficiently small infra is happy with it. It terms of sending e-mail via an @apache.org e-mail address, if it is abusive (i.e. spammy) then we do rely on folks reporting it to us. The PMC is responsible for granting (and revoking) commit access. There is nothing (of a technical nature - you'll have to answer to the board and your community for the social aspects) stopping you removing inactive committers from the appropriate LDAP group(s). I'd add that the PMC is responsible for reviewing all the commits made to the PMC's repositories. You are expected to spot if a long inactive committer suddenly starts making changes or an account you don't recognise makes changes. Likewise, active committers are expected to spot changes in their name they did not make. More generally, if infra has a security concern we shut stuff down and/or lock accounts first and ask questions later. Any security concerns should be reported immediately to r...@apache.org Finally, infra periodically enforces password resets for all committers. This has the helpful side-effect of effectively locking unused committer accounts. Mark
Re: Why are committers accounts never terminated?
I would liked to add to Mark's answer that just because a volunteer steps away, they still have the merit and karma they earned. Life sometimes gets in the way but we want volunteers to be able to step back into things. I have also never heard of anyone misusing karma granted on return. So I would think it extraordinary to remove commit access. You never know when they might be back or another tlp takes their interest. They could lose there credentials which Mark has covered but otherwise I hope I have explained more of the ideology behind they why. Regards, KAM On March 12, 2015 6:59:57 AM EDT, Mark Thomas ma...@apache.org wrote: On 12/03/2015 09:50, Jacques Le Roux wrote: Hi Infra Team and All, I really wonder why a committer account can not be terminated?
Re: Welcome to Deepak Dixit as new committer!
Congrats Deepak, welcome on board :) Jacques Le 12/03/2015 12:19, Jacopo Cappellato a écrit : The OFBiz PMC has invited Deepak Dixit to become a new committer and he has accepted the new role. Deepak, thank you for your continued commitment and valuable contributions. Welcome onboard! Jacopo
[jira] [Commented] (OFBIZ-5522) Introduce websocket usage
[ https://issues.apache.org/jira/browse/OFBIZ-5522?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14358524#comment-14358524 ] Neeraj kumar commented on OFBIZ-5522: - These procedures seem straightforward but in real they are complex and topsy-turvy one. Packers and Movers Hyderabad @ http://www.expert5th.in/packers-and-movers-hyderabad/ Introduce websocket usage - Key: OFBIZ-5522 URL: https://issues.apache.org/jira/browse/OFBIZ-5522 Project: OFBiz Issue Type: Task Components: framework Affects Versions: Trunk Reporter: Jacques Le Roux Priority: Minor After a discussion with Ean, was suggested (draft here): You need a service that lets you subscribe a widget to an entity and then propagate change events to the widget as the entity is modified. A generic mechanism like that could eventually expand to be a general purpose data bound widgets system that mostly looks like the existing system but magically reflects updates. Could be used with/for * The entity cache and webforms to automatically update views when data changes. * Replaces the current system notes * Create a dashboard type pages (to be discussed futher) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
Re: Welcome to Deepak Dixit as new committer!
Congratulations Deepak On Thu, Mar 12, 2015 at 1:19 PM, Jacopo Cappellato jacopo.cappell...@hotwaxsystems.com wrote: The OFBiz PMC has invited Deepak Dixit to become a new committer and he has accepted the new role. Deepak, thank you for your continued commitment and valuable contributions. Welcome onboard! Jacopo
Re: Welcome to Deepak Dixit as new committer!
Congratulations, Deepak! Best regards, Pierre Smits *ORRTIZ.COM http://www.orrtiz.com* Services Solutions for Cloud- Based Manufacturing, Professional Services and Retail Trade http://www.orrtiz.com On Thu, Mar 12, 2015 at 12:25 PM, Gavin Mabie kwikst...@gmail.com wrote: Congratulations Deepak On Thu, Mar 12, 2015 at 1:19 PM, Jacopo Cappellato jacopo.cappell...@hotwaxsystems.com wrote: The OFBiz PMC has invited Deepak Dixit to become a new committer and he has accepted the new role. Deepak, thank you for your continued commitment and valuable contributions. Welcome onboard! Jacopo
Re: Welcome to Deepak Dixit as new committer!
Congratulations Deepak :) Thanks -- Divesh Dutta. On Thu, Mar 12, 2015 at 4:55 PM, Gavin Mabie kwikst...@gmail.com wrote: Congratulations Deepak On Thu, Mar 12, 2015 at 1:19 PM, Jacopo Cappellato jacopo.cappell...@hotwaxsystems.com wrote: The OFBiz PMC has invited Deepak Dixit to become a new committer and he has accepted the new role. Deepak, thank you for your continued commitment and valuable contributions. Welcome onboard! Jacopo
Re: Welcome to Deepak Dixit as new committer!
Many congratulations Deepak! -- Thanks Regards Nitesh Goyal HotWax Systems Pvt. Ltd. www.hotwaxsystems.com On Thu, Mar 12, 2015 at 4:55 PM, Gavin Mabie kwikst...@gmail.com wrote: Congratulations Deepak On Thu, Mar 12, 2015 at 1:19 PM, Jacopo Cappellato jacopo.cappell...@hotwaxsystems.com wrote: The OFBiz PMC has invited Deepak Dixit to become a new committer and he has accepted the new role. Deepak, thank you for your continued commitment and valuable contributions. Welcome onboard! Jacopo
Re: Welcome to Deepak Dixit as new committer!
Congratulations Deepak and welcome!! -- Thanks Regards, Mridul Pathak Senior Manager HotWax Systems http://www.hotwaxsystems.com On Mar 12, 2015, at 4:49 PM, Jacopo Cappellato jacopo.cappell...@hotwaxsystems.com wrote: The OFBiz PMC has invited Deepak Dixit to become a new committer and he has accepted the new role. Deepak, thank you for your continued commitment and valuable contributions. Welcome onboard! Jacopo
Re: Welcome to Deepak Dixit as new committer!
Congratulations Deepak !! On Thu, Mar 12, 2015 at 4:55 PM, Gavin Mabie kwikst...@gmail.com wrote: Congratulations Deepak On Thu, Mar 12, 2015 at 1:19 PM, Jacopo Cappellato jacopo.cappell...@hotwaxsystems.com wrote: The OFBiz PMC has invited Deepak Dixit to become a new committer and he has accepted the new role. Deepak, thank you for your continued commitment and valuable contributions. Welcome onboard! Jacopo
Re: Welcome to Deepak Dixit as new committer!
Many congratulations Deepak !!! :) Rishi Solanki Manager, Enterprise Software Development HotWax Systems Pvt. Ltd. Direct: +91-9893287847 http://www.hotwaxmedia.com On Thu, Mar 12, 2015 at 5:04 PM, Nitesh Goyal nitesh.go...@hotwaxsystems.com wrote: Many congratulations Deepak! -- Thanks Regards Nitesh Goyal HotWax Systems Pvt. Ltd. www.hotwaxsystems.com On Thu, Mar 12, 2015 at 4:55 PM, Gavin Mabie kwikst...@gmail.com wrote: Congratulations Deepak On Thu, Mar 12, 2015 at 1:19 PM, Jacopo Cappellato jacopo.cappell...@hotwaxsystems.com wrote: The OFBiz PMC has invited Deepak Dixit to become a new committer and he has accepted the new role. Deepak, thank you for your continued commitment and valuable contributions. Welcome onboard! Jacopo
Re: Welcome to Deepak Dixit as new committer!
Congratulations, we hope the new additions would contribute to a better, happier, more productive ofbiz community. Best of luck! On Thu, Mar 12, 2015 at 2:55 PM, Rishi Solanki rishisolan...@gmail.com wrote: Many congratulations Deepak !!! :) Rishi Solanki Manager, Enterprise Software Development HotWax Systems Pvt. Ltd. Direct: +91-9893287847 http://www.hotwaxmedia.com On Thu, Mar 12, 2015 at 5:04 PM, Nitesh Goyal nitesh.go...@hotwaxsystems.com wrote: Many congratulations Deepak! -- Thanks Regards Nitesh Goyal HotWax Systems Pvt. Ltd. www.hotwaxsystems.com On Thu, Mar 12, 2015 at 4:55 PM, Gavin Mabie kwikst...@gmail.com wrote: Congratulations Deepak On Thu, Mar 12, 2015 at 1:19 PM, Jacopo Cappellato jacopo.cappell...@hotwaxsystems.com wrote: The OFBiz PMC has invited Deepak Dixit to become a new committer and he has accepted the new role. Deepak, thank you for your continued commitment and valuable contributions. Welcome onboard! Jacopo
Re: Welcome to Deepak Dixit as new committer!
Deepak, Welcome aboard. Regards Anil Patel Thanks and Regards Anil Patel COO Hotwax Media Inc http://www.hotwaxmedia.com/ ApacheCon US 2014 Silver Sponsor http://na.apachecon.com/sponsor/our-sponsors On Thu, Mar 12, 2015 at 7:19 AM, Jacopo Cappellato jacopo.cappell...@hotwaxsystems.com wrote: The OFBiz PMC has invited Deepak Dixit to become a new committer and he has accepted the new role. Deepak, thank you for your continued commitment and valuable contributions. Welcome onboard! Jacopo
Re: Groovy at Apache
https://blogs.apache.org/foundation/entry/groovy_submitted_to_become_a On Mar 4, 2015, at 8:41 AM, Mridul Pathak mridul.pat...@hotwaxsystems.com wrote: That’s a great news. -- Thanks Regards, Mridul Pathak Senior Manager HotWax Systems http://www.hotwaxsystems.com On Mar 4, 2015, at 11:07 AM, Pranay Pandey pranay.pan...@hotwaxsystems.com wrote: Good one. On Mar 4, 2015 9:49 AM, Ashish Vijaywargiya ashish.vijaywarg...@hotwaxsystems.com wrote: Wow, Excellent news!! Thanks for sharing it Jacques. :-) Kind Regards Ashish Vijaywargiya HotWax Systems - est. 1997 On Tue, Mar 3, 2015 at 9:14 PM, jler...@apache.org jler...@apache.org wrote: Forwarded FYI Jacques Message transféré Sujet : Groovy at Apache Date : Tue, 3 Mar 2015 12:16:52 +0100 De :Cédric Champeau cedric.champ...@gmail.com Pour : elecha...@apache.org, bdelacre...@apache.org, Guillaume Laforge glafo...@gmail.com, Jochen Theodorou blackd...@gmx.org, Paul King pa...@asert.com.au Copie à : amania...@apache.org, r...@apache.org, ebo...@apache.org, jler...@apache.org Hi everyone! On behalf of the Groovy team, I am pleased to announce that we are going to submit a proposal to join the ASF. Thank you very much for the time you spent to answer our questions or concerns, and who knows maybe some of you will be willing to become mentors for the project? The decision will be made public soon, we wanted to let you know before the news goes out. Best regards, Cédric
[jira] [Updated] (OFBIZ-6143) Incorporate the readme for the projectmgr component
[ https://issues.apache.org/jira/browse/OFBIZ-6143?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pierre Smits updated OFBIZ-6143: Attachment: OFBIZ-6143-ProjectMgr-README.patch This patch is a first attempt to address the issue. Feedback is welcome. Incorporate the readme for the projectmgr component --- Key: OFBIZ-6143 URL: https://issues.apache.org/jira/browse/OFBIZ-6143 Project: OFBiz Issue Type: Improvement Components: specialpurpose/projectmgr Affects Versions: Trunk Reporter: Pierre Smits Assignee: Pierre Smits Attachments: OFBIZ-6143-ProjectMgr-README.patch -- This message was sent by Atlassian JIRA (v6.3.4#6332)
