Re: Move accounting ap and ar to plugin ?

[Deepak Dixit]

+1 for moving AP/AR to plugins.
We can open jira ticket for the same.

On Mon, Sep 3, 2018 at 7:02 PM, Nicolas Malin 
wrote:

> Yeah thanks all for your constructive return :)
>
> I saw two specific features: commission invoicing and batch payment. As
> Sharan spot it, all functional process are present on the accounting
> component, I have the feeling that we are all agree on this idea with a
> attention to doesn't lost important part possibly hidden on AP/AR.
>
> Taher, I have two reasons to don't just delete them:
> * The code current works and seem to be easy to maintain
> * Load in official plugins an example on business screen who simplify
> generic screen with potential problem that can be raise by the split :)
>
> I will try to split it.
> Thanks
>
> Nicolas
>
>
>
> On 03/09/2018 13:07, Taher Alkhateeb wrote:
>
>> Very interesting thoughts Sharan, Jacopo and everyone.
>>
>> Thinking about this some more, and given that -- as I understood it --
>> the AP and AR are really nothing more than specialized filtration
>> screens of the general purpose screens in the accounting webapp, then
>> why not delete them? Are people depending on these screens? Is it
>> worth writing and maintaining a plugin for it?
>> On Mon, Sep 3, 2018 at 12:27 PM Sharan Foga  wrote:
>>
>>>
>>>
>>> On 2018/09/03 08:11:26, Jacopo Cappellato >> ms.com> wrote:
>>>
 On Sat, Sep 1, 2018 at 2:09 PM Nicolas Malin 
 wrote:

 Hello,
>
> After analyze the webapp accounting AR and accounting AP, I didn't see
> any logic to keep them on the functional framework. The main webapp is
> accounting, AP/AR are a business orientation that we can load at demand
> through plugins.
>
> Your opinion ?
>
> As far as I remember, the AP/AR web applications were created as a
 specialized versions of the user interfaces for some business processes
 (account receivables and account payables related tasks) that were
 already
 available in the more general "accounting" web application. I like the
 idea
 to move them to plugins but, as mentioned by Taher, we should also
 verify
 if there are specific features that are available only in the AP/AR
 version
 and not in the "accounting" application: if we find some, then we should
 migrate the basic artifacts to the main "accounting" app and then move
 the
 specialized screens to plugins. I think such cases will be rare but one
 possible candidate is the "batch payment" functionality of the AR app.

>>> I thought the batch payment was one of the options for the Payment Group
>>> which is on the main accounting menu so any processing can be done from
>>> there too.
>>>
>>> Thanks
>>> Sharan
>>>
>>>
 PS: In the same idea we can move on separate plugin all thirdparty
> accounting element to slimdown the accounting component and must
> harness
> the plugin system :)
>
> +1

 Jacopo


 Nicolas
>
>
>
>

Re: [QUESTION] Should we not check fields consistency?

[Deepak Dixit]

It would be good if we add validation at UI level instead of doing changes
in core services.
Based on the context rules may be different in different cases.

On Tue, Sep 4, 2018 at 2:44 AM, Taher Alkhateeb 
wrote:

> Julien makes a good point. This is too specific and context sensitive to
> apply across the board.
>
> On Mon, Sep 3, 2018, 4:28 PM Julien NICOLAS 
> wrote:
>
> > Hello
> >
> > I've already implemented this kind of things and if you want to be
> > exhaustive, you have to do it at least in service AND in UI.
> >
> > However, it really depend on use cases that it depend on the customer
> > tastes. When it depend on customer tastes, I prefer to keep it open in
> > the framework / OOTB webapp than limit the OFBiz possibilities.
> >
> > The only reason that we can do it is for legal locking features...
> > but... it could depend on the country, so...
> >
> > My 2 cents,
> >
> > Julien.
> >
> >
> > Le 03/09/2018 à 14:55, Jacques Le Roux a écrit :
> > > By root I mean the point where things begin. And for entering data for
> > > end users it all start in UI. If you can stop things at this level,
> > > you don't have to worry for sequel. That's what I mean by "root in
> > > UI". Maybe "seed in UI" would have been a better image :)
> > >
> > > It would be more to prevent users's typo errors, fat fingers and such,
> > > without ambition to rule all cases, notably for later actions.
> > >
> > > Rest inline...
> > >
> > > Le 03/09/2018 à 14:19, Taher Alkhateeb a écrit :
> > >> I don't know what it means by the root in UI, but we are arriving at a
> > >> complex topic: Validation.
> > > Yep, I know. Let's try to keep it as simple as possible
> > >
> > >> Validation is something that can happen on many levels like:
> > >> - entity definition level
> > >> - entity-auto level
> > >> - service level
> > >> - UI level
> > >> - route level
> > >>
> > >> Each one of those has advantages and disadvantages. So I don't think
> > >> this is something we can make a rule for. What if a user wants to
> > >> enter a back-dated order?
> > > Good question. They are cases, as in my examples, where common sense
> > > applies and there are no doubts (eg shipping before creating comes to
> > > mind). A case like you suggest should not stop us to think about all
> > > the others.
> > >
> > >> What if a user wants to be able to search
> > >> for a date range in the past,
> > > That should not be a problem. It's all about keeping things
> > > consistent. For instance not reserving after shipping. I'm sure there
> > > are plenty other cases where common sense applies. I only speak about
> > > dates here, but I don't suggest to restrict only to date fields.
> > > There also case where it's not as simple and then we need to think
> > > about it. In this case do you think at something particularly? An URL
> > > would help.
> > >
> > >> what if the site owner wants validation
> > >> on the service level for security because users can break out of
> > >> browser validation and enter a back-dated dates?
> > > That's another topic I'd say. I'm not sure, but maybe we can enforce
> > > this rule, even on the client side.
> > > To begin with baby steps, we should try to deliver common sense rules
> > > OOTB and let users adapt them to their needs.
> > > Maybe we can even have a vision to help them. But my intention here is
> > > to keep things as simple as possible to begin.
> > >
> > >
> > >> I think this proposal needs more information and details. Otherwise
> > >> it's hard to determine what is the right decision as circumstances
> > >> vary widely
> > > It was not a proposal so far, only a [QUESTION] to see if we are
> > > interested in researching this. I know it's not that simple, thank you
> > > for your questions. Let's see if others believe we should make it a
> > > [PROPOSAL]
> > >
> > > Jacques
> > >
> > >> On Mon, Sep 3, 2018 at 2:45 PM Jacques Le Roux
> > >>  wrote:
> > >>> It's only about checking at the root in UI when entering data and
> > >>> not let things go as long as the value is not correct
> > >>>
> > >>> Jacques
> > >>>
> > >>>
> > >>> Le 03/09/2018 à 13:08, Taher Alkhateeb a écrit :
> >  Well, it depends on where the cross checks happen. Are you talking
> >  about UI? entity-auto? somewhere else?
> >  On Mon, Sep 3, 2018 at 11:52 AM deepak nigam
> >   wrote:
> > > +1.
> > >
> > > Thanks for the putting this forward. Please count me in for this
> > > effort.
> > >
> > >
> > > Thanks & Regards
> > > --
> > > Deepak Nigam
> > > HotWax Systems Pvt. Ltd.
> > >
> > >
> > > On Mon, Sep 3, 2018 at 2:06 PM Jacques Le Roux
> > > 
> > > wrote:
> > >
> > >> Hi,
> > >>
> > >> I have always found that not having dates cross-checks in OFBiz
> > >> is a minus.
> > >>
> > >> For instance while creating/editing an order we can enter
> > >>
> > >> * an anti-dated shipping date (eg 2018-08-1 entered today)
> > >> 

Re: Move accounting ap and ar to plugin ?

[Rishi Solanki]

+1 for moving AR/AP to plugins. And big +1 for Jacopo remarks.


--
Rishi Solanki
Sr Manager, Enterprise Software Development
HotWax Systems Pvt. Ltd.
Direct: +91-9893287847
http://www.hotwaxsystems.com
www.hotwax.co


On Mon, Sep 3, 2018 at 7:15 PM Taher Alkhateeb 
wrote:

> Sounds good to me then. +1
>
> On Mon, Sep 3, 2018, 4:32 PM Nicolas Malin 
> wrote:
>
> > Yeah thanks all for your constructive return :)
> >
> > I saw two specific features: commission invoicing and batch payment. As
> > Sharan spot it, all functional process are present on the accounting
> > component, I have the feeling that we are all agree on this idea with a
> > attention to doesn't lost important part possibly hidden on AP/AR.
> >
> > Taher, I have two reasons to don't just delete them:
> > * The code current works and seem to be easy to maintain
> > * Load in official plugins an example on business screen who simplify
> > generic screen with potential problem that can be raise by the split :)
> >
> > I will try to split it.
> > Thanks
> >
> > Nicolas
> >
> >
> > On 03/09/2018 13:07, Taher Alkhateeb wrote:
> > > Very interesting thoughts Sharan, Jacopo and everyone.
> > >
> > > Thinking about this some more, and given that -- as I understood it --
> > > the AP and AR are really nothing more than specialized filtration
> > > screens of the general purpose screens in the accounting webapp, then
> > > why not delete them? Are people depending on these screens? Is it
> > > worth writing and maintaining a plugin for it?
> > > On Mon, Sep 3, 2018 at 12:27 PM Sharan Foga  wrote:
> > >>
> > >>
> > >> On 2018/09/03 08:11:26, Jacopo Cappellato <
> > jacopo.cappell...@hotwaxsystems.com> wrote:
> > >>> On Sat, Sep 1, 2018 at 2:09 PM Nicolas Malin <
> nicolas.ma...@nereide.fr
> > >
> > >>> wrote:
> > >>>
> >  Hello,
> > 
> >  After analyze the webapp accounting AR and accounting AP, I didn't
> see
> >  any logic to keep them on the functional framework. The main webapp
> is
> >  accounting, AP/AR are a business orientation that we can load at
> > demand
> >  through plugins.
> > 
> >  Your opinion ?
> > 
> > >>> As far as I remember, the AP/AR web applications were created as a
> > >>> specialized versions of the user interfaces for some business
> processes
> > >>> (account receivables and account payables related tasks) that were
> > already
> > >>> available in the more general "accounting" web application. I like
> the
> > idea
> > >>> to move them to plugins but, as mentioned by Taher, we should also
> > verify
> > >>> if there are specific features that are available only in the AP/AR
> > version
> > >>> and not in the "accounting" application: if we find some, then we
> > should
> > >>> migrate the basic artifacts to the main "accounting" app and then
> move
> > the
> > >>> specialized screens to plugins. I think such cases will be rare but
> one
> > >>> possible candidate is the "batch payment" functionality of the AR
> app.
> > >> I thought the batch payment was one of the options for the Payment
> > Group which is on the main accounting menu so any processing can be done
> > from there too.
> > >>
> > >> Thanks
> > >> Sharan
> > >>
> > >>>
> >  PS: In the same idea we can move on separate plugin all thirdparty
> >  accounting element to slimdown the accounting component and must
> > harness
> >  the plugin system :)
> > 
> > >>> +1
> > >>>
> > >>> Jacopo
> > >>>
> > >>>
> >  Nicolas
> > 
> > 
> >
> >
>

Re: [QUESTION] Should we not check fields consistency?

[Taher Alkhateeb]

Julien makes a good point. This is too specific and context sensitive to
apply across the board.

On Mon, Sep 3, 2018, 4:28 PM Julien NICOLAS 
wrote:

> Hello
>
> I've already implemented this kind of things and if you want to be
> exhaustive, you have to do it at least in service AND in UI.
>
> However, it really depend on use cases that it depend on the customer
> tastes. When it depend on customer tastes, I prefer to keep it open in
> the framework / OOTB webapp than limit the OFBiz possibilities.
>
> The only reason that we can do it is for legal locking features...
> but... it could depend on the country, so...
>
> My 2 cents,
>
> Julien.
>
>
> Le 03/09/2018 à 14:55, Jacques Le Roux a écrit :
> > By root I mean the point where things begin. And for entering data for
> > end users it all start in UI. If you can stop things at this level,
> > you don't have to worry for sequel. That's what I mean by "root in
> > UI". Maybe "seed in UI" would have been a better image :)
> >
> > It would be more to prevent users's typo errors, fat fingers and such,
> > without ambition to rule all cases, notably for later actions.
> >
> > Rest inline...
> >
> > Le 03/09/2018 à 14:19, Taher Alkhateeb a écrit :
> >> I don't know what it means by the root in UI, but we are arriving at a
> >> complex topic: Validation.
> > Yep, I know. Let's try to keep it as simple as possible
> >
> >> Validation is something that can happen on many levels like:
> >> - entity definition level
> >> - entity-auto level
> >> - service level
> >> - UI level
> >> - route level
> >>
> >> Each one of those has advantages and disadvantages. So I don't think
> >> this is something we can make a rule for. What if a user wants to
> >> enter a back-dated order?
> > Good question. They are cases, as in my examples, where common sense
> > applies and there are no doubts (eg shipping before creating comes to
> > mind). A case like you suggest should not stop us to think about all
> > the others.
> >
> >> What if a user wants to be able to search
> >> for a date range in the past,
> > That should not be a problem. It's all about keeping things
> > consistent. For instance not reserving after shipping. I'm sure there
> > are plenty other cases where common sense applies. I only speak about
> > dates here, but I don't suggest to restrict only to date fields.
> > There also case where it's not as simple and then we need to think
> > about it. In this case do you think at something particularly? An URL
> > would help.
> >
> >> what if the site owner wants validation
> >> on the service level for security because users can break out of
> >> browser validation and enter a back-dated dates?
> > That's another topic I'd say. I'm not sure, but maybe we can enforce
> > this rule, even on the client side.
> > To begin with baby steps, we should try to deliver common sense rules
> > OOTB and let users adapt them to their needs.
> > Maybe we can even have a vision to help them. But my intention here is
> > to keep things as simple as possible to begin.
> >
> >
> >> I think this proposal needs more information and details. Otherwise
> >> it's hard to determine what is the right decision as circumstances
> >> vary widely
> > It was not a proposal so far, only a [QUESTION] to see if we are
> > interested in researching this. I know it's not that simple, thank you
> > for your questions. Let's see if others believe we should make it a
> > [PROPOSAL]
> >
> > Jacques
> >
> >> On Mon, Sep 3, 2018 at 2:45 PM Jacques Le Roux
> >>  wrote:
> >>> It's only about checking at the root in UI when entering data and
> >>> not let things go as long as the value is not correct
> >>>
> >>> Jacques
> >>>
> >>>
> >>> Le 03/09/2018 à 13:08, Taher Alkhateeb a écrit :
>  Well, it depends on where the cross checks happen. Are you talking
>  about UI? entity-auto? somewhere else?
>  On Mon, Sep 3, 2018 at 11:52 AM deepak nigam
>   wrote:
> > +1.
> >
> > Thanks for the putting this forward. Please count me in for this
> > effort.
> >
> >
> > Thanks & Regards
> > --
> > Deepak Nigam
> > HotWax Systems Pvt. Ltd.
> >
> >
> > On Mon, Sep 3, 2018 at 2:06 PM Jacques Le Roux
> > 
> > wrote:
> >
> >> Hi,
> >>
> >> I have always found that not having dates cross-checks in OFBiz
> >> is a minus.
> >>
> >> For instance while creating/editing an order we can enter
> >>
> >> * an anti-dated shipping date (eg 2018-08-1 entered today)
> >> * The recently added reserved date can be after the shipping
> >> date
> >> * etc. (not only dates but mostly)
> >>
> >> Should we not make an effort to check the consistency of fields
> >> values
> >> when they are entered?
> >>
> >> Because this is a simple question to see if we agree about making an
> >> effort on that, I don't get into more details yet
> >>
> >> Thanks for your opinions
> >>
> 

Re: Should we keep the multi-tenants feature in OFBiz?

[Rajesh Mallah]

Hi Jacques / List ,
Your Inline response did not reach me on my email id and I came to know
about your response from the
archives only.


> Q: Are you using your suggestions in production?
>
A: Yes external connection pooling was eventually adopted to run an
application that were accessed
 at web-scale. yes there were load balancing arrangements at various
parts of the architecture.
One of the significant architectural pattern that was employed in that
application is that it maintained
two kinds of global connection handles one for reading  (to the  cluster of
read-only DB slave instances)
and one for writing.  For reading no transaction was begun in the http
request - response cycle. In case of
writing only DB transaction was begun and attempt was made to make the
duration of transaction as
short as possible.

Actually in their case *the* instance would have been initially always *the*
> same.
> So deploying copies was not a problem.
>
>
Yes cloning and deploying is feasible at times .


> @Jacques Le Roux  there is also:
> https://issues.apache.org/jira/browse/OFBIZ-10284 for which i had worked
> on
>
> Thanks for *the* reminder, more on that later...
>

Actually I will have to redo it as my patch was based on last stable
release , i was asked to do it
for the latest tip.

regds
mallah.




On Mon, Sep 3, 2018 at 7:40 PM Jacques Le Roux 
wrote:

> Hi Jinghai,
>
> Inline...
>
>
> Le 03/09/2018 à 10:35, Shi Jinghai a écrit :
> > Hi Jacques,
> >
> > I assume we face the same requirement: how to become a value-added
> reseller of cloud services.
> Actually no, I only want to know if we want to keep the multi-tenants
> feature as is now, remove it or change to another model.
>
> > In China, the reseller margin could be 15-20% from Alibaba cloud or
> other cloud venders, so there's a new business model that we can offer some
> vertical OFBiz applications "free" and profitable.
> >
> > Kubernetes is the management tool to sell/distribute OFBiz applications.
> >
> > The OFBiz applications can be a multi-tenants model: multiple customers
> share one machine at a low price, this model is suitable for tiny/small
> customers.
> >
> > The OFBiz applications can also be a multi-instances model: each
> customer can scale up/down its-own application on-demand, this model is
> suitable for medium/large customers.
> >
> > Every customer can upgrade from multi-tenants to multi-instances, or
> downgrade from multi-instances to multi-tenants.
> >
> > Thank you for this topic. Please count me in if we have the same target.
> We have not the same target, mine is less ambitious.
>
> Your analysis is interesting. It also means that you not only want to keep
> the multi-tenants feature in OFBiz but also add the multi-instances model.
> That makes sense but I'm not sure if the project wants to go that far.
>
> Thanks for answering and sharing your ideas
>
> Cheers
>
> Jacques
> >
> > Kind Regards,
> >
> > Shi Jinghai
> >
> >
> >
> > -邮件原件-
> > 发件人: Jacques Le Roux [mailto:jacques.le.r...@les7arts.com]
> > 发送时间: 2018年9月2日 16:13
> > 收件人: dev@ofbiz.apache.org
> > 主题: Re: Should we keep the multi-tenants feature in OFBiz?
> >
> > Hi Jinghai,
> >
> > Inline...
> >
> >
> > Le 29/08/2018 à 14:49, Shi Jinghai a écrit :
> >> Hi Jacques,
> >>
> >> Honestly I was shocked by this email, I'm working on deploying OFBiz in
> Kubernetes, are you monitoring me?
> > Not at all :D
> >
> >> In 2010, Kubernetes was quite new and not good enough, now it's the
> standard on cloud deploy management, and we can support it.
> > I agree Kubernetes is a good tool. How do you envision to use it with
> OFBiz? I see it more as a production tool, not something we can embed like
> Tomcat.
> >
> >> Before doing that, we have to answer some common questions in cloud
> running lifecycle, such as how may instances/requests can share one CPU,
> how to deliver(create) an instance, how to isolate an instance, how to
> offline, how to remove, how to online again and etc.
> > You seem to be advanced in this, have you already , even partially,
> answered these questions? Are you working on a multi-tenant solution?
> >
> >> Personally I don't think we have to remove current multi-tenants
> implements, add a SAAS implement would be OK.
> > The problem with the current implementation is that it has changed the
> OFBiz code in some places, not always for the good.
> > It seems you not alone to want to keep it. Are you using it as is?
> > They are also people who would be glad to get rid of.
> > Let's see...
> >
> > Jacques
> >
> >> Kind Regards,
> >>
> >> Shi Jinghai
> >>
> >>
> >> -邮件原件-
> >> 发件人: Jacques Le Roux [mailto:jacques.le.r...@les7arts.com]
> >> 发送时间: 2018年8月29日 17:46
> >> 收件人: dev@ofbiz.apache.org
> >> 主题: Should we keep the multi-tenants feature in OFBiz?
> >>
> >> Hi,
> >>
> >> The multi-tenants feature in OFBiz only allows a dozens or maybe even
> few hundreds tenants, after it begin to be a lot of DBs!
> 

Re: [QUESTION] Should we not check fields consistency?

[Girish Vasmatkar]

I am all for having validations at the UI level, at least. Apart from Date,
there are other fields that need some basic validations. Showing
error/waring on tabbing out is one of the simplest forms for validation we
can put on certain fields.

+1 for this change.


On Mon, Sep 3, 2018 at 10:24 PM Jacques Le Roux <
jacques.le.r...@les7arts.com> wrote:

> Interesting idea, but please Richard subscribe to the dev ML, your email
> has been moderated
>
> Thanks
>
> Jacques
>
>
> Le 03/09/2018 à 15:59, Richard a écrit :
> > Some systems warn or block depending on the user's role.  A "bookkeeper"
> might not be able to enter incorrect data, while an administrator may just
> > receive a warning.
> >
> >
> > Jacques Le Roux wrote:
> >> One thing we could do is not block but warn the user, easy, simple
> >>
> >> Jacques
> >>
> >>
> >> Le 03/09/2018 à 15:28, Julien NICOLAS a écrit :
> >>> Hello
> >>>
> >>> I've already implemented this kind of things and if you want to be
> exhaustive, you have to do it at least in service AND in UI.
> >>>
> >>> However, it really depend on use cases that it depend on the customer
> tastes. When it depend on customer tastes, I prefer to keep it open in the
> >>> framework / OOTB webapp than limit the OFBiz possibilities.
> >>>
> >>> The only reason that we can do it is for legal locking features...
> but... it could depend on the country, so...
> >>>
> >>> My 2 cents,
> >>>
> >>> Julien.
> >>>
> >>>
> >>> Le 03/09/2018 à 14:55, Jacques Le Roux a écrit :
>  By root I mean the point where things begin. And for entering data
> for end users it all start in UI. If you can stop things at this level, you
>  don't have to worry for sequel. That's what I mean by "root in UI".
> Maybe "seed in UI" would have been a better image :)
> 
>  It would be more to prevent users's typo errors, fat fingers and
> such, without ambition to rule all cases, notably for later actions.
> 
>  Rest inline...
> 
>  Le 03/09/2018 à 14:19, Taher Alkhateeb a écrit :
> > I don't know what it means by the root in UI, but we are arriving at
> a
> > complex topic: Validation.
>  Yep, I know. Let's try to keep it as simple as possible
> 
> > Validation is something that can happen on many levels like:
> > - entity definition level
> > - entity-auto level
> > - service level
> > - UI level
> > - route level
> >
> > Each one of those has advantages and disadvantages. So I don't think
> > this is something we can make a rule for. What if a user wants to
> > enter a back-dated order?
>  Good question. They are cases, as in my examples, where common sense
> applies and there are no doubts (eg shipping before creating comes to
> mind).
>  A case like you suggest should not stop us to think about all the
> others.
> 
> > What if a user wants to be able to search
> > for a date range in the past,
>  That should not be a problem. It's all about keeping things
> consistent. For instance not reserving after shipping. I'm sure there are
> plenty
>  other cases where common sense applies. I only speak about dates
> here, but I don't suggest to restrict only to date fields.
>  There also case where it's not as simple and then we need to think
> about it. In this case do you think at something particularly? An URL would
> help.
> 
> > what if the site owner wants validation
> > on the service level for security because users can break out of
> > browser validation and enter a back-dated dates?
>  That's another topic I'd say. I'm not sure, but maybe we can enforce
> this rule, even on the client side.
>  To begin with baby steps, we should try to deliver common sense rules
> OOTB and let users adapt them to their needs.
>  Maybe we can even have a vision to help them. But my intention here
> is to keep things as simple as possible to begin.
> 
> 
> > I think this proposal needs more information and details. Otherwise
> > it's hard to determine what is the right decision as circumstances
> > vary widely
>  It was not a proposal so far, only a [QUESTION] to see if we are
> interested in researching this. I know it's not that simple, thank you for
> your
>  questions. Let's see if others believe we should make it a [PROPOSAL]
> 
>  Jacques
> 
> > On Mon, Sep 3, 2018 at 2:45 PM Jacques Le Roux
> >  wrote:
> >> It's only about checking at the root in UI when entering data and
> not let things go as long as the value is not correct
> >>
> >> Jacques
> >>
> >>
> >> Le 03/09/2018 à 13:08, Taher Alkhateeb a écrit :
> >>> Well, it depends on where the cross checks happen. Are you talking
> >>> about UI? entity-auto? somewhere else?
> >>> On Mon, Sep 3, 2018 at 11:52 AM deepak nigam <
> deepak.nigam1...@gmail.com> wrote:
>  +1.
> 
>  Thanks for the putting this forward. Please count me in for 

Re: [QUESTION] Should we not check fields consistency?

[Jacques Le Roux]

Interesting idea, but please Richard subscribe to the dev ML, your email has 
been moderated

Thanks

Jacques


Le 03/09/2018 à 15:59, Richard a écrit :
Some systems warn or block depending on the user's role.  A "bookkeeper" might not be able to enter incorrect data, while an administrator may just 
receive a warning.



Jacques Le Roux wrote:

One thing we could do is not block but warn the user, easy, simple

Jacques


Le 03/09/2018 à 15:28, Julien NICOLAS a écrit :

Hello

I've already implemented this kind of things and if you want to be exhaustive, 
you have to do it at least in service AND in UI.

However, it really depend on use cases that it depend on the customer tastes. When it depend on customer tastes, I prefer to keep it open in the 
framework / OOTB webapp than limit the OFBiz possibilities.


The only reason that we can do it is for legal locking features... but... it 
could depend on the country, so...

My 2 cents,

Julien.


Le 03/09/2018 à 14:55, Jacques Le Roux a écrit :
By root I mean the point where things begin. And for entering data for end users it all start in UI. If you can stop things at this level, you 
don't have to worry for sequel. That's what I mean by "root in UI". Maybe "seed in UI" would have been a better image :)


It would be more to prevent users's typo errors, fat fingers and such, without 
ambition to rule all cases, notably for later actions.

Rest inline...

Le 03/09/2018 à 14:19, Taher Alkhateeb a écrit :

I don't know what it means by the root in UI, but we are arriving at a
complex topic: Validation.

Yep, I know. Let's try to keep it as simple as possible


Validation is something that can happen on many levels like:
- entity definition level
- entity-auto level
- service level
- UI level
- route level

Each one of those has advantages and disadvantages. So I don't think
this is something we can make a rule for. What if a user wants to
enter a back-dated order?
Good question. They are cases, as in my examples, where common sense applies and there are no doubts (eg shipping before creating comes to mind). 
A case like you suggest should not stop us to think about all the others.



What if a user wants to be able to search
for a date range in the past,
That should not be a problem. It's all about keeping things consistent. For instance not reserving after shipping. I'm sure there are plenty 
other cases where common sense applies. I only speak about dates here, but I don't suggest to restrict only to date fields.

There also case where it's not as simple and then we need to think about it. In 
this case do you think at something particularly? An URL would help.


what if the site owner wants validation
on the service level for security because users can break out of
browser validation and enter a back-dated dates?

That's another topic I'd say. I'm not sure, but maybe we can enforce this rule, 
even on the client side.
To begin with baby steps, we should try to deliver common sense rules OOTB and 
let users adapt them to their needs.
Maybe we can even have a vision to help them. But my intention here is to keep 
things as simple as possible to begin.



I think this proposal needs more information and details. Otherwise
it's hard to determine what is the right decision as circumstances
vary widely
It was not a proposal so far, only a [QUESTION] to see if we are interested in researching this. I know it's not that simple, thank you for your 
questions. Let's see if others believe we should make it a [PROPOSAL]


Jacques


On Mon, Sep 3, 2018 at 2:45 PM Jacques Le Roux
 wrote:

It's only about checking at the root in UI when entering data and not let 
things go as long as the value is not correct

Jacques


Le 03/09/2018 à 13:08, Taher Alkhateeb a écrit :

Well, it depends on where the cross checks happen. Are you talking
about UI? entity-auto? somewhere else?
On Mon, Sep 3, 2018 at 11:52 AM deepak nigam  wrote:

+1.

Thanks for the putting this forward. Please count me in for this effort.


Thanks & Regards
--
Deepak Nigam
HotWax Systems Pvt. Ltd.


On Mon, Sep 3, 2018 at 2:06 PM Jacques Le Roux 
wrote:


Hi,

I have always found that not having dates cross-checks in OFBiz is a minus.

For instance while creating/editing an order we can enter

    * an anti-dated shipping date (eg 2018-08-1 entered today)
    * The recently added reserved date can be after the shipping date
    * etc. (not only dates but mostly)

Should we not make an effort to check the consistency of fields values
when they are entered?

Because this is a simple question to see if we agree about making an
effort on that, I don't get into more details yet

Thanks for your opinions

Jacques

Re: [QUESTION] Should we not check fields consistency?

[Richard]

Some systems warn or block depending on the user's role.  A "bookkeeper" 
might not be able to enter incorrect data, while an administrator may 
just receive a warning.



Jacques Le Roux wrote:

One thing we could do is not block but warn the user, easy, simple

Jacques


Le 03/09/2018 à 15:28, Julien NICOLAS a écrit :

Hello

I've already implemented this kind of things and if you want to be 
exhaustive, you have to do it at least in service AND in UI.


However, it really depend on use cases that it depend on the customer 
tastes. When it depend on customer tastes, I prefer to keep it open in 
the framework / OOTB webapp than limit the OFBiz possibilities.


The only reason that we can do it is for legal locking features... 
but... it could depend on the country, so...


My 2 cents,

Julien.


Le 03/09/2018 à 14:55, Jacques Le Roux a écrit :
By root I mean the point where things begin. And for entering data 
for end users it all start in UI. If you can stop things at this 
level, you don't have to worry for sequel. That's what I mean by 
"root in UI". Maybe "seed in UI" would have been a better image :)


It would be more to prevent users's typo errors, fat fingers and 
such, without ambition to rule all cases, notably for later actions.


Rest inline...

Le 03/09/2018 à 14:19, Taher Alkhateeb a écrit :

I don't know what it means by the root in UI, but we are arriving at a
complex topic: Validation.

Yep, I know. Let's try to keep it as simple as possible


Validation is something that can happen on many levels like:
- entity definition level
- entity-auto level
- service level
- UI level
- route level

Each one of those has advantages and disadvantages. So I don't think
this is something we can make a rule for. What if a user wants to
enter a back-dated order?
Good question. They are cases, as in my examples, where common sense 
applies and there are no doubts (eg shipping before creating comes to 
mind). A case like you suggest should not stop us to think about all 
the others.



What if a user wants to be able to search
for a date range in the past,
That should not be a problem. It's all about keeping things 
consistent. For instance not reserving after shipping. I'm sure there 
are plenty other cases where common sense applies. I only speak about 
dates here, but I don't suggest to restrict only to date fields.
There also case where it's not as simple and then we need to think 
about it. In this case do you think at something particularly? An URL 
would help.



what if the site owner wants validation
on the service level for security because users can break out of
browser validation and enter a back-dated dates?
That's another topic I'd say. I'm not sure, but maybe we can enforce 
this rule, even on the client side.
To begin with baby steps, we should try to deliver common sense rules 
OOTB and let users adapt them to their needs.
Maybe we can even have a vision to help them. But my intention here 
is to keep things as simple as possible to begin.




I think this proposal needs more information and details. Otherwise
it's hard to determine what is the right decision as circumstances
vary widely
It was not a proposal so far, only a [QUESTION] to see if we are 
interested in researching this. I know it's not that simple, thank 
you for your questions. Let's see if others believe we should make it 
a [PROPOSAL]


Jacques


On Mon, Sep 3, 2018 at 2:45 PM Jacques Le Roux
 wrote:
It's only about checking at the root in UI when entering data and 
not let things go as long as the value is not correct


Jacques


Le 03/09/2018 à 13:08, Taher Alkhateeb a écrit :

Well, it depends on where the cross checks happen. Are you talking
about UI? entity-auto? somewhere else?
On Mon, Sep 3, 2018 at 11:52 AM deepak nigam 
 wrote:

+1.

Thanks for the putting this forward. Please count me in for this 
effort.



Thanks & Regards
--
Deepak Nigam
HotWax Systems Pvt. Ltd.


On Mon, Sep 3, 2018 at 2:06 PM Jacques Le Roux 


wrote:


Hi,

I have always found that not having dates cross-checks in OFBiz 
is a minus.


For instance while creating/editing an order we can enter

    * an anti-dated shipping date (eg 2018-08-1 entered today)
    * The recently added reserved date can be after the shipping 
date

    * etc. (not only dates but mostly)

Should we not make an effort to check the consistency of fields 
values

when they are entered?

Because this is a simple question to see if we agree about 
making an

effort on that, I don't get into more details yet

Thanks for your opinions

Jacques

Re: OFBiz CRM for ASF Fundraising Team

[Jacques Le Roux]

Le 03/09/2018 à 17:07, Sharan Foga a écrit :

It's not obvious to new users what SFA is or means. In the past I  think there 
have been conversations about renaming it to CRM as people know  that 
abbreviation. Perhaps it's time to start that discussion again...

Thanks
Sharan

Hi Sharan

Indeed, it seems to me too that CRM is much more known than SFA

Nevertheless there is a difference between them: 
https://www.google.fr/search?q=sfa+vs+crm=UTF-8
Reading articles there (notably https://www.quora.com/What-are-the-key-differences-between-CRM-and-SFA) it seems to me that what we have in OFBiz is 
more SFA than CRM


Jacques

Re: OFBiz CRM for ASF Fundraising Team

[Sharan Foga]

Hi Pierre

Sorry for the late response on this!

Daniel says that he isn't in any rush to get a solution in place and so wants 
to take the time to make sure what they implement is going to be the right 
solution. I think he is also getting sent links to other CRM software that 
other people have used and have recommended. He needs to spend some time 
deciding and defining what is needed and how it will be used.

One important thing I wanted to mention  is that Daniel went to our OFBiz demo 
to take a look at our CRM module before we chatted . and couldn't find it! 
(In the end I had to show him where to look and tell him what it was called.)

It's not obvious to new users what SFA is or means. In the past I  think there 
have been conversations about renaming it to CRM as people know  that 
abbreviation. Perhaps it's time to start that discussion again...

Thanks
Sharan





On 2018/08/18 10:28:12, Pierre Smits  wrote: 
> Hi Sharan,
> 
> How did the call with Daniel go? Did you make any progress?
> 
> 
> Best regards,
> 
> Pierre Smits
> 
> Apache Trafodion , Vice President
> Apache Directory , PMC Member
> Apache Incubator , committer
> Apache OFBiz , contributor since 2008
> Apache Steve , committer
> 
> On Sun, Jul 29, 2018 at 8:11 PM, Pierre Smits 
> wrote:
> 
> > Hi Sharan,
> >
> > That is great news. Hopefully this time there will be something achievable
> > coming out of the talks. There have been many such requests/proposals in
> > the past.
> >
> > Best
> >
> > P
> >
> > On Sun, 29 Jul 2018 at 16:15 Sharan Foga  wrote:
> >
> >> Hi All
> >>
> >> I’ve received an enquiry from Daniel Ruggeri from the ASF Fundraising
> >> team asking about the possibility of using OFBiz CRM to manage their
> >> processes. I’m hoping to setup a call with him later this week to talk
> >> about their requirements.
> >>
> >> This could be great news for OFBiz so will let you know what happens and
> >> bring that information back to this list.
> >>
> >> Thanks
> >> Sharan
> >>
> > --
> > Sent from my phone
> >
> 

Re: Should we keep the multi-tenants feature in OFBiz?

[Jacques Le Roux]

Hi Jinghai,

Inline...


Le 03/09/2018 à 10:35, Shi Jinghai a écrit :

Hi Jacques,

I assume we face the same requirement: how to become a value-added reseller of 
cloud services.

Actually no, I only want to know if we want to keep the multi-tenants feature 
as is now, remove it or change to another model.


In China, the reseller margin could be 15-20% from Alibaba cloud or other cloud venders, 
so there's a new business model that we can offer some vertical OFBiz applications 
"free" and profitable.

Kubernetes is the management tool to sell/distribute OFBiz applications.

The OFBiz applications can be a multi-tenants model: multiple customers share 
one machine at a low price, this model is suitable for tiny/small customers.

The OFBiz applications can also be a multi-instances model: each customer can 
scale up/down its-own application on-demand, this model is suitable for 
medium/large customers.

Every customer can upgrade from multi-tenants to multi-instances, or downgrade 
from multi-instances to multi-tenants.

Thank you for this topic. Please count me in if we have the same target.

We have not the same target, mine is less ambitious.

Your analysis is interesting. It also means that you not only want to keep the multi-tenants feature in OFBiz but also add the multi-instances model. 
That makes sense but I'm not sure if the project wants to go that far.


Thanks for answering and sharing your ideas

Cheers

Jacques


Kind Regards,

Shi Jinghai



-邮件原件-
发件人: Jacques Le Roux [mailto:jacques.le.r...@les7arts.com]
发送时间: 2018年9月2日 16:13
收件人: dev@ofbiz.apache.org
主题: Re: Should we keep the multi-tenants feature in OFBiz?

Hi Jinghai,

Inline...


Le 29/08/2018 à 14:49, Shi Jinghai a écrit :

Hi Jacques,

Honestly I was shocked by this email, I'm working on deploying OFBiz in 
Kubernetes, are you monitoring me?

Not at all :D


In 2010, Kubernetes was quite new and not good enough, now it's the standard on 
cloud deploy management, and we can support it.

I agree Kubernetes is a good tool. How do you envision to use it with OFBiz? I 
see it more as a production tool, not something we can embed like Tomcat.


Before doing that, we have to answer some common questions in cloud running 
lifecycle, such as how may instances/requests can share one CPU, how to 
deliver(create) an instance, how to isolate an instance, how to offline, how to 
remove, how to online again and etc.

You seem to be advanced in this, have you already , even partially, answered 
these questions? Are you working on a multi-tenant solution?


Personally I don't think we have to remove current multi-tenants implements, 
add a SAAS implement would be OK.

The problem with the current implementation is that it has changed the OFBiz 
code in some places, not always for the good.
It seems you not alone to want to keep it. Are you using it as is?
They are also people who would be glad to get rid of.
Let's see...

Jacques


Kind Regards,

Shi Jinghai


-邮件原件-
发件人: Jacques Le Roux [mailto:jacques.le.r...@les7arts.com]
发送时间: 2018年8月29日 17:46
收件人: dev@ofbiz.apache.org
主题: Should we keep the multi-tenants feature in OFBiz?

Hi,

The multi-tenants feature in OFBiz only allows a dozens or maybe even few 
hundreds tenants, after it begin to be a lot of DBs!
I faced that with a startup which wanted to handle thousands, if not millions 
(actually they failed), of tenants, obviously OFBiz can't do that.

I don't break any secret to say that I was working with David (and Andrew) on a 
project in 2010 when David had to quickly answer to the client's
demand who wanted to have tenants. David brilliantly and quickly delivered, but 
it was only a start.

After many improvements, this feature still have some issues
       
https://nam03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fissues.apache.org%2Fjira%2Fbrowse%2FOFBIZ-6066data=02%7C01%7C%7C08ade5bcabda49a1f68308d610abf411%7C84df9e7fe9f640afb435%7C1%7C0%7C636714728052368674sdata=QCPlqtRHjd9a%2Fq3NIVujeqhR3o6sjjZ0sUEbFk4ojp8%3Dreserved=0
       
https://nam03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fissues.apache.org%2Fjira%2Fbrowse%2FOFBIZ-7900data=02%7C01%7C%7C08ade5bcabda49a1f68308d610abf411%7C84df9e7fe9f640afb435%7C1%7C0%7C636714728052368674sdata=fxUSwHPjg%2F8Nf2aDGCODhKauIVAbmK1wb%2B67%2FPZGrRU%3Dreserved=0
       
https://nam03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fissues.apache.org%2Fjira%2Fbrowse%2FOFBIZ-6164data=02%7C01%7C%7C08ade5bcabda49a1f68308d610abf411%7C84df9e7fe9f640afb435%7C1%7C0%7C636714728052368674sdata=MoH0jYAEo5IY0HA5xQOO2ZBKKMMU9RdloK1xlWNY6oY%3Dreserved=0
       
https://nam03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fissues.apache.org%2Fjira%2Fbrowse%2FOFBIZ-6065data=02%7C01%7C%7C08ade5bcabda49a1f68308d610abf411%7C84df9e7fe9f640afb435%7C1%7C0%7C636714728052368674sdata=4lZb89MwttM6VGxNdT9XSeP0sEL6UBlEMOdwf%2BsU9c8%3Dreserved=0

Also this is somehow related
       

Re: Move accounting ap and ar to plugin ?

[Taher Alkhateeb]

Sounds good to me then. +1

On Mon, Sep 3, 2018, 4:32 PM Nicolas Malin  wrote:

> Yeah thanks all for your constructive return :)
>
> I saw two specific features: commission invoicing and batch payment. As
> Sharan spot it, all functional process are present on the accounting
> component, I have the feeling that we are all agree on this idea with a
> attention to doesn't lost important part possibly hidden on AP/AR.
>
> Taher, I have two reasons to don't just delete them:
> * The code current works and seem to be easy to maintain
> * Load in official plugins an example on business screen who simplify
> generic screen with potential problem that can be raise by the split :)
>
> I will try to split it.
> Thanks
>
> Nicolas
>
>
> On 03/09/2018 13:07, Taher Alkhateeb wrote:
> > Very interesting thoughts Sharan, Jacopo and everyone.
> >
> > Thinking about this some more, and given that -- as I understood it --
> > the AP and AR are really nothing more than specialized filtration
> > screens of the general purpose screens in the accounting webapp, then
> > why not delete them? Are people depending on these screens? Is it
> > worth writing and maintaining a plugin for it?
> > On Mon, Sep 3, 2018 at 12:27 PM Sharan Foga  wrote:
> >>
> >>
> >> On 2018/09/03 08:11:26, Jacopo Cappellato <
> jacopo.cappell...@hotwaxsystems.com> wrote:
> >>> On Sat, Sep 1, 2018 at 2:09 PM Nicolas Malin  >
> >>> wrote:
> >>>
>  Hello,
> 
>  After analyze the webapp accounting AR and accounting AP, I didn't see
>  any logic to keep them on the functional framework. The main webapp is
>  accounting, AP/AR are a business orientation that we can load at
> demand
>  through plugins.
> 
>  Your opinion ?
> 
> >>> As far as I remember, the AP/AR web applications were created as a
> >>> specialized versions of the user interfaces for some business processes
> >>> (account receivables and account payables related tasks) that were
> already
> >>> available in the more general "accounting" web application. I like the
> idea
> >>> to move them to plugins but, as mentioned by Taher, we should also
> verify
> >>> if there are specific features that are available only in the AP/AR
> version
> >>> and not in the "accounting" application: if we find some, then we
> should
> >>> migrate the basic artifacts to the main "accounting" app and then move
> the
> >>> specialized screens to plugins. I think such cases will be rare but one
> >>> possible candidate is the "batch payment" functionality of the AR app.
> >> I thought the batch payment was one of the options for the Payment
> Group which is on the main accounting menu so any processing can be done
> from there too.
> >>
> >> Thanks
> >> Sharan
> >>
> >>>
>  PS: In the same idea we can move on separate plugin all thirdparty
>  accounting element to slimdown the accounting component and must
> harness
>  the plugin system :)
> 
> >>> +1
> >>>
> >>> Jacopo
> >>>
> >>>
>  Nicolas
> 
> 
>
>

Re: [QUESTION] Should we not check fields consistency?

[Jacques Le Roux]

One thing we could do is not block but warn the user, easy, simple

Jacques


Le 03/09/2018 à 15:28, Julien NICOLAS a écrit :

Hello

I've already implemented this kind of things and if you want to be exhaustive, 
you have to do it at least in service AND in UI.

However, it really depend on use cases that it depend on the customer tastes. When it depend on customer tastes, I prefer to keep it open in the 
framework / OOTB webapp than limit the OFBiz possibilities.


The only reason that we can do it is for legal locking features... but... it 
could depend on the country, so...

My 2 cents,

Julien.


Le 03/09/2018 à 14:55, Jacques Le Roux a écrit :
By root I mean the point where things begin. And for entering data for end users it all start in UI. If you can stop things at this level, you 
don't have to worry for sequel. That's what I mean by "root in UI". Maybe "seed in UI" would have been a better image :)


It would be more to prevent users's typo errors, fat fingers and such, without 
ambition to rule all cases, notably for later actions.

Rest inline...

Le 03/09/2018 à 14:19, Taher Alkhateeb a écrit :

I don't know what it means by the root in UI, but we are arriving at a
complex topic: Validation.

Yep, I know. Let's try to keep it as simple as possible


Validation is something that can happen on many levels like:
- entity definition level
- entity-auto level
- service level
- UI level
- route level

Each one of those has advantages and disadvantages. So I don't think
this is something we can make a rule for. What if a user wants to
enter a back-dated order?
Good question. They are cases, as in my examples, where common sense applies and there are no doubts (eg shipping before creating comes to mind). A 
case like you suggest should not stop us to think about all the others.



What if a user wants to be able to search
for a date range in the past,
That should not be a problem. It's all about keeping things consistent. For instance not reserving after shipping. I'm sure there are plenty other 
cases where common sense applies. I only speak about dates here, but I don't suggest to restrict only to date fields.

There also case where it's not as simple and then we need to think about it. In 
this case do you think at something particularly? An URL would help.


what if the site owner wants validation
on the service level for security because users can break out of
browser validation and enter a back-dated dates?

That's another topic I'd say. I'm not sure, but maybe we can enforce this rule, 
even on the client side.
To begin with baby steps, we should try to deliver common sense rules OOTB and 
let users adapt them to their needs.
Maybe we can even have a vision to help them. But my intention here is to keep 
things as simple as possible to begin.



I think this proposal needs more information and details. Otherwise
it's hard to determine what is the right decision as circumstances
vary widely
It was not a proposal so far, only a [QUESTION] to see if we are interested in researching this. I know it's not that simple, thank you for your 
questions. Let's see if others believe we should make it a [PROPOSAL]


Jacques


On Mon, Sep 3, 2018 at 2:45 PM Jacques Le Roux
 wrote:

It's only about checking at the root in UI when entering data and not let 
things go as long as the value is not correct

Jacques


Le 03/09/2018 à 13:08, Taher Alkhateeb a écrit :

Well, it depends on where the cross checks happen. Are you talking
about UI? entity-auto? somewhere else?
On Mon, Sep 3, 2018 at 11:52 AM deepak nigam  wrote:

+1.

Thanks for the putting this forward. Please count me in for this effort.


Thanks & Regards
--
Deepak Nigam
HotWax Systems Pvt. Ltd.


On Mon, Sep 3, 2018 at 2:06 PM Jacques Le Roux 
wrote:


Hi,

I have always found that not having dates cross-checks in OFBiz is a minus.

For instance while creating/editing an order we can enter

    * an anti-dated shipping date (eg 2018-08-1 entered today)
    * The recently added reserved date can be after the shipping date
    * etc. (not only dates but mostly)

Should we not make an effort to check the consistency of fields values
when they are entered?

Because this is a simple question to see if we agree about making an
effort on that, I don't get into more details yet

Thanks for your opinions

Jacques

Re: [QUESTION] Should we not check fields consistency?

[Sanjay Yadav]

+1 Jacques. I will say with consistency, field level validation is also
very important. It will restrict the user to enter incorrect data into the
system.

Best Regards,

*Sanjay Yadav* | Manager, Enterprise Quality Assurance
HotWax Commerce  by HotWax Systems

80, Scheme No. 78, Indore, M.P. 452010, India
Mobile Phone: 787 918 8830 | Linkedin: Sanjay-Yadav



On Mon, Sep 3, 2018 at 2:06 PM Jacques Le Roux 
wrote:

> Hi,
>
> I have always found that not having dates cross-checks in OFBiz is a minus.
>
> For instance while creating/editing an order we can enter
>
>   * an anti-dated shipping date (eg 2018-08-1 entered today)
>   * The recently added reserved date can be after the shipping date
>   * etc. (not only dates but mostly)
>
> Should we not make an effort to check the consistency of fields values
> when they are entered?
>
> Because this is a simple question to see if we agree about making an
> effort on that, I don't get into more details yet
>
> Thanks for your opinions
>
> Jacques
>
>

Re: Move accounting ap and ar to plugin ?

[Nicolas Malin]

Yeah thanks all for your constructive return :)

I saw two specific features: commission invoicing and batch payment. As 
Sharan spot it, all functional process are present on the accounting 
component, I have the feeling that we are all agree on this idea with a 
attention to doesn't lost important part possibly hidden on AP/AR.


Taher, I have two reasons to don't just delete them:
* The code current works and seem to be easy to maintain
* Load in official plugins an example on business screen who simplify 
generic screen with potential problem that can be raise by the split :)


I will try to split it.
Thanks

Nicolas


On 03/09/2018 13:07, Taher Alkhateeb wrote:

Very interesting thoughts Sharan, Jacopo and everyone.

Thinking about this some more, and given that -- as I understood it --
the AP and AR are really nothing more than specialized filtration
screens of the general purpose screens in the accounting webapp, then
why not delete them? Are people depending on these screens? Is it
worth writing and maintaining a plugin for it?
On Mon, Sep 3, 2018 at 12:27 PM Sharan Foga  wrote:



On 2018/09/03 08:11:26, Jacopo Cappellato  
wrote:

On Sat, Sep 1, 2018 at 2:09 PM Nicolas Malin 
wrote:


Hello,

After analyze the webapp accounting AR and accounting AP, I didn't see
any logic to keep them on the functional framework. The main webapp is
accounting, AP/AR are a business orientation that we can load at demand
through plugins.

Your opinion ?


As far as I remember, the AP/AR web applications were created as a
specialized versions of the user interfaces for some business processes
(account receivables and account payables related tasks) that were already
available in the more general "accounting" web application. I like the idea
to move them to plugins but, as mentioned by Taher, we should also verify
if there are specific features that are available only in the AP/AR version
and not in the "accounting" application: if we find some, then we should
migrate the basic artifacts to the main "accounting" app and then move the
specialized screens to plugins. I think such cases will be rare but one
possible candidate is the "batch payment" functionality of the AR app.

I thought the batch payment was one of the options for the Payment Group which 
is on the main accounting menu so any processing can be done from there too.

Thanks
Sharan




PS: In the same idea we can move on separate plugin all thirdparty
accounting element to slimdown the accounting component and must harness
the plugin system :)


+1

Jacopo



Nicolas

Re: Issue with opening a bookmarked page when the user is logged out

[Ritesh Kumar]

Hello team,

Thanks, everyone for your inputs.
I have attached the patch on the ticket  OFBIZ-10539
  to fix the issue.

Kindly have a look into this and let me know if there are any additional
inputs.



On Mon, Aug 27, 2018 at 11:20 AM Ritesh Kumar <
ritesh.ku...@hotwaxsystems.com> wrote:

> Thanks, Girish for clearly explaining my concern and everyone for your
> inputs.
>
> I have created the ticket ( OFBIZ-10539
> ). Soon, I will be
> providing the solution patch for review.
>
> On Sun, Aug 26, 2018 at 3:36 PM Michael Brohl 
> wrote:
>
>> OFBiz handles multiple request parameters with the same name well if you
>> use POST requests.
>>
>> For GET requests, there seem to be no standard for multiple parameters
>> with the same name, see [1]. I thinks it would be good to investigate
>> further and see if we can fix this.
>>
>> I don't see a problem with REST here, the data will most probably
>> transferred in some kind of JSON structure.
>>
>> [1]
>>
>> https://stackoverflow.com/questions/24059773/correct-way-to-pass-multiple-values-for-same-parameter-name-in-get-request#24728298
>>
>> Regards,
>>
>> Michael
>>
>>
>> Am 26.08.18 um 07:09 schrieb Taher Alkhateeb:
>> > Hmmm, based on Girish's feedback I think perhaps the next step should
>> be to
>> > open a JIRA and further investigate. Thinking about it some more, maybe
>> > this would have an impact on the REST API project we're working on.
>> >
>> > On Sun, Aug 26, 2018, 7:57 AM Girish Vasmatkar <
>> > girish.vasmat...@hotwaxsystems.com> wrote:
>> >
>> >> Hi Ritesh
>> >>
>> >> It does look like an issue to me.
>> >>
>> >> I believe (correct me if I am wrong) it is not so much about whether
>> GET is
>> >> appropriate here, it is more about that the framework is unable to
>> handle
>> >> multiple request parameters with same name, which is a common case
>> when we
>> >> talk about multiple check boxes on a form representing a single
>> entity. The
>> >> fact that GET is doing it's job correctly when the user is logged in
>> (means
>> >> when you change the method from POST to GET and the user is already
>> logged
>> >> in) and not so much when the user is logged out and the request is
>> made via
>> >> bookmark, shows that the code is not working properly.
>> >>
>> >> Then, there is also an issue with URL encoding and decoding that
>> becomes
>> >> apparent with executing your scenario. Whether it is correct to change
>> the
>> >> form method is arguable, but the code should be able to handle it. If a
>> >> form were to be designed with GET method and the only elements present
>> on
>> >> the form are two check boxes and a text field and if you were to select
>> >> both check boxes and have value with spaces in the text box, this
>> scenario
>> >> would still fail.
>> >>
>> >> I think the simplest approach would have been to just store query
>> string
>> >> (request.getQueryString()) in the session attribute instead of Map
>> (but I
>> >> think it was well pondered upon to use Map) and then just redirecting
>> to
>> >> the saved URL once the user loges in. I did it on my local workstation
>> and
>> >> it just worked perfectly. May be one reason why a map was used instead
>> of
>> >> storing query string was to handle unencoded requests coming from
>> browsers
>> >> such as IE. I may be wrong so please correct me if anyone has an idea
>> >> around this piece of code as to why Map was used instead of storing the
>> >> query string in session to be used later on.
>> >>
>> >> If you can do something to fix the existing code, that would be better
>> >> approach, IMO.
>> >>
>> >> May be it is not a major issue but certainly worthy of having a
>> dedicated
>> >> JIRA for. Everybody, please chime in and provide your thoughts.
>> >>
>> >> Thanks and Best regards,
>> >> Girish Vasmatkar
>> >> HotWax Systems
>> >>
>> >> On Sat, Aug 25, 2018 at 8:03 PM Taher Alkhateeb <
>> >> slidingfilame...@gmail.com>
>> >> wrote:
>> >>
>> >>> Okay, I understand this issue. I don't think it is possible to
>> >>> abstract away a complex search screen with http GET method for
>> >>> bookmarks. The performFind service is quite complex and it is
>> >>> difficult to replicate the requirements using GET. GET is not designed
>> >>> to handle multiple languages, spaces, and other peculiarities that are
>> >>> needed for such a screen to work.
>> >>>
>> >>> There are multiple solutions that I can see here. One of them is
>> >>> simply to create a new entity, let's call it SearchFilter, that saves
>> >>> search parameters, which can be applied later on. Either way, you need
>> >>> to customize, your problem is not OFBiz, your problem is http GET
>> >>> limitations.
>> >>> On Fri, Aug 24, 2018 at 12:35 PM Ritesh Kumar
>> >>>  wrote:
>>  Using the POST method does not append form data to the URL, i.e, the
>>  parameters will not be visible in the URL.
>>  For example, take a Find 

Re: [QUESTION] Should we not check fields consistency?

[Julien NICOLAS]

Hello

I've already implemented this kind of things and if you want to be 
exhaustive, you have to do it at least in service AND in UI.


However, it really depend on use cases that it depend on the customer 
tastes. When it depend on customer tastes, I prefer to keep it open in 
the framework / OOTB webapp than limit the OFBiz possibilities.


The only reason that we can do it is for legal locking features... 
but... it could depend on the country, so...


My 2 cents,

Julien.


Le 03/09/2018 à 14:55, Jacques Le Roux a écrit :
By root I mean the point where things begin. And for entering data for 
end users it all start in UI. If you can stop things at this level, 
you don't have to worry for sequel. That's what I mean by "root in 
UI". Maybe "seed in UI" would have been a better image :)


It would be more to prevent users's typo errors, fat fingers and such, 
without ambition to rule all cases, notably for later actions.


Rest inline...

Le 03/09/2018 à 14:19, Taher Alkhateeb a écrit :

I don't know what it means by the root in UI, but we are arriving at a
complex topic: Validation.

Yep, I know. Let's try to keep it as simple as possible


Validation is something that can happen on many levels like:
- entity definition level
- entity-auto level
- service level
- UI level
- route level

Each one of those has advantages and disadvantages. So I don't think
this is something we can make a rule for. What if a user wants to
enter a back-dated order?
Good question. They are cases, as in my examples, where common sense 
applies and there are no doubts (eg shipping before creating comes to 
mind). A case like you suggest should not stop us to think about all 
the others.



What if a user wants to be able to search
for a date range in the past,
That should not be a problem. It's all about keeping things 
consistent. For instance not reserving after shipping. I'm sure there 
are plenty other cases where common sense applies. I only speak about 
dates here, but I don't suggest to restrict only to date fields.
There also case where it's not as simple and then we need to think 
about it. In this case do you think at something particularly? An URL 
would help.



what if the site owner wants validation
on the service level for security because users can break out of
browser validation and enter a back-dated dates?
That's another topic I'd say. I'm not sure, but maybe we can enforce 
this rule, even on the client side.
To begin with baby steps, we should try to deliver common sense rules 
OOTB and let users adapt them to their needs.
Maybe we can even have a vision to help them. But my intention here is 
to keep things as simple as possible to begin.




I think this proposal needs more information and details. Otherwise
it's hard to determine what is the right decision as circumstances
vary widely
It was not a proposal so far, only a [QUESTION] to see if we are 
interested in researching this. I know it's not that simple, thank you 
for your questions. Let's see if others believe we should make it a 
[PROPOSAL]


Jacques


On Mon, Sep 3, 2018 at 2:45 PM Jacques Le Roux
 wrote:
It's only about checking at the root in UI when entering data and 
not let things go as long as the value is not correct


Jacques


Le 03/09/2018 à 13:08, Taher Alkhateeb a écrit :

Well, it depends on where the cross checks happen. Are you talking
about UI? entity-auto? somewhere else?
On Mon, Sep 3, 2018 at 11:52 AM deepak nigam 
 wrote:

+1.

Thanks for the putting this forward. Please count me in for this 
effort.



Thanks & Regards
--
Deepak Nigam
HotWax Systems Pvt. Ltd.


On Mon, Sep 3, 2018 at 2:06 PM Jacques Le Roux 


wrote:


Hi,

I have always found that not having dates cross-checks in OFBiz 
is a minus.


For instance while creating/editing an order we can enter

    * an anti-dated shipping date (eg 2018-08-1 entered today)
    * The recently added reserved date can be after the shipping 
date

    * etc. (not only dates but mostly)

Should we not make an effort to check the consistency of fields 
values

when they are entered?

Because this is a simple question to see if we agree about making an
effort on that, I don't get into more details yet

Thanks for your opinions

Jacques

Re: [QUESTION] Should we not check fields consistency?

[Jacques Le Roux]

By root I mean the point where things begin. And for entering data for end users it all start in UI. If you can stop things at this level, you don't 
have to worry for sequel. That's what I mean by "root in UI". Maybe "seed in UI" would have been a better image :)


It would be more to prevent users's typo errors, fat fingers and such, without 
ambition to rule all cases, notably for later actions.

Rest inline...

Le 03/09/2018 à 14:19, Taher Alkhateeb a écrit :

I don't know what it means by the root in UI, but we are arriving at a
complex topic: Validation.

Yep, I know. Let's try to keep it as simple as possible


Validation is something that can happen on many levels like:
- entity definition level
- entity-auto level
- service level
- UI level
- route level

Each one of those has advantages and disadvantages. So I don't think
this is something we can make a rule for. What if a user wants to
enter a back-dated order?
Good question. They are cases, as in my examples, where common sense applies and there are no doubts (eg shipping before creating comes to mind). A 
case like you suggest should not stop us to think about all the others.



What if a user wants to be able to search
for a date range in the past,
That should not be a problem. It's all about keeping things consistent. For instance not reserving after shipping. I'm sure there are plenty other 
cases where common sense applies. I only speak about dates here, but I don't suggest to restrict only to date fields.

There also case where it's not as simple and then we need to think about it. In 
this case do you think at something particularly? An URL would help.


what if the site owner wants validation
on the service level for security because users can break out of
browser validation and enter a back-dated dates?

That's another topic I'd say. I'm not sure, but maybe we can enforce this rule, 
even on the client side.
To begin with baby steps, we should try to deliver common sense rules OOTB and 
let users adapt them to their needs.
Maybe we can even have a vision to help them. But my intention here is to keep 
things as simple as possible to begin.



I think this proposal needs more information and details. Otherwise
it's hard to determine what is the right decision as circumstances
vary widely
It was not a proposal so far, only a [QUESTION] to see if we are interested in researching this. I know it's not that simple, thank you for your 
questions. Let's see if others believe we should make it a [PROPOSAL]


Jacques


On Mon, Sep 3, 2018 at 2:45 PM Jacques Le Roux
 wrote:

It's only about checking at the root in UI when entering data and not let 
things go as long as the value is not correct

Jacques


Le 03/09/2018 à 13:08, Taher Alkhateeb a écrit :

Well, it depends on where the cross checks happen. Are you talking
about UI? entity-auto? somewhere else?
On Mon, Sep 3, 2018 at 11:52 AM deepak nigam  wrote:

+1.

Thanks for the putting this forward. Please count me in for this effort.


Thanks & Regards
--
Deepak Nigam
HotWax Systems Pvt. Ltd.


On Mon, Sep 3, 2018 at 2:06 PM Jacques Le Roux 
wrote:


Hi,

I have always found that not having dates cross-checks in OFBiz is a minus.

For instance while creating/editing an order we can enter

* an anti-dated shipping date (eg 2018-08-1 entered today)
* The recently added reserved date can be after the shipping date
* etc. (not only dates but mostly)

Should we not make an effort to check the consistency of fields values
when they are entered?

Because this is a simple question to see if we agree about making an
effort on that, I don't get into more details yet

Thanks for your opinions

Jacques

Re: [QUESTION] Should we not check fields consistency?

[Taher Alkhateeb]

I don't know what it means by the root in UI, but we are arriving at a
complex topic: Validation.

Validation is something that can happen on many levels like:
- entity definition level
- entity-auto level
- service level
- UI level
- route level

Each one of those has advantages and disadvantages. So I don't think
this is something we can make a rule for. What if a user wants to
enter a back-dated order? What if a user wants to be able to search
for a date range in the past, what if the site owner wants validation
on the service level for security because users can break out of
browser validation and enter a back-dated dates?

I think this proposal needs more information and details. Otherwise
it's hard to determine what is the right decision as circumstances
vary widely
On Mon, Sep 3, 2018 at 2:45 PM Jacques Le Roux
 wrote:
>
> It's only about checking at the root in UI when entering data and not let 
> things go as long as the value is not correct
>
> Jacques
>
>
> Le 03/09/2018 à 13:08, Taher Alkhateeb a écrit :
> > Well, it depends on where the cross checks happen. Are you talking
> > about UI? entity-auto? somewhere else?
> > On Mon, Sep 3, 2018 at 11:52 AM deepak nigam  
> > wrote:
> >> +1.
> >>
> >> Thanks for the putting this forward. Please count me in for this effort.
> >>
> >>
> >> Thanks & Regards
> >> --
> >> Deepak Nigam
> >> HotWax Systems Pvt. Ltd.
> >>
> >>
> >> On Mon, Sep 3, 2018 at 2:06 PM Jacques Le Roux 
> >> 
> >> wrote:
> >>
> >>> Hi,
> >>>
> >>> I have always found that not having dates cross-checks in OFBiz is a 
> >>> minus.
> >>>
> >>> For instance while creating/editing an order we can enter
> >>>
> >>>* an anti-dated shipping date (eg 2018-08-1 entered today)
> >>>* The recently added reserved date can be after the shipping date
> >>>* etc. (not only dates but mostly)
> >>>
> >>> Should we not make an effort to check the consistency of fields values
> >>> when they are entered?
> >>>
> >>> Because this is a simple question to see if we agree about making an
> >>> effort on that, I don't get into more details yet
> >>>
> >>> Thanks for your opinions
> >>>
> >>> Jacques
> >>>
> >>>
>

Re: [QUESTION] Should we not check fields consistency?

[Jacques Le Roux]

It's only about checking at the root in UI when entering data and not let 
things go as long as the value is not correct

Jacques


Le 03/09/2018 à 13:08, Taher Alkhateeb a écrit :

Well, it depends on where the cross checks happen. Are you talking
about UI? entity-auto? somewhere else?
On Mon, Sep 3, 2018 at 11:52 AM deepak nigam  wrote:

+1.

Thanks for the putting this forward. Please count me in for this effort.


Thanks & Regards
--
Deepak Nigam
HotWax Systems Pvt. Ltd.


On Mon, Sep 3, 2018 at 2:06 PM Jacques Le Roux 
wrote:


Hi,

I have always found that not having dates cross-checks in OFBiz is a minus.

For instance while creating/editing an order we can enter

   * an anti-dated shipping date (eg 2018-08-1 entered today)
   * The recently added reserved date can be after the shipping date
   * etc. (not only dates but mostly)

Should we not make an effort to check the consistency of fields values
when they are entered?

Because this is a simple question to see if we agree about making an
effort on that, I don't get into more details yet

Thanks for your opinions

Jacques

Re: svn commit: r1839927 - in /ofbiz/site: about-ofbiz.html mailing-lists.html

[Swapnil Mane]

Thanks so much, Deepak for spotting and sharing the appropriate way to
update the code base of the OFBiz site repository :-)
I have updated the above changes in tpl.php at rev#1839934.

In this process, I also found changes done in existing code at rev#1833497
was also having similar things. Updated that as well at rev#1839936.

Thanks again!


- Best Regards,
Swapnil M Mane
HotWax Systems 

On Mon, Sep 3, 2018 at 3:53 PM Deepak Dixit  wrote:

> Hi Swapnil,
>
> Please update .php file and use php2html.sh to generate the html file.
> These changes will be overridden when we generate html using  php2html.sh
>
> You can find the php file at following location
>
> https://svn.apache.org/repos/asf/ofbiz/site/template/page/
>
> Thanks & Regards
> --
> Deepak Dixit
>
>
> On Mon, Sep 3, 2018 at 3:16 PM,  wrote:
>
> > Author: swapnilmmane
> > Date: Mon Sep  3 09:46:50 2018
> > New Revision: 1839927
> >
> > URL: http://svn.apache.org/viewvc?rev=1839927=rev
> > Log:
> > Removed the extra full stop from the sentence
> >
> > Modified:
> > ofbiz/site/about-ofbiz.html
> > ofbiz/site/mailing-lists.html
> >
> > Modified: ofbiz/site/about-ofbiz.html
> > URL: http://svn.apache.org/viewvc/ofbiz/site/about-ofbiz.html?
> > rev=1839927=1839926=1839927=diff
> > 
> > ==
> > --- ofbiz/site/about-ofbiz.html (original)
> > +++ ofbiz/site/about-ofbiz.html Mon Sep  3 09:46:50 2018
> > @@ -144,7 +144,7 @@
> >   Developer Mailing
> > List
> >  The developer list is strictly for topics related to
> > the design and development of the OFBiz Project itself.
> >  Please don't ask questions relevant to User Mailing List in this
> > Mailing List.
> > - If you are not sure to which list to post to then use the User
> > Mailing List..
> > + If you are not sure to which list to post to then use the User
> > Mailing List.
> >  Developer List 
> >
> >   Commit Mailing List
> >
> > Modified: ofbiz/site/mailing-lists.html
> > URL: http://svn.apache.org/viewvc/ofbiz/site/mailing-lists.html?
> > rev=1839927=1839926=1839927=diff
> > 
> > ==
> > --- ofbiz/site/mailing-lists.html (original)
> > +++ ofbiz/site/mailing-lists.html Mon Sep  3 09:46:50 2018
> > @@ -146,7 +146,7 @@
> > Developer Mailing
> > List
> > The developer list is strictly for topics related
> > to the design and development of the OFBiz Project itself.
> >Please don't ask questions
> > relevant to User Mailing List in this Mailing List.
> > -   If you are not sure to which list to post to then use the User
> > Mailing List..
> > +   If you are not sure to which list to post to then use the User
> > Mailing List.
> >Developer List
> >  
> >  
> >
> >
> >
>

Re: [QUESTION] Should we not check fields consistency?

[Taher Alkhateeb]

Well, it depends on where the cross checks happen. Are you talking
about UI? entity-auto? somewhere else?
On Mon, Sep 3, 2018 at 11:52 AM deepak nigam  wrote:
>
> +1.
>
> Thanks for the putting this forward. Please count me in for this effort.
>
>
> Thanks & Regards
> --
> Deepak Nigam
> HotWax Systems Pvt. Ltd.
>
>
> On Mon, Sep 3, 2018 at 2:06 PM Jacques Le Roux 
> wrote:
>
> > Hi,
> >
> > I have always found that not having dates cross-checks in OFBiz is a minus.
> >
> > For instance while creating/editing an order we can enter
> >
> >   * an anti-dated shipping date (eg 2018-08-1 entered today)
> >   * The recently added reserved date can be after the shipping date
> >   * etc. (not only dates but mostly)
> >
> > Should we not make an effort to check the consistency of fields values
> > when they are entered?
> >
> > Because this is a simple question to see if we agree about making an
> > effort on that, I don't get into more details yet
> >
> > Thanks for your opinions
> >
> > Jacques
> >
> >

Re: Move accounting ap and ar to plugin ?

[Taher Alkhateeb]

Very interesting thoughts Sharan, Jacopo and everyone.

Thinking about this some more, and given that -- as I understood it --
the AP and AR are really nothing more than specialized filtration
screens of the general purpose screens in the accounting webapp, then
why not delete them? Are people depending on these screens? Is it
worth writing and maintaining a plugin for it?
On Mon, Sep 3, 2018 at 12:27 PM Sharan Foga  wrote:
>
>
>
> On 2018/09/03 08:11:26, Jacopo Cappellato 
>  wrote:
> > On Sat, Sep 1, 2018 at 2:09 PM Nicolas Malin 
> > wrote:
> >
> > > Hello,
> > >
> > > After analyze the webapp accounting AR and accounting AP, I didn't see
> > > any logic to keep them on the functional framework. The main webapp is
> > > accounting, AP/AR are a business orientation that we can load at demand
> > > through plugins.
> > >
> > > Your opinion ?
> > >
> >
> > As far as I remember, the AP/AR web applications were created as a
> > specialized versions of the user interfaces for some business processes
> > (account receivables and account payables related tasks) that were already
> > available in the more general "accounting" web application. I like the idea
> > to move them to plugins but, as mentioned by Taher, we should also verify
> > if there are specific features that are available only in the AP/AR version
> > and not in the "accounting" application: if we find some, then we should
> > migrate the basic artifacts to the main "accounting" app and then move the
> > specialized screens to plugins. I think such cases will be rare but one
> > possible candidate is the "batch payment" functionality of the AR app.
>
> I thought the batch payment was one of the options for the Payment Group 
> which is on the main accounting menu so any processing can be done from there 
> too.
>
> Thanks
> Sharan
>
> >
> >
> > >
> > > PS: In the same idea we can move on separate plugin all thirdparty
> > > accounting element to slimdown the accounting component and must harness
> > > the plugin system :)
> > >
> >
> > +1
> >
> > Jacopo
> >
> >
> > >
> > > Nicolas
> > >
> > >
> >

Re: svn commit: r1839927 - in /ofbiz/site: about-ofbiz.html mailing-lists.html

[Deepak Dixit]

Hi Swapnil,

Please update .php file and use php2html.sh to generate the html file.
These changes will be overridden when we generate html using  php2html.sh

You can find the php file at following location

https://svn.apache.org/repos/asf/ofbiz/site/template/page/

Thanks & Regards
--
Deepak Dixit


On Mon, Sep 3, 2018 at 3:16 PM,  wrote:

> Author: swapnilmmane
> Date: Mon Sep  3 09:46:50 2018
> New Revision: 1839927
>
> URL: http://svn.apache.org/viewvc?rev=1839927=rev
> Log:
> Removed the extra full stop from the sentence
>
> Modified:
> ofbiz/site/about-ofbiz.html
> ofbiz/site/mailing-lists.html
>
> Modified: ofbiz/site/about-ofbiz.html
> URL: http://svn.apache.org/viewvc/ofbiz/site/about-ofbiz.html?
> rev=1839927=1839926=1839927=diff
> 
> ==
> --- ofbiz/site/about-ofbiz.html (original)
> +++ ofbiz/site/about-ofbiz.html Mon Sep  3 09:46:50 2018
> @@ -144,7 +144,7 @@
>   Developer Mailing
> List
>  The developer list is strictly for topics related to
> the design and development of the OFBiz Project itself.
>  Please don't ask questions relevant to User Mailing List in this
> Mailing List.
> - If you are not sure to which list to post to then use the User
> Mailing List..
> + If you are not sure to which list to post to then use the User
> Mailing List.
>  Developer List 
>
>   Commit Mailing List
>
> Modified: ofbiz/site/mailing-lists.html
> URL: http://svn.apache.org/viewvc/ofbiz/site/mailing-lists.html?
> rev=1839927=1839926=1839927=diff
> 
> ==
> --- ofbiz/site/mailing-lists.html (original)
> +++ ofbiz/site/mailing-lists.html Mon Sep  3 09:46:50 2018
> @@ -146,7 +146,7 @@
> Developer Mailing
> List
> The developer list is strictly for topics related
> to the design and development of the OFBiz Project itself.
>Please don't ask questions
> relevant to User Mailing List in this Mailing List.
> -   If you are not sure to which list to post to then use the User
> Mailing List..
> +   If you are not sure to which list to post to then use the User
> Mailing List.
>Developer List
>  
>  
>
>
>

Re: Move accounting ap and ar to plugin ?

[Sharan Foga]

On 2018/09/03 08:11:26, Jacopo Cappellato  
wrote: 
> On Sat, Sep 1, 2018 at 2:09 PM Nicolas Malin 
> wrote:
> 
> > Hello,
> >
> > After analyze the webapp accounting AR and accounting AP, I didn't see
> > any logic to keep them on the functional framework. The main webapp is
> > accounting, AP/AR are a business orientation that we can load at demand
> > through plugins.
> >
> > Your opinion ?
> >
> 
> As far as I remember, the AP/AR web applications were created as a
> specialized versions of the user interfaces for some business processes
> (account receivables and account payables related tasks) that were already
> available in the more general "accounting" web application. I like the idea
> to move them to plugins but, as mentioned by Taher, we should also verify
> if there are specific features that are available only in the AP/AR version
> and not in the "accounting" application: if we find some, then we should
> migrate the basic artifacts to the main "accounting" app and then move the
> specialized screens to plugins. I think such cases will be rare but one
> possible candidate is the "batch payment" functionality of the AR app.

I thought the batch payment was one of the options for the Payment Group which 
is on the main accounting menu so any processing can be done from there too.

Thanks
Sharan

> 
> 
> >
> > PS: In the same idea we can move on separate plugin all thirdparty
> > accounting element to slimdown the accounting component and must harness
> > the plugin system :)
> >
> 
> +1
> 
> Jacopo
> 
> 
> >
> > Nicolas
> >
> >
> 

Re: Move accounting ap and ar to plugin ?

[Sharan Foga]

Hi All

I really like the idea of making AR and AP plugins. I’ve taken a quick look and 
from what I can see all of the functionality in them are just specialised 
filters of what is already available in the accounting menu.

It looks like our accounting module was originally created with all possible 
accounting functions combined into one module so we have  GL, AR, AP etc 
already all included as part of accounting. 

Many users are used to having an accounting module with the accounting 
functions broken down into specialist submodules  and if people can’t see or 
find them easily they don’t think they exist so I can understand why the AR and 
AP applications were added. That being said – why keep this type of duplication 
in our framework? I think this is something that could be optional and so more 
useful as a plugin.

Having different implementations of base functionality is exactly where the 
plugins could help us give users what they are looking.

Thanks
Sharan

On 2018/09/03 08:11:26, Jacopo Cappellato  
wrote: 
> On Sat, Sep 1, 2018 at 2:09 PM Nicolas Malin 
> wrote:
> 
> > Hello,
> >
> > After analyze the webapp accounting AR and accounting AP, I didn't see
> > any logic to keep them on the functional framework. The main webapp is
> > accounting, AP/AR are a business orientation that we can load at demand
> > through plugins.
> >
> > Your opinion ?
> >
> 
> As far as I remember, the AP/AR web applications were created as a
> specialized versions of the user interfaces for some business processes
> (account receivables and account payables related tasks) that were already
> available in the more general "accounting" web application. I like the idea
> to move them to plugins but, as mentioned by Taher, we should also verify
> if there are specific features that are available only in the AP/AR version
> and not in the "accounting" application: if we find some, then we should
> migrate the basic artifacts to the main "accounting" app and then move the
> specialized screens to plugins. I think such cases will be rare but one
> possible candidate is the "batch payment" functionality of the AR app.
> 
> 
> >
> > PS: In the same idea we can move on separate plugin all thirdparty
> > accounting element to slimdown the accounting component and must harness
> > the plugin system :)
> >
> 
> +1
> 
> Jacopo
> 
> 
> >
> > Nicolas
> >
> >
> 

Re: [QUESTION] Should we not check fields consistency?

[deepak nigam]

+1.

Thanks for the putting this forward. Please count me in for this effort.


Thanks & Regards
--
Deepak Nigam
HotWax Systems Pvt. Ltd.


On Mon, Sep 3, 2018 at 2:06 PM Jacques Le Roux 
wrote:

> Hi,
>
> I have always found that not having dates cross-checks in OFBiz is a minus.
>
> For instance while creating/editing an order we can enter
>
>   * an anti-dated shipping date (eg 2018-08-1 entered today)
>   * The recently added reserved date can be after the shipping date
>   * etc. (not only dates but mostly)
>
> Should we not make an effort to check the consistency of fields values
> when they are entered?
>
> Because this is a simple question to see if we agree about making an
> effort on that, I don't get into more details yet
>
> Thanks for your opinions
>
> Jacques
>
>

Re: Should we keep the multi-tenants feature in OFBiz?

[Julian Smith]

Hi All,

Blockfrieght, Inc. has a alpha (work in progress) Kubernetes wrapper /
production deployment repository (work in progress) published here:

https://github.com/blockfreight/ofbiz-erp

Feedback / Advice and Bug-Reports welcome (as is suggestions of how to make
the example more canonical and of use to other’s globally.

Regards,

Julian Smith,

Blockfreight, Inc.
535 Mission street 14th floor
San Francisco, CA 94205

Re: Move accounting ap and ar to plugin ?

[Julian Smith]

Hi All,

Is there any module / code / notion of subscription billing?

As in automating SaaS accounting (on the service provider, SaaS producer
side) ??

If the module system is evolved - how might we be able to put something
like that together there? (If it doesn’t already exist in Ofbiz today)

Regards,

Julian Smith,

Blockfreight, Inc.
535 Mission street 14th floor
San Francisco, CA 94205

[QUESTION] Should we not check fields consistency?

[Jacques Le Roux]

Hi,

I have always found that not having dates cross-checks in OFBiz is a minus.

For instance while creating/editing an order we can enter

 * an anti-dated shipping date (eg 2018-08-1 entered today)
 * The recently added reserved date can be after the shipping date
 * etc. (not only dates but mostly)

Should we not make an effort to check the consistency of fields values when 
they are entered?

Because this is a simple question to see if we agree about making an effort on 
that, I don't get into more details yet

Thanks for your opinions

Jacques

Re: Should we keep the multi-tenants feature in OFBiz?

[Shi Jinghai]

Hi Jacques,

I assume we face the same requirement: how to become a value-added reseller of 
cloud services. In China, the reseller margin could be 15-20% from Alibaba 
cloud or other cloud venders, so there's a new business model that we can offer 
some vertical OFBiz applications "free" and profitable.

Kubernetes is the management tool to sell/distribute OFBiz applications.

The OFBiz applications can be a multi-tenants model: multiple customers share 
one machine at a low price, this model is suitable for tiny/small customers.

The OFBiz applications can also be a multi-instances model: each customer can 
scale up/down its-own application on-demand, this model is suitable for 
medium/large customers.

Every customer can upgrade from multi-tenants to multi-instances, or downgrade 
from multi-instances to multi-tenants.

Thank you for this topic. Please count me in if we have the same target.

Kind Regards,

Shi Jinghai



-邮件原件-
发件人: Jacques Le Roux [mailto:jacques.le.r...@les7arts.com] 
发送时间: 2018年9月2日 16:13
收件人: dev@ofbiz.apache.org
主题: Re: Should we keep the multi-tenants feature in OFBiz?

Hi Jinghai,

Inline...


Le 29/08/2018 à 14:49, Shi Jinghai a écrit :
> Hi Jacques,
>
> Honestly I was shocked by this email, I'm working on deploying OFBiz in 
> Kubernetes, are you monitoring me?
Not at all :D

> In 2010, Kubernetes was quite new and not good enough, now it's the standard 
> on cloud deploy management, and we can support it.
I agree Kubernetes is a good tool. How do you envision to use it with OFBiz? I 
see it more as a production tool, not something we can embed like Tomcat.

> Before doing that, we have to answer some common questions in cloud running 
> lifecycle, such as how may instances/requests can share one CPU, how to 
> deliver(create) an instance, how to isolate an instance, how to offline, how 
> to remove, how to online again and etc.
You seem to be advanced in this, have you already , even partially, answered 
these questions? Are you working on a multi-tenant solution?

> Personally I don't think we have to remove current multi-tenants implements, 
> add a SAAS implement would be OK.
The problem with the current implementation is that it has changed the OFBiz 
code in some places, not always for the good.
It seems you not alone to want to keep it. Are you using it as is?
They are also people who would be glad to get rid of.
Let's see...

Jacques

>
> Kind Regards,
>
> Shi Jinghai
>
>
> -邮件原件-
> 发件人: Jacques Le Roux [mailto:jacques.le.r...@les7arts.com]
> 发送时间: 2018年8月29日 17:46
> 收件人: dev@ofbiz.apache.org
> 主题: Should we keep the multi-tenants feature in OFBiz?
>
> Hi,
>
> The multi-tenants feature in OFBiz only allows a dozens or maybe even few 
> hundreds tenants, after it begin to be a lot of DBs!
> I faced that with a startup which wanted to handle thousands, if not millions 
> (actually they failed), of tenants, obviously OFBiz can't do that.
>
> I don't break any secret to say that I was working with David (and Andrew) on 
> a project in 2010 when David had to quickly answer to the client's
> demand who wanted to have tenants. David brilliantly and quickly delivered, 
> but it was only a start.
>
> After many improvements, this feature still have some issues
>       
> https://nam03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fissues.apache.org%2Fjira%2Fbrowse%2FOFBIZ-6066data=02%7C01%7C%7C08ade5bcabda49a1f68308d610abf411%7C84df9e7fe9f640afb435%7C1%7C0%7C636714728052368674sdata=QCPlqtRHjd9a%2Fq3NIVujeqhR3o6sjjZ0sUEbFk4ojp8%3Dreserved=0
>       
> https://nam03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fissues.apache.org%2Fjira%2Fbrowse%2FOFBIZ-7900data=02%7C01%7C%7C08ade5bcabda49a1f68308d610abf411%7C84df9e7fe9f640afb435%7C1%7C0%7C636714728052368674sdata=fxUSwHPjg%2F8Nf2aDGCODhKauIVAbmK1wb%2B67%2FPZGrRU%3Dreserved=0
>       
> https://nam03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fissues.apache.org%2Fjira%2Fbrowse%2FOFBIZ-6164data=02%7C01%7C%7C08ade5bcabda49a1f68308d610abf411%7C84df9e7fe9f640afb435%7C1%7C0%7C636714728052368674sdata=MoH0jYAEo5IY0HA5xQOO2ZBKKMMU9RdloK1xlWNY6oY%3Dreserved=0
>       
> https://nam03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fissues.apache.org%2Fjira%2Fbrowse%2FOFBIZ-6065data=02%7C01%7C%7C08ade5bcabda49a1f68308d610abf411%7C84df9e7fe9f640afb435%7C1%7C0%7C636714728052368674sdata=4lZb89MwttM6VGxNdT9XSeP0sEL6UBlEMOdwf%2BsU9c8%3Dreserved=0
>
> Also this is somehow related
>       
> https://nam03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fissues.apache.org%2Fjira%2Fbrowse%2FOFBIZ-6712data=02%7C01%7C%7C08ade5bcabda49a1f68308d610abf411%7C84df9e7fe9f640afb435%7C1%7C0%7C636714728052368674sdata=LdE%2FSQc51d%2BeN1TdZMFJgDLJT8MmFaN16VPP9H1izto%3Dreserved=0
>
> And most importantly
>       
> 

Re: svn commit: r1839763 - in /ofbiz/ofbiz-framework/trunk/framework/entity: src/main/java/org/apache/ofbiz/entity/test/EntityUtilTestSuite.java src/main/java/org/apache/ofbiz/entity/util/EntityUtil.j

[Gil Portenseigne]

Hello Taher !

I'll be a little bit more verbose in commit log next times :), and for
the tStream, it was a miss, i'll fix it soon.

Thanks as always for your review !

Gil

Le samedi 01 sept. 2018 à 21:24:56 (+0300), Taher Alkhateeb a écrit :
> Hi Gil,
> 
> Awesome work :) it took me a while to understand that you also
> committed tests along with the refactoring. For the future I recommend
> mentioning this somewhere in the commit log for easy review. Also,
> perhaps as a further improvement you might want to rename the tStream
> variable into something more meaningful. The variable name might be a
> bit vague.
> On Fri, Aug 31, 2018 at 6:46 PM  wrote:
> >
> > Author: pgil
> > Date: Fri Aug 31 15:32:02 2018
> > New Revision: 1839763
> >
> > URL: http://svn.apache.org/viewvc?rev=1839763=rev
> > Log:
> > Implemented: Refactor EntityUtil findBy methods using Stream API
> > (OFBIZ-10537)
> >
> > Thanks Jacques and Mathieu for the review
> >
> > Added:
> > 
> > ofbiz/ofbiz-framework/trunk/framework/entity/src/main/java/org/apache/ofbiz/entity/test/EntityUtilTestSuite.java
> >(with props)
> > Modified:
> > 
> > ofbiz/ofbiz-framework/trunk/framework/entity/src/main/java/org/apache/ofbiz/entity/util/EntityUtil.java
> > ofbiz/ofbiz-framework/trunk/framework/entity/testdef/entitytests.xml
> >
> > Added: 
> > ofbiz/ofbiz-framework/trunk/framework/entity/src/main/java/org/apache/ofbiz/entity/test/EntityUtilTestSuite.java
> > URL: 
> > http://svn.apache.org/viewvc/ofbiz/ofbiz-framework/trunk/framework/entity/src/main/java/org/apache/ofbiz/entity/test/EntityUtilTestSuite.java?rev=1839763=auto
> > ==
> > --- 
> > ofbiz/ofbiz-framework/trunk/framework/entity/src/main/java/org/apache/ofbiz/entity/test/EntityUtilTestSuite.java
> >  (added)
> > +++ 
> > ofbiz/ofbiz-framework/trunk/framework/entity/src/main/java/org/apache/ofbiz/entity/test/EntityUtilTestSuite.java
> >  Fri Aug 31 15:32:02 2018
> > @@ -0,0 +1,101 @@
> > +/***
> > + * Licensed to the Apache Software Foundation (ASF) under one
> > + * or more contributor license agreements.  See the NOTICE file
> > + * distributed with this work for additional information
> > + * regarding copyright ownership.  The ASF licenses this file
> > + * to you under the Apache License, Version 2.0 (the
> > + * "License"); you may not use this file except in compliance
> > + * with the License.  You may obtain a copy of the License at
> > + *
> > + * http://www.apache.org/licenses/LICENSE-2.0
> > + *
> > + * Unless required by applicable law or agreed to in writing,
> > + * software distributed under the License is distributed on an
> > + * "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
> > + * KIND, either express or implied.  See the License for the
> > + * specific language governing permissions and limitations
> > + * under the License.
> > + 
> > ***/
> > +package org.apache.ofbiz.entity.test;
> > +
> > +import org.apache.ofbiz.base.util.StringUtil;
> > +import org.apache.ofbiz.base.util.UtilMisc;
> > +import org.apache.ofbiz.entity.GenericValue;
> > +import org.apache.ofbiz.entity.condition.EntityCondition;
> > +import org.apache.ofbiz.entity.condition.EntityExpr;
> > +import org.apache.ofbiz.entity.condition.EntityOperator;
> > +import org.apache.ofbiz.entity.testtools.EntityTestCase;
> > +import org.apache.ofbiz.entity.util.EntityUtil;
> > +
> > +import java.util.ArrayList;
> > +import java.util.List;
> > +
> > +public class EntityUtilTestSuite extends EntityTestCase {
> > +
> > +public static final String module = 
> > EntityUtilTestSuite.class.getName();
> > +
> > +public static final long TEST_COUNT = 1000;
> > +
> > +public EntityUtilTestSuite(String name) {
> > +super(name);
> > +}
> > +
> > +private List prepareGenericValueList() {
> > +List newValues = new ArrayList<>();
> > +for (int i = 0; i < TEST_COUNT; i++) {
> > +newValues.add(delegator.makeValue("Testing", "testingId", 
> > StringUtil.padNumberString(String.valueOf(i), 5), "description", 
> > "Description " + i % 10));
> > +}
> > +return newValues;
> > +}
> > +
> > +public void testGetFieldListFromEntityList() {
> > +List newValues = prepareGenericValueList();
> > +List descriptionList = 
> > EntityUtil.getFieldListFromEntityList(newValues, "description", false);
> > +assertEquals("Get not distinct field list from " + TEST_COUNT + " 
> > entity", TEST_COUNT, descriptionList.size());
> > +assertEquals("Get first description value", "Description 0", 
> > descriptionList.get(0));
> > +assertEquals("Get tens description value", "Description 0", 
> > descriptionList.get(10));
> > +
> > +descriptionList = 

Re: Move accounting ap and ar to plugin ?

[Jacopo Cappellato]

On Sat, Sep 1, 2018 at 2:09 PM Nicolas Malin 
wrote:

> Hello,
>
> After analyze the webapp accounting AR and accounting AP, I didn't see
> any logic to keep them on the functional framework. The main webapp is
> accounting, AP/AR are a business orientation that we can load at demand
> through plugins.
>
> Your opinion ?
>

As far as I remember, the AP/AR web applications were created as a
specialized versions of the user interfaces for some business processes
(account receivables and account payables related tasks) that were already
available in the more general "accounting" web application. I like the idea
to move them to plugins but, as mentioned by Taher, we should also verify
if there are specific features that are available only in the AP/AR version
and not in the "accounting" application: if we find some, then we should
migrate the basic artifacts to the main "accounting" app and then move the
specialized screens to plugins. I think such cases will be rare but one
possible candidate is the "batch payment" functionality of the AR app.


>
> PS: In the same idea we can move on separate plugin all thirdparty
> accounting element to slimdown the accounting component and must harness
> the plugin system :)
>

+1

Jacopo


>
> Nicolas
>
>

Re: CSRF attack and prevention

[Girish Vasmatkar]

Thanks Jacques and Nicolas. I will take this further in the security group
and will soon have updates there. My bad I didn't realise we need to take
it up over there.

Thanks and Best Regards,
Girish Vasmatkar
HotWax Systems

On Mon, Sep 3, 2018 at 1:21 PM Jacques Le Roux 
wrote:

> Hi Girish,
>
> Nicolas is right, I just want to say that I already tried to use the
> CsrfPreventionFilter Tomcat Filter (wrongly noted RestCsrfPreventionFilter
> in the
> link below) without success, please refer to
>
> https://markmail.org/message/r245yie623cdo3wz
>
> Your help is welcome :)
>
> Jacques
>
>
> Le 02/09/2018 à 21:15, Nicolas Malin a écrit :
> > Hi Girish,
> >
> > Thanks for your warm. If you want to detail your please prefer send an
> email to secur...@ofbiz.apache.org instead of open an issue to JIRA.
> >
> > Nicolas
> >
> >
> > On 02/09/2018 17:36, girish.vasmat...@hotwaxsystems.com wrote:
> >> Hi All
> >>
> >>   It looks like there is no mechanism to prevent CSRF attack in
> ofbiz. If I am logged in to ofbiz instance on my local and create a sample
> >> standalone HTML page and try to submit to either a GET or a POST ofbiz
> URL, I am successfully through and various cookies (applicable to the
> >> domain) are also sent by the browser to Ofbiz instance. That
> essentially is CSRF. This can be reproduced with a script tag with a valid
> ofbiz URL
> >> as src and you can actually see in the developer console the request
> made through and response is received.
> >>
> >> Of course this attack has a context - that the user is logged in and
> happens on the victim's browser.
> >>
> >> I replaced ofbiz URL with gmail and made sure I am logged in to my
> gmail account. I saw a vague/obsure response from gmail in the console
> meaning
> >> it prevented itself.
> >>
> >>   I feel we can handle it in multiple ways and one of the ways is
> adding SameSite cookie which is a fairly new concept and per latest
> information
> >> Chrome already supports it and FireFox has also added support for the
> same. Browsers supporting this Cookie will not send JSESSIONID or any other
> >> SameSite cookie to the request if the request is cross-site. Each
> cookie needs to be flagged with SameSite with possible values being strict
> or lax.
> >> Here's its IETF draft -
> https://tools.ietf.org/html/draft-west-first-party-cookies-07
> >>
> >>   I also think we should not rely on this as the sole prevention
> mechanism and should also do something on the server side in the sense that
> we
> >> should not rely on the browser support. Tomcat does support a filter -
> org.apache.catalina.filters.CsrfPreventionFilter that appends a nonce for
> >> every request and stores the same in session.
> >>
> >> We should also add support for checking Origin and Referrer headers. I
> think there is a lot we can do.
> >>
> >> I have not seen any reference in the current trunk code for both
> SameSite cookie and CsrfPreventionFilter filter. If we can make everyone on
> the
> >> same page on CSRF, I would like to propose we go ahead with this
> change. I think we will need to handle it in multiple ways.
> >>
> >> I can create a JIRA with all details provided we have the necessary
> concord.
> >>
> >>
> >> Thanks and Best regards,
> >> Girish Vasmatkar
> >> HotWax Systems
> >>
> >
> >
>
>

Re: Move accounting ap and ar to plugin ?

[Julien NICOLAS]

+1


Le 02/09/2018 à 10:36, Jacques Le Roux a écrit :
But do you really need to show all your medals in each email :) ? 

Re: CSRF attack and prevention

[Jacques Le Roux]

Hi Girish,

Nicolas is right, I just want to say that I already tried to use the CsrfPreventionFilter Tomcat Filter (wrongly noted RestCsrfPreventionFilter in the 
link below) without success, please refer to


https://markmail.org/message/r245yie623cdo3wz

Your help is welcome :)

Jacques


Le 02/09/2018 à 21:15, Nicolas Malin a écrit :

Hi Girish,

Thanks for your warm. If you want to detail your please prefer send an email to 
secur...@ofbiz.apache.org instead of open an issue to JIRA.

Nicolas


On 02/09/2018 17:36, girish.vasmat...@hotwaxsystems.com wrote:

Hi All

  It looks like there is no mechanism to prevent CSRF attack in ofbiz. If I am logged in to ofbiz instance on my local and create a sample 
standalone HTML page and try to submit to either a GET or a POST ofbiz URL, I am successfully through and various cookies (applicable to the 
domain) are also sent by the browser to Ofbiz instance. That essentially is CSRF. This can be reproduced with a script tag with a valid ofbiz URL 
as src and you can actually see in the developer console the request made through and response is received.


Of course this attack has a context - that the user is logged in and happens on 
the victim's browser.

I replaced ofbiz URL with gmail and made sure I am logged in to my gmail account. I saw a vague/obsure response from gmail in the console meaning 
it prevented itself.


  I feel we can handle it in multiple ways and one of the ways is adding SameSite cookie which is a fairly new concept and per latest information 
Chrome already supports it and FireFox has also added support for the same. Browsers supporting this Cookie will not send JSESSIONID or any other 
SameSite cookie to the request if the request is cross-site. Each cookie needs to be flagged with SameSite with possible values being strict or lax.

Here's its IETF draft - 
https://tools.ietf.org/html/draft-west-first-party-cookies-07

  I also think we should not rely on this as the sole prevention mechanism and should also do something on the server side in the sense that we 
should not rely on the browser support. Tomcat does support a filter - org.apache.catalina.filters.CsrfPreventionFilter that appends a nonce for 
every request and stores the same in session.


We should also add support for checking Origin and Referrer headers. I think 
there is a lot we can do.

I have not seen any reference in the current trunk code for both SameSite cookie and CsrfPreventionFilter filter. If we can make everyone on the 
same page on CSRF, I would like to propose we go ahead with this change. I think we will need to handle it in multiple ways.


I can create a JIRA with all details provided we have the necessary concord.


Thanks and Best regards,
Girish Vasmatkar
HotWax Systems