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