I agree with david.
snowc sent the following on 9/5/2009 8:46 PM:
> Thanks BJ, I have commented out the code in LoginServices.java.
>
> Thinking a bit deeper about the admin screen behaviour - why would admin
> only want to temporarily disable an account for 5 minutes?
>
>
> BJ Freeman wrote:
>
Thanks BJ, I have commented out the code in LoginServices.java.
Thinking a bit deeper about the admin screen behaviour - why would admin
only want to temporarily disable an account for 5 minutes?
BJ Freeman wrote:
>
> you can recode the re-activation service so if there is no date it will
> no
you can recode the re-activation service so if there is no date it will
not re-activate.
snowc sent the following on 9/5/2009 7:53 PM:
> In MHO, while not permanently disabling accounts for failed logins may be
> desirable, this behaviour is not desirable for the admin interface. The
> default f
In MHO, while not permanently disabling accounts for failed logins may be
desirable, this behaviour is not desirable for the admin interface. The
default for the admin interface should be to permanently disable the
account.
David E Jones wrote:
>
>
> The reason for this (which is configuratio
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"
Ok. My concern is about functional design of Disable/Enable status section
in Party manager for UserLogin ent
Maybe all that is needed is a tooltip stating what to do to permanently
disable the account.
-Adrian
masionas wrote:
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 part
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
From: "masionas"
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 wr
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
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 gener
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 disab
Interesting trick, I put at link to Nabble Forum http://www.nabble.com/forum/Permalink.jtp?root=18223799&post=18223799&page=y from
http://docs.ofbiz.org/display/OFBIZ/FAQ+-+Tips+-+Tricks+-+Cookbook+-+HowTo#FAQ-Tips-Tricks-Cookbook-HowTo-ProductionTips
Jacques
From: "Robert Volke" <[EMAIL PROTECT
The reason for this (which is configuration in the security.properties
file, BTW, and is documented in the production setup guide) is that
repeated login attempts usually cause an account to be disabled, but
people usually don't want permanent disabling because of the internal/
customer se
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 wi
I am guessing there is a bug that when you entered the disable time.
this is normally set by the system when there is a login try.
Robert Volke sent the following on 7/1/2008 12:41 PM:
> I can' t seem to figure out how to disable user IDs properly. I reviewed the
> documentation I could find an
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.
16 matches
Mail list logo