Re: Ship Before Date and Ship After Date are not getting updated on the OrderItem table
System should always use the OrderItemShipGroup for checking the ship before and ship after dates. And if edit updated these dates then it should be okay, initially system may offer 3 days delivery and then update it due to any availability or technical reason. Also it would be good data at item level and then OISG level to see the difference on first promised date and then changed promised date. -- Rishi Solanki Sr Manager, Enterprise Software Development HotWax Systems Pvt. Ltd. Direct: +91-9893287847 http://www.hotwaxsystems.com www.hotwax.co On Wed, Aug 22, 2018 at 4:35 PM deepak nigam wrote: > Hello All, > > On updating Ship Before Date and Ship After Date from order overview > screen, changes are getting reflected in the OrderItemShipGroup entity but > in the OrderItem entity values remains same. Is this a valid behaviour or > should be considered as a bug? Please let me know the business use cases if > it is a valid behaviour. > > Thanks In Advance. > > Regards > -- > Deepak Nigam > HotWax Systems Pvt. Ltd. >
Re: [PROPOSITION] Demos: replace old by trunk framework only
Hi Taher, Julien I'm all for and looking forward for a generic solution. I still believe (like Julien) it's better to hide, than remove or ignore, those links in the meantime. They are there for already too long... Jacques Le 22/08/2018 à 18:52, Taher Alkhateeb a écrit : Hi Julien, Good ideas, and this is a good start to try and tackle the problem. Whatever we do, we must not keep "ghosts" or things that are waiting for specific outside plugins. The framework should _never_ know anything about the outside. This is a fundamental architectural concept in any layered software system. I'm ready to help if needed, and I think there are many ways to fix this problem. As you said one way is to extend webapps, another is perhaps to optionally include freemarker templates that match a certain pattern if they exist. In other words, you provide a generic plugin-like mechanism for enhancing the system, but the direction is _always_ from the outside to the inside, and not the other way around. And that is what I mean with a root-cause analysis and solutions. So I'm all for a generic solution, but not for hard-wiring any component or any link that is specific to a certain component. That is definitely a code smell and beats the entire purpose of splitting the repositories in the first place. On Wed, Aug 22, 2018 at 11:13 AM Julien NICOLAS wrote: Hi all, My opinion is to hide the link instead of delete it. I don't know if we have other link in this case but it could be important to keep it in source code. It could be convenient to have it for replacement by the good solution But in the same time, we need to think about inter-webapp connection. How a menu from webapp A could be extended by webapp B without putting code in webapp A. It could be interesting to have a new tool bar in product to manage ecommerce when ecommerce is installed. If we have this kind of feature, it could work as well for OOTB webapp like product and stock, party and order, etc. Julien. Le 21/08/2018 à 10:10, Jacques Le Roux a écrit : OK, that your and Michael's opinions. So you prefer NPEs in code than hiding them when necessary? What others think? Jacques Le 21/08/2018 à 09:45, Taher Alkhateeb a écrit : Again, hiding is not a solution and is correcting an error with another error. -1 On Tue, Aug 21, 2018, 10:37 AM Jacques Le Roux wrote: See my answer in the Jira, we can't tolerate NPEs, they are already there for too long Being smart is cool, being smart and clean is better ;) Jacques Le 21/08/2018 à 08:57, Michael Brohl a écrit : We should neither simply remove those links nor should we have anything hard coded. Let's look for a smarter solution. No need to hurry, better take some time to implement something sustainable. Regards, Michael Brohl ecomify GmbH www.ecomify.de Am 21.08.18 um 07:00 schrieb Jacques Le Roux: Of course, but I like to be able to get from the backend to the frontend when it's possible. I don't see any troubles keeping them once it's handled that way, but theoretical ones . Of course if the community prefers to remove them it's far easier and was what I wanted to do initially before having this idea of hiding links Jacques Le 21/08/2018 à 01:03, Taher Alkhateeb a écrit : Simple, don't put any logic that points outwards from the framework. That is sort of why we split repositories in the first place. On Mon, Aug 20, 2018, 8:00 PM Jacques Le Roux < jacques.le.r...@les7arts.com> wrote: Le 20/08/2018 à 16:53, Taher Alkhateeb a écrit : Makes sense. However, i note reading in the JIRA that "we can simply hide the button when the ecommerce component is not present". That sounds like logic that points outwards which is a bad design IMHO. I could not find a better way yet, I'm all ears for ideas. Anyway, I think it is a reasonable step to take. +1 I attached a patch for today at OFBIZ-9241 Jacques On Mon, Aug 20, 2018, 5:31 PM Jacques Le Roux < jacques.le.r...@les7arts.com> wrote: Hi, The proposition is in the title. With the changes I'm introducing with OFBIZ-9241 there will few differences in UI (and presence of js files) between the framework only and the framework+plugins I must add: * since the old is often no longer supported and a release of it is always available (today R13) for users. I think removing the old demo is maybe not a big deal. * I found several cases where people, new to OFBiz, considered OFBiz as what we call the framework, and were considering the plugins as optional. What do you think? Jacques
Re: Old demo restarted
Well, we can ask Infra for help, we can check available solutions, we can create a CRON script that checks things periodically, there are multiple ways to go about this. My personal preference is for a simple CRON script that takes care of this. On Wed, Aug 22, 2018 at 8:25 PM Jacques Le Roux wrote: > > So you prefer that I'm the only one to take care of the demos and act on > alerts? > > Jacques > > > Le 22/08/2018 à 18:53, Taher Alkhateeb a écrit : > > I prefer not to include any tools without proper analysis and > > discussion first. Less is more. > > On Wed, Aug 22, 2018 at 5:31 PM Jacques Le Roux > > wrote: > >> Hi, > >> > >> Should I consider no answers as a lazy consensus and should I send (rare) > >> alerts to this ML? > >> > >> Without any answers I'll consider it a lazy consensus in 2 days. > >> > >> Jacques > >> > >> > >> Le 17/08/2018 à 12:22, Jacques Le Roux a écrit : > >>> Le 13/08/2018 à 18:21, Jacques Le Roux a écrit : > Le 12/08/2018 à 11:26, Jacques Le Roux a écrit : > > Hi, > > > > This morning I noticed the old demo was down and restarted it after > > cleaning things. > > > > Previously (still some weeks ago) Daniel Gruno's (from Infra team) > > company was kindly providing us a mean to monitor our demos but it > > seems that > > this mean is no longer available > > > > I have asked about it and will let you know about it... > > > > Have a good weekend > > > > Jadques > > > Daniel confirmed it's terminated. I turned to UpTimeRobot which is free > and seems as well good :) > > Jacques > > > >>> This thread started on user ML but I don't want to bother everyone with > >>> technical details. > >>> > >>> I used my own @a.o email to create the monitoring. UpTimeRobot is > >>> certainly the best free monitoring tool, with some possibilities others > >>> don't give. > >>> > >>> But the free version has an inconvenient. You can only check every 5 mins > >>> and when the instances restart it takes more than 5 mins each. > >>> > >>> So everyday I get a down an up alerts for each. I have switched to > >>> montastic.com. > >>> > >>> I was wondering if we don't want to share that here. > >>> We could then have these alerts here and any committer, using the info in > >>> https://svn.apache.org/repos/asf/ofbiz/tools/demo-backup could handle > >>> issues. > >>> > >>> It seems better, isn'it? > >>> > >>> Jacques > >>> > >>> >
Re: Old demo restarted
So you prefer that I'm the only one to take care of the demos and act on alerts? Jacques Le 22/08/2018 à 18:53, Taher Alkhateeb a écrit : I prefer not to include any tools without proper analysis and discussion first. Less is more. On Wed, Aug 22, 2018 at 5:31 PM Jacques Le Roux wrote: Hi, Should I consider no answers as a lazy consensus and should I send (rare) alerts to this ML? Without any answers I'll consider it a lazy consensus in 2 days. Jacques Le 17/08/2018 à 12:22, Jacques Le Roux a écrit : Le 13/08/2018 à 18:21, Jacques Le Roux a écrit : Le 12/08/2018 à 11:26, Jacques Le Roux a écrit : Hi, This morning I noticed the old demo was down and restarted it after cleaning things. Previously (still some weeks ago) Daniel Gruno's (from Infra team) company was kindly providing us a mean to monitor our demos but it seems that this mean is no longer available I have asked about it and will let you know about it... Have a good weekend Jadques Daniel confirmed it's terminated. I turned to UpTimeRobot which is free and seems as well good :) Jacques This thread started on user ML but I don't want to bother everyone with technical details. I used my own @a.o email to create the monitoring. UpTimeRobot is certainly the best free monitoring tool, with some possibilities others don't give. But the free version has an inconvenient. You can only check every 5 mins and when the instances restart it takes more than 5 mins each. So everyday I get a down an up alerts for each. I have switched to montastic.com. I was wondering if we don't want to share that here. We could then have these alerts here and any committer, using the info in https://svn.apache.org/repos/asf/ofbiz/tools/demo-backup could handle issues. It seems better, isn'it? Jacques
Re: Old demo restarted
I prefer not to include any tools without proper analysis and discussion first. Less is more. On Wed, Aug 22, 2018 at 5:31 PM Jacques Le Roux wrote: > > Hi, > > Should I consider no answers as a lazy consensus and should I send (rare) > alerts to this ML? > > Without any answers I'll consider it a lazy consensus in 2 days. > > Jacques > > > Le 17/08/2018 à 12:22, Jacques Le Roux a écrit : > > Le 13/08/2018 à 18:21, Jacques Le Roux a écrit : > >> Le 12/08/2018 à 11:26, Jacques Le Roux a écrit : > >>> Hi, > >>> > >>> This morning I noticed the old demo was down and restarted it after > >>> cleaning things. > >>> > >>> Previously (still some weeks ago) Daniel Gruno's (from Infra team) > >>> company was kindly providing us a mean to monitor our demos but it seems > >>> that > >>> this mean is no longer available > >>> > >>> I have asked about it and will let you know about it... > >>> > >>> Have a good weekend > >>> > >>> Jadques > >>> > >> Daniel confirmed it's terminated. I turned to UpTimeRobot which is free > >> and seems as well good :) > >> > >> Jacques > >> > >> > > This thread started on user ML but I don't want to bother everyone with > > technical details. > > > > I used my own @a.o email to create the monitoring. UpTimeRobot is certainly > > the best free monitoring tool, with some possibilities others don't give. > > > > But the free version has an inconvenient. You can only check every 5 mins > > and when the instances restart it takes more than 5 mins each. > > > > So everyday I get a down an up alerts for each. I have switched to > > montastic.com. > > > > I was wondering if we don't want to share that here. > > We could then have these alerts here and any committer, using the info in > > https://svn.apache.org/repos/asf/ofbiz/tools/demo-backup could handle > > issues. > > > > It seems better, isn'it? > > > > Jacques > > > > >
Re: [PROPOSITION] Demos: replace old by trunk framework only
Hi Julien, Good ideas, and this is a good start to try and tackle the problem. Whatever we do, we must not keep "ghosts" or things that are waiting for specific outside plugins. The framework should _never_ know anything about the outside. This is a fundamental architectural concept in any layered software system. I'm ready to help if needed, and I think there are many ways to fix this problem. As you said one way is to extend webapps, another is perhaps to optionally include freemarker templates that match a certain pattern if they exist. In other words, you provide a generic plugin-like mechanism for enhancing the system, but the direction is _always_ from the outside to the inside, and not the other way around. And that is what I mean with a root-cause analysis and solutions. So I'm all for a generic solution, but not for hard-wiring any component or any link that is specific to a certain component. That is definitely a code smell and beats the entire purpose of splitting the repositories in the first place. On Wed, Aug 22, 2018 at 11:13 AM Julien NICOLAS wrote: > > Hi all, > > My opinion is to hide the link instead of delete it. I don't know if we > have other link in this case but it could be important to keep it in > source code. It could be convenient to have it for replacement by the > good solution > > But in the same time, we need to think about inter-webapp connection. > How a menu from webapp A could be extended by webapp B without putting > code in webapp A. > > It could be interesting to have a new tool bar in product to manage > ecommerce when ecommerce is installed. If we have this kind of feature, > it could work as well for OOTB webapp like product and stock, party and > order, etc. > > Julien. > > > Le 21/08/2018 à 10:10, Jacques Le Roux a écrit : > > OK, that your and Michael's opinions. So you prefer NPEs in code than > > hiding them when necessary? > > > > What others think? > > > > Jacques > > > > > > Le 21/08/2018 à 09:45, Taher Alkhateeb a écrit : > >> Again, hiding is not a solution and is correcting an error with another > >> error. > >> > >> -1 > >> > >> On Tue, Aug 21, 2018, 10:37 AM Jacques Le Roux > >> > >> wrote: > >> > >>> See my answer in the Jira, we can't tolerate NPEs, they are already > >>> there > >>> for too long > >>> > >>> Being smart is cool, being smart and clean is better ;) > >>> > >>> Jacques > >>> > >>> > >>> Le 21/08/2018 à 08:57, Michael Brohl a écrit : > We should neither simply remove those links nor should we have > anything > >>> hard coded. > Let's look for a smarter solution. No need to hurry, better take some > >>> time to implement something sustainable. > Regards, > > Michael Brohl > ecomify GmbH > www.ecomify.de > > > Am 21.08.18 um 07:00 schrieb Jacques Le Roux: > > Of course, but I like to be able to get from the backend to the > >>> frontend when it's possible. > > I don't see any troubles keeping them once it's handled that way, but > >>> theoretical ones . > > Of course if the community prefers to remove them it's far easier and > >>> was what I wanted to do initially before having this idea of hiding > >>> links > > Jacques > > > > > > Le 21/08/2018 à 01:03, Taher Alkhateeb a écrit : > >> Simple, don't put any logic that points outwards from the framework. > >>> That > >> is sort of why we split repositories in the first place. > >> > >> On Mon, Aug 20, 2018, 8:00 PM Jacques Le Roux < > >>> jacques.le.r...@les7arts.com> > >> wrote: > >> > >>> Le 20/08/2018 à 16:53, Taher Alkhateeb a écrit : > Makes sense. However, i note reading in the JIRA that "we can > simply > >>> hide > the button when the ecommerce component is not present". That > sounds > >>> like > logic that points outwards which is a bad design IMHO. > >>> I could not find a better way yet, I'm all ears for ideas. > >>> > Anyway, I think it is a reasonable step to take. +1 > >>> I attached a patch for today at OFBIZ-9241 > >>> > >>> Jacques > >>> > On Mon, Aug 20, 2018, 5:31 PM Jacques Le Roux < > >>> jacques.le.r...@les7arts.com> > wrote: > > > Hi, > > > > The proposition is in the title. > > > > With the changes I'm introducing with OFBIZ-9241 there will few > > differences in UI (and presence of js files) between the > > framework > >>> only > >>> and > > the > > framework+plugins > > > > I must add: > > > > * since the old is often no longer supported and a > > release of > >>> it is > > always available (today R13) for users. I think removing the old > >>> demo is > > maybe > >not a big deal. > > * I found several cases where people, new to OFBiz, > > considered > >>> OFBiz > >>>
Re: OFBIZ-10307: Navigate from a domain to another with automated signed in authentication
I reviewed the code and explanation in the beginning of this thread and I have the following comments: - First, in case of a result.containsKey(ModelService.ERROR_MESSAGE) you are still returning "success". Does not make sense at all. - Also the comments are unnecessary and do not make sense in the same code block - The repetition of the return "success" with a validation if separating them is a sign of a code smell. - The comment you wrote: "Check it's the right tenant in case username and password are the same in different tenants. Not sure this is really useful in the case of external server, does not hurt anyway" is self-defeating. Never put in code you won't use. We have enough mess in the code base. - Calling LoginWorker.doBasicLogin(userLogin, request) after the if/else block does not make sense. The else block guarantees falling into the exception. This whole code block needs refactoring - A testing method needs to be provided in detail. For example I'm not sure how the Javascript portions will execute and when. So some provision of a clear testing mechanism is necessary. - Finally, I'm not sure this feature is needed at all. Why not just assign an LDAP server to take care of OFBiz and non-OFBiz in a single sign-on environment. I see too much code being written for something that might not be of great value and there are other better solutions out there. Using JWT tokens might come with problems [1] that need to be justified before we adopt it. [1] https://en.wikipedia.org/wiki/JSON_Web_Token#Vulnerabilities_and_criticism On Wed, Aug 22, 2018 at 5:22 PM Jacques Le Roux wrote: > > Hi Jinghai, > > You can do if you want, but that's not possible in the context of the ASF. > > Also I'm for the ASL2 license as is, not to add a common clause. > > Of course if you pay me for that I would :D But I guess it's a joke, isn'it? > > Jacques > > > Le 22/08/2018 à 14:52, Shi Jinghai a écrit : > > Thank you Jacques! > > > > Perhaps we can build a cloud-ready (SAAS version) OFBiz and add such a > > common clause :) > > > > > > -邮件原件- > > 发件人: Jacques Le Roux [mailto:jacques.le.r...@les7arts.com] > > 发送时间: 2018年8月22日 12:11 > > 收件人: dev@ofbiz.apache.org > > 主题: Re: OFBIZ-10307: Navigate from a domain to another with automated > > signed in authentication > > > > Hi Jinghai, > > > > You maybe read it already, what did redislabs very recently might be > > affecting you > > > > https://redislabs.com/community/commons-clause/ > > > > Jacques > > > > > > Le 15/08/2018 à 14:37, Shi Jinghai a écrit : > >> Dear Jacques, > >> > >> On how to store the Tokens, as a token is a key, value is the UserLogin > >> entity and/or other info, a key-value db, Redis[1] is a good choice. Redis > >> is no.7 in db ranking in Aug 2018[2], becomes more and more popular. > >> Goldman Sachs invested Redis team in last year[3]. It's common view now in > >> China that Redis is better than any others including Gemfire of Pivotal, > >> the railway ticket system of China replaced its 3 Gemfire clusters with 3 > >> Redis clusters last year and then there are much less complains on how > >> difficulties to buy spring festival tickets. > >> > >> Mr. Dai Haipeng contributed a Redis component in Jira[4]. > >> > >> [1] https://redis.io/ > >> [2] https://db-engines.com/en/ranking > >> [3] > >> https://redislabs.com/press/redis-labs-secures-44-million-funding-led-goldman-sachs-private-capital-investing-strengthen-database-leadership/ > >> [4] https://issues.apache.org/jira/browse/OFBIZ-9829 > >> > >> BTW, I'll try to review the patches. > >> > >> Kind Regards, > >> > >> Shi Jinghai > >> > >> -邮件原件- > >> 发件人: Jacques Le Roux [mailto:jacques.le.r...@les7arts.com] > >> 发送时间: 2018年8月15日 15:09 > >> 收件人: dev@ofbiz.apache.org > >> 主题: OFBIZ-10307: Navigate from a domain to another with automated signed > >> in authentication > >> > >> Hi, > >> > >> Some time ago I created https://issues.apache.org/jira/browse/OFBIZ-10307. > >> > >> I asked for reviews but only Taher answered and he asked to know the goal > >> of this new feature. > >> > >> It was actually developed for a client who needed to get from one OFBiz > >> instance on a server (on a domain) to another OFBiz instance on another > >> server (on another domain) without having to sign up between the 2 while > >> keeping things secure. > >> > >> There could be many reasons why you want to split OFBiz application on > >> servers. In their case it was for performance issues. > >> > >> The technology used is as secure as possible. Like OAuth 2.0 it uses a > >> token but it does not need a middle authorization server (think to > >> two-factor > >> authentication) because it's only for OFBiz instances of the same version. > >> > >> To commit this work we need 1st to agree an commit the work done by Deepak > >> at OFBIZ-9833 "Token Based Authentication" that I use in my last patch. > >> > >> For me there is only one question outstanding: how to store the Token > >> secret. But
Re: Old demo restarted
Hi, Should I consider no answers as a lazy consensus and should I send (rare) alerts to this ML? Without any answers I'll consider it a lazy consensus in 2 days. Jacques Le 17/08/2018 à 12:22, Jacques Le Roux a écrit : Le 13/08/2018 à 18:21, Jacques Le Roux a écrit : Le 12/08/2018 à 11:26, Jacques Le Roux a écrit : Hi, This morning I noticed the old demo was down and restarted it after cleaning things. Previously (still some weeks ago) Daniel Gruno's (from Infra team) company was kindly providing us a mean to monitor our demos but it seems that this mean is no longer available I have asked about it and will let you know about it... Have a good weekend Jadques Daniel confirmed it's terminated. I turned to UpTimeRobot which is free and seems as well good :) Jacques This thread started on user ML but I don't want to bother everyone with technical details. I used my own @a.o email to create the monitoring. UpTimeRobot is certainly the best free monitoring tool, with some possibilities others don't give. But the free version has an inconvenient. You can only check every 5 mins and when the instances restart it takes more than 5 mins each. So everyday I get a down an up alerts for each. I have switched to montastic.com. I was wondering if we don't want to share that here. We could then have these alerts here and any committer, using the info in https://svn.apache.org/repos/asf/ofbiz/tools/demo-backup could handle issues. It seems better, isn'it? Jacques
Re: OFBIZ-10307: Navigate from a domain to another with automated signed in authentication
Hi Jinghai, You can do if you want, but that's not possible in the context of the ASF. Also I'm for the ASL2 license as is, not to add a common clause. Of course if you pay me for that I would :D But I guess it's a joke, isn'it? Jacques Le 22/08/2018 à 14:52, Shi Jinghai a écrit : Thank you Jacques! Perhaps we can build a cloud-ready (SAAS version) OFBiz and add such a common clause :) -邮件原件- 发件人: Jacques Le Roux [mailto:jacques.le.r...@les7arts.com] 发送时间: 2018年8月22日 12:11 收件人: dev@ofbiz.apache.org 主题: Re: OFBIZ-10307: Navigate from a domain to another with automated signed in authentication Hi Jinghai, You maybe read it already, what did redislabs very recently might be affecting you https://redislabs.com/community/commons-clause/ Jacques Le 15/08/2018 à 14:37, Shi Jinghai a écrit : Dear Jacques, On how to store the Tokens, as a token is a key, value is the UserLogin entity and/or other info, a key-value db, Redis[1] is a good choice. Redis is no.7 in db ranking in Aug 2018[2], becomes more and more popular. Goldman Sachs invested Redis team in last year[3]. It's common view now in China that Redis is better than any others including Gemfire of Pivotal, the railway ticket system of China replaced its 3 Gemfire clusters with 3 Redis clusters last year and then there are much less complains on how difficulties to buy spring festival tickets. Mr. Dai Haipeng contributed a Redis component in Jira[4]. [1] https://redis.io/ [2] https://db-engines.com/en/ranking [3] https://redislabs.com/press/redis-labs-secures-44-million-funding-led-goldman-sachs-private-capital-investing-strengthen-database-leadership/ [4] https://issues.apache.org/jira/browse/OFBIZ-9829 BTW, I'll try to review the patches. Kind Regards, Shi Jinghai -邮件原件- 发件人: Jacques Le Roux [mailto:jacques.le.r...@les7arts.com] 发送时间: 2018年8月15日 15:09 收件人: dev@ofbiz.apache.org 主题: OFBIZ-10307: Navigate from a domain to another with automated signed in authentication Hi, Some time ago I created https://issues.apache.org/jira/browse/OFBIZ-10307. I asked for reviews but only Taher answered and he asked to know the goal of this new feature. It was actually developed for a client who needed to get from one OFBiz instance on a server (on a domain) to another OFBiz instance on another server (on another domain) without having to sign up between the 2 while keeping things secure. There could be many reasons why you want to split OFBiz application on servers. In their case it was for performance issues. The technology used is as secure as possible. Like OAuth 2.0 it uses a token but it does not need a middle authorization server (think to two-factor authentication) because it's only for OFBiz instances of the same version. To commit this work we need 1st to agree an commit the work done by Deepak at OFBIZ-9833 "Token Based Authentication" that I use in my last patch. For me there is only one question outstanding: how to store the Token secret. But this should not prevent us to commit Deepak's work. It's now a long time (9 months) since I started this work. And my last patch is ready for a month. I crossed several issues which are now all resolved. So please review and answer to this thread. Without negative comments well argumented I'll commit both OFBIZ-9833 and OFBIZ-10307 in a week. You can always test and review later, we use RTC. Also a veto on a commit is always possible... Of course, as ever, a good consensus is preferred. Let me know if you need more information about the goal. For the technical details I think I already provided them the in OFBIZ-10307. Jacques
Re: [PROPOSITION] Demos: replace old by trunk framework only
Hi Michael, My proposition is to replace old by framework only, not to remove framework+plugins. Jacques Le 21/08/2018 à 08:54, Michael Brohl a écrit : Hi Jacques, for my comments on https://issues.apache.org/jira/projects/OFBIZ/issues/OFBIZ-9241 see Jira. For the proposal, I think we should provide the demo with the framwork + plugins. It shows the portential of the whole ecosystem and I see no reason why we should not make it available? Regards, Michael Brohl ecomify GmbH www.ecomify.de Am 20.08.18 um 16:31 schrieb Jacques Le Roux: Hi, The proposition is in the title. With the changes I'm introducing with OFBIZ-9241 there will few differences in UI (and presence of js files) between the framework only and the framework+plugins I must add: * since the old is often no longer supported and a release of it is always available (today R13) for users. I think removing the old demo is maybe not a big deal. * I found several cases where people, new to OFBiz, considered OFBiz as what we call the framework, and were considering the plugins as optional. What do you think? Jacques
Re: [PROPOSITION] Demos: replace old by trunk framework only
Hi Michael, OK, no problems Jacques Le 22/08/2018 à 15:51, Michael Brohl a écrit : Jacques, just 2 days are not much for discussion in an open source community. Please have in mind that people might not have the time to think about and answer to the discussion in such a short timeframe. Most of us are working full time. I see no need to hurry and propose to put down the vote and wait for at least a week to see if there are additional opinions. Thanks, Michael Am 22.08.18 um 14:02 schrieb Jacques Le Roux: Thanks Julien, At this stage, after 2 days, we already have diverse answers and it's hard to see a clear answer/consensus from that. So after this [PROPOSITION] I'll start 2 [VOTE]s, for: 1. Demos: replace old by trunk framework only? 2. Hide, remove or let as is UI links in framework (including applications) to plugins? BTW Julien, no need to put me in copy, I assiduously follow the OFBiz MLs ;) Jacques Le 22/08/2018 à 10:13, Julien NICOLAS a écrit : Hi all, My opinion is to hide the link instead of delete it. I don't know if we have other link in this case but it could be important to keep it in source code. It could be convenient to have it for replacement by the good solution But in the same time, we need to think about inter-webapp connection. How a menu from webapp A could be extended by webapp B without putting code in webapp A. It could be interesting to have a new tool bar in product to manage ecommerce when ecommerce is installed. If we have this kind of feature, it could work as well for OOTB webapp like product and stock, party and order, etc. Julien. Le 21/08/2018 à 10:10, Jacques Le Roux a écrit : OK, that your and Michael's opinions. So you prefer NPEs in code than hiding them when necessary? What others think? Jacques Le 21/08/2018 à 09:45, Taher Alkhateeb a écrit : Again, hiding is not a solution and is correcting an error with another error. -1 On Tue, Aug 21, 2018, 10:37 AM Jacques Le Roux wrote: See my answer in the Jira, we can't tolerate NPEs, they are already there for too long Being smart is cool, being smart and clean is better ;) Jacques Le 21/08/2018 à 08:57, Michael Brohl a écrit : We should neither simply remove those links nor should we have anything hard coded. Let's look for a smarter solution. No need to hurry, better take some time to implement something sustainable. Regards, Michael Brohl ecomify GmbH www.ecomify.de Am 21.08.18 um 07:00 schrieb Jacques Le Roux: Of course, but I like to be able to get from the backend to the frontend when it's possible. I don't see any troubles keeping them once it's handled that way, but theoretical ones . Of course if the community prefers to remove them it's far easier and was what I wanted to do initially before having this idea of hiding links Jacques Le 21/08/2018 à 01:03, Taher Alkhateeb a écrit : Simple, don't put any logic that points outwards from the framework. That is sort of why we split repositories in the first place. On Mon, Aug 20, 2018, 8:00 PM Jacques Le Roux < jacques.le.r...@les7arts.com> wrote: Le 20/08/2018 à 16:53, Taher Alkhateeb a écrit : Makes sense. However, i note reading in the JIRA that "we can simply hide the button when the ecommerce component is not present". That sounds like logic that points outwards which is a bad design IMHO. I could not find a better way yet, I'm all ears for ideas. Anyway, I think it is a reasonable step to take. +1 I attached a patch for today at OFBIZ-9241 Jacques On Mon, Aug 20, 2018, 5:31 PM Jacques Le Roux < jacques.le.r...@les7arts.com> wrote: Hi, The proposition is in the title. With the changes I'm introducing with OFBIZ-9241 there will few differences in UI (and presence of js files) between the framework only and the framework+plugins I must add: * since the old is often no longer supported and a release of it is always available (today R13) for users. I think removing the old demo is maybe not a big deal. * I found several cases where people, new to OFBiz, considered OFBiz as what we call the framework, and were considering the plugins as optional. What do you think? Jacques
Re: [PROPOSITION] Demos: replace old by trunk framework only
Jacques, just 2 days are not much for discussion in an open source community. Please have in mind that people might not have the time to think about and answer to the discussion in such a short timeframe. Most of us are working full time. I see no need to hurry and propose to put down the vote and wait for at least a week to see if there are additional opinions. Thanks, Michael Am 22.08.18 um 14:02 schrieb Jacques Le Roux: Thanks Julien, At this stage, after 2 days, we already have diverse answers and it's hard to see a clear answer/consensus from that. So after this [PROPOSITION] I'll start 2 [VOTE]s, for: 1. Demos: replace old by trunk framework only? 2. Hide, remove or let as is UI links in framework (including applications) to plugins? BTW Julien, no need to put me in copy, I assiduously follow the OFBiz MLs ;) Jacques Le 22/08/2018 à 10:13, Julien NICOLAS a écrit : Hi all, My opinion is to hide the link instead of delete it. I don't know if we have other link in this case but it could be important to keep it in source code. It could be convenient to have it for replacement by the good solution But in the same time, we need to think about inter-webapp connection. How a menu from webapp A could be extended by webapp B without putting code in webapp A. It could be interesting to have a new tool bar in product to manage ecommerce when ecommerce is installed. If we have this kind of feature, it could work as well for OOTB webapp like product and stock, party and order, etc. Julien. Le 21/08/2018 à 10:10, Jacques Le Roux a écrit : OK, that your and Michael's opinions. So you prefer NPEs in code than hiding them when necessary? What others think? Jacques Le 21/08/2018 à 09:45, Taher Alkhateeb a écrit : Again, hiding is not a solution and is correcting an error with another error. -1 On Tue, Aug 21, 2018, 10:37 AM Jacques Le Roux wrote: See my answer in the Jira, we can't tolerate NPEs, they are already there for too long Being smart is cool, being smart and clean is better ;) Jacques Le 21/08/2018 à 08:57, Michael Brohl a écrit : We should neither simply remove those links nor should we have anything hard coded. Let's look for a smarter solution. No need to hurry, better take some time to implement something sustainable. Regards, Michael Brohl ecomify GmbH www.ecomify.de Am 21.08.18 um 07:00 schrieb Jacques Le Roux: Of course, but I like to be able to get from the backend to the frontend when it's possible. I don't see any troubles keeping them once it's handled that way, but theoretical ones . Of course if the community prefers to remove them it's far easier and was what I wanted to do initially before having this idea of hiding links Jacques Le 21/08/2018 à 01:03, Taher Alkhateeb a écrit : Simple, don't put any logic that points outwards from the framework. That is sort of why we split repositories in the first place. On Mon, Aug 20, 2018, 8:00 PM Jacques Le Roux < jacques.le.r...@les7arts.com> wrote: Le 20/08/2018 à 16:53, Taher Alkhateeb a écrit : Makes sense. However, i note reading in the JIRA that "we can simply hide the button when the ecommerce component is not present". That sounds like logic that points outwards which is a bad design IMHO. I could not find a better way yet, I'm all ears for ideas. Anyway, I think it is a reasonable step to take. +1 I attached a patch for today at OFBIZ-9241 Jacques On Mon, Aug 20, 2018, 5:31 PM Jacques Le Roux < jacques.le.r...@les7arts.com> wrote: Hi, The proposition is in the title. With the changes I'm introducing with OFBIZ-9241 there will few differences in UI (and presence of js files) between the framework only and the framework+plugins I must add: * since the old is often no longer supported and a release of it is always available (today R13) for users. I think removing the old demo is maybe not a big deal. * I found several cases where people, new to OFBiz, considered OFBiz as what we call the framework, and were considering the plugins as optional. What do you think? Jacques smime.p7s Description: S/MIME Cryptographic Signature
Re: OFBIZ-10307: Navigate from a domain to another with automated signed in authentication
Thank you Jacques! Perhaps we can build a cloud-ready (SAAS version) OFBiz and add such a common clause :) -邮件原件- 发件人: Jacques Le Roux [mailto:jacques.le.r...@les7arts.com] 发送时间: 2018年8月22日 12:11 收件人: dev@ofbiz.apache.org 主题: Re: OFBIZ-10307: Navigate from a domain to another with automated signed in authentication Hi Jinghai, You maybe read it already, what did redislabs very recently might be affecting you https://redislabs.com/community/commons-clause/ Jacques Le 15/08/2018 à 14:37, Shi Jinghai a écrit : > Dear Jacques, > > On how to store the Tokens, as a token is a key, value is the UserLogin > entity and/or other info, a key-value db, Redis[1] is a good choice. Redis is > no.7 in db ranking in Aug 2018[2], becomes more and more popular. Goldman > Sachs invested Redis team in last year[3]. It's common view now in China that > Redis is better than any others including Gemfire of Pivotal, the railway > ticket system of China replaced its 3 Gemfire clusters with 3 Redis clusters > last year and then there are much less complains on how difficulties to buy > spring festival tickets. > > Mr. Dai Haipeng contributed a Redis component in Jira[4]. > > [1] https://redis.io/ > [2] https://db-engines.com/en/ranking > [3] > https://redislabs.com/press/redis-labs-secures-44-million-funding-led-goldman-sachs-private-capital-investing-strengthen-database-leadership/ > [4] https://issues.apache.org/jira/browse/OFBIZ-9829 > > BTW, I'll try to review the patches. > > Kind Regards, > > Shi Jinghai > > -邮件原件- > 发件人: Jacques Le Roux [mailto:jacques.le.r...@les7arts.com] > 发送时间: 2018年8月15日 15:09 > 收件人: dev@ofbiz.apache.org > 主题: OFBIZ-10307: Navigate from a domain to another with automated signed in > authentication > > Hi, > > Some time ago I created https://issues.apache.org/jira/browse/OFBIZ-10307. > > I asked for reviews but only Taher answered and he asked to know the goal of > this new feature. > > It was actually developed for a client who needed to get from one OFBiz > instance on a server (on a domain) to another OFBiz instance on another > server (on another domain) without having to sign up between the 2 while > keeping things secure. > > There could be many reasons why you want to split OFBiz application on > servers. In their case it was for performance issues. > > The technology used is as secure as possible. Like OAuth 2.0 it uses a token > but it does not need a middle authorization server (think to two-factor > authentication) because it's only for OFBiz instances of the same version. > > To commit this work we need 1st to agree an commit the work done by Deepak at > OFBIZ-9833 "Token Based Authentication" that I use in my last patch. > > For me there is only one question outstanding: how to store the Token secret. > But this should not prevent us to commit Deepak's work. > > It's now a long time (9 months) since I started this work. And my last patch > is ready for a month. > > I crossed several issues which are now all resolved. So please review and > answer to this thread. > > Without negative comments well argumented I'll commit both OFBIZ-9833 and > OFBIZ-10307 in a week. You can always test and review later, we use RTC. > > Also a veto on a commit is always possible... Of course, as ever, a good > consensus is preferred. > > Let me know if you need more information about the goal. For the technical > details I think I already provided them the in OFBIZ-10307. > > Jacques >
Re: OFBIZ-10307: Navigate from a domain to another with automated signed in authentication
Hi Michael, Release means from private to public, i.e. upload to github. -邮件原件- 发件人: Michael Brohl [mailto:michael.br...@ecomify.de] 发送时间: 2018年8月21日 15:24 收件人: dev@ofbiz.apache.org 主题: Re: OFBIZ-10307: Navigate from a domain to another with automated signed in authentication Hi Shi, what do you mean when you say you are going to release the plugin? Where will this take place? Regards, Michael Am 19.08.18 um 22:00 schrieb Shi Jinghai: > Thanks Jacques! > > If so, I'll release a CAS plugin to make OFBiz offer OAuth2 alliance next > week. I have cas 4.2.x version running in production environment, I'll > upgrade it to cas 5.2.x and then release it. > > > > -邮件原件- > 发件人: Jacques Le Roux [mailto:jacques.le.r...@les7arts.com] > 发送时间: 2018年8月19日 18:34 > 收件人: dev@ofbiz.apache.org > 主题: Re: OFBIZ-10307: Navigate from a domain to another with automated signed > in authentication > > Hi Jinghai, > > Actually I did not pick auth0 (not to be confused with > https://en.wikipedia.org/wiki/OAuth) nor https://oauth.net/2/ because those > need a central > Identify server (as is the SAML protocol). > > I simply send a JWT token: https://en.wikipedia.org/wiki/JSON_Web_Token and > https://jwt.io/ to > > Please refer to OFBIZ-10307 "Navigate from a domain to another with automated > signed in authentication" > > Thanks for your interest. > > Jacques > > > Le 17/08/2018 à 09:02, Shi Jinghai a écrit : >> Hi Jacques, >> >> OK, I think the redis topic is jumped to next step. >> >> I have read the patches carelly, as a fan of Apereo CAS[1], I wonder why >> choose auth0[2] rather than CAS. And is the implement OAuth2 alliance? >> >> [1] https://github.com/apereo/cas >> [2] https://auth0.com/ >> >> Kind Regards, >> >> Shi Jinghai >> >> >> -邮件原件- >> 发件人: Jacques Le Roux [mailto:jacques.le.r...@les7arts.com] >> 发送时间: 2018年8月16日 2:08 >> 收件人: dev@ofbiz.apache.org >> 主题: Re: OFBIZ-10307: Navigate from a domain to another with automated signed >> in authentication >> >> Hi Jinghai, >> >> The problem with the token master secret key is to guarantee its secrecy at >> max. >> >> We already discussed different solutions at https://s.apache.org/7yyR and >> https://s.apache.org/IBDM >> >> How is Redis more secure than Postgres for storing values? >> >> Thanks >> >> Jacques >> >> >> Le 15/08/2018 à 14:37, Shi Jinghai a écrit : >>> Dear Jacques, >>> >>> On how to store the Tokens, as a token is a key, value is the UserLogin >>> entity and/or other info, a key-value db, Redis[1] is a good choice. Redis >>> is no.7 in db ranking in Aug 2018[2], becomes more and more popular. >>> Goldman Sachs invested Redis team in last year[3]. It's common view now in >>> China that Redis is better than any others including Gemfire of Pivotal, >>> the railway ticket system of China replaced its 3 Gemfire clusters with 3 >>> Redis clusters last year and then there are much less complains on how >>> difficulties to buy spring festival tickets. >>> >>> Mr. Dai Haipeng contributed a Redis component in Jira[4]. >>> >>> [1] https://redis.io/ >>> [2] https://db-engines.com/en/ranking >>> [3] >>> https://redislabs.com/press/redis-labs-secures-44-million-funding-led-goldman-sachs-private-capital-investing-strengthen-database-leadership/ >>> [4] https://issues.apache.org/jira/browse/OFBIZ-9829 >>> >>> BTW, I'll try to review the patches. >>> >>> Kind Regards, >>> >>> Shi Jinghai >>> >>> -邮件原件- >>> 发件人: Jacques Le Roux [mailto:jacques.le.r...@les7arts.com] >>> 发送时间: 2018年8月15日 15:09 >>> 收件人: dev@ofbiz.apache.org >>> 主题: OFBIZ-10307: Navigate from a domain to another with automated signed in >>> authentication >>> >>> Hi, >>> >>> Some time ago I created https://issues.apache.org/jira/browse/OFBIZ-10307. >>> >>> I asked for reviews but only Taher answered and he asked to know the goal >>> of this new feature. >>> >>> It was actually developed for a client who needed to get from one OFBiz >>> instance on a server (on a domain) to another OFBiz instance on another >>> server (on another domain) without having to sign up between the 2 while >>> keeping things secure. >>> >>> There could be many reasons why you want to split OFBiz application on >>> servers. In their case it was for performance issues. >>> >>> The technology used is as secure as possible. Like OAuth 2.0 it uses a >>> token but it does not need a middle authorization server (think to >>> two-factor >>> authentication) because it's only for OFBiz instances of the same version. >>> >>> To commit this work we need 1st to agree an commit the work done by Deepak >>> at OFBIZ-9833 "Token Based Authentication" that I use in my last patch. >>> >>> For me there is only one question outstanding: how to store the Token >>> secret. But this should not prevent us to commit Deepak's work. >>> >>> It's now a long time (9 months) since I started this work. And my last >>> patch is ready for a month. >>> >>> I crossed several issues which are now all
Re: [PROPOSITION] Demos: replace old by trunk framework only
Thanks Julien, At this stage, after 2 days, we already have diverse answers and it's hard to see a clear answer/consensus from that. So after this [PROPOSITION] I'll start 2 [VOTE]s, for: 1. Demos: replace old by trunk framework only? 2. Hide, remove or let as is UI links in framework (including applications) to plugins? BTW Julien, no need to put me in copy, I assiduously follow the OFBiz MLs ;) Jacques Le 22/08/2018 à 10:13, Julien NICOLAS a écrit : Hi all, My opinion is to hide the link instead of delete it. I don't know if we have other link in this case but it could be important to keep it in source code. It could be convenient to have it for replacement by the good solution But in the same time, we need to think about inter-webapp connection. How a menu from webapp A could be extended by webapp B without putting code in webapp A. It could be interesting to have a new tool bar in product to manage ecommerce when ecommerce is installed. If we have this kind of feature, it could work as well for OOTB webapp like product and stock, party and order, etc. Julien. Le 21/08/2018 à 10:10, Jacques Le Roux a écrit : OK, that your and Michael's opinions. So you prefer NPEs in code than hiding them when necessary? What others think? Jacques Le 21/08/2018 à 09:45, Taher Alkhateeb a écrit : Again, hiding is not a solution and is correcting an error with another error. -1 On Tue, Aug 21, 2018, 10:37 AM Jacques Le Roux wrote: See my answer in the Jira, we can't tolerate NPEs, they are already there for too long Being smart is cool, being smart and clean is better ;) Jacques Le 21/08/2018 à 08:57, Michael Brohl a écrit : We should neither simply remove those links nor should we have anything hard coded. Let's look for a smarter solution. No need to hurry, better take some time to implement something sustainable. Regards, Michael Brohl ecomify GmbH www.ecomify.de Am 21.08.18 um 07:00 schrieb Jacques Le Roux: Of course, but I like to be able to get from the backend to the frontend when it's possible. I don't see any troubles keeping them once it's handled that way, but theoretical ones . Of course if the community prefers to remove them it's far easier and was what I wanted to do initially before having this idea of hiding links Jacques Le 21/08/2018 à 01:03, Taher Alkhateeb a écrit : Simple, don't put any logic that points outwards from the framework. That is sort of why we split repositories in the first place. On Mon, Aug 20, 2018, 8:00 PM Jacques Le Roux < jacques.le.r...@les7arts.com> wrote: Le 20/08/2018 à 16:53, Taher Alkhateeb a écrit : Makes sense. However, i note reading in the JIRA that "we can simply hide the button when the ecommerce component is not present". That sounds like logic that points outwards which is a bad design IMHO. I could not find a better way yet, I'm all ears for ideas. Anyway, I think it is a reasonable step to take. +1 I attached a patch for today at OFBIZ-9241 Jacques On Mon, Aug 20, 2018, 5:31 PM Jacques Le Roux < jacques.le.r...@les7arts.com> wrote: Hi, The proposition is in the title. With the changes I'm introducing with OFBIZ-9241 there will few differences in UI (and presence of js files) between the framework only and the framework+plugins I must add: * since the old is often no longer supported and a release of it is always available (today R13) for users. I think removing the old demo is maybe not a big deal. * I found several cases where people, new to OFBiz, considered OFBiz as what we call the framework, and were considering the plugins as optional. What do you think? Jacques
Ship Before Date and Ship After Date are not getting updated on the OrderItem table
Hello All, On updating Ship Before Date and Ship After Date from order overview screen, changes are getting reflected in the OrderItemShipGroup entity but in the OrderItem entity values remains same. Is this a valid behaviour or should be considered as a bug? Please let me know the business use cases if it is a valid behaviour. Thanks In Advance. Regards -- Deepak Nigam HotWax Systems Pvt. Ltd.
Re: [PROPOSITION] Demos: replace old by trunk framework only
Hi all, My opinion is to hide the link instead of delete it. I don't know if we have other link in this case but it could be important to keep it in source code. It could be convenient to have it for replacement by the good solution But in the same time, we need to think about inter-webapp connection. How a menu from webapp A could be extended by webapp B without putting code in webapp A. It could be interesting to have a new tool bar in product to manage ecommerce when ecommerce is installed. If we have this kind of feature, it could work as well for OOTB webapp like product and stock, party and order, etc. Julien. Le 21/08/2018 à 10:10, Jacques Le Roux a écrit : OK, that your and Michael's opinions. So you prefer NPEs in code than hiding them when necessary? What others think? Jacques Le 21/08/2018 à 09:45, Taher Alkhateeb a écrit : Again, hiding is not a solution and is correcting an error with another error. -1 On Tue, Aug 21, 2018, 10:37 AM Jacques Le Roux wrote: See my answer in the Jira, we can't tolerate NPEs, they are already there for too long Being smart is cool, being smart and clean is better ;) Jacques Le 21/08/2018 à 08:57, Michael Brohl a écrit : We should neither simply remove those links nor should we have anything hard coded. Let's look for a smarter solution. No need to hurry, better take some time to implement something sustainable. Regards, Michael Brohl ecomify GmbH www.ecomify.de Am 21.08.18 um 07:00 schrieb Jacques Le Roux: Of course, but I like to be able to get from the backend to the frontend when it's possible. I don't see any troubles keeping them once it's handled that way, but theoretical ones . Of course if the community prefers to remove them it's far easier and was what I wanted to do initially before having this idea of hiding links Jacques Le 21/08/2018 à 01:03, Taher Alkhateeb a écrit : Simple, don't put any logic that points outwards from the framework. That is sort of why we split repositories in the first place. On Mon, Aug 20, 2018, 8:00 PM Jacques Le Roux < jacques.le.r...@les7arts.com> wrote: Le 20/08/2018 à 16:53, Taher Alkhateeb a écrit : Makes sense. However, i note reading in the JIRA that "we can simply hide the button when the ecommerce component is not present". That sounds like logic that points outwards which is a bad design IMHO. I could not find a better way yet, I'm all ears for ideas. Anyway, I think it is a reasonable step to take. +1 I attached a patch for today at OFBIZ-9241 Jacques On Mon, Aug 20, 2018, 5:31 PM Jacques Le Roux < jacques.le.r...@les7arts.com> wrote: Hi, The proposition is in the title. With the changes I'm introducing with OFBIZ-9241 there will few differences in UI (and presence of js files) between the framework only and the framework+plugins I must add: * since the old is often no longer supported and a release of it is always available (today R13) for users. I think removing the old demo is maybe not a big deal. * I found several cases where people, new to OFBiz, considered OFBiz as what we call the framework, and were considering the plugins as optional. What do you think? Jacques
