maxctrl alter user fails to process purely numeric passwords, resulting in "No password provided" error

The maxctrl command-line utility fails to correctly parse the password argument when it consists entirely of digits (e.g., 123456). Instead of treating the input as a string, the parser likely misinterprets it as a numeric index or an invalid argument, resulting in an API request with a missing password attribute.

Steps to Reproduce:
========

Create a user:
maxctrl create user testuser temp_pass --type=admin

Attempt to change the password to a numeric-only value:
maxctrl alter user testuser 7654321

Actual Result: The command fails with a 400 Bad Request from the REST API:

JSON

{

    "errors": [

        {

            "detail": "No password provided"

        }

    ]

}

Note: The same command works if an alphabet character is added (e.g., a7654321).

Ex:

[root@maxscale ~]# maxctrl --version

24.02.8

[root@maxscale ~]# maxctrl create user testuser temp_pass --type=admin

OK

[root@maxscale ~]# maxctrl alter user testuser 7654321

Error: Server at http://127.0.0.1:8989 responded with 400 Bad Request to `PATCH users/inet/testuser`

{

    "errors": [

        {

            "detail": "No password provided"

        }

    ]

}

Expected Result: The maxctrl tool should treat any value in the second argument position as a literal string and pass it to the password attribute in the JSON payload, regardless of whether it contains only numbers.

Workaround: Users must bypass the high-level alter user command and use the raw API patch method:

maxctrl api patch users/inet/testuser '{"data":{"type":"users","attributes":{"password":"7654321"}}}'

Suggested Fix:
Update the maxctrl argument parser logic to explicitly cast the password argument to a string type before constructing the REST API payload.