[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

[deepak nigam-2]

+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 <[hidden email]>
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
>
>

[taher]

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 <[hidden email]> 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 <[hidden email]>
> 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
> >
> >

[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 <[hidden email]> 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 <[hidden email]>
>> 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
>>>
>>>

[taher]

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
<[hidden email]> 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 <[hidden email]> 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 <[hidden email]>
> >> 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
> >>>
> >>>
>

[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
> <[hidden email]> 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 <[hidden email]> 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 <[hidden email]>
>>>> 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
>>>>>
>>>>>

[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
>> <[hidden email]> 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
>>>> <[hidden email]> 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
>>>>> <[hidden email]>
>>>>> 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
>>>>>>
>>>>>>
>
>

[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 <http://www.hotwax.co/> by HotWax Systems
<http://www.hotwaxsystems.com/>
80, Scheme No. 78, Indore, M.P. 452010, India
Mobile Phone: [phone] | Linkedin: Sanjay-Yadav
<https://www.linkedin.com/in/sanjay-yadav/>


On Mon, Sep 3, 2018 at 2:06 PM Jacques Le Roux <[hidden email]>
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
>
>

[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
>>> <[hidden email]> 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 <[hidden email]> 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 <[hidden email]>
>>>>>> 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
>>>>>>>
>>>>>>>
>>
>>
>
>

[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
>>>> <[hidden email]> 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
>>>>>> <[hidden email]> 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
>>>>>>> <[hidden email]>
>>>>>>> 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
>>>>>>>>
>>>>>>>>
>>>
>>>
>>
>>
>
>

[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
>>>>> <[hidden email]> 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 <[hidden email]> 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 <[hidden email]>
>>>>>>>> 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
>>>>>>>>>
>>>>>>>>>
>>>>
>>>>
>>>
>>>
>>
>>
>
>

[grv]

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 <
[hidden email]> 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
> >>>>> <[hidden email]> 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 <
> [hidden email]> 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 <
> [hidden email]>
> >>>>>>>> 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
> >>>>>>>>>
> >>>>>>>>>
> >>>>
> >>>>
> >>>
> >>>
> >>
> >>
> >
> >
>
>

[taher]

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 <[hidden email]>
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
> >> <[hidden email]> 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
> >>>> <[hidden email]> 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
> >>>>> <[hidden email]>
> >>>>> 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
> >>>>>>
> >>>>>>
> >
> >
>
>

[Deepak Dixit-3]

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 <[hidden email]>
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 <[hidden email]>
> 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
> > >> <[hidden email]> 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
> > >>>> <[hidden email]> 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
> > >>>>> <[hidden email]>
> > >>>>> 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
> > >>>>>>
> > >>>>>>
> > >
> > >
> >
> >
>