Do you speak about
https://localhost:8443/partymgr/control/editlogin?partyId=admin&userLoginId=flexadmin
?
If yes, did you try to set "Disabled Date Time" ?
Jacques
From: "masionas" <michael.koro...@gmail.com>
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" <michael.koro...@gmail.com>
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" <michael.koro...@gmail.com>
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 <bibr...@iguanait.com> 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.
