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