Ok. My concern is about functional design of Disable/Enable status section in Party manager for UserLogin entity. It looks, it is the right place to control it for a given party. The only design drawback I see there as it is now is that it disables login for 5 min and then re-enable it. In a real world scenario who needs this funcitonlity? Why you would disable login for 5 min manually and as I remember it does not give a note that it was disabled only for 5 min?
I think no need to have it as a separate function in Webtools as it is already exists in Party Manager context and is the right place to be. just a bit strange behaviour of 5 min re-enabling. Do you see my point, Jacques? jacques.le.roux wrote: > > From: "masionas" <[email protected]> >> HI Jacques, >> >> Thanks for your reply. But in a real world I think other scenario >> actually >> happens. For example, company fires an employee and obviously respective >> user account should be Disabled PERMANENTLY. Since userlogin is disabled >> by >> the SYSTEM automatically in the case of wrong login reties I do not see >> why >> UI in Party manager should duplicate it? It looks more logical to me >> have >> that UI for permanent disable. > > Sorry I'm not sure to understand you. What I proposed was to create a new > section in Webtools (admin tools) where someone (with > admin right) would be able to disable permanently a login (beware a party > may have several logins...).? > Have a look at updateUserLoginSecurity service > > Jacques > >> >> jacques.le.roux wrote: >>> >>> This is used for disabling an UserLogin temporarily after some (3?) >>> tries >>> (in case, for instance, someone tried to force it). >>> So I'm not seeing what is to fix here. If you need an UI to permanently >>> disable a login you could contribute a patch. >>> I'd suggest using Webtools as place with a new general entry about >>> parties >>> then... >>> You could even use the new service to parametrize the above behaviour >>> with >>> a property. >>> >>> Jacques >>> >>> From: "masionas" <[email protected]> >>>> >>>> Hi Guys, >>>> >>>> Any updates on whether it was fixed lately? With 9.04 release it seems >>>> still >>>> needs the workaround instead of directly to disable login permanently. >>>> >>>> >>>> Robert Volke wrote: >>>>> >>>>> Wow, that did the trick. When I first saved the Enabled flag change >>>>> to >>>>> N, >>>>> it automatically populated the disabled date, so I deleted this date >>>>> and >>>>> saved the change again. Now the disabled admin can no longer login. >>>>> It >>>>> looks like if you simply disable an account and leave the time stamp, >>>>> it >>>>> will automatically enable again in 5 minutes. I'm not sure why it >>>>> does >>>>> this, and I didn't see a way to change the end date for the disable so >>>>> I'm >>>>> going to inform my users to use this work around. >>>>> >>>>> Thank you for all of the help, >>>>> Robert Volke >>>>> >>>>>>>> Bilgin Ibryam <[email protected]> 7/1/2008 3:53:22 PM >>> >>>>> >>>>> Hi Robert, >>>>> >>>>> try to set the Enabled Flag to "N" WITHOUT Disabled Date Time. >>>>> >>>>> Bilgin >>>>> >>>>> ---------------------------------------------------------------- >>>>> This message was sent using IMP, the Internet Messaging Program. >>>>> >>>>> >>>>> >>>>> >>>> >>>> -- >>>> View this message in context: >>>> http://www.nabble.com/Users-with-disabled-accounts-are-still-able-to-login-tp18223799p24922534.html >>>> Sent from the OFBiz - User mailing list archive at Nabble.com. >>>> >>> >>> >>> >> >> -- >> View this message in context: >> http://www.nabble.com/Users-with-disabled-accounts-are-still-able-to-login-tp18223799p24971362.html >> Sent from the OFBiz - User mailing list archive at Nabble.com. >> > > > > -- View this message in context: http://www.nabble.com/Users-with-disabled-accounts-are-still-able-to-login-tp18223799p24972825.html Sent from the OFBiz - User mailing list archive at Nabble.com.
