@DeveloperChris:

Regarding (2/): I'm the author of fix to 09532 and I did concern for the implications. In fact, this bug was caused by another overfixed bug. Current git version behaviour has been the standard for a long time. After 09532 fix, a standard user without user permission can not see other users when he access user window to change his password. Could you describe how you get the situation you describe?

Regarding (3/): Again, I'm not able to reproduce the situation you describe. When modifying survey permission, he can see only users or groups he created.

Anyway, passwod policy could be certainly improved. In our organization, we have a patch to force users to use LDAP authentication. This way we solve other problems you don't mention in your "speech" (password complexity, expired passwords, etc) too.

@DeveloperChris:

Regarding (1/): There is an option "display_user_password_in_email" to prevent passwords from being sent in email. See config-defaults.php.

And there is an authentication method (I have never tried) to use always one time passwords.

In the two above images it can be seen that the user can see all other registered users.
That user does not have any global user permissions set as can be seen in the second image.

With respect to the following settings
1/ display_user_password_in_email
2/ use_one_time_passwords

The first replaces the password with the message "Please contact your administrator". And then I assume the administrator sends the user their password via Umm email?

The second does not work the way I first envisaged. The password needs to be set directly in the database by a third party application (perhaps there is an api for it) and then it is expired after the password is used once.

It is most definitely a one time password. The user cannot get back in because it is deleted once it has been used.

Of course I could implement it in that way by manually adding a password to the DB and send instructions to the user to change their password once they have logged in. But there is no way to force it upon them (as the system currently stands).

With 100's of users this is an impractical solution.

I am sorry you thought my bug report/feature request was a 'speech' I was only trying to describe the problem in as much detail as possible without over doing it. I find providing less detail ends up in a to and fro until the actual problem is nailed. Too much detail (and stressing the important words) can be insulting as apparently I was. For that I apologise.

As to standard password complexity rules. Apart from length and ruling out the most obvious bad passwords I subscribe to this line of thought.
https://xkcd.com/936/

@DeveloperChris:

Regarding your screenshots: Could you try to reproduce this situation in current git version? I tried and I couldn't.

Regarding passwords in emails: I agree with you about sending passwords in emails is not a good practice. In fact, I think the best option is not an one time password but a temporal URL to set a valid password. I just wanted to show you some workarounds for current version. You can prevent LimeSurvey to send password and use an alternative to emails or you can just force using LDAP as we do in our organization (in 2.06, this will be possible without code modifications).

Regarding one time password functionality: Sorry, I have never tried. No time to analyse it these days.

Regarding password complexity: I agree with you and xkcd. But there is at least a validation that could be done in every scenario: Preventing very short passwords. The ideal solution should be a way to configure validations. Every LimeSurvey administrator could choose for his instance.

Regarding your excuses: Thanks, accepted. Sorry if I was rude using the word "speech". As another regular user, thanks a lot for trying to improve LimeSurvey. Perhaps splitting your suggestions in different bug reports and closing this one would be a good idea.

I used git clone

No difference. Still the same as shown in my uploaded images

I thought perhaps it was because the user was assigned to the same surveys as the other users.

So I removed the user in question from all surveys. No difference I am afraid.

Not sure why you are seeing different from me. Perhaps the DB? Ours was a fresh install of build 141126. It wasn't an upgrade from a previous version.

Unfortunately we cannot use LDAP.

I have just done some debugging. It appears the application is working as designed which is a bit of an issue for me.

The reason why the users are showing up in the list is because they are in the same group (didn't think about that when doing my tests above).

The definition of usercontrolSameGroupPolicy only allows for show all in same group or show all regardless whereas I would prefer to see show group, show none or show all.

For user list : usercontrolSameGroupPolicy

It's done for this. Super admin always see all users.

But : actually in 2.06 : we can extend User Permission, then show/hide some user.

@aesteaban : i can take the "user form" system , adding New password system.

I move it to Feature request for 2 things:

• LS is used more in "one entreprise" with some client, client have access to survey but not to user management, then usercontrolSameGroupPolicy does the trick.
• For security : i already used one LimeSurvey with different DB and upload dir for each client. Usage of config.php depend on webserver name and go on.

PS2: LS3 DBAuthPlugin can be deactivated and replaced by something else. Then wait for LS3 seems better.

@DenisChenu: In fact, this issue is assigned to me because I answered to initial comment. You can take whatever part of this issue you like. IMHO this issue should be closed. I have created two feature requests for issues treated here: 09598 and 09599. The only remaining issue treated just here is usercontrolSameGroupPolicy one but I think this is not a bug.

"i already used one LimeSurvey with different DB and upload dir for each client. Usage of config.php depend on webserver name and go on."

For maximum security I host a completely separate instance. but for the rest we are a large Gov Dept with many sub departments sometimes with common users having a separate instance or even just DB is not feasable.

I think its correct to make this feature requests, Not so much a bug as more "doesn't suit all use cases"..

@DeveloperChris: Like asteban say : thig bug/feature is not clear. 3 problem (or more) in one report.

One is here : http://bugs.limesurvey.org/view.php?id=9599 (for one time password User create)
Open another if needed.

I can confirm the issue : 3/ Survey admins can see all users and groups in Survey Security settings.

@DeveloperChris: I close this one , please :
1: report the usercontrolSameGroupPolicy bug
2: report a feature (or strong support a featire) for password generation
3: report a feature for password updating

This bug report neeed different fix, then different bug report.