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