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: [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: [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: [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: [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: [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: [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
>
>

[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