Ah, that explains it. Thanks!

Hi all,

I've created new TFS 50430 against the issue, should be specified by the feature owner finally. To be honest, the validation should be performed at least for user name in my view.

BR, Oleg QA

Thanks, Oleg!

Hi Imar

The problem regarding #50430 "User types and required fields" has been resolved in Dynamicweb version 9.4.15

To upgrade please choose this version download from here:

http://doc.dynamicweb.com/releases-and-downloads/releases

Let me know if you need any more help regarding this

Kind Regards
Dynamicweb Support
Kristian Kirkholt

Hi guys,

I just tested this in 9.4.18 and it seems that password is still required. When I create, say, a Dealer type with just some address info and no user name and password visible, I get the following response when I save:

"Password must contain numbers, upper and lower case characters and special characters."

I must enable, and enter, a password for it to work.

When I hide the User name field, and then create a new user without an email address, I get a hard .NET Exception:

Server Error in '/' Application.

Username or Email must have a nonempty value

Description: An unhandled exception occurred during the execution of the current web request. Please review the stack trace for more information about the error and where it originated in the code. 

Exception Details: System.Exception: Username or Email must have a nonempty value

Source Error: 
 

Stack Trace: 
 

[Exception: Username or Email must have a nonempty value]
   Dynamicweb.Security.UserManagement.User.Save() +650
   Dynamicweb.Admin.UserManagement.EditUser.Save() +4869
   Dynamicweb.Admin.UserManagement.EditUser.Page_Load(Object sender, EventArgs e) +1790
   System.Web.UI.Control.OnLoad(EventArgs e) +106
   System.Web.UI.Control.LoadRecursive() +68
   System.Web.UI.Page.ProcessRequestMain(Boolean includeStagesBeforeAsyncPoint, Boolean includeStagesAfterAsyncPoint) +3785

Looks like this needs a bit more work to be really usable. Would love to be able to create new "users" with just basic data such as an address so I can use them as dealers, shops, event locations and so on.

Thanks!

Imar

Hi Imar,

I've tested the case on DW9.4.18 and have appropriate popup defines with #50430 fix (please, have a look at the code changes and discussion inside the TFS if needs). Since you mentioned the specific notice I've used password security feature enabled. The same results are when the feature is disabled. Please, find the proof.

Please, ensure that your admin is 9.4.18 in fact or provide more details about your setup otherwise.

BR, Oleg QA 

HI again,

I've just seen some issue related to not saving the user if Name field is extra exists for the type and password security is enabled (but no exception occurs). So, current work around - temporary disable the feature.

Please, confirm the case fits your one to submit new TFS.

BR, Oleg   

I'm pretty confused by these videos ;-) In your last one, you seem to be showing Address Only twice. The first time it works, the second time it doesn't. What's the difference?

And am I correct that I cannot have a type that just has a name and address fields, but that it must have at least either a user name or an email address? That would be OK, but I would like to know for sure.

And is the password issue a bug that will be fixed and is the "temporary disable the feature" work around just temporary? If not, that would be a pretty bad work around  ;-)

Cheers,

Imar

HI,

The logic was defined by #50430 prohibits create new user without name/user name/email, appropriate notice is shown to user - first video taken with user item type has only address fileds (Address1&Address2) regardless password security enabled/disabled. The second video says the following issue - if the type has at least 'Name' field and the same address fields then it's not possible to create backend user ('Allow backend login' option is provided via its parent group) and password security is enabled. It's OK when either the password security is disabled or the created user is not 'backend' one or the type has password field as well. New TFS 53978 has been created against the unsaving.

BR, Oleg  

OK thanks Oleg!

Hi Oleg,

I just looked at the fix in 53978 and I am not sure it makes sense. Instead of presenting the error message "Password must contain numbers, upper and lower case characters and special characters." in a hidden way (since the password field is not visible) as it was previously, it now shows it in an alert box. This is a little better as you can at least tell what the problem is: a missing password.

However, the underlying problem isn't fixed: having the ability to create a "user" without a user name or password. For example, I'd like to create a Store location which would have these fields:

- Name
- Street
- Zip code
- City

And nothing else. I thought the whole idea of user types would be to allow us to create definitions like that, without having awkward fields that only make sense to true users. Adding a password field to a store just to meet the password requirements doesn't make a lot of sense to me.

In my opinion, I should be able to create a user type like the above, and then I should be able to create a user / store based on that definition without supplying a password. Whether Dynamicweb internally then generates a password or marks this user as a "password-less" user somehow, I don't care.

Does this make sense? Or am I rambling?

Imar

Hi Imar,

It may have any sense in fact. I've notified the feature owners in DW about it and asked to comment the topic. Thanks.

 BR, Oleg QA

Hi Imar,

I'll get QA to explain to me exactly what the problem is. I can easily create users with Password security enabled and only UserName visible - which is, as you said, the whole point.

To make it clear: You are supposed to be able to create new users without passwords, if the user is configured as such.

I'll get QA to update once this is fixed. Thanks for the feedback! :)

BR

Martin

Thanks Oleg and Martin!

We are on 9.13.11, and still seeing this issue.  Setting up stores with the User template still requires a password when saving a store.  Please clarify the workaround/fix as we prefer not to expose & create passwords for the stores.     

Hi,

I've tested the issue on environment based on last 9.13.13 as well as 9.14.1 admin and was not able to reproduce it. Please, have a look at the video regarding the check and specify your case if it's out of my scenario. Note about mandatory availability of 'Name' field at least (defined by 50430 fix mentioned above).

BR, Oleg QA 

Thank you for the screencast, sending you mine.  The only differences I noted is we have "Enable Password security - Dynamicweb Administration" and "Enable Password security - Extranet" checked, whereas you do not.  Is that second checkbox what is forcing us to apply a password?  I don't believe we'd want to uncheck that.   

https://www.screencast.com/t/FXOhlvnYi 

Hi,

I've tried to test 9.13.13 admin using settings the same as you show in the video but was not able to catch it anyway. The notice is shown when 'Allow backend login' option is available(to define created backend user as one folows to 'Dynamicweb Administrator password security' settings) and enabled in group only. It's current limitation cannon be considered as bug. But as far as I see your video says that created user has the option not avialable, so try to have a look at definition of group ("Tandy Stores") the user is created and play with settings as well (e.g. try to create new user under regular top group etc.) 

BR, Oleg QA

Thanks Oleg.  'Allow backend login option' has always been hidden on both the group type (named StoreGroup) and user type (named Store).  I created another new StoreGroup and new Store user and it still requires Password, also we've reproduced on another site.  Could there be a global setting difference?  Would you like access to my site to take a look?    

Hi,

I don't have access to any solution by Angel credentials, all further tests and comments regarding to your specific case are from DW support only, refer there, pls. Thanks.

BR, Oleg QA 

Hi Oleg,

I was able to repro both scenarios (yours and Lora's). The issue is when password complexity is set (not Low) it prompts for the password. Can you try to repro with password complexity set to either Medium or High?

Thanks!
BR, Mario

Hi all,

I don't think the issue is real bug in the case, since always forse to perform the password security with specific complexity can hight priority in the case (the behavior was approved by TFS 53978). But I've created new task 10594 to research it by experts again and fix a new logic if approved or consider it as feature finally. Results will be provided here I hope.

BR, Oleg QA   

Thanks for opening up a research task.  If a password field isn't required for a User, the password field complexity rules should not be enforced.  Hope this will be resolved soon, believe the only workaround for now is to set passwords on Stores since we do not want to reduce the site's password complexity to "Low".   Let me know if there is any other alternative.

Hi Lora

This has been scheduled for development in this sprint.

BR Nicolai 

Thank you Nicolai & Oleg.