lorthirk/kapua

Min Password Value Saved Although too Short

Opened this issue · 3 comments

If user enters min password length < 12, Kapua reports an error, and the value is not saved.
But if user changes view to e.g. UserService and comes back, you can see that the value is saved.

Nevertheless, when you navigate to different view (e.g. Tags or Endpoints) and then return, the previous vald value is set in the box.
This should be fixed.

Testflow:

  1. Login as kapua-sys
  2. Go to Accounts, create an account (e.g. acco0)
  3. Select acc0, go to Account settings, enter e.g. "1" int he min password length
  4. Close the error, navigate to e.g. TagService or UserService inside this account settings, discard changes
  5. Return back to that field - observe the number - it stays at "1"
  6. Change views to e.g. Enpoints and then return - observe the filed once again - it is set to previous valid value

Expected behavior
Value should not (even implicitly) be saved if it does not meet the minimum requirements.

Screenshots
Screenshot 2020-10-28 at 10 05 30

Version of Kapua
https://github.com/lorthirk/kapua/tree/feature-configurablePasswordLength

Type of deployment
[ ] Local Vagrant deployment
[x] Docker
[ ] Openshift (in its variants)
[ ] Others

Main component affected
[x] Console (in case of console please report info on which browser you encountered the problem)
[ ] REST API -> did not try rest api!!! -> please check!
[ ] Message Broker
[ ] - Others

Additional context
Add any other context about the problem here.

Hey @lorthirk,
I have checked this and the problem persists in the latest commit.

Ok, I managed to reproduce this, and it happens with other services as well. Here's a test case for UserService:

  1. create an account (e.g. acc0)
  2. set infiniteChildUsers to true for account acc0
  3. create a user in acc0
  4. try to set infiniteChildUser to false
  5. observe error
  6. try to navigate to another service, discarding changes
  7. navigate back to UserService: infiniteChildUsers is still false, while it should be true

So I would treat this as a separate issue, to be fixed in the Account Configuration component itself