Yep, that will do it...

Nope I use the DDT for all deployments but obviously something when south and I don't have the time to find a way to duplicate it now so I just removed the offended record from my database and the customer's.

Edhy Rijo

Guess it could happen if you copied the SFS tables to the production database instead of deploying them with the DDT, maybe.

You are welcome, Edhy!

Glad you got it working.

Found the problem.  The SFSPreferences table have 2 records where it should be only one, the code in the Security Editor may be expecting to have only one record in this table and once changing the values, it was saved, but was using the invalid record to validate the user maintenance form.

Once I removed the 1st record, then it worked as expected.  See attached image. 

Now to figure out how I end up with duplicate records

Thanks Ivan!

Edhy Rijo

Thanks for testing this Ivan.  it is very weird. The assembly looks OK, I tested in my dev with 1.7.3 and at the customer with previous version and they both give the broken rule for complex password.  I have not hacked any table, so what else could be causing this kind of weirdness?

Edhy Rijo

Have you checked your MicroFour.StrataFrame.Security reference version?

Did it all, it worked. Here are some screen shots for you to tell me if there is something else I should try.

Then, I changed back to unchecked Complex Passwords and changed the password all over again. Saved with no error messages.

Hi Ivan,



Please try this:



1.- In Global Preference check the Complex Password and save it.

2.- Edit a User and assign a password like: StrataFrame1 and save it.

3.- Go back to Global Preference Uncheck the Complex Password, set all Password restrictions to zero and save it.

4.- Try changing the user password to 1234 or 123456 based on the password Minimum Length.



In my case I will get the broken rule.

Edhy Rijo

Hi Edhy.

Just tried it over here and it worked fine.

By the way, I wouldn't hack the user's table, if I remember well everything is in an encripted field with a check number that will find out if it's been tampered.

I have been able to change the password via the Security Editor and with the menu option from my application that calls the change password dialog:

If you would like to give me a step-by-step of how I could reproduce the error, I will test over here.

I am getting this same issue running SF 1.7.3.0.



Complex password is unchecked, Password Restrictions are all in zero (0) and still I try to change the password will bet the broken rule for complex password "The password supplied does not meet the minimum complexity requirements......"



This problem is currently happening on a customer which have previous version of SF assemblies. Can anybody confirm this? I need to change some password at a customer and don't know what else to do or hack in the security tables.

Edhy Rijo