🔒 feat: password reset disable option; fix: account email error message

[berry-13]

Summary

feat: Implement a disable option for password reset

fix: Resolve the error message regarding incorrect account email

Change Type

• [x] Bug fix (non-breaking change which fixes an issue)
• [x] New feature (non-breaking change which adds functionality)
• [x] Documentation update

Testing

Checklist

• [x] My code adheres to this project's style guidelines
• [x] I have performed a self-review of my own code
• [x] I have commented in any complex areas of my code
• [x] I have made pertinent documentation changes
• [x] My changes do not introduce new warnings
• [x] I have written tests demonstrating that my changes are effective or that my feature works
• [x] Local unit tests pass with my changes
• [x] Any changes dependent on mine have been merged and published in downstream modules.
• [x] New documents have been locally validated with mkdocs

[XHyperDEVX]

Will only the option to reset the password be deactivated here or will the "Reset password" option also disappear from the UI?

[berry-13]

Will only the option to reset the password be deactivated here or will the "Reset password" option also disappear from the UI?

wdym exactly? this disable the password reset from both frontend and backend

[XHyperDEVX]

i mean if this hyperlink also disappears or if when you click on it only the message "password reset disabled" is displayed (because i only saw this in the code)

[berry-13]

i mean if this hyperlink also disappears or if when you click on it only the message "password reset disabled" is displayed (because i only saw this in the code)

no no, also that button disappears when disabling the reset password

[danny-avila]

@Berry-13 tests failing?

[danny-avila]

@Berry-13 Adjusting the existing, failing tests to match the new behavior looks pretty simple. Please work on this when you get the chance.

[danny-avila]

@ohneda I removed the eslint import/order rule in this PR. I noticed since that PR was merged, there has been a noticeable slowdown when saving files, likely due to eslint processing. Also, it was still not ordering it as desired, so it didn't seem worth to include.

[danny-avila]

It's enough to update the contributing page:

7. Module Import Conventions

• npm packages first,

  • from shortest line (top) to longest (bottom)

• Followed by typescript types (pertains to data-provider and client workspaces)

  • longest line (top) to shortest (bottom)
  • types from package come first

• Lastly, local imports

  • longest line (top) to shortest (bottom)
  • imports with alias ~ treated the same as relative import with respect to line length

[ohneda]

@ohneda I removed the eslint import/order rule in this PR. I noticed since that PR was merged, there has been a noticeable slowdown when saving files, likely due to eslint processing. Also, it was still not ordering it as desired, so it didn't seem worth to include.

ok, no problem. Thank you for letting me know!