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