Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Password change field should be disabled, if password change is disabled #1436

Closed
phriedrich opened this issue Dec 4, 2019 · 12 comments
Closed

Comments

@phriedrich
Copy link
Contributor

  • Your Rocket.Chat Experimental app version: 1.25.0.12983
  • Your Rocket.Chat server version: 2.3.0
  • Device (or Simulator) you're running with: iPad w/ iPad OS 13.2.3

We get the user information via LDAP and disabled the option to change the user's password within Rocket.Chat.

On the web version, the password change field in the user's profile settings is correctly disabled and can not be selected.

In the app I can (try) to set a new password, at least I can select the field and write something. The field should be disabled if the option is not enabled.

Password change field

@ankar84
Copy link
Contributor

ankar84 commented Dec 6, 2019

Same case, and I totally agree with that issue!
Please fix it.

@diegolmello
Copy link
Member

That setting is not implemented on the app yet.

@phriedrich
Copy link
Contributor Author

phriedrich commented Dec 19, 2019

Note:

With the /api/v1/settings.public endpoint we can get the information, which data are allowed to edit. Some of them we should probably check and use to limit what the user can edit:

  • Accounts_AllowPasswordChange
  • Accounts_AllowRealNameChange
  • Accounts_AllowUserAvatarChange
  • Accounts_AllowUserProfileChange
  • Accounts_AllowUsernameChange

For example it's also possible that it is not allowed to change the email address or the username.

@devyaniChoubey
Copy link
Contributor

Can I work on it?

@phriedrich
Copy link
Contributor Author

Sure, would be really nice to have this fixed.

@Prateek93a
Copy link
Contributor

@phriedrich @devyaniChoubey If work is not being done on this, can I take this up?

@phriedrich
Copy link
Contributor Author

@Prateek93a I'm not working on this, but I don't know if @devyaniChoubey did some work already.

This ticket is also related to #1590, probably both could be fixed with one PR.

@Prateek93a
Copy link
Contributor

@phriedrich Yes, #1590 will also be fixed in the similar way. In the same PR, all the above mentioned permissions can be checked and implemented accordingly. Thanks
@devyaniChoubey Are you working on this? If not, can I take it up?

@devyaniChoubey
Copy link
Contributor

devyaniChoubey commented Jan 19, 2020

@Prateek93a Yes I am working on it. I will soon create a PR.I will try to do it by today.

@Prateek93a
Copy link
Contributor

@devyaniChoubey Ok, Great.

@phriedrich
Copy link
Contributor Author

@devyaniChoubey Any updates on this?

@phriedrich
Copy link
Contributor Author

This has been solved with the mentioned PR.

Many thanks to everyone involved, especially @tanmoyopenroot and @diegolmello!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

5 participants